From nobody Wed Oct 1 02:38:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC791ACD8E for ; Wed, 1 Oct 2014 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.635 X-Spam-Level: *** X-Spam-Status: No, score=3.635 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnPD2Reqc5St for ; Wed, 1 Oct 2014 02:38:35 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBFD1AC7E7 for ; Wed, 1 Oct 2014 02:38:34 -0700 (PDT) Received: from 10.236.62.155 (EHLO OPE10HT07.tp.gk.corp.tepenet) ([10.236.62.155]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id COA14549; Wed, 01 Oct 2014 11:38:11 +0200 (CEST) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+IfJWdndvPc0W8NTzcZ4VQIJwIh4kAgAeEHQCAAAKgAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaa4CAAQJyAIAB8XFwgAJ16YCABToFsA== Date: Wed, 1 Oct 2014 09:37:52 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F8A7A7@OPE10MB05.tp.gk.corp.tepenet> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745F8A7A7OPE10MB05tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.10.1.92119:17:8.317, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __URI_NO_WWW, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __HTML_FONT_BLUE, __HAS_HTML, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, WEBMAIL_SOURCE, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0207.542BCB84.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0207.542BCB84.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b21e99559804b25f5713c1d1a2f2b032 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8OccMZtbNzL5YwGATRYjT8BLDzU Cc: "v6ops@ietf.org WG" , "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , Tore Anderson , Kossut Tomasz - Hurt Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 09:38:40 -0000 --_000_2D29C51862222E49B991EF64EEB0B5B745F8A7A7OPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cDovL2ZvcnVtLmVhLmNvbS9lYWZvcnVtL3Bvc3RzL2xpc3QvOTc0MTIyOS5wYWdlDQoNCm1h eWJlIGlzIG1vcmUgYXBwbGljYXRpb24gbGlrZSB0aGlzIGFib3ZlLg0KDQpCUiwNCk1jeg0KDQoN CkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6 IFN1bmRheSwgU2VwdGVtYmVyIDI4LCAyMDE0IDU6NDcgQU0NClRvOiBDemVyd29ua2EgTWljaGHF giAxIC0gSHVydA0KQ2M6IEhlYXRsZXksIE5pY2s7IFRvcmUgQW5kZXJzb247IE1ldHNjaHVsYXQs IEhvbGdlciAoaG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZSk7IGRyYWZ0LXdhbmctdjZvcHMt eGxhdC1wcmVmaXgtZGlzY292ZXJ5QHRvb2xzLmlldGYub3JnOyB2Nm9wc0BpZXRmLm9yZyBXRzsg S29zc3V0IFRvbWFzeiAtIEh1cnQNClN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJh ZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnkNCg0KQ2FuIHlvdSBwcm92aWRlIGV4 YW1wbGVzIG9mIHdoYXQgZG9lcyBub3Qgd29yayB3aXRoIEROUzY0Pw0KDQpJbiBmYWN0LCB0aGF0 IHdvdWxkIGJlIHVzZWZ1bCB0byBkb2N1bWVudCBpbiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 Lg0KDQpPbiBGcmksIFNlcCAyNiwgMjAxNCBhdCA5OjE3IFBNLCBDemVyd29ua2EgTWljaGHFgiAx IC0gSHVydCA8TWljaGFsLkN6ZXJ3b25rYTFAb3JhbmdlLmNvbTxtYWlsdG86TWljaGFsLkN6ZXJ3 b25rYTFAb3JhbmdlLmNvbT4+IHdyb3RlOg0KT1BMIHVzZSBBUE4gSVB2Ni1vbmx5IGZvciBhbGwg c2VydmljZXMgd2UgaGF2ZSwgYnV0IHNvbWUgbW9iaWxlIG9wZXJhdG9ycyB1c2UgZGlmZmVyZW50 IEFQTiBmb3IgdGV0aGVyaW5nLiBXaHkgPw0KDQppZiB3ZSBhcHBseSB0aGUgYXJjaGl0ZWN0dXJl IENMQVQrUExBVCtETlMgd2UgY2FuIGFjaGlldmUgcXVhbGl0eSBvZiBzZXJ2aWNlIGxpa2UgaW4g RFMsIHdpdGggRE5TNjQgTk9ULg0KDQpCUiwNCk1jeg0KDQo= --_000_2D29C51862222E49B991EF64EEB0B5B745F8A7A7OPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6Ilp3eWvFgnkgdGVrc3QgWm5hayI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSBabmFrIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxl LW5hbWU6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQpzcGFuLlN0eWx3aWFkb21vY2llLW1h aWwxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5ad3lreXRla3N0Wm5h aw0KCXttc28tc3R5bGUtbmFtZToiWnd5a8WCeSB0ZWtzdCBabmFrIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Ilp3eWvFgnkgdGVrc3QiOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJQTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cDovL2Zv cnVtLmVhLmNvbS9lYWZvcnVtL3Bvc3RzL2xpc3QvOTc0MTIyOS5wYWdlIj5odHRwOi8vZm9ydW0u ZWEuY29tL2VhZm9ydW0vcG9zdHMvbGlzdC85NzQxMjI5LnBhZ2U8L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5tYXliZSBpcyBtb3JlIGFwcGxpY2F0aW9uIGxpa2UgdGhpcyBhYm92ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NY3o8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIFNlcHRlbWJlciAyOCwgMjAxNCA1OjQ3IEFNPGJyPg0K PGI+VG86PC9iPiBDemVyd29ua2EgTWljaGHFgiAxIC0gSHVydDxicj4NCjxiPkNjOjwvYj4gSGVh dGxleSwgTmljazsgVG9yZSBBbmRlcnNvbjsgTWV0c2NodWxhdCwgSG9sZ2VyIChob2xnZXIubWV0 c2NodWxhdEB0ZWxla29tLmRlKTsgZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3Zl cnlAdG9vbHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnIFdHOyBLb3NzdXQgVG9tYXN6IC0gSHVy dDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXdhbmct djZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2FuIHlvdSBwcm92aWRlIGV4YW1wbGVzIG9mIHdoYXQgZG9lcyBub3Qgd29yayB3 aXRoIEROUzY0PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gZmFjdCwgdGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8gZG9jdW1lbnQgaW4gYW4gaW5mb3JtYXRp b25hbCBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMjYsIDIwMTQgYXQgOToxNyBQTSwgQ3plcndvbmthIE1p Y2hhxYIgMSAtIEh1cnQgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWwuQ3plcndvbmthMUBvcmFu Z2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFsLkN6ZXJ3b25rYTFAb3JhbmdlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T1BMIHVzZSBB UE4gSVB2Ni1vbmx5IGZvciBhbGwgc2VydmljZXMgd2UgaGF2ZSwgYnV0IHNvbWUgbW9iaWxlIG9w ZXJhdG9ycyB1c2UgZGlmZmVyZW50IEFQTiBmb3IgdGV0aGVyaW5nLiBXaHkgPzxicj4NCjxicj4N CmlmIHdlIGFwcGx5IHRoZSBhcmNoaXRlY3R1cmUgQ0xBVCYjNDM7UExBVCYjNDM7RE5TIHdlIGNh biBhY2hpZXZlIHF1YWxpdHkgb2Ygc2VydmljZSBsaWtlIGluIERTLCB3aXRoIEROUzY0IE5PVC48 YnI+DQo8YnI+DQpCUiw8YnI+DQpNY3ogPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_2D29C51862222E49B991EF64EEB0B5B745F8A7A7OPE10MB05tpgkco_-- From nobody Wed Oct 1 09:52:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEAF1ACE84 for ; Wed, 1 Oct 2014 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDQmvVwfeSef for ; Wed, 1 Oct 2014 09:52:54 -0700 (PDT) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id EFB6A1ACE7B for ; Wed, 1 Oct 2014 09:52:53 -0700 (PDT) Received: (qmail 24166 messnum 5485339 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 1 Oct 2014 16:52:51 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mail09.svc.cra.dublin.eircom.net (qp 24166) with SMTP; 1 Oct 2014 16:52:51 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id xssn1o00J0mJ9Tz01ssqJ5; Wed, 01 Oct 2014 17:52:51 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_5606D7BD-0C2E-42BE-96AF-1D56FCBF41C9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745F8A7A7@OPE10MB05.tp.gk.corp.tepenet> Date: Wed, 1 Oct 2014 17:52:40 +0100 Message-Id: <72D3BE66-C5D2-4DF2-895B-3030245ABEF6@eircom.net> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> <2D29C51862222E49B991EF64EEB0B5B745F8A7A7@OPE10MB05.tp.gk.corp.tepenet> To: =?utf-8?Q?Czerwonka_Micha=C5=82_1_-_Hurt?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/owqZ-t2NMMzLcx6_LHEJ4w2GxUg Cc: "v6ops@ietf.org WG" , Tore Anderson , "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , Kossut Tomasz - Hurt Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:52:56 -0000 --Apple-Mail=_5606D7BD-0C2E-42BE-96AF-1D56FCBF41C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is this an issue only seen from tethered hosts in the 64share/RFC 7278 = case or have you also seen apps on the UE with the problem? BR Ross On 1 Oct 2014, at 10:37, Czerwonka Micha=C5=82 1 - Hurt = wrote: > http://forum.ea.com/eaforum/posts/list/9741229.page > =20 > maybe is more application like this above. > =20 > BR, > Mcz > =20 > =20 > From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Sent: Sunday, September 28, 2014 5:47 AM > To: Czerwonka Micha=C5=82 1 - Hurt > Cc: Heatley, Nick; Tore Anderson; Metschulat, Holger = (holger.metschulat@telekom.de); = draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org = WG; Kossut Tomasz - Hurt > Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery > =20 > Can you provide examples of what does not work with DNS64? > =20 > In fact, that would be useful to document in an informational = document. > =20 > On Fri, Sep 26, 2014 at 9:17 PM, Czerwonka Micha=C5=82 1 - Hurt = wrote: > OPL use APN IPv6-only for all services we have, but some mobile = operators use different APN for tethering. Why ? >=20 > if we apply the architecture CLAT+PLAT+DNS we can achieve quality of = service like in DS, with DNS64 NOT. >=20 > BR, > Mcz > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_5606D7BD-0C2E-42BE-96AF-1D56FCBF41C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Is = this an issue only seen from tethered hosts in the 64share/RFC 7278 case = or have you also seen apps on the UE with the = problem?

BR
Ross

On = 1 Oct 2014, at 10:37, Czerwonka Micha=C5=82 1 - Hurt <Michal.Czerwonka1@orange.com<= /a>> wrote:

 
maybe is more application like = this above.
 
BR,
Mcz
 
 
From: Lorenzo Colitti [mailto:lorenzo@google.com] 
Sent: Sunday, September 28, 2014 = 5:47 AM
To: Czerwonka Micha=C5=82 1 - = Hurt
Cc: Heatley, Nick; Tore = Anderson; Metschulat, Holger (holger.metschulat@telekom.de<= /a>); draf= t-wang-v6ops-xlat-prefix-discovery@tools.ietf.org; v6ops@ietf.org WG; Kossut Tomasz - = Hurt
Subject: Re: [v6ops] new draft: = draft-wang-v6ops-xlat-prefix-discovery
 
Can you provide examples of what does not work with = DNS64?
 
In = fact, that would be useful to document in an informational = document.
 
On = Fri, Sep 26, 2014 at 9:17 PM, Czerwonka Micha=C5=82 1 - Hurt <Michal.Czerwonka1@orange.com> = wrote:
OPL use APN = IPv6-only for all services we have, but some mobile operators use = different APN for tethering. Why ?

if we apply the architecture = CLAT+PLAT+DNS we can achieve quality of service like in DS, with DNS64 = NOT.

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

= --Apple-Mail=_5606D7BD-0C2E-42BE-96AF-1D56FCBF41C9-- From nobody Wed Oct 1 12:00:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221381A7023 for ; Wed, 1 Oct 2014 12:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_khLdZ77Ipl for ; Wed, 1 Oct 2014 12:00:50 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A038D1A1BFC for ; Wed, 1 Oct 2014 12:00:47 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so682197pdi.5 for ; Wed, 01 Oct 2014 12:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7/u7Smll4V+zsdRdDipCTmuQNpAQNa2pSpgWHIPjx64=; b=jBXIvUK1TFNgydZQRurTw62UBz2ZhJ02tXQ616UGXua01q7HdTkTIc4tyB0BeGZh5o IVCpR7gOedY1OQkLnm8ERRJvvZQG+SjZjQiZwELBPM/Qadif7Wep0fA0bsS9EM6dUUj7 GJS0zitoK/RSe9NeIOTHfeUZ50BtAUTSSYWUkka4+KAfFm99KurVhI8kwfelJdRibEo5 +Vl1LqZL3HH8m9Tr+Q+eHgfwJtRZP6m7sDpYZgpx5pHrE6aNFJu/ie9V6TSKzjFnLjCd yydxumeX/WV8q52Hq5eIaiVvrPIn9oem2qoak8fU1NX80BaL9Nf4z8X0ydlAYElwH5Hr a2EQ== X-Received: by 10.68.96.4 with SMTP id do4mr81785526pbb.44.1412190047190; Wed, 01 Oct 2014 12:00:47 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id va2sm1692536pac.15.2014.10.01.12.00.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 12:00:46 -0700 (PDT) Message-ID: <542C4F5C.30704@gmail.com> Date: Thu, 02 Oct 2014 08:00:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <542A36AC.9030203@gont.com.ar> In-Reply-To: <542A36AC.9030203@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E7c073YJiRNrzWp5I3dmHRGBRxY Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:00:52 -0000 fwiw I think this is very useful information and should be polished and published. I have no strong opinion whether it should be published via v6ops or as an Independent Submission RFC. Regards Brian On 30/09/2014 17:50, Fernando Gont wrote: > Folks, > > Earlier in September we published a revision of our I-D "IPv6 Extension > Headers in the Real World" > (). > > At this point in time, we're interested in knowing whether our I-D is of > value for the IPv6 ops community, such that we can decide whether to > continue working/improving it. Additionally, if there's anything you > think we've missed in the document, we'd like to hear from you. > > Overall, our I-D is meant to provide a reality-check with respect to the > issues surrounding IPv6 Extension Headers and their use on the public > Internet. More specifically, its goals are: > > 1) Provide data regarding support of IPv6 EHs in the real world. > > This is interesting data to refer people to (e.g., folks > developing protocols) regarding the extent to which IPv6 EHs > are usable on the public Internet (at least with web, mail, and > name servers). > > > 2) Summarize the issues associated with IPv6 EHs (performance, security, > etc.) > > This is of use for folks concerned with the issues surrounding > IPv6 EHs, and covers practical issues. > > > 3) Summarizes the implications of the aforementioned filtering. > > For example, if you're designing a protocol that is meant to > work on the public Internet, you may want to provide some fall-back > mechanism that does not employ IPv6 EHs. > > Yet another of the implications is the security issue that has > been discussed on-list: if e.g. IPv6 fragments are dropped and you > can be tricked into generating them, you may be subject to a DoS > attack. > > > 4) Flag possible further work > > Here we try to flag areas where the further work may be needed, > such as adding fall-back mechanisms to some existing protocols, > or avoiding the use of IPv6 EHs where possible. > > > Thanks! > > Best regards, From nobody Wed Oct 1 13:33:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0CB1A8788 for ; Wed, 1 Oct 2014 13:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8oBUNkJ0Qat for ; Wed, 1 Oct 2014 13:33:32 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710E41A8785 for ; Wed, 1 Oct 2014 13:33:32 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so1558874wgh.9 for ; Wed, 01 Oct 2014 13:33:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8xHKoqA1qAdPoTAU8h9m7KAtHtBinrV196H935aQGMo=; b=TCru6UTzDhDkU9ZBYI9NtNVK7HsdIbj5Ulu/53zs5fdLOn4bjYYrCThZWF9Iz/0TTb o53EUNrR748GB0fPoSlUx6TsQXiHTcipUrMD6W0OTujyebEYB5bJEXw7zshwq+7sPkEF ansupAf3GMLDlwkeLJQ+DBMj6mPp2IUandB7nEUlSkfaVAIcQbrCdSvJWcGmT9JNwFVu PKlb7mCwpuYUAju+w8MfgiQ/5J4TNKxTZ510+7M9HN4cUICb0gr+M3vf3ynqAWyyLOwZ iZZlspwg9uzb52EN2XcLjjGKG1hVzmLpVGknCjj+gtxVtnRMJYmLsEv+YT9CCMragumE JoBA== X-Gm-Message-State: ALoCoQmWRn2+snkrGYJCQdTwiBWLu4+UPJFsAX3aA4uHM2lWOtkENc6tauyhFAZlHhUR0d+ocTdM MIME-Version: 1.0 X-Received: by 10.194.237.164 with SMTP id vd4mr64452070wjc.46.1412195610985; Wed, 01 Oct 2014 13:33:30 -0700 (PDT) Received: by 10.194.119.233 with HTTP; Wed, 1 Oct 2014 13:33:30 -0700 (PDT) In-Reply-To: <542A36AC.9030203@gont.com.ar> References: <542A36AC.9030203@gont.com.ar> Date: Wed, 1 Oct 2014 16:33:30 -0400 Message-ID: From: Warren Kumari To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZIeOdsYmFsbX3k2M6a6sBHhxTgE Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:33:39 -0000 On Tue, Sep 30, 2014 at 12:50 AM, Fernando Gont wrote: > Folks, > > Earlier in September we published a revision of our I-D "IPv6 Extension > Headers in the Real World" > (). > > At this point in time, we're interested in knowing whether our I-D is of > value for the IPv6 ops community, such that we can decide whether to > continue working/improving it. Yes please! Burying our heads in the sand and pretending that they all work fine in no way helps with V6 deployment. Having users and operators get burnt because they didn't know about issues with EH simply leads to people turning off v6 - once bitten, twice shy... W > Additionally, if there's anything you > think we've missed in the document, we'd like to hear from you. > > Overall, our I-D is meant to provide a reality-check with respect to the > issues surrounding IPv6 Extension Headers and their use on the public > Internet. More specifically, its goals are: > > 1) Provide data regarding support of IPv6 EHs in the real world. > > This is interesting data to refer people to (e.g., folks > developing protocols) regarding the extent to which IPv6 EHs > are usable on the public Internet (at least with web, mail, and > name servers). > > > 2) Summarize the issues associated with IPv6 EHs (performance, security, > etc.) > > This is of use for folks concerned with the issues surrounding > IPv6 EHs, and covers practical issues. > > > 3) Summarizes the implications of the aforementioned filtering. > > For example, if you're designing a protocol that is meant to > work on the public Internet, you may want to provide some fall-back > mechanism that does not employ IPv6 EHs. > > Yet another of the implications is the security issue that has > been discussed on-list: if e.g. IPv6 fragments are dropped and you > can be tricked into generating them, you may be subject to a DoS > attack. > > > 4) Flag possible further work > > Here we try to flag areas where the further work may be needed, > such as adding fall-back mechanisms to some existing protocols, > or avoiding the use of IPv6 EHs where possible. > > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Oct 1 13:41:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37AD1A7023 for ; Wed, 1 Oct 2014 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaCJmeQy636X for ; Wed, 1 Oct 2014 13:40:58 -0700 (PDT) Received: from Mail.Yoyodyne.COM (Mail.Yoyodyne.com [69.36.251.10]) by ietfa.amsl.com (Postfix) with SMTP id 5ABCA1A8546 for ; Wed, 1 Oct 2014 13:40:58 -0700 (PDT) Received: from [192.168.66.110] ([208.76.186.125]) by Mail.Yoyodyne.COM via Internet for (and others); Wed, 1 Oct 2014 13:40:53 PDT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Wed, 1 Oct 2014 13:40:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04C50271-D4F6-4A78-B588-DF8C1E5C52D9@merike.com> References: <542A36AC.9030203@gont.com.ar> To: Warren Kumari X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/u8564kfB-KW68gW-6P97vTlspd4 Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:41:01 -0000 On Oct 1, 2014, at 1:33 PM, Warren Kumari wrote: > On Tue, Sep 30, 2014 at 12:50 AM, Fernando Gont = wrote: >> Folks, >>=20 >> Earlier in September we published a revision of our I-D "IPv6 = Extension >> Headers in the Real World" >> = (). >>=20 >> At this point in time, we're interested in knowing whether our I-D is = of >> value for the IPv6 ops community, such that we can decide whether to >> continue working/improving it. >=20 > Yes please! >=20 > Burying our heads in the sand and pretending that they all work fine > in no way helps with V6 deployment. >=20 > Having users and operators get burnt because they didn't know about > issues with EH simply leads to people turning off v6 - once bitten, > twice shy=85 Might I may a recommendation to also include IPsec wg for some of this = discussion and/or mobility groups. They are the *only* EH that I know that in the real world might = actually be used. Most specifically the RH EH Type2 that's used in mobile environments and then = the AH/ESP for IPsec. You may want reach *customers* who are not necessarily 'operators' who = are utilizing the EHs. Just a suggestion :) The biggest PITA for all vendors are EH=85.it's my = litmus test for all vendors to see if they REALLY have an IPv6 implementation. =20 Caveat - I haven't kept up with this work=85.will try and read latest = draft in next few days - merike >=20 > W >=20 >> Additionally, if there's anything you >> think we've missed in the document, we'd like to hear from you. >>=20 >> Overall, our I-D is meant to provide a reality-check with respect to = the >> issues surrounding IPv6 Extension Headers and their use on the public >> Internet. More specifically, its goals are: >>=20 >> 1) Provide data regarding support of IPv6 EHs in the real world. >>=20 >> This is interesting data to refer people to (e.g., folks >> developing protocols) regarding the extent to which IPv6 EHs >> are usable on the public Internet (at least with web, mail, and >> name servers). >>=20 >>=20 >> 2) Summarize the issues associated with IPv6 EHs (performance, = security, >> etc.) >>=20 >> This is of use for folks concerned with the issues surrounding >> IPv6 EHs, and covers practical issues. >>=20 >>=20 >> 3) Summarizes the implications of the aforementioned filtering. >>=20 >> For example, if you're designing a protocol that is meant to >> work on the public Internet, you may want to provide some = fall-back >> mechanism that does not employ IPv6 EHs. >>=20 >> Yet another of the implications is the security issue that has >> been discussed on-list: if e.g. IPv6 fragments are dropped and you >> can be tricked into generating them, you may be subject to a DoS >> attack. >>=20 >>=20 >> 4) Flag possible further work >>=20 >> Here we try to flag areas where the further work may be needed, >> such as adding fall-back mechanisms to some existing protocols, >> or avoiding the use of IPv6 EHs where possible. >>=20 >>=20 >> Thanks! >>=20 >> Best regards, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Oct 1 15:36:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957441A87CC for ; Wed, 1 Oct 2014 15:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSJDamvGZJl9 for ; Wed, 1 Oct 2014 15:36:00 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3A01A87CA for ; Wed, 1 Oct 2014 15:36:00 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s91MZYUd012639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 15:35:34 -0700 (PDT) Message-ID: <542C81B7.10601@isi.edu> Date: Wed, 01 Oct 2014 15:35:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , IPv6 Operations References: <542A36AC.9030203@gont.com.ar> In-Reply-To: <542A36AC.9030203@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nKnvxDnkkmAy5JqFZgSt7d2wI6Q Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:36:01 -0000 There is no need for multiple documents on this topic. This information should be rolled into draft-gont-opsec-ipv6-eh-filtering-02 Joe On 9/29/2014 9:50 PM, Fernando Gont wrote: > Folks, > > Earlier in September we published a revision of our I-D "IPv6 Extension > Headers in the Real World" > (). > > At this point in time, we're interested in knowing whether our I-D is of > value for the IPv6 ops community, such that we can decide whether to > continue working/improving it. Additionally, if there's anything you > think we've missed in the document, we'd like to hear from you. > > Overall, our I-D is meant to provide a reality-check with respect to the > issues surrounding IPv6 Extension Headers and their use on the public > Internet. More specifically, its goals are: > > 1) Provide data regarding support of IPv6 EHs in the real world. > > This is interesting data to refer people to (e.g., folks > developing protocols) regarding the extent to which IPv6 EHs > are usable on the public Internet (at least with web, mail, and > name servers). > > > 2) Summarize the issues associated with IPv6 EHs (performance, security, > etc.) > > This is of use for folks concerned with the issues surrounding > IPv6 EHs, and covers practical issues. > > > 3) Summarizes the implications of the aforementioned filtering. > > For example, if you're designing a protocol that is meant to > work on the public Internet, you may want to provide some fall-back > mechanism that does not employ IPv6 EHs. > > Yet another of the implications is the security issue that has > been discussed on-list: if e.g. IPv6 fragments are dropped and you > can be tricked into generating them, you may be subject to a DoS > attack. > > > 4) Flag possible further work > > Here we try to flag areas where the further work may be needed, > such as adding fall-back mechanisms to some existing protocols, > or avoiding the use of IPv6 EHs where possible. > > > Thanks! > > Best regards, > From nobody Wed Oct 1 15:45:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462D1A87CC for ; Wed, 1 Oct 2014 15:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbjTBLeqSeY3 for ; Wed, 1 Oct 2014 15:45:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339691A87D4 for ; Wed, 1 Oct 2014 15:45:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s91MiqBR031270; Wed, 1 Oct 2014 23:44:52 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s91MiqBR031270 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1412203493; bh=MU0QaIB3vgGcSEqIxy8cxvwh0bY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=PnOZQj1ThCNyYFrGBzGuS5hPL5Ae+XKnH9yyQmi7XtLwvOFizSKB4P2vP1WfkVnj5 OEikvkSoqHfhppBqhGUFcXCZ8Tgc5oNIGxQTHBVmmyArxEjrvZ3zoDdjCY+s4bnycE fR2VoY5agLJBbiOvZY5bhgdNXAVJ1gjDNllmvl18= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q90Niq2875612547gs ret-id none; Wed, 01 Oct 2014 23:44:53 +0100 Received: from [192.168.1.112] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s91MiiZW000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 23:44:44 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tim Chown X-Mailer: iPhone Mail (12A405) In-Reply-To: <542C81B7.10601@isi.edu> Date: Wed, 1 Oct 2014 23:44:43 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> To: Joe Touch X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q90Niq287561254700; tid=q90Niq2875612547gs; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s91MiqBR031270 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0Uq_U9IVGGjQAOPMIVkCKtEa43I Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:45:04 -0000 I'd argue a separate 'problem statement' is a better approach. -- Tim > On 1 Oct 2014, at 23:35, Joe Touch wrote: > > There is no need for multiple documents on this topic. This information > should be rolled into draft-gont-opsec-ipv6-eh-filtering-02 > > Joe > >> On 9/29/2014 9:50 PM, Fernando Gont wrote: >> Folks, >> >> Earlier in September we published a revision of our I-D "IPv6 Extension >> Headers in the Real World" >> (). >> >> At this point in time, we're interested in knowing whether our I-D is of >> value for the IPv6 ops community, such that we can decide whether to >> continue working/improving it. Additionally, if there's anything you >> think we've missed in the document, we'd like to hear from you. >> >> Overall, our I-D is meant to provide a reality-check with respect to the >> issues surrounding IPv6 Extension Headers and their use on the public >> Internet. More specifically, its goals are: >> >> 1) Provide data regarding support of IPv6 EHs in the real world. >> >> This is interesting data to refer people to (e.g., folks >> developing protocols) regarding the extent to which IPv6 EHs >> are usable on the public Internet (at least with web, mail, and >> name servers). >> >> >> 2) Summarize the issues associated with IPv6 EHs (performance, security, >> etc.) >> >> This is of use for folks concerned with the issues surrounding >> IPv6 EHs, and covers practical issues. >> >> >> 3) Summarizes the implications of the aforementioned filtering. >> >> For example, if you're designing a protocol that is meant to >> work on the public Internet, you may want to provide some fall-back >> mechanism that does not employ IPv6 EHs. >> >> Yet another of the implications is the security issue that has >> been discussed on-list: if e.g. IPv6 fragments are dropped and you >> can be tricked into generating them, you may be subject to a DoS >> attack. >> >> >> 4) Flag possible further work >> >> Here we try to flag areas where the further work may be needed, >> such as adding fall-back mechanisms to some existing protocols, >> or avoiding the use of IPv6 EHs where possible. >> >> >> Thanks! >> >> Best regards, > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Oct 1 15:53:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4AD1A882B for ; Wed, 1 Oct 2014 15:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s8PzBLDY4-u for ; Wed, 1 Oct 2014 15:52:55 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D1E1A8827 for ; Wed, 1 Oct 2014 15:52:54 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s91Mq3Uv015956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 15:52:03 -0700 (PDT) Message-ID: <542C8595.6080809@isi.edu> Date: Wed, 01 Oct 2014 15:52:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jBJ9DIDvuw2-NhZlT-syfTHzTy0 Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:52:58 -0000 On 10/1/2014 3:44 PM, Tim Chown wrote: > I'd argue a separate 'problem statement' is a better approach. If the IETF were developing a new protocol, yes. But in this case we have operational observations and operational recommendations. The two are tightly coupled; the latter makes no sense without the former anyway. I don't see "here's what I saw" and "here's what to do about it" as separately useful. Joe > > -- > Tim > >> On 1 Oct 2014, at 23:35, Joe Touch wrote: >> >> There is no need for multiple documents on this topic. This information >> should be rolled into draft-gont-opsec-ipv6-eh-filtering-02 >> >> Joe >> >>> On 9/29/2014 9:50 PM, Fernando Gont wrote: >>> Folks, >>> >>> Earlier in September we published a revision of our I-D "IPv6 Extension >>> Headers in the Real World" >>> (). >>> >>> At this point in time, we're interested in knowing whether our I-D is of >>> value for the IPv6 ops community, such that we can decide whether to >>> continue working/improving it. Additionally, if there's anything you >>> think we've missed in the document, we'd like to hear from you. >>> >>> Overall, our I-D is meant to provide a reality-check with respect to the >>> issues surrounding IPv6 Extension Headers and their use on the public >>> Internet. More specifically, its goals are: >>> >>> 1) Provide data regarding support of IPv6 EHs in the real world. >>> >>> This is interesting data to refer people to (e.g., folks >>> developing protocols) regarding the extent to which IPv6 EHs >>> are usable on the public Internet (at least with web, mail, and >>> name servers). >>> >>> >>> 2) Summarize the issues associated with IPv6 EHs (performance, security, >>> etc.) >>> >>> This is of use for folks concerned with the issues surrounding >>> IPv6 EHs, and covers practical issues. >>> >>> >>> 3) Summarizes the implications of the aforementioned filtering. >>> >>> For example, if you're designing a protocol that is meant to >>> work on the public Internet, you may want to provide some fall-back >>> mechanism that does not employ IPv6 EHs. >>> >>> Yet another of the implications is the security issue that has >>> been discussed on-list: if e.g. IPv6 fragments are dropped and you >>> can be tricked into generating them, you may be subject to a DoS >>> attack. >>> >>> >>> 4) Flag possible further work >>> >>> Here we try to flag areas where the further work may be needed, >>> such as adding fall-back mechanisms to some existing protocols, >>> or avoiding the use of IPv6 EHs where possible. >>> >>> >>> Thanks! >>> >>> Best regards, >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Oct 1 23:11:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69F1A00C9 for ; Wed, 1 Oct 2014 23:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xXStIzukb-H for ; Wed, 1 Oct 2014 23:11:48 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02171A00AB for ; Wed, 1 Oct 2014 23:11:48 -0700 (PDT) Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:851:61d1:a593:2e06]) by dougbarton.us (Postfix) with ESMTPSA id E1CA122B2D for ; Thu, 2 Oct 2014 06:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1412230308; bh=UYqOHGdOHvhBiporzqUig9zb3HJlfbQymwm05JY8ts8=; h=Date:From:To:Subject:References:In-Reply-To; b=WRvyt/zOXXZI1KNipkrXrp15uAuTisueK1XFJtT5Ifirwz+A8Zr+P9U12LiAXVBiL 58TssgeYUK69JuAYieY0qKjXBIjETTFiTUmJVzqCnoWINWF5HlLjg0FFSxzs2/P9IT 6KP5Y4FE5+RWRoRWwIdEkD4xuXoW5kOjs9mtYJ7M= Message-ID: <542CEC3B.9020402@dougbarton.us> Date: Wed, 01 Oct 2014 23:10:03 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> In-Reply-To: <542C8595.6080809@isi.edu> OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_UBLUHCoKzMIEBQ5AOqqi3v8ZCs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 06:11:50 -0000 On 10/1/14 3:52 PM, Joe Touch wrote: > > > On 10/1/2014 3:44 PM, Tim Chown wrote: >> I'd argue a separate 'problem statement' is a better approach. > > If the IETF were developing a new protocol, yes. > > But in this case we have operational observations and operational > recommendations. The two are tightly coupled; the latter makes no sense > without the former anyway. > > I don't see "here's what I saw" and "here's what to do about it" as > separately useful. +1 From nobody Thu Oct 2 02:46:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9841A028A for ; Thu, 2 Oct 2014 02:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.736 X-Spam-Level: * X-Spam-Status: No, score=1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEE5WL1r6JLH for ; Thu, 2 Oct 2014 02:45:56 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52BE71A0276 for ; Thu, 2 Oct 2014 02:45:55 -0700 (PDT) Received: from 10.236.62.137 (EHLO OPE10HT03.tp.gk.corp.tepenet) ([10.236.62.137]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id COC10612; Thu, 02 Oct 2014 11:45:46 +0200 (CEST) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Ross Chandler Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+IfJWdndvPc0W8NTzcZ4VQIJwIh4kAgAeEHQCAAAKgAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaa4CAAQJyAIAB8XFwgAJ16YCABToFsIAAWF8AgAE4SKA= Date: Thu, 2 Oct 2014 09:45:45 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F8AA6F@OPE10MB05.tp.gk.corp.tepenet> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> <2D29C51862222E49B991EF64EEB0B5B745F8A7A7@OPE10MB05.tp.gk.corp.tepenet> <72D3BE66-C5D2-4DF2-895B-3030245ABEF6@eircom.net> In-Reply-To: <72D3BE66-C5D2-4DF2-895B-3030245ABEF6@eircom.net> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745F8AA6FOPE10MB05tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.10.2.90018:17:8.317, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_BODY_WEBMAIL, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, WEBMAIL_SOURCE, MULTIPLE_RCPTS, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0203.542D1ECB.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0203.542D1ECB.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b21e99559804b25f5713c1d1a2f2b032 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KBmIc6byedLTQCOgz6AUMxR1qxU Cc: "v6ops@ietf.org WG" , Tore Anderson , "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , Kossut Tomasz - Hurt Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 09:46:05 -0000 --_000_2D29C51862222E49B991EF64EEB0B5B745F8AA6FOPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3JpZ2luIGNsaWVudCBydW4gb24gUEMgd2l0aCB3aW5kb3dzIG9ubHksIHNvIGl04oCZcyB0ZXRo ZXJpbmcuDQoNCkJSLA0KTWN6DQoNCkZyb206IFJvc3MgQ2hhbmRsZXIgW21haWx0bzpyb3NzQGVp cmNvbS5uZXRdDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDEsIDIwMTQgNjo1MyBQTQ0KVG86 IEN6ZXJ3b25rYSBNaWNoYcWCIDEgLSBIdXJ0DQpDYzogTG9yZW56byBDb2xpdHRpOyB2Nm9wc0Bp ZXRmLm9yZyBXRzsgZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnlAdG9vbHMu aWV0Zi5vcmc7IFRvcmUgQW5kZXJzb247IEtvc3N1dCBUb21hc3ogLSBIdXJ0DQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292 ZXJ5DQoNCklzIHRoaXMgYW4gaXNzdWUgb25seSBzZWVuIGZyb20gdGV0aGVyZWQgaG9zdHMgaW4g dGhlIDY0c2hhcmUvUkZDIDcyNzggY2FzZSBvciBoYXZlIHlvdSBhbHNvIHNlZW4gYXBwcyBvbiB0 aGUgVUUgd2l0aCB0aGUgcHJvYmxlbT8NCg0KQlINClJvc3MNCg0KT24gMSBPY3QgMjAxNCwgYXQg MTA6MzcsIEN6ZXJ3b25rYSBNaWNoYcWCIDEgLSBIdXJ0IDxNaWNoYWwuQ3plcndvbmthMUBvcmFu Z2UuY29tPG1haWx0bzpNaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29tPj4gd3JvdGU6DQoNCg0K aHR0cDovL2ZvcnVtLmVhLmNvbS9lYWZvcnVtL3Bvc3RzL2xpc3QvOTc0MTIyOS5wYWdlDQoNCm1h eWJlIGlzIG1vcmUgYXBwbGljYXRpb24gbGlrZSB0aGlzIGFib3ZlLg0KDQpCUiwNCk1jeg0KDQoN CkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6 IFN1bmRheSwgU2VwdGVtYmVyIDI4LCAyMDE0IDU6NDcgQU0NClRvOiBDemVyd29ua2EgTWljaGHF giAxIC0gSHVydA0KQ2M6IEhlYXRsZXksIE5pY2s7IFRvcmUgQW5kZXJzb247IE1ldHNjaHVsYXQs IEhvbGdlciAoaG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZTxtYWlsdG86aG9sZ2VyLm1ldHNj aHVsYXRAdGVsZWtvbS5kZT4pOyBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVy eUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNj b3ZlcnlAdG9vbHMuaWV0Zi5vcmc+OyB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5v cmc+IFdHOyBLb3NzdXQgVG9tYXN6IC0gSHVydA0KU3ViamVjdDogUmU6IFt2Nm9wc10gbmV3IGRy YWZ0OiBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeQ0KDQpDYW4geW91IHBy b3ZpZGUgZXhhbXBsZXMgb2Ygd2hhdCBkb2VzIG5vdCB3b3JrIHdpdGggRE5TNjQ/DQoNCkluIGZh Y3QsIHRoYXQgd291bGQgYmUgdXNlZnVsIHRvIGRvY3VtZW50IGluIGFuIGluZm9ybWF0aW9uYWwg ZG9jdW1lbnQuDQoNCk9uIEZyaSwgU2VwIDI2LCAyMDE0IGF0IDk6MTcgUE0sIEN6ZXJ3b25rYSBN aWNoYcWCIDEgLSBIdXJ0IDxNaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29tPG1haWx0bzpNaWNo YWwuQ3plcndvbmthMUBvcmFuZ2UuY29tPj4gd3JvdGU6DQpPUEwgdXNlIEFQTiBJUHY2LW9ubHkg Zm9yIGFsbCBzZXJ2aWNlcyB3ZSBoYXZlLCBidXQgc29tZSBtb2JpbGUgb3BlcmF0b3JzIHVzZSBk aWZmZXJlbnQgQVBOIGZvciB0ZXRoZXJpbmcuIFdoeSA/DQoNCmlmIHdlIGFwcGx5IHRoZSBhcmNo aXRlY3R1cmUgQ0xBVCtQTEFUK0ROUyB3ZSBjYW4gYWNoaWV2ZSBxdWFsaXR5IG9mIHNlcnZpY2Ug bGlrZSBpbiBEUywgd2l0aCBETlM2NCBOT1QuDQoNCkJSLA0KTWN6DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2 b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K --_000_2D29C51862222E49B991EF64EEB0B5B745F8AA6FOPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4u VGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVrc3QgZHlta2EiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlN0eWx3aWFkb21vY2llLW1h aWwyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJQTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9yaWdpbiBjbGllbnQgcnVuIG9uIFBDIHdpdGggd2luZG93cyBv bmx5LCBzbyBpdOKAmXMgdGV0aGVyaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1jejxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFJvc3MgQ2hhbmRsZXIgW21haWx0bzpyb3NzQGVpcmNvbS5uZXRdDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBPY3RvYmVyIDAxLCAyMDE0IDY6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEN6 ZXJ3b25rYSBNaWNoYcWCIDEgLSBIdXJ0PGJyPg0KPGI+Q2M6PC9iPiBMb3JlbnpvIENvbGl0dGk7 IHY2b3BzQGlldGYub3JnIFdHOyBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVy eUB0b29scy5pZXRmLm9yZzsgVG9yZSBBbmRlcnNvbjsgS29zc3V0IFRvbWFzeiAtIEh1cnQ8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC13YW5nLXY2b3Bz LXhsYXQtcHJlZml4LWRpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBhbiBpc3N1ZSBv bmx5IHNlZW4gZnJvbSB0ZXRoZXJlZCBob3N0cyBpbiB0aGUgNjRzaGFyZS9SRkMgNzI3OCBjYXNl IG9yIGhhdmUgeW91IGFsc28gc2VlbiBhcHBzIG9uIHRoZSBVRSB3aXRoIHRoZSBwcm9ibGVtPzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvc3M8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxIE9jdCAyMDE0 LCBhdCAxMDozNywgQ3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpNaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29tIj5NaWNoYWwuQ3plcndvbmthMUBvcmFuZ2Uu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6 Ly9mb3J1bS5lYS5jb20vZWFmb3J1bS9wb3N0cy9saXN0Lzk3NDEyMjkucGFnZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL2ZvcnVtLmVhLmNvbS9lYWZvcnVtL3Bvc3RzL2xpc3Qv OTc0MTIyOS5wYWdlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5tYXliZSBpcyBtb3JlIGFwcGxpY2F0aW9uIGxpa2UgdGhpcyBh Ym92ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QlIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NY3o8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TG9yZW56bw0KIENvbGl0dGkgWzxhIGhyZWY9 Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPm1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb208L2E+ XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8 Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+U3VuZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMTQgNTo0NyBBTTxicj4NCjxiPlRvOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q3plcndvbmthIE1p Y2hhxYIgMSAtIEh1cnQ8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkhlYXRsZXksIE5pY2s7IFRvcmUgQW5kZXJzb247IE1ldHNj aHVsYXQsIEhvbGdlciAoPGEgaHJlZj0ibWFpbHRvOmhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20u ZGUiPmhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU8L2E+KTsNCjxhIGhyZWY9Im1haWx0bzpk cmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeUB0b29scy5pZXRmLm9yZyI+ZHJh ZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnlAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0K PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4gV0c7IEtv c3N1dCBUb21hc3ogLSBIdXJ0PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJh ZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3Zlcnk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4geW91IHBy b3ZpZGUgZXhhbXBsZXMgb2Ygd2hhdCBkb2VzIG5vdCB3b3JrIHdpdGggRE5TNjQ/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBmYWN0LCB0aGF0IHdvdWxkIGJlIHVzZWZ1bCB0byBkb2N1bWVudCBpbiBh biBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIFNlcCAyNiwgMjAxNCBhdCA5OjE3IFBNLCBDemVyd29ua2EgTWljaGHFgiAxIC0gSHVydCAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhbC5DemVyd29ua2ExQG9yYW5nZS5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5NaWNoYWwuQ3plcndvbmthMUBvcmFu Z2UuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T1BMIHVzZSBBUE4gSVB2Ni1vbmx5IGZvciBhbGwgc2Vy dmljZXMgd2UgaGF2ZSwgYnV0IHNvbWUgbW9iaWxlIG9wZXJhdG9ycyB1c2UgZGlmZmVyZW50IEFQ TiBmb3IgdGV0aGVyaW5nLiBXaHkgPzxicj4NCjxicj4NCmlmIHdlIGFwcGx5IHRoZSBhcmNoaXRl Y3R1cmUgQ0xBVCYjNDM7UExBVCYjNDM7RE5TIHdlIGNhbiBhY2hpZXZlIHF1YWxpdHkgb2Ygc2Vy dmljZSBsaWtlIGluIERTLCB3aXRoIEROUzY0IE5PVC48YnI+DQo8YnI+DQpCUiw8YnI+DQpNY3o8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGlu ZyBsaXN0PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPnY2b3BzQGlldGYub3Jn PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj48c3BhbiBsYW5nPSJF Ti1VUyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D29C51862222E49B991EF64EEB0B5B745F8AA6FOPE10MB05tpgkco_-- From nobody Thu Oct 2 04:30:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00B91A1A25 for ; Thu, 2 Oct 2014 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5BYzPz0qKak for ; Thu, 2 Oct 2014 04:30:48 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0281A1A2A for ; Thu, 2 Oct 2014 04:30:48 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rp18so2293546iec.35 for ; Thu, 02 Oct 2014 04:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7WWuXwQDOcMlicLh2r/T3sMlJfs8sf81WuE2BPbPK2A=; b=VnYxElwwcz7HGmxoOZ4HdiwF9npFw7asLnYIQiaKF4o5c32eQm2RSPxfSl93tSk1hC WmiXplqPbYUAexbbTIS9fFGqS4YuOcdgHTft8naeiJgTnSmaLbmc60TLPOPMGQxtpmgk UXgcipSpp6dKgURlgIMG1uyn2p13vHyOyF+3Ht5qAJqNfdbOWr59piof2Gu2SxVeHkfy EClDbqG7X95gzrrt2idD/tIOpbOhIVYOnm5J+lh+Xyuaxomm0iFPQ//KTEYvxnUH9H4/ /82vFQ4RJYhPkYXfdW22FLhh8Hpk+NtG6rZ/0g6pNG2j/WUs0itfSgbIYc7zTa0RyL4n 5djw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7WWuXwQDOcMlicLh2r/T3sMlJfs8sf81WuE2BPbPK2A=; b=GLh7FESGJuWBMmzXnK9coOJB5owz+A8WLVVty5ncXeJ60Dy87+fFJ01ScWnkFuGjiI paZns2NPiKYIHjivA9dZTEzmrlfn3zg7gDaBDV2h7UvIYn8ZQYwyl15fCdlDgNamRxBJ zARq39aAzMm/oqu37zmSCjw5oMmBDvC4bhhbLBqayICoYiLU19Pph6yQgBv9OgOO6/Zd VHZgyMSsaFsIpnAp6ljj6LndRYE9BnU6y5wT/d8ZiBsTjG69zgLSGu87M6xWJ2/m5nqx SGEMDtaDIQNjnNzsgUg/vWaUWVzlKzdQY9F0mG/xpBisOeihDI7JmlzO/nl/nI+eYiZI qd2g== X-Gm-Message-State: ALoCoQnos6MRyh73PTGcGfeTGGzxaXzGkrakBW6oCWRf3Khx497LEBQqg2frbf6AzLDaTDFsL3nR X-Received: by 10.50.87.99 with SMTP id w3mr3870942igz.4.1412249447749; Thu, 02 Oct 2014 04:30:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Thu, 2 Oct 2014 04:30:27 -0700 (PDT) In-Reply-To: <542C8595.6080809@isi.edu> References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> From: Lorenzo Colitti Date: Thu, 2 Oct 2014 20:30:27 +0900 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e0111b854ab164705046ef2ec Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RtfmK8Pc0mLbBicv9Xm79tfWbv8 Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs , IPv6 Operations , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:30:49 -0000 --089e0111b854ab164705046ef2ec Content-Type: text/plain; charset=UTF-8 On Thu, Oct 2, 2014 at 7:52 AM, Joe Touch wrote: > I don't see "here's what I saw" and "here's what to do about it" as > separately useful. > In theory having separate documents is useless. In practice having separate documents is extremely useful, because it turns out that it's much easier to agree on "here's what I saw" than on "here's what to do about it". In a consensus-oriented body like the IETF, there's no output until people agree, so attempting to document both a problem and a solution at the same time can take months or even years longer than documenting the two separately. --089e0111b854ab164705046ef2ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 2, 2014 at 7:52 AM, Joe Touch <touch@isi.edu> wrote:
=
I don't see "here's what I saw&= quot; and "here's what to do about it" as
separately useful.

In theory having separate docum= ents is useless.

In practice having separate docum= ents is extremely useful, because it turns out that it's much easier to= agree on "here's what I saw" than on "here's what t= o do about it". In a consensus-oriented body like the IETF, there'= s no output until people agree, so attempting to document both a problem an= d a solution at the same time can take months or even years longer than doc= umenting the two separately.
--089e0111b854ab164705046ef2ec-- From nobody Thu Oct 2 04:51:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1761A1ADB for ; Thu, 2 Oct 2014 04:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZnTjkbogM1x for ; Thu, 2 Oct 2014 04:51:55 -0700 (PDT) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2FE1A1AD0 for ; Thu, 2 Oct 2014 04:51:54 -0700 (PDT) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.150]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 06:51:51 -0500 From: "Metzler, Dan J" To: Lorenzo Colitti , Joe Touch Thread-Topic: [v6ops] IPv6 Extension Headers in the Real World Thread-Index: AQHP3cgE66Go8UIYvka1CtjXhjqwQpwcKteAgAACD4CAANPigP//ribA Date: Thu, 2 Oct 2014 11:51:50 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: multipart/alternative; boundary="_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7ITSNT440iowauio_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hAm-G_wUcRSciWmfDlvI0dfe2l4 Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:51:57 -0000 --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7ITSNT440iowauio_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCB0aGluayB0aGF0IGlmIGl04oCZcyBtdWNoIGVhc2llciB0byBhZ3JlZSBvbiDigJxo ZXJl4oCZcyB3aGF0IEkgc2F34oCdLCB0aGVuIGl0IHdvdWxkIHdvcmsgYmV0dGVyIGlmIHRoZSBm aXJzdCBkcmFmdCBpbmNsdWRlcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIGFuZCB0aGVuIGxhdGVy IGRyYWZ0cyBmbGVzaCBvdXQg4oCcaGVyZeKAmXMgd2hhdCB0byBkbyBhYm91dCBpdOKAnS4gIEV2 ZW4gaW4gcHJhY3RpY2UsIHNpbXBseSBhZ3JlZWluZyBvbiB0aGUgbmF0dXJlIG9mIHRoZSBwcm9i bGVtLCBpcyBvZiBsaW1pdGVkIHZhbHVlIHdpdGhvdXQgdGhlIGtub3dsZWRnZSBvZiBzb2x1dGlv bnMsIG9yIGV2ZW4gdGhlIGtub3dsZWRnZSB0aGF0IGEgc29sdXRpb24gbWF5IG5vdCBleGlzdCB5 ZXQuICBFdmVuIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBzb2x1dGlvbnMgdG8gYSBwcm9ibGVtLCBp dCBpcyBhbHdheXMgaW1wb3J0YW50IHRvIHN0YXRlIHRoZSBwcm9ibGVtIHRoYXQgZWFjaCBzb2x1 dGlvbiBpcyBkZXNpZ25lZCB0byBzb2x2ZSB3aGVuIHByZXNlbnRpbmcgYW55IHNvbHV0aW9uLg0K DQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIsIDIwMTQgNjozMCBB TQ0KVG86IEpvZSBUb3VjaA0KQ2M6IGRyYWZ0LWdvbnQtdjZvcHMtaXB2Ni1laHMtaW4tcmVhbC13 b3JsZEB0b29scy5pZXRmLm9yZzsgVjZvcHMgQ2hhaXJzOyBJUHY2IE9wZXJhdGlvbnM7IEZlcm5h bmRvIEdvbnQNClN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgRXh0ZW5zaW9uIEhlYWRlcnMgaW4g dGhlIFJlYWwgV29ybGQNCg0KT24gVGh1LCBPY3QgMiwgMjAxNCBhdCA3OjUyIEFNLCBKb2UgVG91 Y2ggPHRvdWNoQGlzaS5lZHU8bWFpbHRvOnRvdWNoQGlzaS5lZHU+PiB3cm90ZToNCkkgZG9uJ3Qg c2VlICJoZXJlJ3Mgd2hhdCBJIHNhdyIgYW5kICJoZXJlJ3Mgd2hhdCB0byBkbyBhYm91dCBpdCIg YXMNCnNlcGFyYXRlbHkgdXNlZnVsLg0KDQpJbiB0aGVvcnkgaGF2aW5nIHNlcGFyYXRlIGRvY3Vt ZW50cyBpcyB1c2VsZXNzLg0KDQpJbiBwcmFjdGljZSBoYXZpbmcgc2VwYXJhdGUgZG9jdW1lbnRz IGlzIGV4dHJlbWVseSB1c2VmdWwsIGJlY2F1c2UgaXQgdHVybnMgb3V0IHRoYXQgaXQncyBtdWNo IGVhc2llciB0byBhZ3JlZSBvbiAiaGVyZSdzIHdoYXQgSSBzYXciIHRoYW4gb24gImhlcmUncyB3 aGF0IHRvIGRvIGFib3V0IGl0Ii4gSW4gYSBjb25zZW5zdXMtb3JpZW50ZWQgYm9keSBsaWtlIHRo ZSBJRVRGLCB0aGVyZSdzIG5vIG91dHB1dCB1bnRpbCBwZW9wbGUgYWdyZWUsIHNvIGF0dGVtcHRp bmcgdG8gZG9jdW1lbnQgYm90aCBhIHByb2JsZW0gYW5kIGEgc29sdXRpb24gYXQgdGhlIHNhbWUg dGltZSBjYW4gdGFrZSBtb250aHMgb3IgZXZlbiB5ZWFycyBsb25nZXIgdGhhbiBkb2N1bWVudGlu ZyB0aGUgdHdvIHNlcGFyYXRlbHkuDQo= --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7ITSNT440iowauio_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQg dGhpbmsgdGhhdCBpZiBpdOKAmXMgbXVjaCBlYXNpZXIgdG8gYWdyZWUgb24g4oCcaGVyZeKAmXMg d2hhdCBJIHNhd+KAnSwgdGhlbiBpdCB3b3VsZCB3b3JrIGJldHRlciBpZiB0aGUgZmlyc3QgZHJh ZnQgaW5jbHVkZXMgdGhlIHByb2JsZW0gc3RhdGVtZW50LCBhbmQgdGhlbg0KIGxhdGVyIGRyYWZ0 cyBmbGVzaCBvdXQg4oCcaGVyZeKAmXMgd2hhdCB0byBkbyBhYm91dCBpdOKAnS4mbmJzcDsgRXZl biBpbiBwcmFjdGljZSwgc2ltcGx5IGFncmVlaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIHByb2Js ZW0sIGlzIG9mIGxpbWl0ZWQgdmFsdWUgd2l0aG91dCB0aGUga25vd2xlZGdlIG9mIHNvbHV0aW9u cywgb3IgZXZlbiB0aGUga25vd2xlZGdlIHRoYXQgYSBzb2x1dGlvbiBtYXkgbm90IGV4aXN0IHll dC4mbmJzcDsgRXZlbiBpZiB0aGVyZSBhcmUgbXVsdGlwbGUNCiBzb2x1dGlvbnMgdG8gYSBwcm9i bGVtLCBpdCBpcyBhbHdheXMgaW1wb3J0YW50IHRvIHN0YXRlIHRoZSBwcm9ibGVtIHRoYXQgZWFj aCBzb2x1dGlvbiBpcyBkZXNpZ25lZCB0byBzb2x2ZSB3aGVuIHByZXNlbnRpbmcgYW55IHNvbHV0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBPY3RvYmVyIDIsIDIwMTQgNjozMCBBTTxicj4NCjxiPlRvOjwvYj4gSm9l IFRvdWNoPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLWluLXJlYWwt d29ybGRAdG9vbHMuaWV0Zi5vcmc7IFY2b3BzIENoYWlyczsgSVB2NiBPcGVyYXRpb25zOyBGZXJu YW5kbyBHb250PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIElQdjYgRXh0ZW5zaW9u IEhlYWRlcnMgaW4gdGhlIFJlYWwgV29ybGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9jdCAyLCAyMDE0 IGF0IDc6NTIgQU0sIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlzaS5lZHUi IHRhcmdldD0iX2JsYW5rIj50b3VjaEBpc2kuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBzZWUgJnF1b3Q7 aGVyZSdzIHdoYXQgSSBzYXcmcXVvdDsgYW5kICZxdW90O2hlcmUncyB3aGF0IHRvIGRvIGFib3V0 IGl0JnF1b3Q7IGFzPGJyPg0Kc2VwYXJhdGVseSB1c2VmdWwuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSW4gdGhlb3J5IGhh dmluZyBzZXBhcmF0ZSBkb2N1bWVudHMgaXMgdXNlbGVzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcHJhY3RpY2UgaGF2aW5nIHNlcGFy YXRlIGRvY3VtZW50cyBpcyBleHRyZW1lbHkgdXNlZnVsLCBiZWNhdXNlIGl0IHR1cm5zIG91dCB0 aGF0IGl0J3MgbXVjaCBlYXNpZXIgdG8gYWdyZWUgb24gJnF1b3Q7aGVyZSdzIHdoYXQgSSBzYXcm cXVvdDsgdGhhbiBvbiAmcXVvdDtoZXJlJ3Mgd2hhdCB0byBkbyBhYm91dCBpdCZxdW90Oy4gSW4g YSBjb25zZW5zdXMtb3JpZW50ZWQgYm9keSBsaWtlIHRoZSBJRVRGLCB0aGVyZSdzIG5vIG91dHB1 dCB1bnRpbA0KIHBlb3BsZSBhZ3JlZSwgc28gYXR0ZW1wdGluZyB0byBkb2N1bWVudCBib3RoIGEg cHJvYmxlbSBhbmQgYSBzb2x1dGlvbiBhdCB0aGUgc2FtZSB0aW1lIGNhbiB0YWtlIG1vbnRocyBv ciBldmVuIHllYXJzIGxvbmdlciB0aGFuIGRvY3VtZW50aW5nIHRoZSB0d28gc2VwYXJhdGVseS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7ITSNT440iowauio_-- From nobody Thu Oct 2 06:13:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E911A7D82 for ; Thu, 2 Oct 2014 06:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cziQPGsoJN0I for ; Thu, 2 Oct 2014 06:13:15 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E741A701D for ; Thu, 2 Oct 2014 06:13:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s92DD6Wf003912; Thu, 2 Oct 2014 14:13:06 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s92DD6Wf003912 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1412255587; bh=3Sep6cnM7NviE5ntFVjTTTUugBc=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=cPFUtAw1ci/Rc1P6PjIEz1cgydQqN5ihrrVlEzXxr6PpS4aQm3O7+L7zomdpJhF4R x9HAobxqBhIkDENDV1DEuSaqejPh7yvAqGYX5e+TvwpT9mBFS+UdELWRWHYEBFqtXh EBcfb9qPbYaknaEiHV6T3MSftA7Tfkk68c/BrQw0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q91ED63054707044px ret-id none; Thu, 02 Oct 2014 14:13:07 +0100 Received: from [IPv6:2001:630:d0:ed04:8142:4437:7d2e:7792] ([IPv6:2001:630:d0:ed04:8142:4437:7d2e:7792]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s92DD3vO018650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2014 14:13:04 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_08E3CD8A-0CFE-4B75-A517-230BD2EE417D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> Date: Thu, 2 Oct 2014 14:13:03 +0100 Message-ID: References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> To: "Metzler, Dan J" X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q91ED6305470704400; tid=q91ED63054707044px; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s92DD6Wf003912 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-cdaeAXaJlVaEOCnikHXKL0O33Y Cc: IPv6 Operations , Fernando Gont , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:13:25 -0000 --Apple-Mail=_08E3CD8A-0CFE-4B75-A517-230BD2EE417D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2 Oct 2014, at 12:51, Metzler, Dan J wrote: > I would think that if it=92s much easier to agree on =93here=92s what = I saw=94, then it would work better if the first draft includes the = problem statement, and then later drafts flesh out =93here=92s what to = do about it=94. Even in practice, simply agreeing on the nature of the = problem, is of limited value without the knowledge of solutions, or even = the knowledge that a solution may not exist yet. Even if there are = multiple solutions to a problem, it is always important to state the = problem that each solution is designed to solve when presenting any = solution. Indeed. As an author of the =91what I saw=92 it seems appropriate to = document an issue that others can discuss and decide what action(s) to = take. =20 So separation of authorship is one thing. Another is that there might be multiple =91here=92s what to do about it=92= documents, as there have been with other operational problem = statements. There might be Informational or BCP documents in v6ops = suggesting mitigation methods, and/or there might be protocol changes = through 6man. Tim= --Apple-Mail=_08E3CD8A-0CFE-4B75-A517-230BD2EE417D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 2 = Oct 2014, at 12:51, Metzler, Dan J <dan-metzler@uiowa.edu> = wrote:

I would think that if it=92s much easier to agree = on =93here=92s what I saw=94, then it would work better if the first = draft includes the problem statement, and then later drafts flesh out =93here=92s what to do about it=94.  Even = in practice, simply agreeing on the nature of the problem, is of limited = value without the knowledge of solutions, or even the knowledge that a = solution may not exist yet.  Even if there are multiple solutions to a problem, it is always important to state the problem = that each solution is designed to solve when presenting any = solution.


Indeed. As = an author of the =91what I saw=92 it seems appropriate to document an = issue that others can discuss and decide what action(s) to take. =  

So separation of authorship is one = thing.

Another is that there might be multiple = =91here=92s what to do about it=92 documents, as there have been with = other operational problem statements. There might be Informational or = BCP documents in v6ops suggesting mitigation methods, and/or there might = be protocol changes through = 6man.

Tim
= --Apple-Mail=_08E3CD8A-0CFE-4B75-A517-230BD2EE417D-- From nobody Thu Oct 2 08:05:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA3A1A6FB3 for ; Thu, 2 Oct 2014 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMgagZfm4keF for ; Thu, 2 Oct 2014 08:04:56 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D1A1A8549 for ; Thu, 2 Oct 2014 08:04:56 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s92F3r4i005825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 08:03:56 -0700 (PDT) Message-ID: <542D695A.3070506@isi.edu> Date: Thu, 02 Oct 2014 08:03:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Chown , "Metzler, Dan J" References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YE-gSmxmMEfjBGp-wJgh8j41weo Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:04:58 -0000 You all might consider that "what to do about it" is already being proposed as a WG doc in OPSEC. So I disagree with the entire logic of the idea of sequential publication in this case. It only opens up continued need for coordination between WGs. Joe On 10/2/2014 6:13 AM, Tim Chown wrote: > On 2 Oct 2014, at 12:51, Metzler, Dan J > wrote: > >> I would think that if its much easier to agree on heres what I >> saw, then it would work better if the first draft includes the >> problem statement, and then later drafts flesh out heres what to do >> about it. Even in practice, simply agreeing on the nature of the >> problem, is of limited value without the knowledge of solutions, or >> even the knowledge that a solution may not exist yet. Even if there >> are multiple solutions to a problem, it is always important to state >> the problem that each solution is designed to solve when presenting >> any solution. >> > > Indeed. As an author of the what I saw it seems appropriate to > document an issue that others can discuss and decide what action(s) to > take. > > So separation of authorship is one thing. > > Another is that there might be multiple heres what to do about it > documents, as there have been with other operational problem statements. > There might be Informational or BCP documents in v6ops suggesting > mitigation methods, and/or there might be protocol changes through 6man. > > Tim From nobody Thu Oct 2 08:46:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF11A874C; Thu, 2 Oct 2014 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ1nFBMdxQcY; Thu, 2 Oct 2014 08:45:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4E1A1A89; Thu, 2 Oct 2014 08:45:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 08:45:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BVcij0ZpLLtP3DMtfTPkUZ8AAdk Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:45:56 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is the second iteration of this document to be IETF Last Called having previously been here at draft 04. Substantial changes to the document have occurred inclusive of the removal of much of the normative language. Abstract This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Oct 2 10:27:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3215F1A8A94 for ; Thu, 2 Oct 2014 10:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JizuCoQ5FaqH for ; Thu, 2 Oct 2014 10:27:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29BC1A8F34 for ; Thu, 2 Oct 2014 10:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1020; q=dns/txt; s=iport; t=1412270825; x=1413480425; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=obg57S7TrG1vEdxJ88TXnkHhxtn/ppa4eWC6bqizF/U=; b=dnLr4uxZeih/ZJbU0A8gayj2QsLKm7gL9B4oT21KCCC68rQSQpKWY/MX ax1Zae3JhTnZOaujoWLAAkAp+F3/zNEvmOYfTJSWQ8xk2VrDfInVDeo3H zw9fPssLdKTg5OsgTOO7eecjI29shL6GJX7xC/FB+mdXoBG2CrP9xP5vy M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHuKLVStJV2Q/2dsb2JhbABgDoMAgSwE0jICgQ0WAXuEBAEBAwF5BQsCAQhGMiUCBA4FDg2IGwi9aQEXkCYHgy6BHQWRbYILgUyHb5VzgyNAbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,640,1406592000"; d="asc'?scan'208";a="360192794" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 02 Oct 2014 17:27:05 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s92HR3Nl021498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 17:27:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 12:27:03 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] IPv6 Extension Headers in the Real World Thread-Index: AQHP3mYUoIhO7eAC4EW9CLhXMbng+w== Date: Thu, 2 Oct 2014 17:27:03 +0000 Message-ID: <121A1546-7D1B-4938-8E9E-F6BE15C23BAF@cisco.com> References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> In-Reply-To: <542D695A.3070506@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_9B83CA71-B26F-4D6B-95FB-EA94D5752B53"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SbQ-z57w58T58CUPZxUTwHOCnsQ Cc: IPv6 Operations , Fernando Gont , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:27:06 -0000 --Apple-Mail=_9B83CA71-B26F-4D6B-95FB-EA94D5752B53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 2, 2014, at 8:03 AM, Joe Touch wrote: > So I disagree with the entire logic of the idea of sequential = publication in this case. It only opens up continued need for = coordination between WGs. One solution to that would be to discuss both documents in the same = working group. I=92m open as to which. --Apple-Mail=_9B83CA71-B26F-4D6B-95FB-EA94D5752B53 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFULYrkbjEdbHIsm0MRAj2rAJ46ONS22DiGRAxMHUAA992EgLR/oQCgyBdT 0yhMg4a6LU3uqOvhCzcpxyA= =yCGn -----END PGP SIGNATURE----- --Apple-Mail=_9B83CA71-B26F-4D6B-95FB-EA94D5752B53-- From nobody Fri Oct 3 02:33:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68BD1AD000 for ; Fri, 3 Oct 2014 02:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFcGUg7KnWwS for ; Fri, 3 Oct 2014 02:33:48 -0700 (PDT) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444C51A0233 for ; Fri, 3 Oct 2014 02:33:48 -0700 (PDT) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.150]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 04:33:46 -0500 From: "Metzler, Dan J" To: Joe Touch , Tim Chown Thread-Topic: [v6ops] IPv6 Extension Headers in the Real World Thread-Index: AQHP3cgE66Go8UIYvka1CtjXhjqwQpwcKteAgAACD4CAANPigP//ribAgABuhYCAAB74AIAA2aHA Date: Fri, 3 Oct 2014 09:33:45 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> In-Reply-To: <542D695A.3070506@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XcBqvte2ZmdHCeCynO6jBYeQ78I Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:33:50 -0000 I think perhaps I was a bit vague in my previous email, so just to clarify = my point. I would point out that my comments below imply that there is only one docum= ent under consideration for both "here's what I saw" and "here's what to do= about it". The problem statement and the solution are still presented in the same docu= ment. "If" a problem statement or "here's what I saw" is presented in a se= parate document without a solution, purely for the sake of agreeing on the = problem in a short period of time, typically I would expect another draft o= f the document to come along later with both "here's what I saw" and "here'= s what to do about it", and replace the previous one; not that you would ma= intain the two in separate documents. The idea that there might be a document under discussion in two separate WG= s at the same time is really a separate discussion, and it's based purely t= he idea that two WGs are considering the same problem that determines the n= eed for coordination between WGs; not the number of iterations (drafts) of = a document. I would hope that cooperation or coordination between WGs woul= d happen just because it makes sense when you're both considering solutions= to the same problem. That's true regardless of how many drafts are create= d. Thanks, - Dan > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, October 2, 2014 10:04 AM > To: Tim Chown; Metzler, Dan J > Cc: Lorenzo Colitti; draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.o= rg; > V6ops Chairs; IPv6 Operations; Fernando Gont > Subject: Re: [v6ops] IPv6 Extension Headers in the Real World >=20 > You all might consider that "what to do about it" is already being propos= ed > as a WG doc in OPSEC. >=20 > So I disagree with the entire logic of the idea of sequential publication= in this > case. It only opens up continued need for coordination between WGs. >=20 > Joe >=20 > On 10/2/2014 6:13 AM, Tim Chown wrote: > > On 2 Oct 2014, at 12:51, Metzler, Dan J > > wrote: > > > >> I would think that if it's much easier to agree on "here's what I > >> saw", then it would work better if the first draft includes the > >> problem statement, and then later drafts flesh out "here's what to do > >> about it". Even in practice, simply agreeing on the nature of the > >> problem, is of limited value without the knowledge of solutions, or > >> even the knowledge that a solution may not exist yet. Even if there > >> are multiple solutions to a problem, it is always important to state > >> the problem that each solution is designed to solve when presenting > >> any solution. > >> > > > > Indeed. As an author of the 'what I saw' it seems appropriate to > > document an issue that others can discuss and decide what action(s) to > > take. > > > > So separation of authorship is one thing. > > > > Another is that there might be multiple 'here's what to do about it' > > documents, as there have been with other operational problem > statements. > > There might be Informational or BCP documents in v6ops suggesting > > mitigation methods, and/or there might be protocol changes through > 6man. > > > > Tim From nobody Fri Oct 3 11:31:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EA91A888D for ; Fri, 3 Oct 2014 11:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl8eZ_s3G91K for ; Fri, 3 Oct 2014 11:31:40 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969821A86E9 for ; Fri, 3 Oct 2014 11:31:40 -0700 (PDT) Received: from [2001:5c0:1000:a::31] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xa7df-0006jR-1l; Fri, 03 Oct 2014 20:31:36 +0200 Message-ID: <542EAFEF.30607@gont.com.ar> Date: Fri, 03 Oct 2014 11:17:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Metzler, Dan J" , Joe Touch , Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6J3BamzVJboNzEFLJ4xq2lem_qU Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 18:31:42 -0000 Hi, Dan, On 10/03/2014 06:33 AM, Metzler, Dan J wrote: > I would point out that my comments below imply that there is only one > document under consideration for both "here's what I saw" and "here's > what to do about it". Just for clarification's sake: One might be tempted to assume that one should/can codify the "here is what I saw" into the same document as the "here is what to do about it" because the former is simply the "problem statement" which will be addressed by the later. However, I'm of the idea that that is an over-expectation. > The problem statement and the solution are > still presented in the same document. "If" a problem statement or > "here's what I saw" is presented in a separate document without a > solution, purely for the sake of agreeing on the problem in a short > period of time, typically I would expect another draft of the > document to come along later with both "here's what I saw" and > "here's what to do about it", and replace the previous one; not that > you would maintain the two in separate documents. The advice on filtering need not relate into a solution to the "here is what I saw". For instance, I'm of the idea that if you want your protocol to be able to work on the public Internet, it must be able to operate without IPv6 EHs. IMO, I see the advice on filtering as something "necessary, but not sufficient", if you want. The advice on filtering is one of the action items resulting from the "here's what we saw". But as noted on our I-D, there should be others, like the IETF looking at which protocols rely on IPv6 EHs, and making sure they can still work in the presence of packet filtering. And you certainly do not want the "here's what we saw", "here's how we'd like you to filter packets with EHs", "here's what the IETF should consider when designing new protocols", because they tend to be rather orthogonal, and also targeted at different communities. -- the guy doing the packet filtering is likely different from the guy developing new protocols, etc. > The idea that there might be a document under discussion in two > separate WGs at the same time is really a separate discussion, and > it's based purely the idea that two WGs are considering the same > problem that determines the need for coordination between WGs; not > the number of iterations (drafts) of a document. I would hope that > cooperation or coordination between WGs would happen just because it > makes sense when you're both considering solutions to the same > problem. That's true regardless of how many drafts are created. FWIW, I think that each of the related documents is clearly scoped. And while it's nice to announce a document in all the relevant wgs, one can always note that "discussion is expected to happen at this or that wg". There have been so many instances of documents that might have happened at two or three different wgs, and I don't think there has been a need for "special coordination" among them -- but I guess I might be wrong. Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Oct 3 11:54:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEB81A1A73 for ; Fri, 3 Oct 2014 11:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eCiQjXQv6m6 for ; Fri, 3 Oct 2014 11:54:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87361A1A62 for ; Fri, 3 Oct 2014 11:54:47 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s93IritD012096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Oct 2014 11:53:45 -0700 (PDT) Message-ID: <542EF0BA.2070604@isi.edu> Date: Fri, 03 Oct 2014 11:53:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , "Metzler, Dan J" , Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> In-Reply-To: <542EAFEF.30607@gont.com.ar> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/381UWdexMxJ-Spph0EdNlBJTj2c Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 18:54:48 -0000 On 10/3/2014 7:17 AM, Fernando Gont wrote: > And you certainly do not want the "here's what we saw", "here's how we'd > like you to filter packets with EHs", "here's what the IETF should > consider when designing new protocols", because they tend to be rather > orthogonal, and also targeted at different communities. -- the guy > doing the packet filtering is likely different from the guy developing > new protocols, etc. The coupling of these determines how you act. It determines whether you can filter safely, only when under threat or in a particular environment, or should not filter under any circumstances. And that's why it's dangerous to split these out. These should not be targeted at different communities without a single, coherent context of both what is known to happen, what the risks are, and the recommendations. Ultimately, we need an Internet whose behavior is coherent, not based on potentially interfering communities perceived as being orthogonal. Joe From nobody Fri Oct 3 12:03:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD431A88B1 for ; Fri, 3 Oct 2014 12:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY_KFCY7AuA8 for ; Fri, 3 Oct 2014 12:03:37 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B3E1A88AE for ; Fri, 3 Oct 2014 12:03:37 -0700 (PDT) Received: from [2001:5c0:1000:a::17] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xa88X-0006qm-ER; Fri, 03 Oct 2014 21:03:29 +0200 Message-ID: <542EF2F9.10204@gont.com.ar> Date: Fri, 03 Oct 2014 16:03:21 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Joe Touch , "Metzler, Dan J" , Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> <542EF0BA.2070604@isi.edu> In-Reply-To: <542EF0BA.2070604@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T9szW5ur1euKDbDiw3EqV0fe5kc Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:03:44 -0000 On 10/03/2014 03:53 PM, Joe Touch wrote: > On 10/3/2014 7:17 AM, Fernando Gont wrote: >> And you certainly do not want the "here's what we saw", "here's how we'd >> like you to filter packets with EHs", "here's what the IETF should >> consider when designing new protocols", because they tend to be rather >> orthogonal, and also targeted at different communities. -- the guy >> doing the packet filtering is likely different from the guy developing >> new protocols, etc. > > The coupling of these determines how you act. It determines whether you > can filter safely, only when under threat or in a particular > environment, or should not filter under any circumstances. Have you checked the eh-filtering I-D (drfat-gont-opsec-ipv6-eh-filtering)? Because it has all that analysis in the document itself > And that's why it's dangerous to split these out. These should not be > targeted at different communities without a single, coherent context of > both what is known to happen, what the risks are, and the recommendations. That's all in one I-D. OTOH, the I-D of the subject line is about empirical observations. > Ultimately, we need an Internet whose behavior is coherent, not based on > potentially interfering communities perceived as being orthogonal. You want have coherent Internet, because even when we can provide advice, at the end of the day its each operator's business what they do with their own network. -- in the same way that some networks break PMTUD, while others don't. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sun Oct 5 06:02:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704541A0252 for ; Sun, 5 Oct 2014 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNsyLD6CT_-a for ; Sun, 5 Oct 2014 06:02:52 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EE01A02D4 for ; Sun, 5 Oct 2014 06:02:52 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s95D2eMu010532; Sun, 5 Oct 2014 14:02:40 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s95D2eMu010532 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1412514162; bh=IY80+cN2vIzLGlu84oE1xI6eDR0=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=283f+PDjXkQrM8ELwidqh0e7doTqfgYUfR0YZZlizXgmXJx5Ea7GeHAk+J2w1cJF9 mbUtCN0sxu8/pF3D7EZiR2MTvntKbtDYZX397crGBxwSGhm2qO46V+vJBm0TLoar5A cxu+Le1hSChLJk5yZhXoqdlTsqRAxJCzj6trPdew= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q94E2e0169101780Uy ret-id none; Sun, 05 Oct 2014 14:02:42 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s95D1KQS019989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 5 Oct 2014 14:01:21 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <542EF0BA.2070604@isi.edu> Date: Sun, 5 Oct 2014 14:01:19 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> <542EF0BA.2070604@isi.edu> <08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q94E2e016910178000; tid=q94E2e0169101780Uy; client=relay,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s95D2eMu010532 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CY0KVzo4y6r3jYG9r1oUbm1J3mY Cc: IPv6 Operations , Fernando Gont , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 13:02:56 -0000 On 3 Oct 2014, at 19:53, Joe Touch wrote: > On 10/3/2014 7:17 AM, Fernando Gont wrote: >> And you certainly do not want the "here's what we saw", "here's how = we'd >> like you to filter packets with EHs", "here's what the IETF should >> consider when designing new protocols", because they tend to be = rather >> orthogonal, and also targeted at different communities. -- the guy >> doing the packet filtering is likely different from the guy = developing >> new protocols, etc. >=20 > The coupling of these determines how you act. It determines whether = you > can filter safely, only when under threat or in a particular > environment, or should not filter under any circumstances. >=20 > And that's why it's dangerous to split these out. These should not be > targeted at different communities without a single, coherent context = of > both what is known to happen, what the risks are, and the = recommendations. And I think it works the other way - it=92s cleaner to express an = observation or problem statement, and then leave the community to decide = what action, if any, to take. At the very least here there=92s a clear = warning sign about expectations for the successful transport of IPv6 = packets using EHs, end to end. There=92s many examples of IETF problem statements documented = independently of solutions/BCP/informational guidance. > Ultimately, we need an Internet whose behavior is coherent, not based = on > potentially interfering communities perceived as being orthogonal. Perhaps better to say communities with different perspectives. But your = choice language makes a point. RFC7045 is good in my view, but is not yet where we are at. Part of that = is a default filtering setting by the vendor community. Vendors also = have a part to play in how EHs are handled in general, e.g. the = observations are that longer EH chains lead to more drops. And there is an operational community aspect from how default settings = may be changed, or set in a way that may cause problems. There=92s many = sites who don=92t follow RFC4890 for example, whatever the defaults = provided by vendors might be. And there=92s a community that designs new protocols that might choose = to use EHs. While the sfc WG has made it clear that any use of EHs there = is within a constrained/limited environment (and not across the Internet = at large), perhaps others are taking a more hopeful view=85 But the point remains, documenting the observations/problem = independently allows discussion in those other communities - vendors, = operators and protocol designers - without trying to pre-empt that in a = single document. I=92m not saying there=92s a right or a wrong way, but = I think it=92s better to be able to take stock from a clean problem = statement/set of observations, than try to do everything in one go. It=92s a shame the IETF91 BoF cutoff just went by - a non WG-forming BoF = might have been a good way to tease these issues out.=20 Tim= From nobody Sun Oct 5 12:42:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092E61A1AF2 for ; Sun, 5 Oct 2014 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veMWGqXpodYD for ; Sun, 5 Oct 2014 12:41:59 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC071A1AF3 for ; Sun, 5 Oct 2014 12:41:58 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id z10so2161976pdj.40 for ; Sun, 05 Oct 2014 12:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FbAnVFnLEb86nU66DjCiTcfyfJU4O2eeOV6GoZpuzMg=; b=wkUMew/34NsWZz//BXyUFmA6T9pVXU+Dsi/VH6jFJaXO1JlZshsIBvWmFByq+Ne/op 1+8HtI6UG0QHdacNf8R1aJOBdJI+I2hkO33jLNr1PUb7rPVUtIrtHrM8F8DuEZ14FbOq 630m17n/jKgGzukTqp9UMvKpo+PqcxQ/b4me908On52AnJ0E5Ut4tvxMHaGAdQdOaWhu sfjkcANKgJqEoFG23uOSruxLJCMF2YprQX/AVFQT5qLjGTr1iHQ2FcIxEkeCbo34fEGv fgzwldlpHsPhqOULBVS78NvO9D9yFHuEkbDCiHlQRs6Af06cFBM1BkZgArTmewarUPtE tekA== X-Received: by 10.70.62.42 with SMTP id v10mr13932757pdr.68.1412538118662; Sun, 05 Oct 2014 12:41:58 -0700 (PDT) Received: from [192.168.178.23] (154.197.69.111.dynamic.snap.net.nz. [111.69.197.154]) by mx.google.com with ESMTPSA id ve13sm11647967pac.6.2014.10.05.12.41.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 12:41:57 -0700 (PDT) Message-ID: <54319F01.3050307@gmail.com> Date: Mon, 06 Oct 2014 08:41:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tore@redpill-linpro.com References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> In-Reply-To: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X_3nJwfeSojTOsychdFMtQ9anVg Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 19:42:01 -0000 Tore, One substantive comment first, followed by a nit. The substantive comment is on the positioning of your proposal. Basically I think it is a Good Thing to describe this solution, and its pros and cons. But I still think that for many established operators it's not yet clear that it's the best choice. So I think that (a) Appendix B.4 (Dual Stack) should cite RFC 6883 as a full exploration of the dual stack option. It does after all contain a hidden reference to your draft: "Some ICPs who already have satisfactory operational experience with IPv6 might consider an IPv6-only strategy, with IPv4 clients being supported by translation or proxy in front of their IPv6 content servers." (b) I also think the first lines of1.1 (Motivation and Goals) are a bit too much like opinion - ultimately it should be each operator's choice what they do. Rather than deconstructing your text, I suggest the following friendly amendment: Historically, dual stack [RFC4213] [RFC6883] has been the recommended way to transition from an IPv4-only environment to one capable of serving IPv6 users. However, for data centre operators and Internet content providers, dual stack operation has a number of disadvantages compared to single stack operation. In particular, running two protocols rather than one results in increased complexity and operational overhead, with a very low expected return on investment in the short to medium term while few end-users only have connectivity to the IPv6 Internet. Furthermore, the dual stack approach does not in any way help with the depletion of the IPv4 address space. Therefore, some operators may prefer an approach in which they only need to operate one protocol in the data centre as they prepare for the future. The design goals are: Nit: Something very strange has happened in these two references: 10.2. Informative References [I-D.anderson-v6ops-siit-dc-2xlat] tore, t., "SIIT-DC: Dual Translation Mode", draft- anderson-v6ops-siit-dc-2xlat-00 (work in progress), September 2014. [I-D.gont-6man-deprecate-atomfrag-generation] Gont, F., Will, W., and t. tore, "Deprecating the Generation of IPv6 Atomic Fragments", draft-gont-6man- deprecate-atomfrag-generation-01 (work in progress), August 2014. Regards Brian From nobody Sun Oct 5 23:04:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6361A1B40 for ; Sun, 5 Oct 2014 23:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdzIIr_MlnCo for ; Sun, 5 Oct 2014 23:04:29 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9D01A1B3C for ; Sun, 5 Oct 2014 23:04:29 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=47788 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xb1PH-0001zw-Up; Mon, 06 Oct 2014 08:04:27 +0200 Message-ID: <543230EA.4040002@fud.no> Date: Mon, 06 Oct 2014 08:04:26 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Brian E Carpenter References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <54319F01.3050307@gmail.com> In-Reply-To: <54319F01.3050307@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lpwJ93OuOFHn9Com9amXSHxcDn4 Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 06:04:32 -0000 Hi Brian, * Brian E Carpenter > The substantive comment is on the positioning of your proposal. Basically > I think it is a Good Thing to describe this solution, and its pros and > cons. But I still think that for many established operators it's not yet > clear that it's the best choice. So I think that > > (a) Appendix B.4 (Dual Stack) should cite RFC 6883 as a full exploration > of the dual stack option. It does after all contain a hidden reference to > your draft: "Some ICPs who already have satisfactory operational experience > with IPv6 might consider an IPv6-only strategy, with IPv4 clients being > supported by translation or proxy in front of their IPv6 content servers." > > (b) I also think the first lines of1.1 (Motivation and Goals) are a bit too > much like opinion - ultimately it should be each operator's choice what > they do. Rather than deconstructing your text, I suggest the following > friendly amendment: > > Historically, dual stack [RFC4213] [RFC6883] has been the recommended way to > transition from an IPv4-only environment to one capable of serving > IPv6 users. However, for data centre operators and Internet content > providers, dual stack operation has a number of disadvantages > compared to single stack operation. In particular, running two > protocols rather than one results in increased complexity and > operational overhead, with a very low expected return on investment > in the short to medium term while few end-users only have connectivity > to the IPv6 Internet. Furthermore, the dual stack approach does not > in any way help with the depletion of the IPv4 address space. > > Therefore, some operators may prefer an approach in which they only > need to operate one protocol in the data centre as they prepare for > the future. The design goals are: Thank you! I've added the reference in B.4 and used your suggested text for 1.1, so it'll be part of -02. You can see the result here: https://github.com/toreanderson/ietf/blob/master/siit-dc.raw.txt > Something very strange has happened in these two references: > > 10.2. Informative References > > > [I-D.anderson-v6ops-siit-dc-2xlat] > tore, t., "SIIT-DC: Dual Translation Mode", draft- > anderson-v6ops-siit-dc-2xlat-00 (work in progress), > September 2014. > > [I-D.gont-6man-deprecate-atomfrag-generation] > Gont, F., Will, W., and t. tore, "Deprecating the > Generation of IPv6 Atomic Fragments", draft-gont-6man- > deprecate-atomfrag-generation-01 (work in progress), > August 2014. This I do not quite understand. This strangeness seems to originate from: http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.anderson-v6ops-siit-dc-2xlat.xml and http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.gont-6man-deprecate-atomfrag-generation.xml I have no idea what's happened, but I will try to figure it out. Thanks for pointing it out! Best regards, Tore Anderson From nobody Sun Oct 5 23:19:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1621A1B46 for ; Sun, 5 Oct 2014 23:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXo32QX2tF_7 for ; Sun, 5 Oct 2014 23:18:56 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335651A1B42 for ; Sun, 5 Oct 2014 23:18:56 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=47995 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xb1dG-0002Ig-O0; Mon, 06 Oct 2014 08:18:54 +0200 Message-ID: <5432344D.1010007@fud.no> Date: Mon, 06 Oct 2014 08:18:53 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: IPv6 Operations References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> In-Reply-To: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hFWTtuZF-UHV-LZSTxnvU28Cc1U Subject: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 06:18:58 -0000 Hello, As Brian was quick to notice, I've uploaded a new version of the SIIT-DC draft. I would like to solicit the WG's input on the draft (and its companion draft[1]), in particular whether or not the work is seen as relevant and useful, and any feedback or suggestions big or small on how to further improve it. (Do feel free to send me minor issues in direct e-mail if you prefer no to "spam" the WG list with them.) [1] https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc-2xlat/ Also, since running code is important, I'd like to point out that there are several implementations that implement an SIIT-DC Gateway (or something very close to the spec), from the top of my head and in alphabetical order: Brocade ADX, Cisco ASR1k, F5 BIG-IP LTM, and Linux/TAYGA. There's also an SIIT-DC Host Agent available at https://github.com/toreanderson/clatd (using Linux/TAYGA). Best regards, Tore Anderson -------- Forwarded Message -------- Subject: I-D Action: draft-anderson-v6ops-siit-dc-01.txt Date: Sun, 05 Oct 2014 11:54:23 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org Newsgroups: gmane.ietf.announce A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments Author : Tore Anderson Filename : draft-anderson-v6ops-siit-dc-01.txt Pages : 30 Date : 2014-10-05 Abstract: This document describes SIIT-DC, an extension to Stateless IP/ICMP Translation (SIIT) [RFC6145] that makes it ideally suited for use in IPv6 data centre environments. SIIT-DC simultaneously facilitates IPv6 deployment and IPv4 address conservation. The overall SIIT-DC architecture is described, as well as guidelines for operators. Finally, the normative implementation requirements are described, as a list of additions and changes to SIIT [RFC6145]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-anderson-v6ops-siit-dc-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-siit-dc-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 6 00:30:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2F1A1B59 for ; Mon, 6 Oct 2014 00:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 279GLk253qWK for ; Mon, 6 Oct 2014 00:30:39 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C617D1A1B51 for ; Mon, 6 Oct 2014 00:30:39 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id at20so2708370iec.26 for ; Mon, 06 Oct 2014 00:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YhInAhc2ItEtpedflVD8/EgkHKrY7RadQPLCSD3Nxqc=; b=Ih1H3vDWXVHwgYxfdpCrUhK3ulMfd6duTJc0D2HUuimDXFlstf3w5aWlf3KD0tg8lP DLYMGGzqiO4wTQsNEi1uCvUigwNGp1KvMQxhH4bQGHuXPanQTh6igUIo3r4ghWKayCRf 5Zhrp3gLn7VacKru8ZU2cNnZL05Y8Hds0zoNi0mILf2+KjCtizrclciGZiUe1IP6+0E5 xh0C+Q1bi9Tv4fY2GjZsrDnrD4zclr+z6dAjDso8WqU5jBGolyBZTratdc1TgAt7Ghnx tW+XEuUTFADtUUapbHJk2wv1OJmxnXMqJGUJl9omyH+xIi+orm0ImJPZhYpGrvvQtmWz EG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YhInAhc2ItEtpedflVD8/EgkHKrY7RadQPLCSD3Nxqc=; b=L7T2L56nbE7cQy+Q3QS2AQgG9tVAg/VJvw4kOoVxtzJmLuoPlbc/y3TuXTbDVix9y4 IPsl1u9d8klE6WZpv3d+Sv5NZqpQl5Er7+GkZ76Z7c+v81Zw/1+O4so4VJ2npS8CyFIW wl416lED77cZpp1R+CqYDbqJZmcRQ/KqLISvg36pnsLAEUOZGKrrKSeae3Mn5NP70xFc AIdIDYCJClRlr+6k0OAiTHxWtIoQmFO3/UubCHd+SZFiY+mc9p5jfRam7VuMJ9lYW1LE PKVi262HmaJ1wesSa+24SluoedOEAhGAG5CmIrkeoR/Mtk8209EDIpcTKIhcaaq3ldLw O6/g== X-Gm-Message-State: ALoCoQlTgNvTNjVMH5Vz0rttJ3f+D2AIF8CwMX511grgOssQYM/vAw5mkLhIxF3UYcrKC9nJLfdx X-Received: by 10.43.6.200 with SMTP id ol8mr30463613icb.39.1412580639126; Mon, 06 Oct 2014 00:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Mon, 6 Oct 2014 00:30:18 -0700 (PDT) In-Reply-To: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Mon, 6 Oct 2014 16:30:18 +0900 Message-ID: To: IETF Discussion Content-Type: multipart/alternative; boundary=bcaec5014c9f3663c40504bc0f20 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0kQ6CkCplQXQM7u6b_nnI4gG5-c Cc: "v6ops@ietf.org WG" , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:30:42 -0000 --bcaec5014c9f3663c40504bc0f20 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 3, 2014 at 12:45 AM, The IESG wrote: > This is the second iteration of this document to be IETF Last Called having > previously been here at draft 04. Substantial changes to the document have > occurred inclusive of the removal of much of the normative language. That assessment of the changes is incorrect, unless "removal of the normative language" means "replace all upper-case MUST with lower-case must". The diff from -04 to -13 is at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-v6ops-mobile-device-profile-04.txt&url2=draft-ietf-v6ops-mobile-device-profile-13.txt . The attentive reader will see that that most of the text is identical. That aside: 1. This text is incorrect and should be removed: The key words "must", "must not", "should", "should not", and "may" in this document are to be interpreted as described in RFC 2119 [RFC2119]. It is meaningless to say, in the same document, that "must" is to be interpreted as described in RFC 2119 ("an absolute requirement of the specification"), and simultaneously that "this document is not a standard". 2. I stand by my earlier assessment that this document's requirements are over-broad, and in fact so broad as to harm adoption. There may well be operators or device implementers that seeing with such a high number of requirements may shy away in terror and think that deploying IPv6 in a mobile network is an impossibly high amount of work. That said, given that this document says clearly that it is not a standard, and that compliance is not required, the harm it does will be limited. Regards, Lorenzo --bcaec5014c9f3663c40504bc0f20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 3, 2014 at 12:45 AM, The IESG <iesg-secretary@ietf.org&g= t; wrote:
This is the second iteration of this d= ocument to be IETF Last Called having
previously been here at draft 04. Substantial changes to the document have<= br> occurred inclusive of the removal of much of the normative language.

That assessment of the changes is incorrect, unle= ss "removal of the normative language" means "replace all up= per-case MUST with lower-case must".

The diff= from -04 to -13 is at http://tools.ietf.org/rfc= diff?difftype=3D--hwdiff&url1=3Ddraft-ietf-v6ops-mobile-device-profile-= 04.txt&url2=3Ddraft-ietf-v6ops-mobile-device-profile-13.txt . The a= ttentive reader will see that that most of the text is identical.

That aside:

1. This text is incorr= ect and should be removed:

=C2=A0 =C2=A0The k= ey words "must", "must not", "should", "= should not", and "may"
=C2=A0 =C2=A0in this docume= nt are to be interpreted as described in RFC 2119
=C2=A0 =C2=A0[R= FC2119].

It is meaningless to say, in the sa= me document, that "must" is to be interpreted as described in RFC= 2119 ("an absolute requirement of the specification"), and simul= taneously that "this document is not a standard".

<= /div>
2. I stand by my earlier assessment that this document's requ= irements are over-broad, and in fact so broad as to harm adoption. There ma= y well be operators or device implementers that seeing with such a high num= ber of requirements may shy away in terror and think that deploying IPv6 in= a mobile network is an impossibly high amount of work. That said, given th= at this document says clearly that it is not a standard, and that complianc= e is not required, the harm it does will be limited.

Regards,
Lorenzo
--bcaec5014c9f3663c40504bc0f20-- From nobody Mon Oct 6 02:08:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A821A1B78 for ; Mon, 6 Oct 2014 02:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRbN4AFWX1tE for ; Mon, 6 Oct 2014 02:08:05 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) by ietfa.amsl.com (Postfix) with ESMTP id ED2DC1A1B7A for ; Mon, 6 Oct 2014 02:08:04 -0700 (PDT) Received: from [85.158.137.35:36376] by server-14.bemta-3.messagelabs.com id 98/08-01575-3FB52345; Mon, 06 Oct 2014 09:08:03 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-10.tower-134.messagelabs.com!1412586481!36038742!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31026 invoked from network); 6 Oct 2014 09:08:01 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-10.tower-134.messagelabs.com with SMTP; 6 Oct 2014 09:08:01 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Mon, 06 Oct 2014 10:10:16 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 10:07:49 +0100 From: "Heatley, Nick" To: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= , Ross Chandler Thread-Topic: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery Thread-Index: AQHP0/+Lt72jTbGJ9EemkbZAEwE9WpwImE0AgAeEHACAAAKhAIAAFLQAgAADCQCAACdvAIAAAqUAgAAaaoCAAQsxMIAByHyAgAKWIICABRjpAIAAeXsAgAEbDYCABk5i0A== Date: Mon, 6 Oct 2014 09:07:48 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303BDC45A@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <201409191147.s8JBl1Zv016462@irp-lnx1.cisco.com> <78e3cec1.169cf.148a76af091.Coremail.lilishan48@126.com> <5422BE4E.1040601@fud.no> <5422E1EE.7020202@fud.no> <5422FA4F.3080003@fud.no> <6536E263028723489CCD5B6821D4B21303BBAE5B@UK30S005EXS06.EEAD.EEINT.CO.UK> <2D29C51862222E49B991EF64EEB0B5B745F8A501@OPE10MB05.tp.gk.corp.tepenet> <2D29C51862222E49B991EF64EEB0B5B745F8A7A7@OPE10MB05.tp.gk.corp.tepenet> <72D3BE66-C5D2-4DF2-895B-3030245ABEF6@eircom.net> <2D29C51862222E49B991EF64EEB0B5B745F8AA6F@OPE10MB05.tp.gk.corp.tepenet> In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745F8AA6F@OPE10MB05.tp.gk.corp.tepenet> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303BDC45AUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N8Dd_r992w1f_aLFEb-Aj7J_dJA Cc: "v6ops@ietf.org WG" , Tore Anderson , "draft-wang-v6ops-xlat-prefix-discovery@tools.ietf.org" , Kossut Tomasz - Hurt Subject: Re: [v6ops] new draft: draft-wang-v6ops-xlat-prefix-discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 09:08:09 -0000 --_000_6536E263028723489CCD5B6821D4B21303BDC45AUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIEkgYXNrLCB3YXMgdGhlIHByb2JsZW0gc2VlbiB3aGVuIDQ2NHhsYXQvTkFUNjQgZXh0ZXJu YWwgSVB2NCBhZGRyZXNzIHdhcyB0aGUgc2FtZSBhcyBETlM2NC9OQVQ2NCBleHRlcm5hbCBJUHY0 PyBJLmUuIE5BVDY0IGhhc2ggaXMgb25seSBvbiBJUHY2IHByZWZpeD8NClRoYW5rcy4NCg0KRnJv bTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ3pl cndvbmthIE1pY2hhbCAxIC0gSHVydA0KU2VudDogMDIgT2N0b2JlciAyMDE0IDEwOjQ2DQpUbzog Um9zcyBDaGFuZGxlcg0KQ2M6IHY2b3BzQGlldGYub3JnIFdHOyBUb3JlIEFuZGVyc29uOyBkcmFm dC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeUB0b29scy5pZXRmLm9yZzsgS29zc3V0 IFRvbWFzeiAtIEh1cnQNClN1YmplY3Q6IFJlOiBbdjZvcHNdIG5ldyBkcmFmdDogZHJhZnQtd2Fu Zy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnkNCg0KT3JpZ2luIGNsaWVudCBydW4gb24gUEMg d2l0aCB3aW5kb3dzIG9ubHksIHNvIGl04oCZcyB0ZXRoZXJpbmcuDQoNCkJSLA0KTWN6DQoNCkZy b206IFJvc3MgQ2hhbmRsZXIgW21haWx0bzpyb3NzQGVpcmNvbS5uZXRdDQpTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMDEsIDIwMTQgNjo1MyBQTQ0KVG86IEN6ZXJ3b25rYSBNaWNoYcWCIDEgLSBI dXJ0DQpDYzogTG9yZW56byBDb2xpdHRpOyB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0 Zi5vcmc+IFdHOyBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeUB0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3ZlcnlAdG9v bHMuaWV0Zi5vcmc+OyBUb3JlIEFuZGVyc29uOyBLb3NzdXQgVG9tYXN6IC0gSHVydA0KU3ViamVj dDogUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRp c2NvdmVyeQ0KDQpJcyB0aGlzIGFuIGlzc3VlIG9ubHkgc2VlbiBmcm9tIHRldGhlcmVkIGhvc3Rz IGluIHRoZSA2NHNoYXJlL1JGQyA3Mjc4IGNhc2Ugb3IgaGF2ZSB5b3UgYWxzbyBzZWVuIGFwcHMg b24gdGhlIFVFIHdpdGggdGhlIHByb2JsZW0/DQoNCkJSDQpSb3NzDQoNCk9uIDEgT2N0IDIwMTQs IGF0IDEwOjM3LCBDemVyd29ua2EgTWljaGHFgiAxIC0gSHVydCA8TWljaGFsLkN6ZXJ3b25rYTFA b3JhbmdlLmNvbTxtYWlsdG86TWljaGFsLkN6ZXJ3b25rYTFAb3JhbmdlLmNvbT4+IHdyb3RlOg0K DQpodHRwOi8vZm9ydW0uZWEuY29tL2VhZm9ydW0vcG9zdHMvbGlzdC85NzQxMjI5LnBhZ2UNCg0K bWF5YmUgaXMgbW9yZSBhcHBsaWNhdGlvbiBsaWtlIHRoaXMgYWJvdmUuDQoNCkJSLA0KTWN6DQoN Cg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2Vu dDogU3VuZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMTQgNTo0NyBBTQ0KVG86IEN6ZXJ3b25rYSBNaWNo YcWCIDEgLSBIdXJ0DQpDYzogSGVhdGxleSwgTmljazsgVG9yZSBBbmRlcnNvbjsgTWV0c2NodWxh dCwgSG9sZ2VyIChob2xnZXIubWV0c2NodWxhdEB0ZWxla29tLmRlPG1haWx0bzpob2xnZXIubWV0 c2NodWxhdEB0ZWxla29tLmRlPik7IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292 ZXJ5QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRp c2NvdmVyeUB0b29scy5pZXRmLm9yZz47IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4gV0c7IEtvc3N1dCBUb21hc3ogLSBIdXJ0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcg ZHJhZnQ6IGRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5DQoNCkNhbiB5b3Ug cHJvdmlkZSBleGFtcGxlcyBvZiB3aGF0IGRvZXMgbm90IHdvcmsgd2l0aCBETlM2ND8NCg0KSW4g ZmFjdCwgdGhhdCB3b3VsZCBiZSB1c2VmdWwgdG8gZG9jdW1lbnQgaW4gYW4gaW5mb3JtYXRpb25h bCBkb2N1bWVudC4NCg0KT24gRnJpLCBTZXAgMjYsIDIwMTQgYXQgOToxNyBQTSwgQ3plcndvbmth IE1pY2hhxYIgMSAtIEh1cnQgPE1pY2hhbC5DemVyd29ua2ExQG9yYW5nZS5jb208bWFpbHRvOk1p Y2hhbC5DemVyd29ua2ExQG9yYW5nZS5jb20+PiB3cm90ZToNCk9QTCB1c2UgQVBOIElQdjYtb25s eSBmb3IgYWxsIHNlcnZpY2VzIHdlIGhhdmUsIGJ1dCBzb21lIG1vYmlsZSBvcGVyYXRvcnMgdXNl IGRpZmZlcmVudCBBUE4gZm9yIHRldGhlcmluZy4gV2h5ID8NCg0KaWYgd2UgYXBwbHkgdGhlIGFy Y2hpdGVjdHVyZSBDTEFUK1BMQVQrRE5TIHdlIGNhbiBhY2hpZXZlIHF1YWxpdHkgb2Ygc2Vydmlj ZSBsaWtlIGluIERTLCB3aXRoIEROUzY0IE5PVC4NCg0KQlIsDQpNY3oNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0K djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhp cyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUg YWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZy b20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3Nl LiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBp biBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBl bnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2 aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2 aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAy MzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0 byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVw0K --_000_6536E263028723489CCD5B6821D4B21303BDC45AUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KcC5UZWtzdGR5bWthLCBsaS5U ZWtzdGR5bWthLCBkaXYuVGVrc3RkeW1rYQ0KCXttc28tc3R5bGUtbmFtZToiVGVrc3QgZHlta2Ei Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSBabmFrIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5UZWtzdGR5bWthWm5haw0KCXttc28tc3R5 bGUtbmFtZToiVGVrc3QgZHlta2EgWm5hayI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNhbiBJIGFzaywgd2FzIHRoZSBwcm9ibGVtIHNlZW4gd2hlbiA0NjR4bGF0L05BVDY0IGV4dGVy bmFsIElQdjQgYWRkcmVzcyB3YXMgdGhlIHNhbWUgYXMgRE5TNjQvTkFUNjQgZXh0ZXJuYWwgSVB2 ND8gSS5lLiBOQVQ2NCBoYXNoIGlzIG9ubHkgb24gSVB2NiBwcmVmaXg/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Q3plcndvbmthIE1pY2hhbCAxIC0gSHVydDxicj4NCjxiPlNlbnQ6PC9i PiAwMiBPY3RvYmVyIDIwMTQgMTA6NDY8YnI+DQo8Yj5Ubzo8L2I+IFJvc3MgQ2hhbmRsZXI8YnI+ DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnIFdHOyBUb3JlIEFuZGVyc29uOyBkcmFmdC13YW5n LXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeUB0b29scy5pZXRmLm9yZzsgS29zc3V0IFRvbWFz eiAtIEh1cnQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFm dC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PcmlnaW4gY2xpZW50 IHJ1biBvbiBQQyB3aXRoIHdpbmRvd3Mgb25seSwgc28gaXTigJlzIHRldGhlcmluZy48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5NY3o8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb3NzIENoYW5kbGVyIFs8YSBocmVmPSJtYWlsdG86 cm9zc0BlaXJjb20ubmV0Ij5tYWlsdG86cm9zc0BlaXJjb20ubmV0PC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMDEsIDIwMTQgNjo1MyBQTTxicj4NCjxiPlRvOjwv Yj4gQ3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ8YnI+DQo8Yj5DYzo8L2I+IExvcmVuem8gQ29s aXR0aTsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4g V0c7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtd2FuZy12Nm9wcy14bGF0LXByZWZpeC1kaXNjb3Zl cnlAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5 QHRvb2xzLmlldGYub3JnPC9hPjsgVG9yZSBBbmRlcnNvbjsgS29zc3V0IFRvbWFzeiAtIEh1cnQ8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFmdC13YW5nLXY2 b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUEwi PklzIHRoaXMgYW4gaXNzdWUgb25seSBzZWVuIGZyb20gdGV0aGVyZWQgaG9zdHMgaW4gdGhlIDY0 c2hhcmUvUkZDIDcyNzggY2FzZSBvciBoYXZlIHlvdSBhbHNvIHNlZW4gYXBwcyBvbiB0aGUgVUUg d2l0aCB0aGUgcHJvYmxlbT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUEwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlBMIj5CUjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlBMIj5Sb3NzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUEwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iUEwiPk9uIDEgT2N0IDIwMTQsIGF0IDEwOjM3LCBDemVyd29ua2EgTWljaGHFgiAxIC0gSHVy dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhbC5DemVyd29ua2ExQG9yYW5nZS5jb20iPk1pY2hh bC5DemVyd29ua2ExQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iUEwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUEwiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL2ZvcnVtLmVhLmNvbS9lYWZvcnVtL3Bvc3RzL2xp c3QvOTc0MTIyOS5wYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vZm9ydW0u ZWEuY29tL2VhZm9ydW0vcG9zdHMvbGlzdC85NzQxMjI5LnBhZ2U8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IlBMIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm1heWJlIGlzIG1vcmUgYXBwbGljYXRpb24gbGlrZSB0aGlz IGFib3ZlLjwvc3Bhbj48c3BhbiBsYW5nPSJQTCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i UEwiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QlIsPC9zcGFuPjxzcGFuIGxhbmc9IlBMIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1jejwvc3Bhbj48c3BhbiBsYW5nPSJQ TCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iUEwiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IlBMIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJQTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJQTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iUEwiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Mb3JlbnpvDQogQ29saXR0aSBbPGEgaHJlZj0i bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSI+bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbTwvYT5d PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5TdW5kYXksIFNlcHRlbWJlciAyOCwgMjAxNCA1OjQ3IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DemVyd29ua2EgTWlj aGHFgiAxIC0gSHVydDxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+SGVhdGxleSwgTmljazsgVG9yZSBBbmRlcnNvbjsgTWV0c2No dWxhdCwgSG9sZ2VyICg8YSBocmVmPSJtYWlsdG86aG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5k ZSI+aG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZTwvYT4pOw0KPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LXdhbmctdjZvcHMteGxhdC1wcmVmaXgtZGlzY292ZXJ5QHRvb2xzLmlldGYub3JnIj5kcmFm dC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeUB0b29scy5pZXRmLm9yZzwvYT47DQo8 YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiBXRzsgS29z c3V0IFRvbWFzeiAtIEh1cnQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFt2Nm9wc10gbmV3IGRyYWZ0OiBkcmFm dC13YW5nLXY2b3BzLXhsYXQtcHJlZml4LWRpc2NvdmVyeTwvc3Bhbj48c3BhbiBsYW5nPSJQTCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iUEwiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJQTCI+Q2FuIHlv dSBwcm92aWRlIGV4YW1wbGVzIG9mIHdoYXQgZG9lcyBub3Qgd29yayB3aXRoIEROUzY0PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJQTCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UEwiPkluIGZhY3QsIHRoYXQgd291bGQgYmUgdXNlZnVsIHRvIGRvY3VtZW50IGluIGFuIGluZm9y bWF0aW9uYWwgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJQ TCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlBMIj5PbiBGcmksIFNlcCAyNiwgMjAxNCBh dCA5OjE3IFBNLCBDemVyd29ua2EgTWljaGHFgiAxIC0gSHVydCAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhbC5DemVyd29ua2ExQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5NaWNoYWwuQ3plcndvbmthMUBvcmFuZ2UuY29tPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlBMIj5PUEwgdXNlIEFQTiBJUHY2LW9ubHkgZm9yIGFs bCBzZXJ2aWNlcyB3ZSBoYXZlLCBidXQgc29tZSBtb2JpbGUgb3BlcmF0b3JzIHVzZSBkaWZmZXJl bnQgQVBOIGZvciB0ZXRoZXJpbmcuIFdoeSA/PGJyPg0KPGJyPg0KaWYgd2UgYXBwbHkgdGhlIGFy Y2hpdGVjdHVyZSBDTEFUJiM0MztQTEFUJiM0MztETlMgd2UgY2FuIGFjaGlldmUgcXVhbGl0eSBv ZiBzZXJ2aWNlIGxpa2UgaW4gRFMsIHdpdGggRE5TNjQgTk9ULjxicj4NCjxicj4NCkJSLDxicj4N Ck1jejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUEwiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PHNw YW4gbGFuZz0iUEwiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwv c3Bhbj48c3BhbiBsYW5nPSJQTCIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+PHNwYW4gbGFuZz0iRU4t VVMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KDQo8UD5OT1RJQ0UgQU5EIERJU0NMQUlNRVI8QlI+VGhpcyBlLW1haWwgKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIA0KZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJz b24ocykuJm5ic3A7IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIA0Kbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZyb20geW91ciBz eXN0ZW0gYW5kIGRvIG5vdCANCmRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55IHB1cnBvc2UuJm5ic3A7 IDxCUj4mbmJzcDs8QlI+V2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIA0KYW5kIG91dGdvaW5n IGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBz dGVwcyB0byANCmVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVl IGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyANCnlvdXIgcmVzcG9uc2liaWxpdHkgdG8g ZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIDwvUD4NCjxQ PkVFIExpbWl0ZWQ8QlI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlczxCUj5Db21wYW55 IFJlZ2lzdGVyZWQgTnVtYmVyOiANCjAyMzgyMTYxPEJSPlJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJl c3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIA0KSGVydGZvcmRzaGly ZSwgQUwxMCA5Qlc8L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6536E263028723489CCD5B6821D4B21303BDC45AUK30S005EXS06EE_-- From nobody Mon Oct 6 08:28:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5FC1A6FDD for ; Mon, 6 Oct 2014 08:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC736j41lFqM for ; Mon, 6 Oct 2014 08:28:27 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68C41A02DD for ; Mon, 6 Oct 2014 08:28:27 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s96FRRdo020969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Oct 2014 08:27:30 -0700 (PDT) Message-ID: <5432B4E1.1050908@isi.edu> Date: Mon, 06 Oct 2014 08:27:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> <542EF0BA.2070604@isi.edu> <08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QdEFK0HfnRRYvrmYEFpMbzVZLN0 Cc: IPv6 Operations , Fernando Gont , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:28:29 -0000 On 10/5/2014 6:01 AM, Tim Chown wrote: > On 3 Oct 2014, at 19:53, Joe Touch wrote: ... >> Ultimately, we need an Internet whose behavior is coherent, not based on >> potentially interfering communities perceived as being orthogonal. > > Perhaps better to say communities with different perspectives. But your choice language makes a point. > > RFC7045 is good in my view, but is not yet where we are at. Which raises an additional point. The ink on that is barely dry. What changed that warrants looking at this again so soon? BOTH docs ought to address that (this doc mentions that RFC only in passing in the intro, ... > But the point remains, documenting the observations/problem > independently allows discussion in those other communities - vendors, > operators and protocol designers - without trying to pre-empt that in a > single document. Im not saying theres a right or a wrong way, but I > think its better to be able to take stock from a clean problem > statement/set of observations, than try to do everything in one go. That ship sailed with RFC7045. Right now, we're not talking about a hypothetical sequence of docs. We're talking about operational recommendations that have already been offered as a WG doc in OPSEC a few weeks ago this AND now this doc in V6OPS. > Its a shame the IETF91 BoF cutoff just went by - a non WG-forming > BoF might have been a good way to tease these issues out. The only people who really need to be at that meeting right now are the ADs and chairs of OPSEC and V6OPS. Although I appreciate that everyone thinks that "this can be coordinated", we're seeing ample evidence to the contrary. It's useful to note here that NEITHER DOC REFERENCES THE OTHER, despite being written by the same author (which begs the question of "end run"). If this is left to the WGs, then the WGs need to decide if they can manage each of these documents in the isolation the context that already has been allowed to exist and is already promoted by the author - or if that can *only* happen in a single doc. Joe From furry@google.com Wed Oct 1 16:03:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19361A87EB for ; Wed, 1 Oct 2014 16:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzJIeBN3eEgn for ; Wed, 1 Oct 2014 16:03:05 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071561A8821 for ; Wed, 1 Oct 2014 16:03:04 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id x13so1302591qcv.18 for ; Wed, 01 Oct 2014 16:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i0KOj4OQo5NgW7NFEjHG3seu4PStdFEQ5ezE0v1QT54=; b=dHsYiScZB6A2hdNuc2myGmDT0KbxmD9P6XwPaYss+J8Rkrqk+4Z7qfJv2F2j8wj8oL ljWUdd1vpdqHAu/1L303vfk1VzDmVZ+BLa7DNPp0iT3CTSDn1BD1WgQl+LqTMQyS9+pm GBkrrVxTKk3QejQ+ukf0t9hV8HaRgpGwY7DU8eP0b+bcqm3vNoXajEr+j9KfzBLYpx5i RAya/xdDE+hTWulUCJU+LaCedSW3SMo6HgNo/xSkRmtQEndQ+rE0lX1WPtMvbLMuVj7g GQ/A/4u/npr/BHJ/IY2eX+7kTQGKs9SbD8gFiQBcXDxOMJTM4sQZIARU06RASqFJ+2is 7hZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i0KOj4OQo5NgW7NFEjHG3seu4PStdFEQ5ezE0v1QT54=; b=ItrQb1AgeX47Jxx3k8ZvIycPacHRhGra4J7MfL0h5lmfYTYdsYNUmnAvOCV1fpUwV9 GDFHdL1v2KZQtUyx6aB2ZqM3Vp0qqX4bZB2tg1p9jNVSSDETx+SIPsz8z+/89VQBCH/L mc7J5sKC5/mjW9s5gOXLpU91vXXfkgCZYFDkRgo/NKVkP/ynG/mSz3l7VIrJL+Y0DgV7 ZfPCP3nZukUaz0h9zfkpdE+OgQut4AlqMSTVJuwo/LCviNnt3XBFRpdczqiE+x9cXYWs vMEBk7n0Ayy+8NORwaNYV8X8nKrfrSoX4fehRrX4YpT5mERTT2Wc1Ul1am5wYnt/JrJq iztg== X-Gm-Message-State: ALoCoQm12CNchocZlzO8RmyiH4kqpfKyAqPNVH6LJPzFjmrkYoHV6qX6If/LuXB5CscQRG8pL2vW X-Received: by 10.140.48.1 with SMTP id n1mr29522183qga.104.1412204584237; Wed, 01 Oct 2014 16:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.234.71 with HTTP; Wed, 1 Oct 2014 16:02:43 -0700 (PDT) In-Reply-To: <542C81B7.10601@isi.edu> References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> From: Jen Linkova Date: Thu, 2 Oct 2014 01:02:43 +0200 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zse0U0zRngI9MdKz3W2KLymx7oY X-Mailman-Approved-At: Mon, 06 Oct 2014 08:30:02 -0700 Cc: "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , IPv6 Operations , V6ops Chairs , Fernando Gont Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 23:13:58 -0000 On Thu, Oct 2, 2014 at 12:35 AM, Joe Touch wrote: > There is no need for multiple documents on this topic. This information > should be rolled into draft-gont-opsec-ipv6-eh-filtering-02 I agree that those two documents d overlap - especially in the section of ipv6-ehs-in-real-world which discusses the security implication of filtering (I believe it's a very good idea to add either such section or a reference to this draft to opsec-ipv6-eh-filtering-02). I'm not so sure if both documents should be merged as one is documenting the operational experience and the current situation while another one is providing some recommendations. > > On 9/29/2014 9:50 PM, Fernando Gont wrote: >> Folks, >> >> Earlier in September we published a revision of our I-D "IPv6 Extension >> Headers in the Real World" >> (). >> >> At this point in time, we're interested in knowing whether our I-D is of >> value for the IPv6 ops community, such that we can decide whether to >> continue working/improving it. Additionally, if there's anything you >> think we've missed in the document, we'd like to hear from you. >> >> Overall, our I-D is meant to provide a reality-check with respect to the >> issues surrounding IPv6 Extension Headers and their use on the public >> Internet. More specifically, its goals are: >> >> 1) Provide data regarding support of IPv6 EHs in the real world. >> >> This is interesting data to refer people to (e.g., folks >> developing protocols) regarding the extent to which IPv6 EHs >> are usable on the public Internet (at least with web, mail, and >> name servers). >> >> >> 2) Summarize the issues associated with IPv6 EHs (performance, security, >> etc.) >> >> This is of use for folks concerned with the issues surrounding >> IPv6 EHs, and covers practical issues. >> >> >> 3) Summarizes the implications of the aforementioned filtering. >> >> For example, if you're designing a protocol that is meant to >> work on the public Internet, you may want to provide some fall-back >> mechanism that does not employ IPv6 EHs. >> >> Yet another of the implications is the security issue that has >> been discussed on-list: if e.g. IPv6 fragments are dropped and you >> can be tricked into generating them, you may be subject to a DoS >> attack. >> >> >> 4) Flag possible further work >> >> Here we try to flag areas where the further work may be needed, >> such as adding fall-back mechanisms to some existing protocols, >> or avoiding the use of IPv6 EHs where possible. >> >> >> Thanks! >> >> Best regards, >> -- sincerely yours, Jen Linkova a.k.a Furry Network Engineer Brandschenkestrasse 110, 8002 Zurich, Switzerland Company Identifikationsnummer: CH-020.4.028.116-1 This email can contain confidential information.If you received this email by mistake, do not pass it to third parties and delete all copies and enclosures, and let us know that it has been delivered to wrong address. Thank you. From nobody Mon Oct 6 08:45:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E11A0309 for ; Mon, 6 Oct 2014 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zR9Pi8vraBF for ; Mon, 6 Oct 2014 08:45:49 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1870D1A02F6 for ; Mon, 6 Oct 2014 08:45:49 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s96Fiat7024198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Oct 2014 08:44:39 -0700 (PDT) Message-ID: <5432B8E6.7050108@isi.edu> Date: Mon, 06 Oct 2014 08:44:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> <542EF0BA.2070604@isi.edu> <08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk> <5432B4E1.1050908@isi.edu> In-Reply-To: <5432B4E1.1050908@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/juep3_LH3n5_MmaKGA_zq44NN_E Cc: IPv6 Operations , Fernando Gont , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" , V6ops Chairs Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:45:50 -0000 On 10/6/2014 8:27 AM, Joe Touch wrote: > ... > Although I appreciate that everyone thinks that "this can be > coordinated", we're seeing ample evidence to the contrary. It's useful > to note here that NEITHER DOC REFERENCES THE OTHER, despite being > written by the same author (which begs the question of "end run"). Correction: the latest OPSEC doc does cite the V6OPS one in a throw-away sentence of the intro, but fails to explain in detail how the two docs are linked. (it also cites "recent studies" - plural - even though only the authors' own study is the only one cited) Joe From nobody Mon Oct 6 14:36:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6277B1A8A51 for ; Mon, 6 Oct 2014 14:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.414 X-Spam-Level: X-Spam-Status: No, score=0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eVZfryHfPdc for ; Mon, 6 Oct 2014 14:36:29 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D04B1A1A19 for ; Mon, 6 Oct 2014 14:36:29 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so3615019igc.6 for ; Mon, 06 Oct 2014 14:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zcpy58hBXdppM+WfYX7l6MfuscpvUYlI4CuFNPA862E=; b=kA/t9JCoCDl9CMOhyMOHHbMYmZrkSSZoIveqZ/QF4Pe+ZrNm1k59vhX62B3pdf6j1o c+T/jPYKqn6Nm5RTQ2/Yz8oUS/igkqUbNLWWd/bFpK0pe9Kba9S+WbahyO1nVoo6KIZb qaGFLNMnor5kXlmbgob632gCDsvcTCjIAyaHxWJ0cZ0otuggRdXYpZnvREtI6IF67UF/ jCYqX7hpMhO5pR+GldidsldRGjGB2n10ndhgoXU3ADhiFTB32QCQtNx/9P5jSc/0x9g7 c/b0CeFP9TY2zTgJwvmrV4AxuCqQ9SNhk3k1+3mvQBkjI3G8vhR+cRqyJOLMVk9W7BwQ 5l1Q== MIME-Version: 1.0 X-Received: by 10.43.61.4 with SMTP id wu4mr6896819icb.77.1412631388846; Mon, 06 Oct 2014 14:36:28 -0700 (PDT) Received: by 10.107.137.231 with HTTP; Mon, 6 Oct 2014 14:36:28 -0700 (PDT) In-Reply-To: <5432344D.1010007@fud.no> References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <5432344D.1010007@fud.no> Date: Mon, 6 Oct 2014 23:36:28 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OSREv367mqvG1-R7IjX4dgiCrr8 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:36:31 -0000 Tore, A few thoughts/nits about both of the drafts. draft-anderson-v6ops-siit-dc: "4.1. Application Support for NAT" might also mention the apps that use the IP ID (this is mainly diagnostic stuff like tcptraceroute) - adding the host agent would not get them to work. "4.7. Migration from Dual Stack" says about using the DNS round robin to migrate from dual stack. Do you mean having IPv6 native, IPv4 native and IPv4-translated addresses in the DNS replies sent to the client ? Sounds like this would add quite a lot of complexity, but maybe I am reading it incorrectly. "4.8.2. IPv6 Atomic Fragments" If the application does use the IPv4 ID bit (though it might be deemed as corner case), and you do the dc-xlat, might be beneficial to always add the atomic fragments - this way one can recover (at least in theory) the IPv4 ID back. "4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6" I observed somewhat subtle interactions when translating ICMPv4 into ICMPv6: ICMPv4 spec (rfc792) says to include just the IP header + 64 bits of the original packet that triggered the ICMP, while the ICMPv6 (RFC4443) has a "MUST" in 2.4c to include as much of original message as possible without violating the MTU.. - so if an application relies on extra info *and* the intermediate node does not provide that, it might fail. (NB: In my tests, some IPv4 boxes do give more than IP+64bit, some do not..) Also: since on the v4->v6 path the fragments can be definitely smaller than 1280 bytes, is it worth mentioning in this section that the server may have to reassemble the smaller fragments than 1280 and more ? Another tricky case that might arise in this scenario is if ICMPv4 was sent big enough to be fragmented on the way. The translator (if it does not do at least the virtual reassembly) does not know the full length of the reassembled ICMPv6 packet, but has to add it as part of the checksum calculation. "5.2. Static Address Mapping Function" There should be discussion or at least a reference about the translation and checksum neutrality similar to http://tools.ietf.org/html/rfc6052#section-4.1 - some things that are possible to do with a checksum-neutral transform, are not possible without it - as mentioned in http://tools.ietf.org/html/rfc6052#section-4.1. "5.4. Loop Prevention Mechanism" In the v6->v4 direction, one can send a packet sourced from the server within a Static Address Mapping IPv6 address to a /128 within SIIT preffix that maps to the same IPv4 address - as a result causing the reinjection of an IPv4 packet with src=dst=server_IPv4_public_address, thus causing a translation into IPv6 with src=dst=server_IPv6_static_address_mapping address and delivered back to the server. On quick look it should be harmless, but the fact that this ambiguity exists, is probably worth mentioning maybe - also since it was not there in pure SIIT. draft-anderson-v6ops-siit-dc-2xlat: Probably discussing a new scenario compared to 464XLAT, namely, the communication between the two servers within the DC between the IPv4 legacy apps, let's follow a path of (src, dst) pair: Initial (4A,4B) packet seen by host agent A will be translated into (S6A, SIIT6B), then sent to the SIIT-DC, where it will be translated into (4A, 4B), then routed back, then translated as (S6A, S6B), then sent to host agent B, then translated to (4A,4B). The reply to this packet will be sent as (4B, 4A), translated by the host agent B to (S6B, SIIT6B), then hits SIIT-DC, gets translated to (4B, 4A), hits SIIT-DC again, gets translated to (S6B, S6A), sent to host A, there translated by host agent A to (4B, 4A). This pattern creates a traffic visibility issue and makes a SIIT-DC a potential bottleneck - since they are located at the edge of the network - so is worth mentioning/discussing. On the topic of running code: could be fun to kick the tires of https://github.com/ayourtch/nat46/tree/master/nat46/modules with regard to using it as a host agent, it might work though it might require a bit too much plumbing (routing + ND proxy on the outer interface) to be practically usable ? --a On 10/6/14, Tore Anderson wrote: > Hello, > > As Brian was quick to notice, I've uploaded a new version of the SIIT-DC > draft. I would like to solicit the WG's input on the draft (and its > companion draft[1]), in particular whether or not the work is seen as > relevant and useful, and any feedback or suggestions big or small on how > to further improve it. (Do feel free to send me minor issues in direct > e-mail if you prefer no to "spam" the WG list with them.) > > [1] https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc-2xlat/ > > Also, since running code is important, I'd like to point out that there > are several implementations that implement an SIIT-DC Gateway (or > something very close to the spec), from the top of my head and in > alphabetical order: Brocade ADX, Cisco ASR1k, F5 BIG-IP LTM, and > Linux/TAYGA. There's also an SIIT-DC Host Agent available at > https://github.com/toreanderson/clatd (using Linux/TAYGA). > > Best regards, > Tore Anderson > > -------- Forwarded Message -------- > Subject: I-D Action: draft-anderson-v6ops-siit-dc-01.txt > Date: Sun, 05 Oct 2014 11:54:23 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Newsgroups: gmane.ietf.announce > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SIIT-DC: Stateless IP/ICMP Translation for IPv6 > Data Centre Environments > Author : Tore Anderson > Filename : draft-anderson-v6ops-siit-dc-01.txt > Pages : 30 > Date : 2014-10-05 > > Abstract: > This document describes SIIT-DC, an extension to Stateless IP/ICMP > Translation (SIIT) [RFC6145] that makes it ideally suited for use in > IPv6 data centre environments. SIIT-DC simultaneously facilitates > IPv6 deployment and IPv4 address conservation. The overall SIIT-DC > architecture is described, as well as guidelines for operators. > Finally, the normative implementation requirements are described, as > a list of additions and changes to SIIT [RFC6145]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-anderson-v6ops-siit-dc-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-siit-dc-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Oct 6 17:09:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EFD1A90EB for ; Mon, 6 Oct 2014 17:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.773 X-Spam-Level: X-Spam-Status: No, score=-113.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_iqgZEk8vHR for ; Mon, 6 Oct 2014 17:09:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081A71A90DE for ; Mon, 6 Oct 2014 17:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2631; q=dns/txt; s=iport; t=1412640569; x=1413850169; h=from:to:cc:subject:date:message-id:mime-version; bh=38WZqmSwY/upUB5leFUGpXAPOn+0x0TXg7jaxFft+sc=; b=D4iJGKrkwh8+uWvJzF27tx+kMuIUbEIEREEmZu8Kw2Y+ZiaqoBHYTbta pBxRW74ioJ65TAcL/wO2JEtUYf/2PjBEJwRM1dpkYzyKj/5cXMJYBGUH+ HVbHsYqnXGq5936rqLCEuFML8DMf89hKBZb2WmPXEvsuWKgUR42MwyB2n 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFADUuM1StJA2M/2dsb2JhbABfgw5TWQPMJodLgQ0WAXuECnkSAYEAJwQOE4gwDcFAAReQRYRSBZF0gguBTGWHDoFolBiDY4I0gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,666,1406592000"; d="asc'?scan'208";a="361203177" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 07 Oct 2014 00:09:28 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9709SSq031879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Oct 2014 00:09:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 19:09:28 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: Preparing IETF 91 agenda Thread-Index: AQHP4cL1tWzp/Fx1J0yCrTr4zVbS7g== Date: Tue, 7 Oct 2014 00:09:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_1DCA486C-0B9D-4474-8944-B0D2E209D7CA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1UzKAGZ0TdgC6ymOBVIx7QClkx4 Subject: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 00:09:31 -0000 --Apple-Mail=_1DCA486C-0B9D-4474-8944-B0D2E209D7CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As I mentioned last week, Lee and I are pulling together an agenda for = IETF 91. The drop-dead date for new or updated drafts is 27 October, and = frankly it will work better if drafts arrive earlier - as we are looking = for working group commentary on them. Current state of play: IESG: Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis IETF Last Call: Sep 26 draft-ietf-v6ops-mobile-device-profile Working Group Document updated since IETF: Sep 18 draft-ietf-v6ops-design-choices Individual Submission updated since IETF: Aug 24 draft-v6ops-pmtud-ecmp-problem On list, Ray Hunter suggests someone write "a draft = summarizing the ICMP PTB problem" Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world There has been some discussion on-list.=20 Sep 15 draft-anderson-v6ops-siit-dc-2xlat No list commentary Sep 18 draft-elkins-v6ops-multicast-virtual-nodes Some commentary, not supportive Sep 18 draft-wang-v6ops-xlat-prefix-discovery A fair amount of discussion, mostly anti-NAT. Sep 25 draft-ybai-v6ops-ipv6-for-openstack no list commentary Oct 5 draft-anderson-v6ops-siit-dc Some list commentary Working Group Document NOT updated since IETF: Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem Jul 4 draft-ietf-v6ops-ula-usage-recommendations Individual Submission NOT updated since IETF: Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node Jul 3 draft-liu-v6ops-running-multiple-prefixes Jul 4 draft-sun-v6ops-xlat-multi Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x Jul 20 draft-wang-v6ops-flow-label-refelction Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance more data at = http://datatracker.ietf.org/doc/search/?sort=3Dstatus&activedrafts=3Don&na= me=3Dv6ops --Apple-Mail=_1DCA486C-0B9D-4474-8944-B0D2E209D7CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUMy82bjEdbHIsm0MRAjAZAKCUlqjtHZhJFhS9Ekpe/eyZ/ZDFhQCfVHUZ vrvoC5bAOvL/v7yD8Mly5Ew= =V7Xr -----END PGP SIGNATURE----- --Apple-Mail=_1DCA486C-0B9D-4474-8944-B0D2E209D7CA-- From nobody Mon Oct 6 18:23:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8C51A90FA for ; Mon, 6 Oct 2014 18:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahykovz8jkmH for ; Mon, 6 Oct 2014 18:23:01 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2DF1A90FE for ; Mon, 6 Oct 2014 18:23:01 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s971MfsO038927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Oct 2014 01:22:42 GMT (envelope-from joelja@bogus.com) Message-ID: <5433406A.5060401@bogus.com> Date: Mon, 06 Oct 2014 18:22:50 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , IPv6 Operations References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3NTQv9mPqEGP2LENbMoB4GiqMtDTC7RTq" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9O7qMjdG2Vk9mqFGholI1FI1PHU Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 01:23:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3NTQv9mPqEGP2LENbMoB4GiqMtDTC7RTq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/6/14 5:09 PM, Fred Baker (fred) wrote: > As I mentioned last week, Lee and I are pulling together an agenda for = IETF 91. The drop-dead date for new or updated drafts is 27 October, and = frankly it will work better if drafts arrive earlier - as we are looking = for working group commentary on them. >=20 > Current state of play: >=20 > IESG: > Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 > Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis >=20 > IETF Last Call: > Sep 26 draft-ietf-v6ops-mobile-device-profile >=20 > Working Group Document updated since IETF: > Sep 18 draft-ietf-v6ops-design-choices >=20 > Individual Submission updated since IETF: > Aug 24 draft-v6ops-pmtud-ecmp-problem > On list, Ray Hunter suggests someone write "a draft summari= zing the ICMP PTB problem" Imho that fine by me and I might be willing to contribute if someone picks up the pen, but it's not the problem I have really. the problem I have in specific is not dropping the packets I do receive on the floor, which is an operational one for which I have a mitigation. I don't expect further discussion for the existing draft is warranted at this meeting since it was largely revved to address commentary from the last meeting. thanks joel > Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world > There has been some discussion on-list.=20 > Sep 15 draft-anderson-v6ops-siit-dc-2xlat > No list commentary > Sep 18 draft-elkins-v6ops-multicast-virtual-nodes > Some commentary, not supportive > Sep 18 draft-wang-v6ops-xlat-prefix-discovery > A fair amount of discussion, mostly anti-NAT. > Sep 25 draft-ybai-v6ops-ipv6-for-openstack > no list commentary > Oct 5 draft-anderson-v6ops-siit-dc > Some list commentary >=20 > Working Group Document NOT updated since IETF: > Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem > Jul 4 draft-ietf-v6ops-ula-usage-recommendations >=20 > Individual Submission NOT updated since IETF: > Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node > Jul 3 draft-liu-v6ops-running-multiple-prefixes > Jul 4 draft-sun-v6ops-xlat-multi > Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x > Jul 20 draft-wang-v6ops-flow-label-refelction > Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance >=20 > more data at http://datatracker.ietf.org/doc/search/?sort=3Dstatus&acti= vedrafts=3Don&name=3Dv6ops >=20 --3NTQv9mPqEGP2LENbMoB4GiqMtDTC7RTq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQzQGoACgkQ8AA1q7Z/VrIttwCaAkRIVxzQxs7qk6p7CUf9mALJ VyoAn3731yliGyy4a2dhGbxh5XmJ2OZW =I4hG -----END PGP SIGNATURE----- --3NTQv9mPqEGP2LENbMoB4GiqMtDTC7RTq-- From nobody Tue Oct 7 00:25:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB011A9169 for ; Tue, 7 Oct 2014 00:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H85FcZlkFNG0 for ; Tue, 7 Oct 2014 00:25:06 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19E31A913F for ; Tue, 7 Oct 2014 00:24:13 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=35287 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XbP80-0000vR-15; Tue, 07 Oct 2014 09:24:12 +0200 Message-ID: <5433951A.70107@fud.no> Date: Tue, 07 Oct 2014 09:24:10 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <5432344D.1010007@fud.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qvdw0WxBXTjOIERUqPnugzqAeBM Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 07:25:09 -0000 Hi Andrew, Thanks for your feedback, I'll update the drafts to include it sometime this week and ping you off-list to check if you agree with the changes further comments in-line. * Andrew 👽 Yourtchenko > A few thoughts/nits about both of the drafts. > > draft-anderson-v6ops-siit-dc: > > "4.1. Application Support for NAT" might also mention the apps that > use the IP ID (this is mainly diagnostic stuff like tcptraceroute) - > adding the host agent would not get them to work. Ack, look into this and see if I can mention something about it. Though when I'm talking about "application support" here I'm really referring to the main service itself (e.g., HTTP, FTP, SMTP, and so on). > "4.7. Migration from Dual Stack" says about using the DNS round robin > to migrate from dual stack. Do you mean having IPv6 native, IPv4 > native and IPv4-translated addresses in the DNS replies sent to the > client ? Sounds like this would add quite a lot of complexity, but > maybe I am reading it incorrectly. Yes, if you have a service that's currently serving IPv4 traffic nativly using a number of IN A records for load balancing purposes, for example: service.tld. IN A 192.0.2.1 ; native IN A 192.0.2.2 ; native [..] IN A 192.0.2.10 ; native You could gradually migrate traffic to SIIT-DC by adding/replacing individual records pointing to SIIT-DC IPv4 Service Addresses, like so: service.tld. IN A 192.0.2.1 ; native IN A 192.0.2.2 ; native [..] IN A 192.0.2.9 ; native IN A 203.0.113.1 ; SIIT-DC Now you could expect that ~10% of your IPv4 client traffic will move to the SIIT-DC system, while ~90% remains native. If you're happy with the way it works, you can continue migrating until there's no native addresses left, at which point you can remove them from the servers/load balancers if you want. I was thinking this would be a more gentle approach than switching all traffic at once, particularly for high-volume servers. > "4.8.2. IPv6 Atomic Fragments" > > If the application does use the IPv4 ID bit (though it might be deemed > as corner case), and you do the dc-xlat, might be beneficial to always > add the atomic fragments - this way one can recover (at least in > theory) the IPv4 ID back. True, but are there any actual applications (as in, not network diagnostics, but actual services) out there that care about the IPv4 Identification value? > "4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6" > > I observed somewhat subtle interactions when translating ICMPv4 into > ICMPv6: ICMPv4 spec (rfc792) says to include just the IP header + 64 > bits of the original packet that triggered the ICMP, while the ICMPv6 > (RFC4443) has a "MUST" in 2.4c to include as much of original message > as possible without violating the MTU.. - so if an application relies > on extra info *and* the intermediate node does not provide that, it > might fail. (NB: In my tests, some IPv4 boxes do give more than > IP+64bit, some do not..) Right.. This is a property of SIIT/RFC6145 though, it's not specific to SIIT-DC. The translator will just translate whatever information is there. > Also: since on the v4->v6 path the fragments can be definitely smaller > than 1280 bytes, is it worth mentioning in this section that the > server may have to reassemble the smaller fragments than 1280 and more > ? I don't think there's any requirement in any spec that a reassembled IPv6 packet must be larger than or equal to 1280 in size for it to be valid? I think it's worth mentioning only if it is likely to cause problems. My gut feeling says it isn't, but do you have any examples that demonstrate otherwise? (Individual fragments being smaller than 1280 is certainly valid and common too.) > Another tricky case that might arise in this scenario is if ICMPv4 was > sent big enough to be fragmented on the way. The translator (if it > does not do at least the virtual reassembly) does not know the full > length of the reassembled ICMPv6 packet, but has to add it as part of > the checksum calculation. Yep, fragmented ICMP messages will not be translated, cf. RFC6145 section 1.2. > "5.2. Static Address Mapping Function" > > There should be discussion or at least a reference about the > translation and checksum neutrality similar to > http://tools.ietf.org/html/rfc6052#section-4.1 - some things that are > possible to do with a checksum-neutral transform, are not possible > without it - as mentioned in > http://tools.ietf.org/html/rfc6052#section-4.1. Ack. > "5.4. Loop Prevention Mechanism" > > In the v6->v4 direction, one can send a packet sourced from the server > within a Static Address Mapping IPv6 address to a /128 within SIIT > preffix that maps to the same IPv4 address - as a result causing the > reinjection of an IPv4 packet with src=dst=server_IPv4_public_address, > thus causing a translation into IPv6 with > src=dst=server_IPv6_static_address_mapping address and delivered back > to the server. On quick look it should be harmless, but the fact that > this ambiguity exists, is probably worth mentioning maybe - also since > it was not there in pure SIIT. That's a clever way for a server to do a health test of the SIIT-DC GW, actually. :-) But it would be a bit unreliable, as it could trip uRPF filters along the way back. I agree it doesn't seem like a security issue though, as the server can send packets to itself in much less complex ways, too... > draft-anderson-v6ops-siit-dc-2xlat: > > Probably discussing a new scenario compared to 464XLAT, namely, the > communication between the two servers within the DC between the IPv4 > legacy apps, let's follow a path of (src, dst) pair: > > Initial (4A,4B) packet seen by host agent A will be translated into > (S6A, SIIT6B), then sent to the SIIT-DC, where it will be translated > into (4A, 4B), then routed back, then translated as (S6A, S6B), then > sent to host agent B, then translated to (4A,4B). The reply to this > packet will be sent as (4B, 4A), translated by the host agent B to > (S6B, SIIT6B), then hits SIIT-DC, gets translated to (4B, 4A), hits > SIIT-DC again, gets translated to (S6B, S6A), sent to host A, there > translated by host agent A to (4B, 4A). > > This pattern creates a traffic visibility issue and makes a SIIT-DC a > potential bottleneck - since they are located at the edge of the > network - so is worth mentioning/discussing. Ack. I'll try to add a section on hairpinning. > On the topic of running code: could be fun to kick the tires of > https://github.com/ayourtch/nat46/tree/master/nat46/modules with > regard to using it as a host agent, it might work though it might > require a bit too much plumbing (routing + ND proxy on the outer > interface) to be practically usable ? Well, routing and ND proxy you can handle from user space. If you look at my clatd, it's basically just a perl script that discovers the required network environment, sets up routing/ND proxy/etc and fires up TAYGA with the right configuration. If your module supports basic RFC6145 plus the static mapping stuff, it is probably possible to adapt the script to use your module instead of TAYGA. I'll try to play a bit with it later, thanks for the pointer! Tore From nobody Tue Oct 7 02:30:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC791ACCDC; Tue, 7 Oct 2014 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0reDh64Tkp_q; Tue, 7 Oct 2014 02:30:49 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0E21A1B60; Tue, 7 Oct 2014 02:30:48 -0700 (PDT) Received: from [194.106.220.51:48014] by server-7.bemta-14.messagelabs.com id 2F/1E-13362-7C2B3345; Tue, 07 Oct 2014 09:30:47 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-8.tower-92.messagelabs.com!1412674246!19123008!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16817 invoked from network); 7 Oct 2014 09:30:46 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-8.tower-92.messagelabs.com with SMTP; 7 Oct 2014 09:30:46 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Tue, 07 Oct 2014 10:41:45 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 10:30:34 +0100 From: "Heatley, Nick" To: Lorenzo Colitti , IETF Discussion Thread-Topic: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHP3lgstOYuetH+dkamfUnp7cN2RpwioU0AgAG2U0A= Date: Tue, 7 Oct 2014 09:30:33 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303BDD125UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WK36zUKbw-Sjvlo2fL0eBwXOh28 Cc: "v6ops@ietf.org WG" , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:30:51 -0000 --_000_6536E263028723489CCD5B6821D4B21303BDD125UK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Mi4gSSBzdGFuZCBieSBteSBlYXJsaWVyIGFzc2Vzc21lbnQgdGhhdCB0aGlzIGRvY3VtZW50J3Mg cmVxdWlyZW1lbnRzIGFyZSBvdmVyLWJyb2FkLCBhbmQgaW4gZmFjdCBzbyBicm9hZCBhcyB0byBo YXJtIGFkb3B0aW9uLiBUaGVyZSBtYXkgd2VsbCBiZSBvcGVyYXRvcnMgb3IgZGV2aWNlIGltcGxl bWVudGVycyB0aGF0IHNlZWluZyB3aXRoIHN1Y2ggYSBoaWdoIG51bWJlciBvZiByZXF1aXJlbWVu dHMgbWF5IHNoeSBhd2F5IGluIHRlcnJvciBhbmQgdGhpbmsgdGhhdCBkZXBsb3lpbmcgSVB2NiBp biBhIG1vYmlsZSBuZXR3b3JrIGlzIGFuIGltcG9zc2libHkgaGlnaCBhbW91bnQgb2Ygd29yay4g VGhhdCBzYWlkLCBnaXZlbiB0aGF0IHRoaXMgZG9jdW1lbnQgc2F5cyBjbGVhcmx5IHRoYXQgaXQg aXMgbm90IGEgc3RhbmRhcmQsIGFuZCB0aGF0IGNvbXBsaWFuY2UgaXMgbm90IHJlcXVpcmVkLCB0 aGUgaGFybSBpdCBkb2VzIHdpbGwgYmUgbGltaXRlZC4NCg0KVGhlcmUgbWF5IHdlbGwgYmUgb3Bl cmF0b3JzIGFuZCBkZXZpY2UgaW1wbGVtZW50ZXJzIHRoYXQgc2VlIHRoZSBtYW55IGluZGl2aWR1 YWwg4oCcSVB2NuKAnSBSRkNzIGFuZCBzaHkgYXdheS4gVHJhbnNpdGlvbmluZyB0ZWNobm9sb2dp ZXMgYXJlIHN0aWxsIHBlcmNlaXZlZCBhcyBpc3N1ZXMgZm9yIHRoZSBuZXR3b3JrLg0KSWYgdGhp cyBjcm9zcy1vcGVyYXRvciBkb2N1bWVudCBzdGF0ZXMgd2hhdCBpcyByZXF1aXJlZCBvbiB0ZXJt aW5hbHMgdG8gd29yayBpbiBhbGwgbWFqb3IvcHJlZGljdGFibGUgSVB2NiBzY2VuYXJpb3MsIHRo ZW4gaXQgaXMgZ2l2aW5nIHN1Y2ggcGVvcGxlIGEgdmlldyBvZiB3aGF0IGEg4oCcaGVhbHRoeSBh bmQgcm9idXN04oCdIHRlcm1pbmFsIGltcGxlbWVudGF0aW9uIHdvdWxkIGNvbnNpc3Qgb2YuIElm IHRoZXkgYXJlIGFibGUgdG8gZGVsaXZlciBvbiB0aGVzZSByZXF1aXJlbWVudHMgdGhlbiB0aGV5 IGNhbiBzdXBwbHkgYSB0ZXJtaW5hbCByZWFkeSBmb3IgYWxsIGJ1c2luZXNzIGFyZWFzIC9hbGwg b3BlcmF0b3IgbmV0d29yayBzY2VuYXJpb3MuDQooSXQgY2VydGFpbmx5IHN0b3BzIHRoZSBmZWVk YmFjayBJ4oCZdmUgaGFkIGZyb20gY2VydGFpbiBjb3JuZXJzIOKAnHRoYXQgbm8gb3RoZXIgb3Bl cmF0b3JzIGFyZSBhc2tpbmcgZm9yIElQdjbigJ0sIGFuZCDigJx3aGF0IHlvdSBhcmUgYXNraW5n IGZvciBpcyBhIHNpbmdsZSBvcGVyYXRvciByb2FkbWFwIHdoaWNoIHdlIHdvbuKAmXQgZG/igJ0u IFRoYXQgaGFzIGJlZW4gdGhlIHJlYWxpdHkgaGVyZSkuIFNvIEkgZG9u4oCZdCBzZWUgaG93IGEg Y29uc29saWRhdGVkIGRlbWFuZC1zaWRlIHZpZXcgZnJvbSBvcGVyYXRvcnMgd2hvIGFyZSByZWFs bHkgdHJ5aW5nIHRvIGludHJvZHVjZSBJUHY2ICBpbiBtb2JpbGUgY2FuIGhhcm0gYWRvcHRpb24g aW4gYW55IHdheS4NClJlZ2FyZHMsDQpOaWNrDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogMDYg T2N0b2JlciAyMDE0IDA4OjMwDQpUbzogSUVURiBEaXNjdXNzaW9uDQpDYzogdjZvcHNAaWV0Zi5v cmcgV0c7IElFVEYtQW5ub3VuY2UNClN1YmplY3Q6IFJlOiBbdjZvcHNdIExhc3QgQ2FsbDogPGRy YWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTEzLnR4dD4gKEFuIEludGVybmV0 IFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNl cykgdG8gSW5mb3JtYXRpb25hbCBSRkMNCg0KDQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhp cyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIGZvciB0aGUg YWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVtYWlsIGZy b20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFueSBwdXJwb3Nl LiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGVtYWlscyBp biBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBl bnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2 aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2 aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0ZWQNClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IDAy MzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0 byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVw0K --_000_6536E263028723489CCD5B6821D4B21303BDD125UK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4y LiBJIHN0YW5kIGJ5IG15IGVhcmxpZXIgYXNzZXNzbWVudCB0aGF0IHRoaXMgZG9jdW1lbnQncyBy ZXF1aXJlbWVudHMgYXJlIG92ZXItYnJvYWQsIGFuZCBpbiBmYWN0IHNvIGJyb2FkIGFzIHRvIGhh cm0gYWRvcHRpb24uIFRoZXJlIG1heSB3ZWxsIGJlIG9wZXJhdG9ycyBvciBkZXZpY2UgaW1wbGVt ZW50ZXJzIHRoYXQgc2VlaW5nIHdpdGggc3VjaCBhIGhpZ2ggbnVtYmVyDQogb2YgcmVxdWlyZW1l bnRzIG1heSBzaHkgYXdheSBpbiB0ZXJyb3IgYW5kIHRoaW5rIHRoYXQgZGVwbG95aW5nIElQdjYg aW4gYSBtb2JpbGUgbmV0d29yayBpcyBhbiBpbXBvc3NpYmx5IGhpZ2ggYW1vdW50IG9mIHdvcmsu IFRoYXQgc2FpZCwgZ2l2ZW4gdGhhdCB0aGlzIGRvY3VtZW50IHNheXMgY2xlYXJseSB0aGF0IGl0 IGlzIG5vdCBhIHN0YW5kYXJkLCBhbmQgdGhhdCBjb21wbGlhbmNlIGlzIG5vdCByZXF1aXJlZCwg dGhlIGhhcm0gaXQgZG9lcw0KIHdpbGwgYmUgbGltaXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgbWF5IHdlbGwgYmUg b3BlcmF0b3JzIGFuZCBkZXZpY2UgaW1wbGVtZW50ZXJzIHRoYXQgc2VlIHRoZSBtYW55IGluZGl2 aWR1YWwg4oCcSVB2NuKAnSBSRkNzIGFuZCBzaHkgYXdheS4gVHJhbnNpdGlvbmluZyB0ZWNobm9s b2dpZXMgYXJlIHN0aWxsIHBlcmNlaXZlZCBhcw0KIGlzc3VlcyBmb3IgdGhlIG5ldHdvcmsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoaXMgY3Jvc3Mtb3BlcmF0b3IgZG9jdW1l bnQgc3RhdGVzIHdoYXQgaXMgcmVxdWlyZWQgb24gdGVybWluYWxzIHRvIHdvcmsgaW4gYWxsIG1h am9yL3ByZWRpY3RhYmxlIElQdjYgc2NlbmFyaW9zLCB0aGVuIGl0IGlzIGdpdmluZyBzdWNoIHBl b3BsZSBhIHZpZXcgb2YNCiB3aGF0IGEg4oCcaGVhbHRoeSBhbmQgcm9idXN04oCdIHRlcm1pbmFs IGltcGxlbWVudGF0aW9uIHdvdWxkIGNvbnNpc3Qgb2YuIElmIHRoZXkgYXJlIGFibGUgdG8gZGVs aXZlciBvbiB0aGVzZSByZXF1aXJlbWVudHMgdGhlbiB0aGV5IGNhbiBzdXBwbHkgYSB0ZXJtaW5h bCByZWFkeSBmb3IgYWxsIGJ1c2luZXNzIGFyZWFzIC9hbGwgb3BlcmF0b3IgbmV0d29yayBzY2Vu YXJpb3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEl0IGNlcnRhaW5seSBzdG9w cyB0aGUgZmVlZGJhY2sgSeKAmXZlIGhhZCBmcm9tIGNlcnRhaW4gY29ybmVycyDigJx0aGF0IG5v IG90aGVyIG9wZXJhdG9ycyBhcmUgYXNraW5nIGZvciBJUHY24oCdLCBhbmQg4oCcd2hhdCB5b3Ug YXJlIGFza2luZyBmb3IgaXMgYSBzaW5nbGUgb3BlcmF0b3INCiByb2FkbWFwIHdoaWNoIHdlIHdv buKAmXQgZG/igJ0uIFRoYXQgaGFzIGJlZW4gdGhlIHJlYWxpdHkgaGVyZSkuIFNvIEkgZG9u4oCZ dCBzZWUgaG93IGEgY29uc29saWRhdGVkIGRlbWFuZC1zaWRlIHZpZXcgZnJvbSBvcGVyYXRvcnMg d2hvIGFyZSByZWFsbHkgdHJ5aW5nIHRvIGludHJvZHVjZSBJUHY2ICZuYnNwO2luIG1vYmlsZSBj YW4gaGFybSBhZG9wdGlvbiBpbiBhbnkgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaWNrPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8 L2I+IDA2IE9jdG9iZXIgMjAxNCAwODozMDxicj4NCjxiPlRvOjwvYj4gSUVURiBEaXNjdXNzaW9u PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZyBXRzsgSUVURi1Bbm5vdW5jZTxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLXY2b3Bz LW1vYmlsZS1kZXZpY2UtcHJvZmlsZS0xMy50eHQmZ3Q7IChBbiBJbnRlcm5ldCBQcm90b2NvbCBW ZXJzaW9uIDYgKElQdjYpIFByb2ZpbGUgZm9yIDNHUFAgTW9iaWxlIERldmljZXMpIHRvIEluZm9y bWF0aW9uYWwgUkZDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQo8UD5OT1RJQ0UgQU5EIERJU0NMQUlNRVI8QlI+VGhpcyBl LW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVkIA0KZm9yIHRoZSBh Ym92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIA0Kbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlzIGVt YWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCANCmRpc2Nsb3NlIG9yIHVzZSBmb3IgYW55 IHB1cnBvc2UuJm5ic3A7IDxCUj4mbmJzcDs8QlI+V2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5n IA0KYW5kIG91dGdvaW5nIGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4g V2UgaGF2ZSB0YWtlbiBzdGVwcyB0byANCmVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFj aG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyANCnlvdXIgcmVz cG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVj dCB5b3UuIDwvUD4NCjxQPkVFIExpbWl0ZWQ8QlI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBX YWxlczxCUj5Db21wYW55IFJlZ2lzdGVyZWQgTnVtYmVyOiANCjAyMzgyMTYxPEJSPlJlZ2lzdGVy ZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQgUGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQs IA0KSGVydGZvcmRzaGlyZSwgQUwxMCA5Qlc8L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6536E263028723489CCD5B6821D4B21303BDD125UK30S005EXS06EE_-- From nobody Tue Oct 7 02:51:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD8A1ACD5B for ; Tue, 7 Oct 2014 02:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og6p3PnYkz1k for ; Tue, 7 Oct 2014 02:51:02 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7170B1ACD3B for ; Tue, 7 Oct 2014 02:51:02 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so4847426iec.23 for ; Tue, 07 Oct 2014 02:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wtK8TVIKzEYCqFVtWD3wHofZwbHXm2+Ucqv+rFOTHZU=; b=ItcwybH8WGVLDs3jpqz6aaen+BebXLiSV8X/X3pbJD1IpnWOn+jkSZzQgu8Sr3X7lN 83g4VIhr50I9ygVJdGXl53IxDUQOfMOeCj6Gc8Td/z2UuEyw4kAoFmI7ulU42dNY5pCj lu4pHLU3nCFHqmancotO7eeCL5+QKR7kceCB1zFy42tETcjHa/ymUQZsZIbjgb1dplM5 U2ivWzkytbhifcwxSXCbb7jwvlA2XoguxHFMC+7aN2EAPvJRBNto8zxbfyzvuS3A7y+6 WM+eoagPWfWvFNrR/tCjwW/M7LOwnp08Iuj4ngC3bFroMMkAxTwWzXZI8wVWbhgN/Xul bFJg== MIME-Version: 1.0 X-Received: by 10.42.94.12 with SMTP id z12mr3236080icm.46.1412675461833; Tue, 07 Oct 2014 02:51:01 -0700 (PDT) Received: by 10.107.137.231 with HTTP; Tue, 7 Oct 2014 02:51:01 -0700 (PDT) In-Reply-To: <5433951A.70107@fud.no> References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <5432344D.1010007@fud.no> <5433951A.70107@fud.no> Date: Tue, 7 Oct 2014 11:51:01 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Tore Anderson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HX9ILcyCFMsQds9PoEWhx6LxnP4 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:51:04 -0000 Hi Tore, On 10/7/14, Tore Anderson wrote: > Hi Andrew, > > Thanks for your feedback, I'll update the drafts to include it sometime > this week and ping you off-list to check if you agree with the changes > further comments in-line. Thanks! some comments for comments inline. > > * Andrew =F0=9F=91=BD Yourtchenko > >> A few thoughts/nits about both of the drafts. >> >> draft-anderson-v6ops-siit-dc: >> >> "4.1. Application Support for NAT" might also mention the apps that >> use the IP ID (this is mainly diagnostic stuff like tcptraceroute) - >> adding the host agent would not get them to work. > > Ack, look into this and see if I can mention something about it. > > Though when I'm talking about "application support" here I'm really > referring to the main service itself (e.g., HTTP, FTP, SMTP, and so on). Right. I didn't know if there are corner cases that are similar to this one, so it is a strawman indeed. A single-session client-initiated protocols should generally be fine. > >> "4.7. Migration from Dual Stack" says about using the DNS round robin >> to migrate from dual stack. Do you mean having IPv6 native, IPv4 >> native and IPv4-translated addresses in the DNS replies sent to the >> client ? Sounds like this would add quite a lot of complexity, but >> maybe I am reading it incorrectly. > > Yes, if you have a service that's currently serving IPv4 traffic nativly > using a number of IN A records for load balancing purposes, for example: > > service.tld. IN A 192.0.2.1 ; native > IN A 192.0.2.2 ; native > [..] > IN A 192.0.2.10 ; native > > You could gradually migrate traffic to SIIT-DC by adding/replacing > individual records pointing to SIIT-DC IPv4 Service Addresses, like so: > > > service.tld. IN A 192.0.2.1 ; native > IN A 192.0.2.2 ; native > [..] > IN A 192.0.2.9 ; native > IN A 203.0.113.1 ; SIIT-DC > > Now you could expect that ~10% of your IPv4 client traffic will move to > the SIIT-DC system, while ~90% remains native. If you're happy with the > way it works, you can continue migrating until there's no native > addresses left, at which point you can remove them from the servers/load > balancers if you want. I was thinking this would be a more gentle > approach than switching all traffic at once, particularly for > high-volume servers. Right, from dualstack you are moving to "triple-stack", with the third connection having the clientside properties of IPv4 and server-side properties of IPv6. I thought that would be tricky from the troubleshooting standpoint for the same reasons as dual-stack is trickier than single-stack. But I might be seeing a problem where there isn't. > >> "4.8.2. IPv6 Atomic Fragments" >> >> If the application does use the IPv4 ID bit (though it might be deemed >> as corner case), and you do the dc-xlat, might be beneficial to always >> add the atomic fragments - this way one can recover (at least in >> theory) the IPv4 ID back. > > True, but are there any actual applications (as in, not network > diagnostics, but actual services) out there that care about the IPv4 > Identification value? I don't know of any. But we can't claim that CLAT+DC-SIIT is fully equivalent to just IPv4 without it. I'm being pedantic, I know :-) > >> "4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6" >> >> I observed somewhat subtle interactions when translating ICMPv4 into >> ICMPv6: ICMPv4 spec (rfc792) says to include just the IP header + 64 >> bits of the original packet that triggered the ICMP, while the ICMPv6 >> (RFC4443) has a "MUST" in 2.4c to include as much of original message >> as possible without violating the MTU.. - so if an application relies >> on extra info *and* the intermediate node does not provide that, it >> might fail. (NB: In my tests, some IPv4 boxes do give more than >> IP+64bit, some do not..) > > Right.. This is a property of SIIT/RFC6145 though, it's not specific to > SIIT-DC. The translator will just translate whatever information is there= . Agreed. > >> Also: since on the v4->v6 path the fragments can be definitely smaller >> than 1280 bytes, is it worth mentioning in this section that the >> server may have to reassemble the smaller fragments than 1280 and more >> ? > > I don't think there's any requirement in any spec that a reassembled > IPv6 packet must be larger than or equal to 1280 in size for it to be > valid? I think it's worth mentioning only if it is likely to cause > problems. My gut feeling says it isn't, but do you have any examples > that demonstrate otherwise? > > (Individual fragments being smaller than 1280 is certainly valid and > common too.) You're right. For some reason I thought that the standards-compliant initial fragment should not be less than 1280, but that's not correct, thanks. > >> Another tricky case that might arise in this scenario is if ICMPv4 was >> sent big enough to be fragmented on the way. The translator (if it >> does not do at least the virtual reassembly) does not know the full >> length of the reassembled ICMPv6 packet, but has to add it as part of >> the checksum calculation. > > Yep, fragmented ICMP messages will not be translated, cf. RFC6145 > section 1.2. > Right. >> "5.2. Static Address Mapping Function" >> >> There should be discussion or at least a reference about the >> translation and checksum neutrality similar to >> http://tools.ietf.org/html/rfc6052#section-4.1 - some things that are >> possible to do with a checksum-neutral transform, are not possible >> without it - as mentioned in >> http://tools.ietf.org/html/rfc6052#section-4.1. > > Ack. > >> "5.4. Loop Prevention Mechanism" >> >> In the v6->v4 direction, one can send a packet sourced from the server >> within a Static Address Mapping IPv6 address to a /128 within SIIT >> preffix that maps to the same IPv4 address - as a result causing the >> reinjection of an IPv4 packet with src=3Ddst=3Dserver_IPv4_public_addres= s, >> thus causing a translation into IPv6 with >> src=3Ddst=3Dserver_IPv6_static_address_mapping address and delivered bac= k >> to the server. On quick look it should be harmless, but the fact that >> this ambiguity exists, is probably worth mentioning maybe - also since >> it was not there in pure SIIT. > > That's a clever way for a server to do a health test of the SIIT-DC GW, > actually. :-) But it would be a bit unreliable, as it could trip uRPF > filters along the way back. I agree it doesn't seem like a security > issue though, as the server can send packets to itself in much less > complex ways, too... True. :-) > >> draft-anderson-v6ops-siit-dc-2xlat: >> >> Probably discussing a new scenario compared to 464XLAT, namely, the >> communication between the two servers within the DC between the IPv4 >> legacy apps, let's follow a path of (src, dst) pair: >> >> Initial (4A,4B) packet seen by host agent A will be translated into >> (S6A, SIIT6B), then sent to the SIIT-DC, where it will be translated >> into (4A, 4B), then routed back, then translated as (S6A, S6B), then >> sent to host agent B, then translated to (4A,4B). The reply to this >> packet will be sent as (4B, 4A), translated by the host agent B to >> (S6B, SIIT6B), then hits SIIT-DC, gets translated to (4B, 4A), hits >> SIIT-DC again, gets translated to (S6B, S6A), sent to host A, there >> translated by host agent A to (4B, 4A). >> >> This pattern creates a traffic visibility issue and makes a SIIT-DC a >> potential bottleneck - since they are located at the edge of the >> network - so is worth mentioning/discussing. > > Ack. I'll try to add a section on hairpinning. > >> On the topic of running code: could be fun to kick the tires of >> https://github.com/ayourtch/nat46/tree/master/nat46/modules with >> regard to using it as a host agent, it might work though it might >> require a bit too much plumbing (routing + ND proxy on the outer >> interface) to be practically usable ? > > Well, routing and ND proxy you can handle from user space. If you look > at my clatd, it's basically just a perl script that discovers the > required network environment, sets up routing/ND proxy/etc and fires up > TAYGA with the right configuration. If your module supports basic > RFC6145 plus the static mapping stuff, it is probably possible to adapt > the script to use your module instead of TAYGA. I'll try to play a bit > with it later, thanks for the pointer! Oh, nice! So you'd "just" need to have forwarding enabled and install the correct IPv6 route to that interface in addition. I've neglected to do some parts of 6145 because of the module's original place (in tandem with iptables, in a small CPE) , balancing with my bug creation abilities. Unicast me on how it goes - I did an OS X clat proof of concept using the core functions from it, but always useful to have someone else to kick the tires. --a > > Tore > From nobody Tue Oct 7 03:20:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C438D1A1B25 for ; Tue, 7 Oct 2014 03:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFqwJA6R-hFh for ; Tue, 7 Oct 2014 03:20:51 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9B71A1B80 for ; Tue, 7 Oct 2014 03:20:49 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so5025582ieb.14 for ; Tue, 07 Oct 2014 03:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5Teug1wvu/RA/bwzKnxmnIzVXm8b1+rvFkhsj1+YRnY=; b=UYeCGZWG6JnP5TkQ/sJlY8KR1Z6kjE2egp99+bmOi3Vvg5Loiq+y98O1UWYYLDVcc/ CjOKGozQrpcVgPsqrhyG0ymrFnlZPwqnaDFI8H1A8mH2X0hq8ZxA7b4vA7fXLq67jG0e vx76tGthXIXdl25eBIiJqLWF251cCIoQpJAgO4w+yO6d7R0HQidqVv5BuAxx1LbfKQqn lXYwhx/37FJMZC99X86NayJ8Gczi7piPOfVIzoR9kUxQEhDF9ekI9hunEJ8kT5iGT16g gp0CwTZWmwZEyBr2n1i6RWukCVW+mi3e0zy41uppvV+S81B4dykaB3PixDI78FQmw7G4 J0aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5Teug1wvu/RA/bwzKnxmnIzVXm8b1+rvFkhsj1+YRnY=; b=NliE1vWBsyQJV298RikC2qIIJHmBMVMq1bly1FvFmgAr6foScbthiYRUlDexR6n/l7 Q4BlvYD81QxibBtknC8jge70OopiyG9ewkvmxKuFJmQtIBWLzNErzR+ukvShbBxk9Uen TUnrgu4wZ603nZRjulzEj6BeMCA9T7G4AaA8MOeUUw1a7IVMIi4kfQBDwdaBLjIYTrbT Rqti9lGvK4cZIbz3/pykuuVGQk3qoKQCwb7i9YQHpZHwpf42mv5ACdZ9LgtfVdgfd/BT fYE5X6Ax/Zp+bujC2xqBmJ7lKwCUw4nY14o65aFNXPWI/ijmjqDxEsAu+vhmpokYJhpI Tekg== X-Gm-Message-State: ALoCoQlT6npsv30OCDFcLDrMkWIs6ly0B8waWnG8QAmGz+Jc9zbrMDFE9UMTKgQZFbcUqltV0F/g X-Received: by 10.42.49.8 with SMTP id u8mr3462363icf.11.1412677249119; Tue, 07 Oct 2014 03:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Tue, 7 Oct 2014 03:20:28 -0700 (PDT) In-Reply-To: <28225.1412632545@turing-police.cc.vt.edu> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <28225.1412632545@turing-police.cc.vt.edu> From: Lorenzo Colitti Date: Tue, 7 Oct 2014 19:20:28 +0900 Message-ID: To: Valdis.Kletnieks@vt.edu Content-Type: multipart/alternative; boundary=90e6ba1efb469dee3c0504d28d2a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HH0PrQGDwYkfGTlIJMax5-mQOtI Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:20:51 -0000 --90e6ba1efb469dee3c0504d28d2a Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 6:55 AM, wrote: > Also, if you're documenting a protocol that's not an IETF Standard, the > protocol > description can still benefit from RFC2119 semantics. If there's a spot > where the protocol semantic should have a 'MUST NOT', and a client does it > anyhow, what happens? > Sure. But this is not a protocol, this is a recommended set of features. --90e6ba1efb469dee3c0504d28d2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 7, 2014 at 6:55 AM, <Valdis.Kletnieks@vt.edu>= wrote:
Also, if you're documenting a= protocol that's not an IETF Standard, the protocol
description can still benefit from RFC2119 semantics.=C2=A0 If there's = a spot
where the protocol semantic should have a 'MUST NOT', and a client = does it
anyhow, what happens?

Sure. But this is= not a protocol, this is a recommended set of features.
--90e6ba1efb469dee3c0504d28d2a-- From nobody Tue Oct 7 03:31:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10711A1B84 for ; Tue, 7 Oct 2014 03:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBXRSYroEd_M for ; Tue, 7 Oct 2014 03:31:02 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136901A1B7D for ; Tue, 7 Oct 2014 03:31:02 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id rl12so5017983iec.31 for ; Tue, 07 Oct 2014 03:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Thxi9zH2n44F5el6SwreG/Cx8zNBX4WsNTQ9MU3J3og=; b=c6aVgLt2MHhbGslT0wQi5W1zsoX1yoj/h9Jc/xCNq+TogGCzZ3+7Xrj79K646nZkqh X4z7uqTm43jBIFXl9prBpkLlbMPLojSU6fA3CLQ7jniQHaTlLRLeSYnvPiQmlnv4Xtvk rFrpsZmlj0+S3USbbjTvy6Wfr9XgPIu+3qkOfo1x188IWgo21CXY/e3djMNbBb4KrIeJ W5hGr5uL/Rnc3kESppdfvQXtB3QeHqxPk+M+aUU9Fz5nZIciMUIkGZUh2SNcjpUehL8r rcHzKYDXStYEBVm/KSgqg2/hXGjSvXNpewKNvPHifP6nSnjCHb8AYl7/1RuVMkXSSksR tVvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Thxi9zH2n44F5el6SwreG/Cx8zNBX4WsNTQ9MU3J3og=; b=Ilym+dCkYDH1dFht+Ohr3uxS4p5xdl3YpzLGO3xCUz+7xig9o3nK/VMXGBhDH1n01p si5fzGus3ueiMSPG2MFGRgQxfTnTdpJpzW3q8jkQeeMOOzcDkWpv4jVldpTQ6QaDnX09 uK9TGfweR+DY4WYBlean8QXM1AzOyoiypWo7bJDvGwMDHNkDvIuvhoyqOu/HdSoP7CZW 1Kbatme3Eap/E+P9bXuwT2TRgNN/PLxsZ9BcNh4hX8MqOrLExPJyHqfB/1A+yvihV1F8 AjLOiUpkKXBlQMP202AIvdsbTsMIsPg2rpgH0ocLrafe/J0m/wlQhDmV57GGN86/qbix lGKA== X-Gm-Message-State: ALoCoQk36tUNhw8C9oWNDlsZRFTiTcGEDCWp9Igc8rcq9AvLKf8TstlGnm65KztYc64RSQ9bnCEe X-Received: by 10.50.87.99 with SMTP id w3mr4218671igz.4.1412677861400; Tue, 07 Oct 2014 03:31:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Tue, 7 Oct 2014 03:30:41 -0700 (PDT) In-Reply-To: <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Lorenzo Colitti Date: Tue, 7 Oct 2014 19:30:41 +0900 Message-ID: To: "Heatley, Nick" Content-Type: multipart/alternative; boundary=089e0111b8541c89ca0504d2b24a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rlzhohmSjfrUCXxzbT-etcWGZPE Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:31:03 -0000 --089e0111b8541c89ca0504d2b24a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 7, 2014 at 6:30 PM, Heatley, Nick wrote= : > > If this cross-operator document states what is required on terminals to > work in all major/predictable IPv6 scenarios, then it is giving such peop= le > a view of what a =E2=80=9Chealthy and robust=E2=80=9D terminal implementa= tion would consist > of. If they are able to deliver on these requirements then they can suppl= y > a terminal ready for all business areas /all operator network scenarios. > It depends on your point of view. The way I see it, it's giving such people a view of what a kitchen sink consists of. (It certainly stops the feedback I=E2=80=99ve had from certain corners =E2= =80=9Cthat no > other operators are asking for IPv6=E2=80=9D, and =E2=80=9Cwhat you are a= sking for is a > single operator roadmap which we won=E2=80=99t do=E2=80=9D. That has been= the reality > here). So I don=E2=80=99t see how a consolidated demand-side view from op= erators > who are really trying to introduce IPv6 in mobile can harm adoption in a= ny > way. > Show me an operator whose rollout is genuinely blocked on terminal features and I will believe you. But word from everyone I've talked to is that terminal features are not the blocker. Operators such as Verizon Wireless and T-Mobile in the US have deployed tens of millions of IPv6-capable devices, and none of those devices (and, I'd argue, no commercial devices, anywhere) implement all the features in this profile. The vast majority only support a handful. The main problem I have with this document is it provides one more excuse to naysayers who believe that IPv6 is hard. The truth is that various operators have built perfectly functioning IPv6 mobile networks which implement only a handful of these features. But if the naysayers see this document, they'll say "See? Told you - IPv6 is so complicated that it will cost us a boatload of money, and it will bring no additional revenue. No point in implementing it." --089e0111b8541c89ca0504d2b24a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 7, 2014 at 6:30 PM, Heatley, Nick <nick.heatley@ee.co.uk&g= t; wrote:

If this cross-operato= r document states what is required on terminals to work in all major/predic= table IPv6 scenarios, then it is giving such people a view of what a =E2=80=9Chealthy and robust=E2=80=9D terminal implementation would = consist of. If they are able to deliver on these requirements then they can= supply a terminal ready for all business areas /all operator network scena= rios.


It depends on yo= ur point of view. The way I see it, it's giving such people a view of w= hat a kitchen sink consists of.

(It certainly stops the f= eedback I=E2=80=99ve had from certain corners =E2=80=9Cthat no other operat= ors are asking for IPv6=E2=80=9D, and =E2=80=9Cwhat you are asking for is a= single operator roadmap which we won=E2=80=99t do=E2=80=9D. That has been the reality here= ). So I don=E2=80=99t see how a consolidated demand-side view from operator= s who are really trying to introduce IPv6 =C2=A0in mobile can harm adoption= in any way.


Show me= an operator whose rollout is genuinely blocked on terminal features and I = will believe you. But word from everyone I've talked to is that termina= l features are not the blocker. Operators such as Verizon Wireless and T-Mo= bile in the US have deployed tens of millions of IPv6-capable devices, and = none of those devices (and, I'd argue, no commercial devices, anywhere)= implement all the features in this profile. The vast majority only support= a handful.

The main problem I have with this docu= ment is it provides one more excuse to naysayers who believe that IPv6 is h= ard. The truth is that various operators have built perfectly functioning I= Pv6 mobile networks which implement only a handful of these features. But i= f the naysayers see this document, they'll say "See? Told you - IP= v6 is so complicated that it will cost us a boatload of money, and it will = bring no additional revenue. No point in implementing it."
=
--089e0111b8541c89ca0504d2b24a-- From nobody Tue Oct 7 04:42:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0671A88A9; Tue, 7 Oct 2014 04:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ3GwEvUmXwU; Tue, 7 Oct 2014 04:42:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84E91A1B9A; Tue, 7 Oct 2014 04:42:41 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 23FD419019A; Tue, 7 Oct 2014 13:42:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id F19E8C8069; Tue, 7 Oct 2014 13:42:39 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.16]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 13:42:39 +0200 From: To: Lorenzo Colitti , "Heatley, Nick" Thread-Topic: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHP3lgoKCl8M9OLw0Kj/7PVjgLhBJwikIoAgAGz7YCAABDOgIAAMjaw Date: Tue, 7 Oct 2014 11:42:39 +0000 Message-ID: <1145_1412682160_5433D1B0_1145_9036_1_A729C0B3952BEE45A1AA136ADD556BE809D349@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_A729C0B3952BEE45A1AA136ADD556BE809D349OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.7.101820 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wRttVxwBjVuZn5RtMesjszCXGEg Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 11:42:45 -0000 --_000_A729C0B3952BEE45A1AA136ADD556BE809D349OPEXCLILM23corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KT24gVHVlLCBPY3QgNywgMjAxNCBhdCA2OjMwIFBNLCBIZWF0bGV5LCBOaWNrIDxuaWNr LmhlYXRsZXlAZWUuY28udWs8bWFpbHRvOm5pY2suaGVhdGxleUBlZS5jby51az4+IHdyb3RlOg0K SWYgdGhpcyBjcm9zcy1vcGVyYXRvciBkb2N1bWVudCBzdGF0ZXMgd2hhdCBpcyByZXF1aXJlZCBv biB0ZXJtaW5hbHMgdG8gd29yayBpbiBhbGwgbWFqb3IvcHJlZGljdGFibGUgSVB2NiBzY2VuYXJp b3MsIHRoZW4gaXQgaXMgZ2l2aW5nIHN1Y2ggcGVvcGxlIGEgdmlldyBvZiB3aGF0IGEg4oCcaGVh bHRoeSBhbmQgcm9idXN04oCdIHRlcm1pbmFsIGltcGxlbWVudGF0aW9uIHdvdWxkIGNvbnNpc3Qg b2YuIElmIHRoZXkgYXJlIGFibGUgdG8gZGVsaXZlciBvbiB0aGVzZSByZXF1aXJlbWVudHMgdGhl biB0aGV5IGNhbiBzdXBwbHkgYSB0ZXJtaW5hbCByZWFkeSBmb3IgYWxsIGJ1c2luZXNzIGFyZWFz IC9hbGwgb3BlcmF0b3IgbmV0d29yayBzY2VuYXJpb3MuDQoNCkl0IGRlcGVuZHMgb24geW91ciBw b2ludCBvZiB2aWV3LiBUaGUgd2F5IEkgc2VlIGl0LCBpdCdzIGdpdmluZyBzdWNoIHBlb3BsZSBh IHZpZXcgb2Ygd2hhdCBhIGtpdGNoZW4gc2luayBjb25zaXN0cyBvZi4NCltEQl0gTWF5YmUgeW91 IGFyZSByaWdodCwgbWF5YmUgbm90Lg0KDQooSXQgY2VydGFpbmx5IHN0b3BzIHRoZSBmZWVkYmFj ayBJ4oCZdmUgaGFkIGZyb20gY2VydGFpbiBjb3JuZXJzIOKAnHRoYXQgbm8gb3RoZXIgb3BlcmF0 b3JzIGFyZSBhc2tpbmcgZm9yIElQdjbigJ0sIGFuZCDigJx3aGF0IHlvdSBhcmUgYXNraW5nIGZv ciBpcyBhIHNpbmdsZSBvcGVyYXRvciByb2FkbWFwIHdoaWNoIHdlIHdvbuKAmXQgZG/igJ0uIFRo YXQgaGFzIGJlZW4gdGhlIHJlYWxpdHkgaGVyZSkuIFNvIEkgZG9u4oCZdCBzZWUgaG93IGEgY29u c29saWRhdGVkIGRlbWFuZC1zaWRlIHZpZXcgZnJvbSBvcGVyYXRvcnMgd2hvIGFyZSByZWFsbHkg dHJ5aW5nIHRvIGludHJvZHVjZSBJUHY2ICBpbiBtb2JpbGUgY2FuIGhhcm0gYWRvcHRpb24gaW4g YW55IHdheS4NCg0KU2hvdyBtZSBhbiBvcGVyYXRvciB3aG9zZSByb2xsb3V0IGlzIGdlbnVpbmVs eSBibG9ja2VkIG9uIHRlcm1pbmFsIGZlYXR1cmVzIGFuZCBJIHdpbGwgYmVsaWV2ZSB5b3UuIEJ1 dCB3b3JkIGZyb20gZXZlcnlvbmUgSSd2ZSB0YWxrZWQgdG8gaXMgdGhhdCB0ZXJtaW5hbCBmZWF0 dXJlcyBhcmUgbm90IHRoZSBibG9ja2VyLiBPcGVyYXRvcnMgc3VjaCBhcyBWZXJpem9uIFdpcmVs ZXNzIGFuZCBULU1vYmlsZSBpbiB0aGUgVVMgaGF2ZSBkZXBsb3llZCB0ZW5zIG9mIG1pbGxpb25z IG9mIElQdjYtY2FwYWJsZSBkZXZpY2VzLCBhbmQgbm9uZSBvZiB0aG9zZSBkZXZpY2VzIChhbmQs IEknZCBhcmd1ZSwgbm8gY29tbWVyY2lhbCBkZXZpY2VzLCBhbnl3aGVyZSkgaW1wbGVtZW50IGFs bCB0aGUgZmVhdHVyZXMgaW4gdGhpcyBwcm9maWxlLiBUaGUgdmFzdCBtYWpvcml0eSBvbmx5IHN1 cHBvcnQgYSBoYW5kZnVsLg0KW0RCXSBEbyB3ZSBjb25zaWRlciB0aGF0IGFsbCBmZWF0dXJlcyBh cmUgbWFuZGF0b3J5IGluIHRoZSBkcmFmdCA/IE5vdCBhdCBhbGwgYW5kIGl0IGRlbW9uc3RyYXRl cyB0aGF0IFJGQyAyMTE5IHRlcm1pbm9sb2d5IGlzIHVzZWZ1bC4gV2hhdGV2ZXIgeW91IHRoaW5r LCBpdCBpcyBzdGlsbCBhIHByb2JsZW0gdG8gZ2V0IHNvbWUgSVB2Ni1yZWFkeSBkZXZpY2VzIGFu ZCB0aGF0IGV4cGxhaW5zIHdoeSBzb21lIG9uLWdvaW5nIElQdjYgZGVwbG95bWVudCBzdGlsbCBy ZWx5IG9uIHNvbWUgbGltaXRlZCBudW1iZXIgb2YgZGV2aWNlcyBpbiBzb21lIGFyZWFzLiBUaGUg ZG9jdW1lbnQgd2lsbCBub3Qgc29sdmUgZXZlcnl0aGluZyBidXQgaXQgY291bGQgaGVscCBzb21l IG9wZXJhdG9ycyB0byBkaXNjdXNzIHdpdGggdmVuZG9ycyBhYm91dCB0aGVpciByZXF1aXJlbWVu dHMsIGFzIGl0IGhhcyBiZWVuIG1lbnRpb25lZCBieSBzZXZlcmFsIG9uZXMgb24gdGhpcyBtYWls aW5nIGxpc3QuDQoNClRoZSBtYWluIHByb2JsZW0gSSBoYXZlIHdpdGggdGhpcyBkb2N1bWVudCBp cyBpdCBwcm92aWRlcyBvbmUgbW9yZSBleGN1c2UgdG8gbmF5c2F5ZXJzIHdobyBiZWxpZXZlIHRo YXQgSVB2NiBpcyBoYXJkLiBUaGUgdHJ1dGggaXMgdGhhdCB2YXJpb3VzIG9wZXJhdG9ycyBoYXZl IGJ1aWx0IHBlcmZlY3RseSBmdW5jdGlvbmluZyBJUHY2IG1vYmlsZSBuZXR3b3JrcyB3aGljaCBp bXBsZW1lbnQgb25seSBhIGhhbmRmdWwgb2YgdGhlc2UgZmVhdHVyZXMuIEJ1dCBpZiB0aGUgbmF5 c2F5ZXJzIHNlZSB0aGlzIGRvY3VtZW50LCB0aGV5J2xsIHNheSAiU2VlPyBUb2xkIHlvdSAtIElQ djYgaXMgc28gY29tcGxpY2F0ZWQgdGhhdCBpdCB3aWxsIGNvc3QgdXMgYSBib2F0bG9hZCBvZiBt b25leSwgYW5kIGl0IHdpbGwgYnJpbmcgbm8gYWRkaXRpb25hbCByZXZlbnVlLiBObyBwb2ludCBp biBpbXBsZW1lbnRpbmcgaXQuIg0KW0RCXSBPcGVyYXRvcnMgZG8gbm90IG5lZWQgYW55IGV4Y3Vz ZSBmb3Igc29tZSBzdHJhdGVneSBlbGFib3JhdGlvbi4gQW5kIHRoZSBkb2N1bWVudCBkb2VzIG5v dCBhZGQgYW55IG5ldyBodXJkbGVzIGZvciBJUHY2IGRlcGxveW1lbnQgc2luY2UgaXQgbGlzdCBz b21lIHJlcXVpcmVtZW50cyBiYXNlZCBvbiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy4gV2Ugc2hv dWxkIHNwZWFrIGZvciBvdXJzZWx2ZXMgYW5kIHNob3VsZCBub3QgaW1hZ2luZSBob3cgb3RoZXIg cGVvcGxlIHdpbGwgY29uc2lkZXIgc3VjaCBkb2N1bWVudC4NCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== --_000_A729C0B3952BEE45A1AA136ADD556BE809D349OPEXCLILM23corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgT2N0IDcs IDIwMTQgYXQgNjozMCBQTSwgSGVhdGxleSwgTmljayAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpuaWNrLmhlYXRsZXlAZWUuY28udWsiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1V UyI+bmljay5oZWF0bGV5QGVlLmNvLnVrPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmIHRoaXMgY3Jvc3Mtb3BlcmF0b3IgZG9jdW1lbnQgc3RhdGVzIHdoYXQgaXMgcmVxdWly ZWQgb24gdGVybWluYWxzIHRvIHdvcmsgaW4gYWxsDQogbWFqb3IvcHJlZGljdGFibGUgSVB2NiBz Y2VuYXJpb3MsIHRoZW4gaXQgaXMgZ2l2aW5nIHN1Y2ggcGVvcGxlIGEgdmlldyBvZiB3aGF0IGEg 4oCcaGVhbHRoeSBhbmQgcm9idXN04oCdIHRlcm1pbmFsIGltcGxlbWVudGF0aW9uIHdvdWxkIGNv bnNpc3Qgb2YuIElmIHRoZXkgYXJlIGFibGUgdG8gZGVsaXZlciBvbiB0aGVzZSByZXF1aXJlbWVu dHMgdGhlbiB0aGV5IGNhbiBzdXBwbHkgYSB0ZXJtaW5hbCByZWFkeSBmb3IgYWxsIGJ1c2luZXNz IGFyZWFzIC9hbGwNCiBvcGVyYXRvciBuZXR3b3JrIHNjZW5hcmlvcy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgZGVwZW5kcyBvbiB5b3VyIHBvaW50IG9mIHZpZXcuIFRoZSB3YXkg SSBzZWUgaXQsIGl0J3MgZ2l2aW5nIHN1Y2ggcGVvcGxlIGEgdmlldyBvZiB3aGF0IGEga2l0Y2hl biBzaW5rIGNvbnNpc3RzIG9mLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltEQl0g TWF5YmUgeW91IGFyZSByaWdodCwgbWF5YmUgbm90Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihJdCBjZXJ0YWlubHkgc3RvcHMgdGhlIGZlZWRi YWNrIEnigJl2ZSBoYWQgZnJvbSBjZXJ0YWluIGNvcm5lcnMg4oCcdGhhdCBubyBvdGhlciBvcGVy YXRvcnMNCiBhcmUgYXNraW5nIGZvciBJUHY24oCdLCBhbmQg4oCcd2hhdCB5b3UgYXJlIGFza2lu ZyBmb3IgaXMgYSBzaW5nbGUgb3BlcmF0b3Igcm9hZG1hcCB3aGljaCB3ZSB3b27igJl0IGRv4oCd LiBUaGF0IGhhcyBiZWVuIHRoZSByZWFsaXR5IGhlcmUpLiBTbyBJIGRvbuKAmXQgc2VlIGhvdyBh IGNvbnNvbGlkYXRlZCBkZW1hbmQtc2lkZSB2aWV3IGZyb20gb3BlcmF0b3JzIHdobyBhcmUgcmVh bGx5IHRyeWluZyB0byBpbnRyb2R1Y2UgSVB2NiAmbmJzcDtpbiBtb2JpbGUgY2FuIGhhcm0NCiBh ZG9wdGlvbiBpbiBhbnkgd2F5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNob3cgbWUgYW4gb3BlcmF0b3Igd2hvc2Ugcm9sbG91dCBpcyBnZW51 aW5lbHkgYmxvY2tlZCBvbiB0ZXJtaW5hbCBmZWF0dXJlcyBhbmQgSSB3aWxsIGJlbGlldmUgeW91 LiBCdXQgd29yZCBmcm9tIGV2ZXJ5b25lIEkndmUgdGFsa2VkIHRvIGlzIHRoYXQgdGVybWluYWwg ZmVhdHVyZXMgYXJlIG5vdCB0aGUgYmxvY2tlci4gT3BlcmF0b3JzIHN1Y2ggYXMgVmVyaXpvbiBX aXJlbGVzcyBhbmQgVC1Nb2JpbGUgaW4NCiB0aGUgVVMgaGF2ZSBkZXBsb3llZCB0ZW5zIG9mIG1p bGxpb25zIG9mIElQdjYtY2FwYWJsZSBkZXZpY2VzLCBhbmQgbm9uZSBvZiB0aG9zZSBkZXZpY2Vz IChhbmQsIEknZCBhcmd1ZSwgbm8gY29tbWVyY2lhbCBkZXZpY2VzLCBhbnl3aGVyZSkgaW1wbGVt ZW50IGFsbCB0aGUgZmVhdHVyZXMgaW4gdGhpcyBwcm9maWxlLiBUaGUgdmFzdCBtYWpvcml0eSBv bmx5IHN1cHBvcnQgYSBoYW5kZnVsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltE Ql0gRG8gd2UgY29uc2lkZXIgdGhhdCBhbGwgZmVhdHVyZXMgYXJlIG1hbmRhdG9yeSBpbiB0aGUg ZHJhZnQmbmJzcDs/IE5vdCBhdCBhbGwgYW5kIGl0IGRlbW9uc3RyYXRlcyB0aGF0IFJGQyAyMTE5 IHRlcm1pbm9sb2d5IGlzIHVzZWZ1bC4gV2hhdGV2ZXIgeW91DQogdGhpbmssIGl0IGlzIHN0aWxs IGEgcHJvYmxlbSB0byBnZXQgc29tZSBJUHY2LXJlYWR5IGRldmljZXMgYW5kIHRoYXQgZXhwbGFp bnMgd2h5IHNvbWUgb24tZ29pbmcgSVB2NiBkZXBsb3ltZW50IHN0aWxsIHJlbHkgb24gc29tZSBs aW1pdGVkIG51bWJlciBvZiBkZXZpY2VzIGluIHNvbWUgYXJlYXMuIFRoZSBkb2N1bWVudCB3aWxs IG5vdCBzb2x2ZSBldmVyeXRoaW5nIGJ1dCBpdCBjb3VsZCBoZWxwIHNvbWUgb3BlcmF0b3JzIHRv IGRpc2N1c3Mgd2l0aA0KIHZlbmRvcnMgYWJvdXQgdGhlaXIgcmVxdWlyZW1lbnRzLCBhcyBpdCBo YXMgYmVlbiBtZW50aW9uZWQgYnkgc2V2ZXJhbCBvbmVzIG9uIHRoaXMgbWFpbGluZyBsaXN0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbWFpbiBwcm9ibGVtIEkgaGF2ZSB3aXRo IHRoaXMgZG9jdW1lbnQgaXMgaXQgcHJvdmlkZXMgb25lIG1vcmUgZXhjdXNlIHRvIG5heXNheWVy cyB3aG8gYmVsaWV2ZSB0aGF0IElQdjYgaXMgaGFyZC4gVGhlIHRydXRoIGlzIHRoYXQgdmFyaW91 cyBvcGVyYXRvcnMgaGF2ZSBidWlsdCBwZXJmZWN0bHkgZnVuY3Rpb25pbmcgSVB2NiBtb2JpbGUg bmV0d29ya3Mgd2hpY2ggaW1wbGVtZW50IG9ubHkgYSBoYW5kZnVsDQogb2YgdGhlc2UgZmVhdHVy ZXMuIEJ1dCBpZiB0aGUgbmF5c2F5ZXJzIHNlZSB0aGlzIGRvY3VtZW50LCB0aGV5J2xsIHNheSAm cXVvdDtTZWU/IFRvbGQgeW91IC0gSVB2NiBpcyBzbyBjb21wbGljYXRlZCB0aGF0IGl0IHdpbGwg Y29zdCB1cyBhIGJvYXRsb2FkIG9mIG1vbmV5LCBhbmQgaXQgd2lsbCBicmluZyBubyBhZGRpdGlv bmFsIHJldmVudWUuIE5vIHBvaW50IGluIGltcGxlbWVudGluZyBpdC4mcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bREJdIE9wZXJhdG9ycyBkbyBub3QgbmVlZCBhbnkgZXhj dXNlIGZvciBzb21lIHN0cmF0ZWd5IGVsYWJvcmF0aW9uLiBBbmQgdGhlIGRvY3VtZW50IGRvZXMg bm90IGFkZCBhbnkgbmV3IGh1cmRsZXMgZm9yIElQdjYgZGVwbG95bWVudCBzaW5jZSBpdCBsaXN0 DQogc29tZSByZXF1aXJlbWVudHMgYmFzZWQgb24gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuIFdl IHNob3VsZCBzcGVhayBmb3Igb3Vyc2VsdmVzIGFuZCBzaG91bGQgbm90IGltYWdpbmUgaG93IG90 aGVyIHBlb3BsZSB3aWxsIGNvbnNpZGVyIHN1Y2ggZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A729C0B3952BEE45A1AA136ADD556BE809D349OPEXCLILM23corpor_-- From nobody Tue Oct 7 05:22:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8F11A1B8E for ; Tue, 7 Oct 2014 05:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teNJxS1f2Sbt for ; Tue, 7 Oct 2014 05:22:04 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D666F1A1BAA for ; Tue, 7 Oct 2014 05:22:02 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id uq10so6473019igb.0 for ; Tue, 07 Oct 2014 05:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ttpebKioK7k5EKwBag6oEuHR1a8pqHnhfkAW2kJ8jTE=; b=Alk7GUrL8UAAkxHCNlSUAUbKOYGZS7uIVkMSoCq1LEEUMyzX+q826duj3UIuO47UOT ZZpoj7071PSS5z8iO9Ul2r63luv0oHn9NpoCkEr2PFPOCKSqZCwcgMgysomUcH7W2oyQ p5Y2+Thdcu2kLZvhBQHGK7py9/0OTtO+F65ZM3Cz58SYUI2t68C8f6RfTlZ3nYJ9JznY zM1Qp5BeRv2nl4NIM+AVM4vVlcPU2TyX/oJOGNKTHYwVj48Bbiz4H+Q1szWCASRaGFy+ I0VBMdF3ToUNJfzMF6NbQFJ9hByWN4VzgT/FxtRTcxrFGeZlaRbDD5w10rZIM9/fMzjD R43g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ttpebKioK7k5EKwBag6oEuHR1a8pqHnhfkAW2kJ8jTE=; b=VzGkG5NqVMfvAl8dy9qMgBCST8UjYK80rosZ1x/T4PWzE+V6S8aPpGkwGH0KAEMOzw G28UsXAT77/63JF2bMgTf6GyXWOXReqLTu4T5KWgp3ub8RC9elxdfTfNe8nLwQMLrxic kcYzx58wDwP69OigOY4EGv389JQwJWhOZZCnPDqJ2qRGWH1LOVXc0aXfQOSnrESEkEGf J1N5gfB5iInkImgXFhGlcuXsV8Fz/IxHUhxj9govlka2u5ERnTINcHtZ0No9SYfD+q2q sGESSE5AW0XmEilCMMUTHVfC6GnarTnzSsAOXlqzKgbuYsD3dwvRfyL45q8u3XDgfUGr EcTw== X-Gm-Message-State: ALoCoQk1nNKkzsanZP3JFT9Az2dzXViCLo3b33xbK8XY/znDN8RLhiFcLVFY/oEMEQroABKudTTt X-Received: by 10.50.88.5 with SMTP id bc5mr5061723igb.3.1412684522121; Tue, 07 Oct 2014 05:22:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Tue, 7 Oct 2014 05:21:42 -0700 (PDT) In-Reply-To: <1145_1412682160_5433D1B0_1145_9036_1_A729C0B3952BEE45A1AA136ADD556BE809D349@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> <1145_1412682160_5433D1B0_1145_9036_1_A729C0B3952BEE45A1AA136ADD556BE809D349@OPEXCLILM23.corporate.adroot.infra.ftgroup> From: Lorenzo Colitti Date: Tue, 7 Oct 2014 21:21:42 +0900 Message-ID: To: "BINET David IMT/OLN" Content-Type: multipart/alternative; boundary=089e0111c3d41f2d430504d43f53 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LznQYLxW32TNhpxLNSCWrWBB2HI Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:22:05 -0000 --089e0111c3d41f2d430504d43f53 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 8:42 PM, wrote: > Show me an operator whose rollout is genuinely blocked on terminal > features and I will believe you. But word from everyone I've talked to is > that terminal features are not the blocker. Operators such as Verizon > Wireless and T-Mobile in the US have deployed tens of millions of > IPv6-capable devices, and none of those devices (and, I'd argue, no > commercial devices, anywhere) implement all the features in this profile. > The vast majority only support a handful. > > [DB] Do we consider that all features are mandatory in the draft ? Not > at all and it demonstrates that RFC 2119 terminology is useful. > Ok, then. So here are examples of musts that are not required for IPv6 operation in a mobile network, and not supported in widely deployed mobile platforms: C-3 PDP context fallback C-9 RDNSS C-10 DHCPv6 C-11 DNS provisioning order C-12 PDP type limitation W-1 IPv6-only wifi A-1 Privacy addresses (because the IID is provided by the network) A-5 Prefer IPv6 DNS server L-1 DHCPv6 PD L-2 Full Customer Edge Router support A-2 Applications must be IP agnostic A-3 URI format Whatever you think, it is still a problem to get some IPv6-ready devices > and that explains why some on-going IPv6 deployment still rely on some > limited number of devices in some areas. > Then please explain to me how Verizon Wireless supports IPv6 on all its LTE devices, and has done since 2011? > the document does not add any new hurdles for IPv6 deployment since it > list some requirements based on existing specifications. > But it does add hurdles for IPv6 deployment. Because it lists lots of requirements that are not required for IPv6 deployment in mobile networks, and that are not widely supported by mobile devices. > We should speak for ourselves and should not imagine how other people will > consider such document. > Sorry, no. As IETF contributors it is our job to consider what other people will think when they read the documents that we produce. --089e0111c3d41f2d430504d43f53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 7, 2014 at 8:42 PM, <david.binet@orange.com> w= rote:

Show me an operator whose rollout is genuinely blocked on terminal featur= es and I will believe you. But word from everyone I've talked to is tha= t terminal features are not the blocker. Operators such as Verizon Wireless= and T-Mobile in the US have deployed tens of millions of IPv6-capable devices, and none of= those devices (and, I'd argue, no commercial devices, anywhere) implem= ent all the features in this profile. The vast majority only support a hand= ful.

[DB] Do we consider that all feat= ures are mandatory in the draft=C2=A0? Not at all and it demonstrates that = RFC 2119 terminology is useful.


Ok, then. So here are examples of musts that a= re not required for IPv6 operation in a mobile network, and not supported i= n widely deployed mobile platforms:

C-3 PDP contex= t fallback
C-9 RDNSS
C-10 DHCPv6
C-11 DNS pro= visioning order
C-12 PDP type limitation
W-1 IPv6-only = wifi
A-1 Privacy addresses (because the IID is provided by the ne= twork)
A-5 Prefer IPv6 DNS server
L-1 DHCPv6 PD
L-2 Full Customer Edge Router support
A-2 Applications must be= IP agnostic
A-3 URI format

<= div>

Whatever you think, it is still a problem to get some IPv6-ready devices and that expla= ins why some on-going IPv6 deployment still rely on some limited number of = devices in some areas.


Then please explain to me how Verizon Wireless s= upports IPv6 on all its LTE devices, and has done since 2011?
=C2= =A0
<= div>

the document does not add any n= ew hurdles for IPv6 deployment since it list some requirements based on existing specifications.

=

But it does add hu= rdles for IPv6 deployment. Because it lists lots of requirements that are n= ot required for IPv6 deployment in mobile networks, and that are not widely= supported by mobile devices.
=C2=A0

We should speak for ourselves and should not imagine how other= people will consider such document.


Sorry, no. As IETF contributors it= is our job to consider what other people will think when they read the doc= uments that we produce.
--089e0111c3d41f2d430504d43f53-- From nobody Tue Oct 7 06:46:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998711ACDA1 for ; Tue, 7 Oct 2014 06:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSvuer8d_XEl for ; Tue, 7 Oct 2014 06:46:40 -0700 (PDT) Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by ietfa.amsl.com (Postfix) with SMTP id CD9AD1ACD92 for ; Tue, 7 Oct 2014 06:46:04 -0700 (PDT) Received: (qmail 79938 messnum 5385115 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 7 Oct 2014 13:46:03 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail09.svc.cra.dublin.eircom.net (qp 79938) with SMTP; 7 Oct 2014 13:46:03 -0000 Received: from [192.168.43.190] ([185.51.73.4]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 0Dln1p00Y05YtxD01Dm1TN; Tue, 07 Oct 2014 14:46:03 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_3CD2A3E0-4802-4084-A73E-5A9001C164C7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Tue, 7 Oct 2014 14:45:27 +0100 Message-Id: <6BFD1641-B861-4FBF-852D-E1AF48B97973@eircom.net> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/skkHz0dK7sVCrPIRJZao8HLI0UE Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:46:49 -0000 --Apple-Mail=_3CD2A3E0-4802-4084-A73E-5A9001C164C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 7 Oct 2014, at 11:30, Lorenzo Colitti wrote: > On Tue, Oct 7, 2014 at 6:30 PM, Heatley, Nick = wrote: > If this cross-operator document states what is required on terminals = to work in all major/predictable IPv6 scenarios, then it is giving such = people a view of what a =93healthy and robust=94 terminal implementation = would consist of. If they are able to deliver on these requirements then = they can supply a terminal ready for all business areas /all operator = network scenarios. >=20 >=20 > It depends on your point of view. The way I see it, it=92s giving such = people a view of what a kitchen sink consists of. There are a few of these RFCs giving lists. On the fixed side I ask = vendors to support RFC 6092 and RFC 7084 and that starts a dialogue on = want we really need for initial deployment. I=92ve got spreadsheets back = from vendors listing point by point what they support, have road-mapped, = don=92t plan to support. That=92s often fine as I don=92t need all the = features initially. > (It certainly stops the feedback I=92ve had from certain corners =93that= no other operators are asking for IPv6=94, and =93what you are asking = for is a single operator roadmap which we won=92t do=94. That has been = the reality here). So I don=92t see how a consolidated demand-side view = from operators who are really trying to introduce IPv6 in mobile can = harm adoption in any way. >=20 >=20 > Show me an operator whose rollout is genuinely blocked on terminal = features and I will believe you. But word from everyone I've talked to = is that terminal features are not the blocker. Operators such as Verizon = Wireless and T-Mobile in the US have deployed tens of millions of = IPv6-capable devices, and none of those devices (and, I'd argue, no = commercial devices, anywhere) implement all the features in this = profile. The vast majority only support a handful. If Apple iOS supported IPv6-only/464xlat and all mobile devices had = better support for problem roaming cases then I might think this might = not provide a needed signal but it would still be useful to have a = document listing desired features. > The main problem I have with this document is it provides one more = excuse to naysayers who believe that IPv6 is hard. The truth is that = various operators have built perfectly functioning IPv6 mobile networks = which implement only a handful of these features. But if the naysayers = see this document, they'll say "See? Told you - IPv6 is so complicated = that it will cost us a boatload of money, and it will bring no = additional revenue. No point in implementing it.=94 The majority of work implementing the appropriate subset of the features = is with the mobile device vendor. There=92s a growing list of operators = to look at that are doing it under restricted circumstances. Items from = the list could help operators broaden the scope of their IPv6 = deployments. BR Ross --Apple-Mail=_3CD2A3E0-4802-4084-A73E-5A9001C164C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 7 Oct 2014, at 11:30, Lorenzo = Colitti <lorenzo@google.com> = wrote:

On Tue, Oct 7, 2014 at 6:30 PM, Heatley, Nick = <nick.heatley@ee.co.uk> wrote:

If this cross-operator document states what is required on terminals = to work in all major/predictable IPv6 scenarios, then it is giving such = people a view of what a =93healthy and robust=94 terminal implementation would consist = of. If they are able to deliver on these requirements then they can = supply a terminal ready for all business areas /all operator network = scenarios.


It = depends on your point of view. The way I see it, it=92s giving such = people a view of what a kitchen sink consists = of.

There are a few = of these RFCs giving lists.  On the fixed side I ask vendors to = support RFC 6092 and RFC 7084 and that starts a dialogue on want we = really need for initial deployment. I=92ve got spreadsheets back from = vendors listing point by point what they support, have road-mapped, = don=92t plan to support. That=92s often fine as I don=92t need all the = features initially.

(It certainly stops the feedback I=92ve had from = certain corners =93that no other operators are asking for IPv6=94, and = =93what you are asking for is a single operator roadmap which we won=92t do=94. That has been the reality here). So I = don=92t see how a consolidated demand-side view from operators who are = really trying to introduce IPv6  in mobile can harm adoption in any = way.


Show me an = operator whose rollout is genuinely blocked on terminal features and I = will believe you. But word from everyone I've talked to is that terminal = features are not the blocker. Operators such as Verizon Wireless and = T-Mobile in the US have deployed tens of millions of IPv6-capable = devices, and none of those devices (and, I'd argue, no commercial = devices, anywhere) implement all the features in this profile. The vast = majority only support a = handful.

If Apple iOS = supported IPv6-only/464xlat and all mobile devices had better support = for problem roaming cases then I might think this might not provide a = needed signal but it would still be useful to have a document listing = desired features.


The main problem I have with this document is = it provides one more excuse to naysayers who believe that IPv6 is hard. = The truth is that various operators have built perfectly functioning = IPv6 mobile networks which implement only a handful of these features. = But if the naysayers see this document, they'll say "See? Told you - = IPv6 is so complicated that it will cost us a boatload of money, and it = will bring no additional revenue. No point in implementing = it.=94


T= he majority of work implementing the appropriate subset of the features = is with the mobile device vendor. There=92s a growing list of operators = to look at that are doing it under restricted circumstances. Items from = the list could help operators broaden the scope of their IPv6 = deployments.


BR
Ross
=

= --Apple-Mail=_3CD2A3E0-4802-4084-A73E-5A9001C164C7-- From nobody Tue Oct 7 06:56:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316B81ACD90 for ; Tue, 7 Oct 2014 06:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALyZZwWyCh30 for ; Tue, 7 Oct 2014 06:56:01 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254521ACDA7 for ; Tue, 7 Oct 2014 06:55:15 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so5204154iec.23 for ; Tue, 07 Oct 2014 06:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lU2xfue5oFiu6ugf70Un0qv7Nfr13yw1PqhcZ8zd+gA=; b=UyfRuT2oEYN/UtMmtEeXZJKMnEiJ82vsTFB7jRC9I5FyfRWGcRrEVa40NXcvBwkdnb /+AcHjE8GiyQOeIxO6AAsX5J6DS1ljPfrGT4cD8Qzwi7dJbI4B46Ds9bOyPFOMFz1pmm Yse5Iqj4nhRCWuqkmr0PKIxMWyXurl26N/8HBD8V5/sKPRVzq1iGMeq0nk1kihWgWFfp S4/XK1cRDNBeu6/N78RqdsSpdKHgxFa1ejiQqm2kN2xmt2noP4jJLODfRcTK4MMbenB3 7YnWIUE9L9wtFAIZ6b3K15VwEyr8FXSPQPMO8sTY9xQu1d26hcPZ+8SQmOqge2bhWnsU eNIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lU2xfue5oFiu6ugf70Un0qv7Nfr13yw1PqhcZ8zd+gA=; b=TEHXuIfenswivK5Pi1m9qLCvNzF7AjS6+xmFN9KQ6LZnkvKY7ckNiq1mJQhEovQGQb LFFPVUMmjLFlDq/LrI3aE0e9smiQctfqVtb3oQ4u1eZxHMh5zdz4OFRQJGaCOHCj2W5i Gz6TmFRhHMONEXxSjfa66sJUatF2f9C+DpkcPyQpfp9tS1ji4qYKtto9/1dUeANFSmPU UCrse59sxHvNGcnQecSPOf3K2bA769fgIhCPvhBPgNyATlwAFI9OzurL0X2zW7DGFio5 UrVKo3ZEaY4lY0RigVPVeej356g+qLMGU5lGAW3SkL+ioeT6gvujdigjVjc1EyPctrxI iHHg== X-Gm-Message-State: ALoCoQm9x87UTwVlI45HQjzVCY7T3G2D9n2IDaoqAfoYeqcDvwtErfg3wPNZjchEpN/WQ+N5vpDT X-Received: by 10.42.61.137 with SMTP id u9mr5086142ich.54.1412690114391; Tue, 07 Oct 2014 06:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.144 with HTTP; Tue, 7 Oct 2014 06:54:54 -0700 (PDT) In-Reply-To: <6BFD1641-B861-4FBF-852D-E1AF48B97973@eircom.net> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> <6BFD1641-B861-4FBF-852D-E1AF48B97973@eircom.net> From: Lorenzo Colitti Date: Tue, 7 Oct 2014 22:54:54 +0900 Message-ID: To: Ross Chandler Content-Type: multipart/alternative; boundary=20cf302237e7726f050504d58c24 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/znNTGCMG6VXZE-dLlWr_ZLD9gOc Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:56:02 -0000 --20cf302237e7726f050504d58c24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 7, 2014 at 10:45 PM, Ross Chandler wrote: > Show me an operator whose rollout is genuinely blocked on terminal > features and I will believe you. But word from everyone I've talked to is > that terminal features are not the blocker. Operators such as Verizon > Wireless and T-Mobile in the US have deployed tens of millions of > IPv6-capable devices, and none of those devices (and, I'd argue, no > commercial devices, anywhere) implement all the features in this profile. > The vast majority only support a handful. > > If Apple iOS supported IPv6-only/464xlat and all mobile devices had bette= r > support for problem roaming cases then I might think this might not provi= de > a needed signal but it would still be useful to have a document listing > desired features. > I agree with you that these two are problems, and that solving them would improve the state (and the amount of) IPv6 in mobile networks. It would be good to have discussions and publish documents on real issues that actually affect deployment. But the way to do so is not to bury those real issues into a laundry list of requirements. (Not to mention that this document classes 464xlat as "should".) > The majority of work implementing the appropriate subset of the features > is with the mobile device vendor. There=E2=80=99s a growing list of opera= tors to > look at that are doing it under restricted circumstances. Items from the > list could help operators broaden the scope of their IPv6 deployments. > Other than the two features you mention above, which ones are likely to have an impact? Perhaps this document should focus more on those. --20cf302237e7726f050504d58c24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 7, 2014 at 10:45 PM, Ross Chandler <ross@eircom.net> w= rote:
Show me an operator whose= rollout is genuinely blocked on terminal features and I will believe you. = But word from everyone I've talked to is that terminal features are not= the blocker. Operators such as Verizon Wireless and T-Mobile in the US hav= e deployed tens of millions of IPv6-capable devices, and none of those devi= ces (and, I'd argue, no commercial devices, anywhere) implement all the= features in this profile. The vast majority only support a handful.
<= /div>
If Apple iOS supported IPv6-only/464xl= at and all mobile devices had better support for problem roaming cases then= I might think this might not provide a needed signal but it would still be= useful to have a document listing desired features.

I agree with you that these two are problems, and tha= t solving them would improve the state (and the amount of) IPv6 in mobile n= etworks. It would be good to have discussions and publish documents on real= issues that actually affect deployment. But the way to do so is not to bur= y those real issues into a laundry list of requirements. (Not to mention th= at this document classes 464xlat as "should".)
=C2=A0
The majority of work implementing the appropriate subset of the featu= res is with the mobile device vendor. There=E2=80=99s a growing list of ope= rators to look at that are doing it under restricted circumstances. Items f= rom the list could help operators broaden the scope of their IPv6 deploymen= ts.

Other than the two fe= atures you mention above, which ones are likely to have an impact? Perhaps = this document should focus more on those.
--20cf302237e7726f050504d58c24-- From nobody Tue Oct 7 09:29:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6F71ACE3F; Tue, 7 Oct 2014 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-sLAc7ZBsgh; Tue, 7 Oct 2014 09:29:41 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.138]) by ietfa.amsl.com (Postfix) with ESMTP id 8A91F1A914B; Tue, 7 Oct 2014 09:29:40 -0700 (PDT) Received: from [85.158.136.35:28366] by server-2.bemta-5.messagelabs.com id 8E/52-31832-3F414345; Tue, 07 Oct 2014 16:29:39 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-12.tower-125.messagelabs.com!1412699377!36524533!1 X-Originating-IP: [193.36.79.211] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31266 invoked from network); 7 Oct 2014 16:29:37 -0000 Received: from unknown (HELO autechre) (193.36.79.211) by server-12.tower-125.messagelabs.com with SMTP; 7 Oct 2014 16:29:37 -0000 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id ; Tue, 07 Oct 2014 17:31:50 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 17:29:25 +0100 From: "Heatley, Nick" To: Lorenzo Colitti , BINET David IMT/OLN Thread-Topic: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHP3lgstOYuetH+dkamfUnp7cN2RpwioU0AgAG2U0CAAA5ogIAAFBuAgAAK6gCAAEjCUA== Date: Tue, 7 Oct 2014 16:29:24 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303BDD55F@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> <1145_1412682160_5433D1B0_1145_9036_1_A729C0B3952BEE45A1AA136ADD556BE809D349@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303BDD55FUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1UjWkMyraOfjGoWIifZDFdDIOI8 Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:29:49 -0000 --_000_6536E263028723489CCD5B6821D4B21303BDD55FUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCkkgaGF2ZSBoYWQgYW5vdGhlciBsb29rIGF0IHRoZSBsaXN0IG9mIHJlcXRzIHlv dSBoaWdobGlnaHQuIEkgZmluZCBlYWNoIHJlZmVyZW5jaW5nIGEgdmFsaWQgUkZDIG9yIDNHUFAg c2VjdGlvbiwgYW5kIGVhY2ggZXhwbGFpbmluZyB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUgcmVx dCBpcyB2YWxpZC4NClNpbXBseSBhcmd1aW5nIHRoYXQgdGhleSBkbyBub3QgZXhpc3Qgd2lkZWx5 IHRvZGF5IGlzIG5vdCByZWFzb24gdG8gZGlzY291bnQgdGhlc2UuDQpbRm9yIHlvdXIgaW5mbyBv biBwcml2YWN5IGV4dGVuc2lvbiwgdGhlIElJRCBpcyBub3QgcHJvdmlkZWQgYnkgdGhlIG5ldHdv cmssIGEgdGVtcCBJSUQgaXMgcHJvdmlkZWQgZHVyaW5nIHRoZSBhdHRhY2ggdG8gdGhlIFBHVyBi dXQgdGhpcyBpcyB0aGVuIHN1cGVyc2VkZWQgYnkgdGhlIFNMQUFDIHByb2Nlc3MgYWZ0ZXIgdGhl IG5ldHdvcmsgcHJlZml4IGlzIGxlYXJudCB2aWEgUkEuIE1ham9yIGhhbmRzZXQgT1MgaW5jbHVk aW5nIHlvdXJzIHByb3ZpZGUgdGVtcG9yYXJ5IGFkZHJlc3NlcyB3aXRoIHBzZXVkby1yYW5kb20g SUlELl0NClJlZ2FyZGluZyBESENQdjYgYW5kIFByZWZpeCBEZWwsIHRoZW4gSSBrbm93IG9mIG5v IG9wZXJhdG9yIG5ldHdvcmsgdXNpbmcgdGhpcyB0b2RheS4gSG93ZXZlciB0aGlzIGlzIHRoZSBv bmx5IHJlcXVpcmVtZW50IHRoYXQgYSBtb2JpbGUgb3BlcmF0b3IgY2FuIGdpdmUgdG8gdGhlaXIg cHJvZHVjdCBtYXJrZXRpbmcgcGVvcGxlLCBJIGZlZWwgd2Ugd291bGQgYmUgZm9vbGlzaCB0byBs b3NlIHRoZXNlLiBBbiBJUHY2IHJlcXVpcmVtZW50IHRoYXQgYWN0dWFsbHkgY291bGQgYnJpbmcg bmV3IGJ1c2luZXNzIOKYug0KDQpNYXkgSSByZW1pbmQgeW91IG9mIHRoZSBvYmplY3RpdmVzIHNl dCBvdXQgaW4gc2VjdGlvbiAxDQpUaGUgb2JqZWN0aXZlcyBvZiB0aGlzIGVmZm9ydCBhcmU6DQoN CiAgIDEuICBMaXN0IGluIG9uZSBzaW5nbGUgZG9jdW1lbnQgYSBjb21wcmVoZW5zaXZlIGxpc3Qg b2YgSVB2NiBmZWF0dXJlcw0KICAgICAgIGZvciBhIG1vYmlsZSBkZXZpY2UsIGluY2x1ZGluZyBi b3RoIElQdjYtb25seSBhbmQgZHVhbC1zdGFjaw0KICAgICAgIG1vYmlsZSBkZXBsb3ltZW50IGNv bnRleHRzLiAgVGhlc2UgZmVhdHVyZXMgY292ZXIgdmFyaW91cyBuZXR3b3JrDQogICAgICAgdHlw ZXMgc3VjaCBhcyBHUFJTIChHZW5lcmFsIFBhY2tldCBSYWRpbyBTZXJ2aWNlKSwgRVBDIChFdm9s dmVkDQogICAgICAgUGFja2V0IENvcmUpIG9yIElFRUUgODAyLjExIG5ldHdvcmsuDQoNCiAgIDIu ICBIZWxwIE9wZXJhdG9ycyB3aXRoIHRoZSBkZXRhaWxlZCBkZXZpY2UgcmVxdWlyZW1lbnQgbGlz dA0KICAgICAgIHByZXBhcmF0aW9uICh0byBiZSBleGNoYW5nZWQgd2l0aCBkZXZpY2Ugc3VwcGxp ZXJzKS4gIFRoaXMgaXMNCiAgICAgICBhbHNvIGEgY29udHJpYnV0aW9uIHRvIGhhcm1vbml6ZSBP cGVyYXRvcnMnIHJlcXVpcmVtZW50cyB0b3dhcmRzDQogICAgICAgZGV2aWNlIHZlbmRvcnMuDQoN CiAgIDMuICBWZW5kb3JzIHRvIGJlIGF3YXJlIG9mIGEgc2V0IG9mIGZlYXR1cmVzIHRvIGFsbG93 IGZvciBJUHY2DQogICAgICAgY29ubmVjdGl2aXR5IGFuZCBJUHY0IHNlcnZpY2UgY29udGludWl0 eSAob3ZlciBhbiBJUHY2LW9ubHkNCiAgICAgICB0cmFuc3BvcnQpLg0KDQpJIGZpbmQgdGhlIG9i amVjdGl2ZXMgY2xlYXIgYW5kIHRoZSBkb2N1bWVudCBnb2VzIG9uIHRvIG1lZXRzIHRob3NlIG9i amVjdGl2ZXMuDQoNCkluIHRoaXMgcGFwZXIgYm90aCBJUHY2LW9ubHkgYW5kIGR1YWwgc3RhY2sg YXJlIHZhbGlkLCBhbmQgdGhlIHJlcXRzIHRoYXQgYXBwbHkgdG8gSVB2Ni1vbmx5IHRlbmQgdG8g c3RhdGUgdGhhdDsgdGhpcyBpcyBhbiBvcGVyYXRvciBjaG9pY2UuDQpBcyBJIHVuZGVyc3RhbmQg aXQ6DQpWZXJpem9uIFdpcmVsZXNzIGhhdmUgYWNoaWV2ZWQgdGhlaXIgZmFudGFzdGljIElQdjYg cGVuZXRyYXRpb24gdXNpbmcgYSBkdWFsIHN0YWNrIGRlcGxveW1lbnQgbW9kZWwgKHBlcmhhcHMg dGhleSB3b3VsZCB0aGVyZWZvcmUgYXJndWUgdGhhdCA0NjR4bGF0IGlzIG9ubHkgYSDigJxzaG91 bGTigJ0pLg0KVC1Nb2JpbGUgVVMgYWxzbyBoYXZlIGdyZWF0IHJlc3VsdHMgd2l0aCA0NjR4bGF0 IG9uIGFuIElQdjYtb25seSBBUE4sIGhvd2V2ZXIgdGV0aGVyaW5nL3dpZmkgaG90c3BvdCBpcyB2 aWEgYW5vdGhlciBBUE4uDQoNClRvIHByb3ZpZGUgSVB2Ni1vbmx5IG9uIGEgc2luZ2xlIEFQTiBp bmNsdWRpbmcgdGV0aGVyaW5nL1dpZmkgSG9zdHNwb3QgaXMgZGlmZmljdWx0IGR1ZSB0byBicmVh ZHRoIG9mIHRlcm1pbmFsIHN1cHBvcnQsIGluY2x1ZGluZyBzb21lIHBvb3IgdGV0aGVyaW5nIGlu dGVncmF0aW9uIChMX1JFUSM0IGRlZmljaWVuY3kpLg0KQXMgT3JhbmdlIFBvbGFuZCBoYXZlIGVt YmFya2VkIG9uIHRoaXMgZGVwbG95bWVudCwgYSB2aWV3IGZyb20gT3JhbmdlIFBvbGFuZCBhbmQg dGVybWluYWxzIHdvdWxkIGJlIHdlbGNvbWVkIQ0KTXkgcGVyY2VwdGlvbiBpcyB0aGF0LCBpbiB0 aGlzIHNjZW5hcmlvLCBhIG51bWJlciBvZiBPUyBhbmQgT0VNIGltcGxlbWVudGF0aW9ucyB0aGF0 IGNhbiBzdXBwb3J0IGR1YWwgc3RhY2sgcGVyZmVjdGx5IHdlbGwgaGF2ZSBub3QgYWNoaWV2ZWQg c3VpdGFiaWxpdHkgaGVyZS4NCkZvciBvcGVyYXRvcnMgd2hvIG5lZWQgdG8gZGVjb3VwbGUgdGhl aXIgZ3Jvd3RoIGZyb20gSVB2NCBhZGRyZXNzaW5nLCB5b3VyIHN5bm9wc2lzIG9mIOKAnHRlcm1p bmFscyBub3QgYmxvY2tpbmcgcm9sbG91dOKAnSBpcyBub3QgdGhlIHJlYWxpdHkuIFRlcm1pbmFs cyByZW1haW4gYW4gaXNzdWUuDQpCdXQgaXQgaXMgbm90IHRoZSBpbnRlbnRpb24gdG8gbGlzdCBw cm9ibGVtcyBidXQgdG8gaGlnaGxpZ2h0IHdoYXQgaXMgcmVxdWlyZWQgZm9yIHNlcnZpY2UgY29u dGludWl0eS4NClJlZ2FyZHMsDQpOaWNrDQoNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogMDcgT2N0b2JlciAyMDE0IDEzOjIyDQpUbzog QklORVQgRGF2aWQgSU1UL09MTg0KQ2M6IEhlYXRsZXksIE5pY2s7IHY2b3BzQGlldGYub3JnIFdH OyBJRVRGIERpc2N1c3Npb247IElFVEYtQW5ub3VuY2UNClN1YmplY3Q6IFJlOiBbdjZvcHNdIExh c3QgQ2FsbDogPGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTEzLnR4dD4g KEFuIEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3IgM0dQUCBN b2JpbGUgRGV2aWNlcykgdG8gSW5mb3JtYXRpb25hbCBSRkMNCg0KT24gVHVlLCBPY3QgNywgMjAx NCBhdCA4OjQyIFBNLCA8ZGF2aWQuYmluZXRAb3JhbmdlLmNvbTxtYWlsdG86ZGF2aWQuYmluZXRA b3JhbmdlLmNvbT4+IHdyb3RlOg0KU2hvdyBtZSBhbiBvcGVyYXRvciB3aG9zZSByb2xsb3V0IGlz IGdlbnVpbmVseSBibG9ja2VkIG9uIHRlcm1pbmFsIGZlYXR1cmVzIGFuZCBJIHdpbGwgYmVsaWV2 ZSB5b3UuIEJ1dCB3b3JkIGZyb20gZXZlcnlvbmUgSSd2ZSB0YWxrZWQgdG8gaXMgdGhhdCB0ZXJt aW5hbCBmZWF0dXJlcyBhcmUgbm90IHRoZSBibG9ja2VyLiBPcGVyYXRvcnMgc3VjaCBhcyBWZXJp em9uIFdpcmVsZXNzIGFuZCBULU1vYmlsZSBpbiB0aGUgVVMgaGF2ZSBkZXBsb3llZCB0ZW5zIG9m IG1pbGxpb25zIG9mIElQdjYtY2FwYWJsZSBkZXZpY2VzLCBhbmQgbm9uZSBvZiB0aG9zZSBkZXZp Y2VzIChhbmQsIEknZCBhcmd1ZSwgbm8gY29tbWVyY2lhbCBkZXZpY2VzLCBhbnl3aGVyZSkgaW1w bGVtZW50IGFsbCB0aGUgZmVhdHVyZXMgaW4gdGhpcyBwcm9maWxlLiBUaGUgdmFzdCBtYWpvcml0 eSBvbmx5IHN1cHBvcnQgYSBoYW5kZnVsLg0KW0RCXSBEbyB3ZSBjb25zaWRlciB0aGF0IGFsbCBm ZWF0dXJlcyBhcmUgbWFuZGF0b3J5IGluIHRoZSBkcmFmdCA/IE5vdCBhdCBhbGwgYW5kIGl0IGRl bW9uc3RyYXRlcyB0aGF0IFJGQyAyMTE5IHRlcm1pbm9sb2d5IGlzIHVzZWZ1bC4NCg0KT2ssIHRo ZW4uIFNvIGhlcmUgYXJlIGV4YW1wbGVzIG9mIG11c3RzIHRoYXQgYXJlIG5vdCByZXF1aXJlZCBm b3IgSVB2NiBvcGVyYXRpb24gaW4gYSBtb2JpbGUgbmV0d29yaywgYW5kIG5vdCBzdXBwb3J0ZWQg aW4gd2lkZWx5IGRlcGxveWVkIG1vYmlsZSBwbGF0Zm9ybXM6DQoNCkMtMyBQRFAgY29udGV4dCBm YWxsYmFjaw0KQy05IFJETlNTDQpDLTEwIERIQ1B2Ng0KQy0xMSBETlMgcHJvdmlzaW9uaW5nIG9y ZGVyDQpDLTEyIFBEUCB0eXBlIGxpbWl0YXRpb24NClctMSBJUHY2LW9ubHkgd2lmaQ0KQS0xIFBy aXZhY3kgYWRkcmVzc2VzIChiZWNhdXNlIHRoZSBJSUQgaXMgcHJvdmlkZWQgYnkgdGhlIG5ldHdv cmspDQpBLTUgUHJlZmVyIElQdjYgRE5TIHNlcnZlcg0KTC0xIERIQ1B2NiBQRA0KTC0yIEZ1bGwg Q3VzdG9tZXIgRWRnZSBSb3V0ZXIgc3VwcG9ydA0KQS0yIEFwcGxpY2F0aW9ucyBtdXN0IGJlIElQ IGFnbm9zdGljDQpBLTMgVVJJIGZvcm1hdA0KDQpXaGF0ZXZlciB5b3UgdGhpbmssIGl0IGlzIHN0 aWxsIGEgcHJvYmxlbSB0byBnZXQgc29tZSBJUHY2LXJlYWR5IGRldmljZXMgYW5kIHRoYXQgZXhw bGFpbnMgd2h5IHNvbWUgb24tZ29pbmcgSVB2NiBkZXBsb3ltZW50IHN0aWxsIHJlbHkgb24gc29t ZSBsaW1pdGVkIG51bWJlciBvZiBkZXZpY2VzIGluIHNvbWUgYXJlYXMuDQoNClRoZW4gcGxlYXNl IGV4cGxhaW4gdG8gbWUgaG93IFZlcml6b24gV2lyZWxlc3Mgc3VwcG9ydHMgSVB2NiBvbiBhbGwg aXRzIExURSBkZXZpY2VzLCBhbmQgaGFzIGRvbmUgc2luY2UgMjAxMT8NCg0KdGhlIGRvY3VtZW50 IGRvZXMgbm90IGFkZCBhbnkgbmV3IGh1cmRsZXMgZm9yIElQdjYgZGVwbG95bWVudCBzaW5jZSBp dCBsaXN0IHNvbWUgcmVxdWlyZW1lbnRzIGJhc2VkIG9uIGV4aXN0aW5nIHNwZWNpZmljYXRpb25z Lg0KDQpCdXQgaXQgZG9lcyBhZGQgaHVyZGxlcyBmb3IgSVB2NiBkZXBsb3ltZW50LiBCZWNhdXNl IGl0IGxpc3RzIGxvdHMgb2YgcmVxdWlyZW1lbnRzIHRoYXQgYXJlIG5vdCByZXF1aXJlZCBmb3Ig SVB2NiBkZXBsb3ltZW50IGluIG1vYmlsZSBuZXR3b3JrcywgYW5kIHRoYXQgYXJlIG5vdCB3aWRl bHkgc3VwcG9ydGVkIGJ5IG1vYmlsZSBkZXZpY2VzLg0KDQpXZSBzaG91bGQgc3BlYWsgZm9yIG91 cnNlbHZlcyBhbmQgc2hvdWxkIG5vdCBpbWFnaW5lIGhvdyBvdGhlciBwZW9wbGUgd2lsbCBjb25z aWRlciBzdWNoIGRvY3VtZW50Lg0KDQpTb3JyeSwgbm8uIEFzIElFVEYgY29udHJpYnV0b3JzIGl0 IGlzIG91ciBqb2IgdG8gY29uc2lkZXIgd2hhdCBvdGhlciBwZW9wbGUgd2lsbCB0aGluayB3aGVu IHRoZXkgcmVhZCB0aGUgZG9jdW1lbnRzIHRoYXQgd2UgcHJvZHVjZS4NCg0KTk9USUNFIEFORCBE SVNDTEFJTUVSDQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50 ZW5kZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuICBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgZGVsZXRl IHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IGRpc2Nsb3NlIG9yIHVzZSBm b3IgYW55IHB1cnBvc2UuICANCiANCldlIG1heSBtb25pdG9yIGFsbCBpbmNvbWluZyBhbmQgb3V0 Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRh a2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBm cmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRv IGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2VseSBhZmZlY3QgeW91LiANCg0KRUUg TGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcw0KQ29tcGFueSBSZWdpc3Rl cmVkIE51bWJlcjogMDIzODIxNjENClJlZ2lzdGVyZWQgT2ZmaWNlIEFkZHJlc3M6IFRyaWRlbnQg UGxhY2UsIE1vc3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXDQo= --_000_6536E263028723489CCD5B6821D4B21303BDD55FUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkxvcmVuem8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBoYWQgYW5vdGhl ciBsb29rIGF0IHRoZSBsaXN0IG9mIHJlcXRzIHlvdSBoaWdobGlnaHQuIEkgZmluZCBlYWNoIHJl ZmVyZW5jaW5nIGEgdmFsaWQgUkZDIG9yIDNHUFAgc2VjdGlvbiwgYW5kIGVhY2ggZXhwbGFpbmlu ZyB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUNCiByZXF0IGlzIHZhbGlkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TaW1wbHkgYXJndWluZyB0aGF0IHRoZXkgZG8gbm90IGV4aXN0IHdp ZGVseSB0b2RheSBpcyBub3QgcmVhc29uIHRvIGRpc2NvdW50IHRoZXNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bRm9yIHlvdXIgaW5mbyBvbiBwcml2YWN5IGV4dGVuc2lvbiwgdGhl IElJRCBpcyBub3QgcHJvdmlkZWQgYnkgdGhlIG5ldHdvcmssIGEgdGVtcCBJSUQgaXMgcHJvdmlk ZWQgZHVyaW5nIHRoZSBhdHRhY2ggdG8gdGhlIFBHVyBidXQgdGhpcyBpcyB0aGVuIHN1cGVyc2Vk ZWQNCiBieSB0aGUgU0xBQUMgcHJvY2VzcyBhZnRlciB0aGUgbmV0d29yayBwcmVmaXggaXMgbGVh cm50IHZpYSBSQS4gTWFqb3IgaGFuZHNldCBPUyBpbmNsdWRpbmcgeW91cnMgcHJvdmlkZSB0ZW1w b3JhcnkgYWRkcmVzc2VzIHdpdGggcHNldWRvLXJhbmRvbSBJSUQuXTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgREhDUHY2IGFuZCBQcmVmaXggRGVsLCB0aGVuIEkga25v dyBvZiBubyBvcGVyYXRvciBuZXR3b3JrIHVzaW5nIHRoaXMgdG9kYXkuIEhvd2V2ZXIgdGhpcyBp cyB0aGUgb25seSByZXF1aXJlbWVudCB0aGF0IGEgbW9iaWxlIG9wZXJhdG9yIGNhbiBnaXZlIHRv DQogdGhlaXIgcHJvZHVjdCBtYXJrZXRpbmcgcGVvcGxlLCBJIGZlZWwgd2Ugd291bGQgYmUgZm9v bGlzaCB0byBsb3NlIHRoZXNlLiBBbiBJUHY2IHJlcXVpcmVtZW50IHRoYXQgYWN0dWFsbHkgY291 bGQgYnJpbmcgbmV3IGJ1c2luZXNzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5IEkgcmVtaW5k IHlvdSBvZiB0aGUgb2JqZWN0aXZlcyBzZXQgb3V0IGluIHNlY3Rpb24gMTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgb2JqZWN0aXZlcyBv ZiB0aGlzIGVmZm9ydCBhcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgTGlzdCBpbiBvbmUgc2lu Z2xlIGRvY3VtZW50IGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIElQdjYgZmVhdHVyZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBhIG1vYmlsZSBkZXZpY2UsIGluY2x1ZGlu ZyBib3RoIElQdjYtb25seSBhbmQgZHVhbC1zdGFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbW9iaWxlIGRlcGxveW1lbnQgY29udGV4dHMuJm5ic3A7IFRoZXNlIGZlYXR1cmVz IGNvdmVyIHZhcmlvdXMgbmV0d29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dHlwZXMgc3VjaCBhcyBHUFJTIChHZW5lcmFsIFBhY2tldCBSYWRpbyBTZXJ2aWNlKSwgRVBDIChF dm9sdmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYWNrZXQgQ29yZSkgb3Ig SUVFRSA4MDIuMTEgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAyLiZuYnNwOyBIZWxwIE9wZXJhdG9y cyB3aXRoIHRoZSBkZXRhaWxlZCBkZXZpY2UgcmVxdWlyZW1lbnQgbGlzdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlcGFyYXRpb24gKHRvIGJlIGV4Y2hhbmdlZCB3aXRoIGRl dmljZSBzdXBwbGllcnMpLiZuYnNwOyBUaGlzIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhbHNvIGEgY29udHJpYnV0aW9uIHRvIGhhcm1vbml6ZSBPcGVyYXRvcnMnIHJlcXVp cmVtZW50cyB0b3dhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXZpY2Ug dmVuZG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAzLiZuYnNwOyBWZW5kb3JzIHRvIGJlIGF3YXJlIG9mIGEg c2V0IG9mIGZlYXR1cmVzIHRvIGFsbG93IGZvciBJUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb25uZWN0aXZpdHkgYW5kIElQdjQgc2VydmljZSBjb250aW51aXR5IChvdmVy IGFuIElQdjYtb25seTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhbnNwb3J0 KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZmluZCB0aGUgb2JqZWN0aXZl cyBjbGVhciBhbmQgdGhlIGRvY3VtZW50IGdvZXMgb24gdG8gbWVldHMgdGhvc2Ugb2JqZWN0aXZl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkluIHRoaXMgcGFwZXIgYm90aCBJUHY2LW9ubHkgYW5kIGR1YWwgc3RhY2sg YXJlIHZhbGlkLCBhbmQgdGhlIHJlcXRzIHRoYXQgYXBwbHkgdG8gSVB2Ni1vbmx5IHRlbmQgdG8g c3RhdGUgdGhhdDsgdGhpcyBpcyBhbiBvcGVyYXRvciBjaG9pY2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFzIEkgdW5kZXJzdGFuZCBpdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VmVyaXpvbiBXaXJlbGVzcyBoYXZlIGFjaGlldmVkIHRoZWlyIGZhbnRhc3RpYyBJUHY2 IHBlbmV0cmF0aW9uIHVzaW5nIGEgZHVhbCBzdGFjayBkZXBsb3ltZW50IG1vZGVsIChwZXJoYXBz IHRoZXkgd291bGQgdGhlcmVmb3JlIGFyZ3VlIHRoYXQgNDY0eGxhdCBpcyBvbmx5DQogYSDigJxz aG91bGTigJ0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ULU1vYmlsZSBVUyBhbHNv IGhhdmUgZ3JlYXQgcmVzdWx0cyB3aXRoIDQ2NHhsYXQgb24gYW4gSVB2Ni1vbmx5IEFQTiwgaG93 ZXZlciB0ZXRoZXJpbmcvd2lmaSBob3RzcG90IGlzIHZpYSBhbm90aGVyIEFQTi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRvIHByb3ZpZGUgSVB2Ni1vbmx5IG9uIGEgc2luZ2xlIEFQTiBpbmNsdWRpbmcgdGV0aGVyaW5n L1dpZmkgSG9zdHNwb3QgaXMgZGlmZmljdWx0IGR1ZSB0byBicmVhZHRoIG9mIHRlcm1pbmFsIHN1 cHBvcnQsIGluY2x1ZGluZyBzb21lIHBvb3IgdGV0aGVyaW5nIGludGVncmF0aW9uDQogKExfUkVR IzQgZGVmaWNpZW5jeSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIE9yYW5nZSBQ b2xhbmQgaGF2ZSBlbWJhcmtlZCBvbiB0aGlzIGRlcGxveW1lbnQsIGEgdmlldyBmcm9tIE9yYW5n ZSBQb2xhbmQgYW5kIHRlcm1pbmFscyB3b3VsZCBiZSB3ZWxjb21lZCE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TXkgcGVyY2VwdGlvbiBpcyB0aGF0LCBpbiB0aGlzIHNjZW5hcmlvLCBh IG51bWJlciBvZiBPUyBhbmQgT0VNIGltcGxlbWVudGF0aW9ucyB0aGF0IGNhbiBzdXBwb3J0IGR1 YWwgc3RhY2sgcGVyZmVjdGx5IHdlbGwgaGF2ZSBub3QgYWNoaWV2ZWQgc3VpdGFiaWxpdHkgaGVy ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIG9wZXJhdG9ycyB3aG8gbmVlZCB0 byBkZWNvdXBsZSB0aGVpciBncm93dGggZnJvbSBJUHY0IGFkZHJlc3NpbmcsIHlvdXIgc3lub3Bz aXMgb2Yg4oCcdGVybWluYWxzIG5vdCBibG9ja2luZyByb2xsb3V04oCdIGlzIG5vdCB0aGUgcmVh bGl0eS4gVGVybWluYWxzIHJlbWFpbg0KIGFuIGlzc3VlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QnV0IGl0IGlzIG5vdCB0aGUgaW50ZW50aW9uIHRvIGxpc3QgcHJvYmxlbXMgYnV0 IHRvIGhpZ2hsaWdodCB3aGF0IGlzIHJlcXVpcmVkIGZvciBzZXJ2aWNlIGNvbnRpbnVpdHkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk5pY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiAwNyBPY3RvYmVyIDIwMTQgMTM6MjI8YnI+DQo8Yj5Ubzo8L2I+IEJJTkVU IERhdmlkIElNVC9PTE48YnI+DQo8Yj5DYzo8L2I+IEhlYXRsZXksIE5pY2s7IHY2b3BzQGlldGYu b3JnIFdHOyBJRVRGIERpc2N1c3Npb247IElFVEYtQW5ub3VuY2U8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFt2Nm9wc10gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2 aWNlLXByb2ZpbGUtMTMudHh0Jmd0OyAoQW4gSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2IChJ UHY2KSBQcm9maWxlIGZvciAzR1BQIE1vYmlsZSBEZXZpY2VzKSB0byBJbmZvcm1hdGlvbmFsIFJG QzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBPY3QgNywgMjAxNCBhdCA4OjQyIFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJp bmV0QG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZpZC5iaW5ldEBvcmFuZ2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+U2hvdyBtZSBhbiBvcGVyYXRv ciB3aG9zZSByb2xsb3V0IGlzIGdlbnVpbmVseSBibG9ja2VkIG9uIHRlcm1pbmFsIGZlYXR1cmVz IGFuZCBJIHdpbGwgYmVsaWV2ZSB5b3UuIEJ1dCB3b3JkIGZyb20gZXZlcnlvbmUgSSd2ZSB0YWxr ZWQgdG8gaXMgdGhhdCB0ZXJtaW5hbCBmZWF0dXJlcw0KIGFyZSBub3QgdGhlIGJsb2NrZXIuIE9w ZXJhdG9ycyBzdWNoIGFzIFZlcml6b24gV2lyZWxlc3MgYW5kIFQtTW9iaWxlIGluIHRoZSBVUyBo YXZlIGRlcGxveWVkIHRlbnMgb2YgbWlsbGlvbnMgb2YgSVB2Ni1jYXBhYmxlIGRldmljZXMsIGFu ZCBub25lIG9mIHRob3NlIGRldmljZXMgKGFuZCwgSSdkIGFyZ3VlLCBubyBjb21tZXJjaWFsIGRl dmljZXMsIGFueXdoZXJlKSBpbXBsZW1lbnQgYWxsIHRoZSBmZWF0dXJlcyBpbiB0aGlzIHByb2Zp bGUuIFRoZQ0KIHZhc3QgbWFqb3JpdHkgb25seSBzdXBwb3J0IGEgaGFuZGZ1bC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPltEQl0gRG8gd2UgY29uc2lkZXIgdGhhdCBhbGwgZmVhdHVyZXMgYXJlIG1h bmRhdG9yeSBpbiB0aGUgZHJhZnQmbmJzcDs/IE5vdCBhdCBhbGwgYW5kIGl0IGRlbW9uc3RyYXRl cw0KIHRoYXQgUkZDIDIxMTkgdGVybWlub2xvZ3kgaXMgdXNlZnVsLjwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2ssIHRoZW4uIFNvIGhl cmUgYXJlIGV4YW1wbGVzIG9mIG11c3RzIHRoYXQgYXJlIG5vdCByZXF1aXJlZCBmb3IgSVB2NiBv cGVyYXRpb24gaW4gYSBtb2JpbGUgbmV0d29yaywgYW5kIG5vdCBzdXBwb3J0ZWQgaW4gd2lkZWx5 IGRlcGxveWVkIG1vYmlsZSBwbGF0Zm9ybXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMtMyBQRFAgY29udGV4dCBmYWxsYmFjazxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qy05IFJETlNTPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DLTEwIERI Q1B2NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Qy0xMSBETlMgcHJvdmlzaW9uaW5nIG9yZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DLTEyIFBEUCB0eXBlIGxpbWl0YXRpb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlctMSBJUHY2LW9ubHkg d2lmaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QS0xIFByaXZhY3kgYWRkcmVzc2VzIChiZWNhdXNlIHRoZSBJSUQgaXMgcHJvdmlkZWQgYnkgdGhl IG5ldHdvcmspPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BLTUgUHJlZmVyIElQdjYgRE5TIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TC0xIERIQ1B2NiBQRDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TC0yIEZ1bGwgQ3VzdG9tZXIgRWRn ZSBSb3V0ZXIgc3VwcG9ydDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QS0yIEFwcGxpY2F0aW9ucyBtdXN0IGJlIElQIGFnbm9zdGljPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BLTMgVVJJIGZvcm1h dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldoYXRl dmVyIHlvdSB0aGluaywgaXQgaXMgc3RpbGwgYSBwcm9ibGVtIHRvIGdldCBzb21lIElQdjYtcmVh ZHkgZGV2aWNlcyBhbmQgdGhhdCBleHBsYWlucw0KIHdoeSBzb21lIG9uLWdvaW5nIElQdjYgZGVw bG95bWVudCBzdGlsbCByZWx5IG9uIHNvbWUgbGltaXRlZCBudW1iZXIgb2YgZGV2aWNlcyBpbiBz b21lIGFyZWFzLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBwbGVhc2UgZXhwbGFpbiB0 byBtZSBob3cgVmVyaXpvbiBXaXJlbGVzcyBzdXBwb3J0cyBJUHY2IG9uIGFsbCBpdHMgTFRFIGRl dmljZXMsIGFuZCBoYXMgZG9uZSBzaW5jZSAyMDExPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj50aGUgZG9jdW1lbnQgZG9lcyBub3QgYWRkIGFueSBuZXcgaHVyZGxlcyBm b3IgSVB2NiBkZXBsb3ltZW50IHNpbmNlIGl0IGxpc3Qgc29tZSByZXF1aXJlbWVudHMNCiBiYXNl ZCBvbiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1 dCBpdCBkb2VzIGFkZCBodXJkbGVzIGZvciBJUHY2IGRlcGxveW1lbnQuIEJlY2F1c2UgaXQgbGlz dHMgbG90cyBvZiByZXF1aXJlbWVudHMgdGhhdCBhcmUgbm90IHJlcXVpcmVkIGZvciBJUHY2IGRl cGxveW1lbnQgaW4gbW9iaWxlIG5ldHdvcmtzLCBhbmQgdGhhdCBhcmUgbm90IHdpZGVseSBzdXBw b3J0ZWQgYnkgbW9iaWxlIGRldmljZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPldlIHNob3VsZCBzcGVhayBmb3Igb3Vyc2VsdmVzIGFuZCBzaG91bGQgbm90IGltYWdp bmUgaG93IG90aGVyIHBlb3BsZSB3aWxsIGNvbnNpZGVyIHN1Y2ggZG9jdW1lbnQuPC9zcGFuPjxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSwgbm8uIEFzIElFVEYgY29udHJpYnV0b3JzIGl0IGlzIG91 ciBqb2IgdG8gY29uc2lkZXIgd2hhdCBvdGhlciBwZW9wbGUgd2lsbCB0aGluayB3aGVuIHRoZXkg cmVhZCB0aGUgZG9jdW1lbnRzIHRoYXQgd2UgcHJvZHVjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCjxQPk5PVElDRSBBTkQgRElTQ0xB SU1FUjxCUj5UaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5k ZWQgDQpmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4mbmJzcDsgSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgDQpub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwg ZGVsZXRlIHRoaXMgZW1haWwgZnJvbSB5b3VyIHN5c3RlbSBhbmQgZG8gbm90IA0KZGlzY2xvc2Ug b3IgdXNlIGZvciBhbnkgcHVycG9zZS4mbmJzcDsgPEJSPiZuYnNwOzxCUj5XZSBtYXkgbW9uaXRv ciBhbGwgaW5jb21pbmcgDQphbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50 IGxlZ2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRvIA0KZW5zdXJlIHRoYXQgdGhpcyBl bWFpbCBhbmQgYXR0YWNobWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1h aW5zIA0KeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBh ZHZlcnNlbHkgYWZmZWN0IHlvdS4gPC9QPg0KPFA+RUUgTGltaXRlZDxCUj5SZWdpc3RlcmVkIGlu IEVuZ2xhbmQgYW5kIFdhbGVzPEJSPkNvbXBhbnkgUmVnaXN0ZXJlZCBOdW1iZXI6IA0KMDIzODIx NjE8QlI+UmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVudCBQbGFjZSwgTW9zcXVpdG8g V2F5LCBIYXRmaWVsZCwgDQpIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVzwvUD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_6536E263028723489CCD5B6821D4B21303BDD55FUK30S005EXS06EE_-- From nobody Tue Oct 7 09:35:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2E1A86FB; Mon, 6 Oct 2014 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51NSvg8hCNTC; Mon, 6 Oct 2014 14:56:00 -0700 (PDT) Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2001:468:c80:2105:0:2fc:76e3:30de]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F9E1A8AC5; Mon, 6 Oct 2014 14:55:53 -0700 (PDT) Received: from mr4.cc.vt.edu (mr4.cc.vt.edu [198.82.164.236] (may be forged)) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id s96LtpFR019219; Mon, 6 Oct 2014 17:55:51 -0400 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152] (may be forged)) by mr4.cc.vt.edu (8.14.4/8.14.4) with ESMTP id s96Ltjin002129; Mon, 6 Oct 2014 17:55:50 -0400 Received: from turing-police.cc.vt.edu ([IPv6:2001:468:c80:2103:c186:771e:f835:ea9b]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id s96Ltjrn006449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Oct 2014 17:55:45 -0400 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6+dev To: Lorenzo Colitti In-Reply-To: Your message of "Mon, 06 Oct 2014 16:30:18 +0900." From: Valdis.Kletnieks@vt.edu References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1412632545_27612P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 06 Oct 2014 17:55:45 -0400 Message-ID: <28225.1412632545@turing-police.cc.vt.edu> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A30fbTjieCT3ekXX3ylRaQ-kJb4 X-Mailman-Approved-At: Tue, 07 Oct 2014 09:35:07 -0700 Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:56:02 -0000 --==_Exmh_1412632545_27612P Content-Type: text/plain; charset=us-ascii On Mon, 06 Oct 2014 16:30:18 +0900, Lorenzo Colitti said: > 1. This text is incorrect and should be removed: > > The key words "must", "must not", "should", "should not", and "may" > in this document are to be interpreted as described in RFC 2119 > [RFC2119]. > > It is meaningless to say, in the same document, that "must" is to be > interpreted as described in RFC 2119 ("an absolute requirement of the > specification"), and simultaneously that "this document is not a standard". We've probably already done that same exact thing in close to a thousand, if not more, 'Informational" RFC releases. That ship has long since sailed. Also, if you're documenting a protocol that's not an IETF Standard, the protocol description can still benefit from RFC2119 semantics. If there's a spot where the protocol semantic should have a 'MUST NOT', and a client does it anyhow, what happens? --==_Exmh_1412632545_27612P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Exmh version 2.5 07/13/2001 iQIVAwUBVDMP4QdmEQWDXROgAQLuYQ//QR1+ojJGDvVz5dpvlp3f9WEwTo239MlD oJ8+lnX2aBvGHhurdovUBoOx3/CYBv9hviA/o418fQdI+IgSx4s7IQ75vjXE5/sk Iz+dP+BD+PqpDjqQYyY0A+WmXq5E1yp3wZL27F8bHzxDlb3u5blhGQkB1tIQiLhx YYEkzLe5qexoDlIbYwqGYFFx9V/IlNzbfhPO7sm3tFRw9sWTchKtowHS8Z9U2OFN qDA+V62DygJPpDJ4Y0qd8Rulw9VVW4QQE91jLRQiEYU0CbqgYN0Thtj5HUTlMhPt BbbqDMm/eLuBFOKrJyHrm8FY4BFfMUDv+Ozu8edNvYDHYnFoqVGo60/lAmviQajA PZtm7XRI93aoPpRasNou5AUl3BAUbCYa0SqSZ7tv+S+6GqL+3sDaIsih/bDRwICU z8SOGh0Th5pxoNIQBPRSIsRDxVZQJEsRCPG4gI01/FhbvLX/fnsC/2erloBYkXiU OWoO/lZwFOq2gfb3rn/riXJLsifi4FA97g2+ykMFIPXKbiJ2AGLqbDuarQPnQbwA 4gmWCM+jTZKr+YMaZau97LgVPX5K22LEzn6erz80CEEuH/FzoedMpALRNv2vpfzh /UqnXh6gNPvDRveotoD8UG2lBU2veN263O7tSHMjtHdJnaP9E9jxNX8f+Uz8ye91 i4PCQ1hR95I= =uDGS -----END PGP SIGNATURE----- --==_Exmh_1412632545_27612P-- From nobody Tue Oct 7 22:45:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1962F1A9148 for ; Tue, 7 Oct 2014 22:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmIKGF67_SP6 for ; Tue, 7 Oct 2014 22:45:06 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96B671A9116 for ; Tue, 7 Oct 2014 22:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 50D90871612; Wed, 8 Oct 2014 07:45:04 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYLCMAobPV+t; Wed, 8 Oct 2014 07:45:04 +0200 (CEST) Received: from [192.168.0.46] (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 2C44B870067; Wed, 8 Oct 2014 07:45:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: V6ops X-Mailer: iPad Mail (12A405) In-Reply-To: <5432344D.1010007@fud.no> Date: Wed, 8 Oct 2014 07:45:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <5432344D.1010007@fud.no> To: Tore Anderson Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/W1RVJQc2-ISxfNGhXgexBH5bsbQ Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 05:45:09 -0000 Nice draft. Why do you restrict the architecture to a per host agent? Why do you restrict the IPv4 address binding to a virtual network interface?= Wouldn't this dual translation work equally well as a proxy device serving m= ultiple legacy application servers, each with their own unique static addres= s mapping? I'm thinking that true legacy machines are unlikely to be targets for implem= entations of this new technology. Nit s/poining/pointing/ > On 06 Oct 2014, at 08:18, Tore Anderson wrote: >=20 > Hello, >=20 > As Brian was quick to notice, I've uploaded a new version of the SIIT-DC > draft. I would like to solicit the WG's input on the draft (and its > companion draft[1]), in particular whether or not the work is seen as > relevant and useful, and any feedback or suggestions big or small on how > to further improve it. (Do feel free to send me minor issues in direct > e-mail if you prefer no to "spam" the WG list with them.) >=20 > [1] https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc-2xlat/ >=20 > Also, since running code is important, I'd like to point out that there > are several implementations that implement an SIIT-DC Gateway (or > something very close to the spec), from the top of my head and in > alphabetical order: Brocade ADX, Cisco ASR1k, F5 BIG-IP LTM, and > Linux/TAYGA. There's also an SIIT-DC Host Agent available at > https://github.com/toreanderson/clatd (using Linux/TAYGA). >=20 > Best regards, > Tore Anderson >=20 > -------- Forwarded Message -------- > Subject: I-D Action: draft-anderson-v6ops-siit-dc-01.txt > Date: Sun, 05 Oct 2014 11:54:23 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Newsgroups: gmane.ietf.announce >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >=20 >=20 > Title : SIIT-DC: Stateless IP/ICMP Translation for IPv6 D= ata Centre Environments > Author : Tore Anderson > Filename : draft-anderson-v6ops-siit-dc-01.txt > Pages : 30 > Date : 2014-10-05 >=20 > Abstract: > This document describes SIIT-DC, an extension to Stateless IP/ICMP > Translation (SIIT) [RFC6145] that makes it ideally suited for use in > IPv6 data centre environments. SIIT-DC simultaneously facilitates > IPv6 deployment and IPv4 address conservation. The overall SIIT-DC > architecture is described, as well as guidelines for operators. > Finally, the normative implementation requirements are described, as > a list of additions and changes to SIIT [RFC6145]. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-dc/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-anderson-v6ops-siit-dc-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-anderson-v6ops-siit-dc-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 >=20 >=20 From nobody Tue Oct 7 23:57:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE51A004C for ; Tue, 7 Oct 2014 23:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dMfgD02Aa7t for ; Tue, 7 Oct 2014 23:57:12 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4F01A0049 for ; Tue, 7 Oct 2014 23:57:12 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=47761 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XblBN-0006EG-WF; Wed, 08 Oct 2014 08:57:10 +0200 Message-ID: <5434E044.3010108@fud.no> Date: Wed, 08 Oct 2014 08:57:08 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: V6ops References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <5432344D.1010007@fud.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2WVMIAU6MSbo7mT3nZwDsPG9IbE Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 06:57:15 -0000 Good morning, > Nice draft. > > Why do you restrict the architecture to a per host agent? > > Why do you restrict the IPv4 address binding to a virtual network > interface? I'm assuming you're specifically talking about the -2xlat draft here? The plain architecture doesn't include a host agent at all, the host agent is intended to be used only in the case where the application software does not support IPv4, and/or where the application protocol doesn't support NAT. I don't mean to restrict the architecture to a per host agent at all. The -2xlat draft simply seeks to document how the plain SIIT-DC architecture can be extended to support IPv4-only application software and/or application protocols which cannot work through NAT. It's a specific use case with a specific solution. Doesn't mean you can't do other fun stuff too. :-) > Wouldn't this dual translation work equally well as a proxy device > serving multiple legacy application servers, each with their own > unique static address mapping? So if I understand you correctly an SIIT-DC topology that uses all three modes (plain for NAT-friendly HTTP, host agent for NAT-unfriendly FTP, proxy for a couple of IPv4-only machines) could look something like this? (IPv4-only Internet) | +-+-[SIIT-DC Gateway]--------------------+ | xlat prefix: 64:ff9b::/96 | | v4,v6 map 1: 192.0.2.10, 2001:db8::1:1 | | v4,v6 map 2: 192.0.2.15, 2001:db8::a:a | | v4,v6 map 3: 192.0.2.20, 2001:db8::1:2 | | v4,v6 map 4: 192.0.2.25, 2001:db8::f:f | +-+--------------------------------------+ | (IPv6-only data centre network) | +-- 2001:db8:a:a HTTP server, IPv6-only, v4 service addr=192.0.2.15 | +-- 2001:db8:f:e FTP server, IPv6-only (native IPv6 service addr) | 2001:db8:f:f FTP server via Host Agent, service addr=192.0.2.25 | +-+-[SIIT-DC Proxy]---------------------------+ | xlat prefix: 64:ff9b::/96 | | v4,v6 map 1: 192.0.2.10, 2001:db8::1:1 | | static rt 1: 192.0.2.10 nexthop 169.254.0.2 | | v4,v6 map 2: 192.0.2.20, 2001:db8::1:2 | | static rt 2: 192.0.2.20 nexthop 169.254.0.3 | +-+-------------------------------------------+ | (Proxy's IPv4-only private backend LAN - 169.254.0.0/16) | +-- 169.254.0.2 IPv4-only machine 1 (192.0.2.10 on loopback) | \-- 169.254.0.3 IPv4-only machine 2 (192.0.2.20 on loopback) I.e., that the proxy device essentially takes the role of a CE router with an IPv4 LAN behind it (for which it's the default router), but instead of terminating the 192.0.2.x addresses locally, it routes them to endpoints in that IPv4 backend LAN using host routes? (Or something along those lines anyway, the IPv4 topology could of course be as complex as you would like.) I don't see why this wouldn't work just fine. I guess I just never saw the use case for myself (for me it would still be easier to just provision a native IPv4-only VLAN for such a purpose, but I can see the use case if you have an deep IPv6-only network topology and need to support a couple of IPv4-only devices in the innermost parts of it. I'm thinking that describing this SIIT-DC Proxy could be left to a future draft, though, would you agree? > I'm thinking that true legacy machines are unlikely to be targets for > implementations of this new technology. Definitively not. The current drafts are for greenfield deployments, or mostly so. The servers must necessarily support IPv6. The application software and application protocols as well, *unless* you're using a host agent - in which case the server must implement the host agent (today, that is equivalent to "the server must be running Linux" as far as I know). > Nit s/poining/pointing/ Thanks! Tore From nobody Wed Oct 8 00:11:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408F41A0079 for ; Wed, 8 Oct 2014 00:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTXWbFy91MIC for ; Wed, 8 Oct 2014 00:11:17 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A6A4A1A007C for ; Wed, 8 Oct 2014 00:11:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 82D4E871612; Wed, 8 Oct 2014 09:11:15 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGUJjl9SSBB9; Wed, 8 Oct 2014 09:11:15 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 5A738870067; Wed, 8 Oct 2014 09:11:15 +0200 (CEST) Message-ID: <5434E36F.2060005@globis.net> Date: Wed, 08 Oct 2014 09:10:39 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Tore Anderson References: <20141005185423.19533.71711.idtracker@ietfa.amsl.com> <5432344D.1010007@fud.no> <5434E044.3010108@fud.no> In-Reply-To: <5434E044.3010108@fud.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N0IQ0xHwRCV2dbJXHtS1kHAQCus Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-anderson-v6ops-siit-dc-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 07:11:22 -0000 > Tore Anderson > 8 October 2014 08:57 > Good morning, > >> Nice draft. >> >> Why do you restrict the architecture to a per host agent? >> >> Why do you restrict the IPv4 address binding to a virtual network >> interface? > > I'm assuming you're specifically talking about the -2xlat draft here? > The plain architecture doesn't include a host agent at all, the host > agent is intended to be used only in the case where the application > software does not support IPv4, and/or where the application protocol > doesn't support NAT. Correct. Subject line was just taken from a digest message. > > I don't mean to restrict the architecture to a per host agent at all. > The -2xlat draft simply seeks to document how the plain SIIT-DC > architecture can be extended to support IPv4-only application software > and/or application protocols which cannot work through NAT. It's a > specific use case with a specific solution. Doesn't mean you can't do > other fun stuff too. :-) >> Wouldn't this dual translation work equally well as a proxy device >> serving multiple legacy application servers, each with their own >> unique static address mapping? > > So if I understand you correctly an SIIT-DC topology that uses all > three modes (plain for NAT-friendly HTTP, host agent for NAT-unfriendly > FTP, proxy for a couple of IPv4-only machines) could look something like > this? > > (IPv4-only Internet) > | > +-+-[SIIT-DC Gateway]--------------------+ > | xlat prefix: 64:ff9b::/96 | > | v4,v6 map 1: 192.0.2.10, 2001:db8::1:1 | > | v4,v6 map 2: 192.0.2.15, 2001:db8::a:a | > | v4,v6 map 3: 192.0.2.20, 2001:db8::1:2 | > | v4,v6 map 4: 192.0.2.25, 2001:db8::f:f | > +-+--------------------------------------+ > | > (IPv6-only data centre network) > | > +-- 2001:db8:a:a HTTP server, IPv6-only, v4 service addr=192.0.2.15 > | > +-- 2001:db8:f:e FTP server, IPv6-only (native IPv6 service addr) > | 2001:db8:f:f FTP server via Host Agent, service addr=192.0.2.25 > | > +-+-[SIIT-DC Proxy]---------------------------+ > | xlat prefix: 64:ff9b::/96 | > | v4,v6 map 1: 192.0.2.10, 2001:db8::1:1 | > | static rt 1: 192.0.2.10 nexthop 169.254.0.2 | > | v4,v6 map 2: 192.0.2.20, 2001:db8::1:2 | > | static rt 2: 192.0.2.20 nexthop 169.254.0.3 | > +-+-------------------------------------------+ > | > (Proxy's IPv4-only private backend LAN - 169.254.0.0/16) > | > +-- 169.254.0.2 IPv4-only machine 1 (192.0.2.10 on loopback) > | > \-- 169.254.0.3 IPv4-only machine 2 (192.0.2.20 on loopback) > > I.e., that the proxy device essentially takes the role of a CE router > with an IPv4 LAN behind it (for which it's the default router), but > instead of terminating the 192.0.2.x addresses locally, it routes them > to endpoints in that IPv4 backend LAN using host routes? Correct. > (Or something > along those lines anyway, the IPv4 topology could of course be as > complex as you would like.) > > I don't see why this wouldn't work just fine. I guess I just never saw > the use case for myself (for me it would still be easier to just > provision a native IPv4-only VLAN for such a purpose, but I can see the > use case if you have an deep IPv6-only network topology and need to > support a couple of IPv4-only devices in the innermost parts of it. Indeed. Depends on the DC infra. If you have a multi-site DC connected via DWDM and/or dot1qinq and/or private MPLS, sure. If you have deep IPv6-only inter-connected DC sites, or a campus network, then that IPv4 VLAN could be expensive. > I'm > thinking that describing this SIIT-DC Proxy could be left to a future > draft, though, would you agree? Agreed. Although I'm not sure it's a whole lot of work to incorporate it into this draft. >> I'm thinking that true legacy machines are unlikely to be targets for >> implementations of this new technology. > > Definitively not. The current drafts are for greenfield deployments, or > mostly so. The servers must necessarily support IPv6. The application > software and application protocols as well, *unless* you're using a host > agent - in which case the server must implement the host agent (today, > that is equivalent to "the server must be running Linux" as far as I know). > >> Nit s/poining/pointing/ > > Thanks! > > Tore > ------------------------------------------------------------------------ -- Regards, RayH From nobody Wed Oct 8 06:53:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80261A1A91; Wed, 8 Oct 2014 06:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.386 X-Spam-Level: ** X-Spam-Status: No, score=2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWytGWaKg0sI; Wed, 8 Oct 2014 06:53:31 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F0D1A1AA0; Wed, 8 Oct 2014 06:53:29 -0700 (PDT) Received: from 10.236.62.152 (EHLO OPE10HT02.tp.gk.corp.tepenet) ([10.236.62.152]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id CDZ97522; Wed, 08 Oct 2014 15:53:21 +0200 (CEST) From: Kossut Tomasz - Hurt To: "Heatley, Nick" , Lorenzo Colitti , IETF Discussion Thread-Topic: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHP4hhuQuRojk5bGEmIVdNfV1nkHZwmFUAg Date: Wed, 8 Oct 2014 13:52:40 +0000 Message-ID: References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.154] Content-Type: multipart/alternative; boundary="_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE7E836OPE10MB06tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2014.10.8.125718:17:9.753, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __FRAUD_CONTACT_ADDY_B, __HIGHBITS, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __C230066_P5, __STOCK_PHRASE_7, __LINES_OF_YELLING, SUPERLONG_LINE, __HTML_BOLD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_90_100, HTML_95_100, HTML_98_100, HTML_99_100, WEBMAIL_SOURCE, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0208.543541D1.0127, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0208.543541D1.0127, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 18f0e386648b3f9e324ad9d3e2ab7288 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Kpfdrq2PdAXz2bFcZTxHbG6w8_I Cc: "v6ops@ietf.org WG" , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 13:53:35 -0000 --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE7E836OPE10MB06tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpNYWpvcml0eSBvZiBtb2Rlcm4gc21hcnRwaG9uZXMgZnJvbSBTb255LCBIVEMsIExHLCBT YW1zdW5nLCBOb2tpYSBXUDguMSBhcmUgY29tcGxpYW50IHdpdGggQ0xBVCtOQVQ2NC9ETlMvRE5T NjQNClRvZ2V0aGVyIHdpdGggTWljaGHFgiBDemVyd29ua2Egd2UgY3JlYXRlZCBkb2N1bWVudCB3 aXRoIG1hbmRhdG9yeSBJUHY2IHJlcXVpcmVtZW50cywgY2xvc2UgY29vcGVyYXRpb24gd2l0aCB2 ZW5kb3JzIHN1Y2NlZWRlZCBhbmQgd2UgbWFuYWdlZCB0byBsYXVuY2ggZmlyc3QgdGVybWluYWwg KFhwZXJpYSBaMSkgaW4gU2VwdGVtYmVyIDIwMTMsIGFmdGVyIDEyIG1vbnRocyB3ZSBoYXZlIDEz JSBvZiBJUHY2IG9ubHkgbW9iaWxlIHVzZXJzIGluIGEgbmV0d29yay4gSWYgeW91IGFyZSBtb2Jp bGUgb3BlcmF0b3IgYW5kIHlvdSB0aGlua2luZyBhYm91dCBJUHY2IG1pZ3JhdGlvbiB5b3Ugd29u 4oCZdCBoYXZlIGFueSBwcm9ibGVtcyB3aXRoIFNtYXJ0cGhvbmVzIChleGNlcHQgSXBob25lcz1O TyBDTEFUIHN1cHBvcnQpIHRoZSB3YXkgaXMgcGF2ZWQgZm9yIHlvdS4uLg0KDQoNCiAgMS4gIE5l dHdvcmsgQ29uZmlndXJhdGlvbiAoQ0xBVCtOQVQ2NCtETlMpDQpJbnRlcm5ldCBhY2Nlc3MgaXMg ZG9uZSBieSBlc3RhYmxpc2hpbmcgb25lIGRlZGljYXRlZCBJUHY2LW9ubHkgUERQL1BETiBjb250 ZXh0LCBuZXR3b3JrIHN1cHBvcnRzIDQ2NHhsYXQgYXJjaGl0ZWN0dXJlIHdpdGggRE5TIER1YWwt U3RhY2sgKEROUzY0IGZlYXR1cmUgaXMgYXZhaWxhYmxlIG9ubHkgZm9yIGRvbWFpbiDigJxpcHY0 b25seS5hcnBh4oCdKSAtIFJGQyA2ODc3LiBDTEFUIGltcGxlbWVudGF0aW9uIGlzIG1hbmRhdG9y eSBmb3IgYWxsIGRldmljZXMNCg0KDQogIDEuICBVRSwgQ1BFIHZlbmRvciBJUHY2IG1hbmRhdG9y eSByZXF1aXJlbWVudHMNCjIuMS5EeW5hbWljIElQdjYgQWRkcmVzcyBBbGxvY2F0aW9uICsgSUlE IHJhbmRvbWx5IGdlbmVyYXRlZCAocHJpdmFjeSBhZGRyZXNzKSArICBVRSBzaGFsbCB1c2UgdGhl IElJRCBnaXZlbiBpbiBQRFAgYWN0aXZhdGlvbiByZXNwb25zZSBtZXNzYWdlIHRvIGNvbmZpZ3Vy ZSBpdHMgTExBICgzR1BQIFRTICAyMy4wNjA8aHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAvU3BlY3Mv YXJjaGl2ZS8yM19zZXJpZXMvMjMuMDYwPikgaHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAvU3BlY3Mv YXJjaGl2ZS8yM19zZXJpZXMvMjMuMDYwLy4NCjIuMi5DdXN0b21lciBTaWRlIFRyYW5zbGF0b3Ig ZnVuY3Rpb24gKENMQVQpIG11c3QgYmUgZW1iZWRkZWQgKHNtYXJ0cGhvbmUvdGFibGV0L3JvdXRl cikgYXMgcGFydCBvZiA0NjR4bGF0IGFyY2hpdGVjdHVyZSAgUkZDIDY4NzcuIFRoZSBDTEFUIG11 c3Qgc3VwcG9ydCBJQ01QLCBVRFAsIFRDUCwgR1JFIGFuZCBmcmFnbWVudGVkIHBhY2tldC4gY2xh dGQuY29uZiAgLSBtYXkgYmUgZ2VuZXJpYyB3aGVyZSB0aGUgZG9tYWluIGZvciBuYXQ2NCBwcmVm aXggZGlzY292ZXJ5IG11c3QgYmUg4oCcaXB2NG9ubHkuYXJwYeKAnSDigJMgIHN0YXRpYyBjb25m aWd1cmF0aW9uIG1heSBiZSByZXF1aXJlZC4NCmh0dHBzOi8vYW5kcm9pZC5nb29nbGVzb3VyY2Uu Y29tL3BsYXRmb3JtL2V4dGVybmFsL2FuZHJvaWQtY2xhdC8NCjIuMy5NVFUgc2l6ZSAmIGRldmlj ZSBpbnRlcmZhY2VzIC0gSWYgdGhlIG5ldHdvcmsgc2VuZCBNVFUgc2l6ZSBpbiBSQSBtZXNzYWdl LCB0aGVuIGRldmljZSBtdXN0IHNldCBpdCB0byB0aGUgcmFkaW8gaW50ZXJmYWNlIG90aGVyd2lz ZSBzZXQgdGhlIGRlZmF1bHQgdmFsdWU9MTUwMEIuIFRoZSBDTEFUIGRlbW9uIHdpbGwgY2FsY3Vs YXRlIE1UVSBzaXplIGF1dG9tYXRpY2FsbHkgZm9yIGl0cyBpbnRlcmZhY2VzIChjbGF0IGFuZCBj bGF0NCkuDQoNCiAgMS4gIElQdjYgdGV0aGVyaW5nIC0gdGhlIENMQVQgaGVscHMgRHVhbCBTdGFj ayB0ZXRoZXJpbmcgc29sdXRpb24gYm90aCBVU0IvV0lGSSBvbiB0aGUgZGV2aWNlICwgd2hlbiBB UE4gaXMgSVB2Ni1vbmx5LiBUaGUgR2xvYmFsIElQdjYgYW5kIHByaXZhdGUgSVB2NCAoY2xhdCkg bXVzdCBiZSBlbmFibGVkIG9uIHRldGhlcmVkIExBTi4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzcyNzggKHNjZW5hcmlvIDIpDQozLjEuUkEg4oCTIGRldmljZSBzZW5kcyBSQSBtZXNz YWdlIHRvIHRldGhlcmVkIGhvc3Qgd2l0aCBJcHY2IHByZWZpeCBpbmZvcm1hdGlvbi4gUm91dGVy IGxpZmV0aW1lIHNldD05MDAwIHNlY3MuIFJvdXRlciBzZW5kcyBwZXJpb2RpY2FsbHkgUkEgbWVz c2FnZSDigJMgbWF4LiB2YWx1ZSA5MDAwIHNlY3MuDQozLjIuREhDUHY2IOKAkyBkZXZpY2Ugc2Vy dmVyIHJlbGF5cyBQQ08gSXB2NiBETlMnZXMgYWRkcmVzc2VzIHRvIHRldGhlcmVkIGhvc3RzLg0K My4zLkRIQ1B2NCDigJMgZGV2aWNlIHNlcnZlciByZWxheXMgIHByaXZhdGUgSVB2NCBhZGRyZXNz IGFuZCBzZW5kIEROUyBJUHY0IChDTEFUIEROUy1wcm94eSkNCjMuNC5UZXRoZXJpbmcgJiBNVFUg c2l6ZSDigJMgZGV2aWNlIHByb3BhZ2F0ZXMgTVRVIHNpemUgMTUwMEIgdG8gdGV0aGVyZWQgY2xp ZW50cyBpbnRlcmZhY2VzICggSXB2NCZJcHY2KQ0KDQogIDEuICBJUHY2IExURSBVRSAgLSB0aGUg ZGV2aWNlIG11c3Qgc2V0IEVJVCBiaXQ9MSBpbiDigJxJbml0aWFsIEF0dGFjaOKAnSBtZXNzYWdl Lg0KUm9hbWluZyAtIHdoZW4gQVBOIHdpdGggSVB2NiBwcm90b2NvbCBmYWlscyBpbiByb2FtaW5n IGl0IG11c3QgYXV0b21hdGljYWxseSByZXZlcnQgYmFjayBBUE4gcHJvdG9jb2wgdG8gSVB2NA0K DQpPbmUgdGhpbmcgaXMgc3RpbGwgbWlzc2luZyDigJMgZGlmZmVyZW50IEFQTiBwcm9maWxlcyhB UE4gbmFtZStQRFAgdHlwZSkgZm9yIHJvYW1pbmcg4oCTLCB0aGVyZSBhcmUgdHdvIHVzZSBjYXNl czoNCkV1aW50ZXJlbnQg4oCTICjigJxFVSBSb2FtaW5nIFJlZ3VsYXRpb24gSUlJ4oCdKSBJbnRl cm5ldCBBUE4gYXZhaWxhYmxlIGluIFVFIGNvdW50cmllcyAoVlBMTU4gc3Vic2NyaWJlciBpcyBh bGxvd2VkIHRvIHVzZSBWR0dTTiBBUE4pDQrigJxSb2FtaW5nIEZhbGxiYWNrIHRvIElQdjTigJ0g Y3JlYXRpbmcgc2VwYXJhdGUgcm9hbWluZyBwcm9maWxlIHdpdGggQVBOIG5hbWUvUERQIChub3cg cm9hbWluZyBmYWxsYmFjayBpcyBiYXNlZCBvbmx5IG9uIFBEUCB0eXBlIEFuZHJvaWQ0LngvV1A4 LjEpDQoNCkhlcmUgYXJlIHRoZSBiZW5lZml0cyBvZiBleHRlbmRpbmcgQVBOIHByb2ZpbGVzOg0K DQoNCi0gICAgICAgQVBOIHByb2ZpbGVzIGFuZCBpdHMg4oCcem9uZXPigJ0gSFBMTU4vVlBMTU4g Y2FuIHNlcGFyYXRlIElQdjYgZm9ybSBJUHY0DQoNCi0gICAgICAgU2VwYXJhdGUgQVBOIGZvciBI UExNTiAoSXB2NiBvbmx5IEFQTiBmb3IgSFBMTU4pDQoNCi0gICAgICAgU2VwYXJhdGUgIEFQTiBm b3IgVlBMTU4gcm9hbWluZyAoZmFsbGJhY2sgdG8gSVB2NCBiYXNlZCBvbiBBUE4gbmFtZSkNCg0K LSAgICAgICBFdWludGVybmV0IEFQTiBhcyBzZWNvbmRhcnkgcm9hbWluZyBwcm9maWxlIGZvciBt YW51YWwgc2VsZWN0aW9uDQoNCkJlc3QgUmVnYXJkcywNClRvbWFzeiBLb3NzdXQNCg0KDQpGcm9t OiBIZWF0bGV5LCBOaWNrIFttYWlsdG86bmljay5oZWF0bGV5QGVlLmNvLnVrXQ0KU2VudDogVHVl c2RheSwgT2N0b2JlciAwNywgMjAxNCAxMTozMSBBTQ0KVG86IExvcmVuem8gQ29saXR0aTsgSUVU RiBEaXNjdXNzaW9uDQpDYzogdjZvcHNAaWV0Zi5vcmcgV0c7IElFVEYtQW5ub3VuY2UNClN1Ympl Y3Q6IFJlOiBbdjZvcHNdIExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmlj ZS1wcm9maWxlLTEzLnR4dD4gKEFuIEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2Nikg UHJvZmlsZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNlcykgdG8gSW5mb3JtYXRpb25hbCBSRkMNCg0K Mi4gSSBzdGFuZCBieSBteSBlYXJsaWVyIGFzc2Vzc21lbnQgdGhhdCB0aGlzIGRvY3VtZW50J3Mg cmVxdWlyZW1lbnRzIGFyZSBvdmVyLWJyb2FkLCBhbmQgaW4gZmFjdCBzbyBicm9hZCBhcyB0byBo YXJtIGFkb3B0aW9uLiBUaGVyZSBtYXkgd2VsbCBiZSBvcGVyYXRvcnMgb3IgZGV2aWNlIGltcGxl bWVudGVycyB0aGF0IHNlZWluZyB3aXRoIHN1Y2ggYSBoaWdoIG51bWJlciBvZiByZXF1aXJlbWVu dHMgbWF5IHNoeSBhd2F5IGluIHRlcnJvciBhbmQgdGhpbmsgdGhhdCBkZXBsb3lpbmcgSVB2NiBp biBhIG1vYmlsZSBuZXR3b3JrIGlzIGFuIGltcG9zc2libHkgaGlnaCBhbW91bnQgb2Ygd29yay4g VGhhdCBzYWlkLCBnaXZlbiB0aGF0IHRoaXMgZG9jdW1lbnQgc2F5cyBjbGVhcmx5IHRoYXQgaXQg aXMgbm90IGEgc3RhbmRhcmQsIGFuZCB0aGF0IGNvbXBsaWFuY2UgaXMgbm90IHJlcXVpcmVkLCB0 aGUgaGFybSBpdCBkb2VzIHdpbGwgYmUgbGltaXRlZC4NCg0KVGhlcmUgbWF5IHdlbGwgYmUgb3Bl cmF0b3JzIGFuZCBkZXZpY2UgaW1wbGVtZW50ZXJzIHRoYXQgc2VlIHRoZSBtYW55IGluZGl2aWR1 YWwg4oCcSVB2NuKAnSBSRkNzIGFuZCBzaHkgYXdheS4gVHJhbnNpdGlvbmluZyB0ZWNobm9sb2dp ZXMgYXJlIHN0aWxsIHBlcmNlaXZlZCBhcyBpc3N1ZXMgZm9yIHRoZSBuZXR3b3JrLg0KSWYgdGhp cyBjcm9zcy1vcGVyYXRvciBkb2N1bWVudCBzdGF0ZXMgd2hhdCBpcyByZXF1aXJlZCBvbiB0ZXJt aW5hbHMgdG8gd29yayBpbiBhbGwgbWFqb3IvcHJlZGljdGFibGUgSVB2NiBzY2VuYXJpb3MsIHRo ZW4gaXQgaXMgZ2l2aW5nIHN1Y2ggcGVvcGxlIGEgdmlldyBvZiB3aGF0IGEg4oCcaGVhbHRoeSBh bmQgcm9idXN04oCdIHRlcm1pbmFsIGltcGxlbWVudGF0aW9uIHdvdWxkIGNvbnNpc3Qgb2YuIElm IHRoZXkgYXJlIGFibGUgdG8gZGVsaXZlciBvbiB0aGVzZSByZXF1aXJlbWVudHMgdGhlbiB0aGV5 IGNhbiBzdXBwbHkgYSB0ZXJtaW5hbCByZWFkeSBmb3IgYWxsIGJ1c2luZXNzIGFyZWFzIC9hbGwg b3BlcmF0b3IgbmV0d29yayBzY2VuYXJpb3MuDQooSXQgY2VydGFpbmx5IHN0b3BzIHRoZSBmZWVk YmFjayBJ4oCZdmUgaGFkIGZyb20gY2VydGFpbiBjb3JuZXJzIOKAnHRoYXQgbm8gb3RoZXIgb3Bl cmF0b3JzIGFyZSBhc2tpbmcgZm9yIElQdjbigJ0sIGFuZCDigJx3aGF0IHlvdSBhcmUgYXNraW5n IGZvciBpcyBhIHNpbmdsZSBvcGVyYXRvciByb2FkbWFwIHdoaWNoIHdlIHdvbuKAmXQgZG/igJ0u IFRoYXQgaGFzIGJlZW4gdGhlIHJlYWxpdHkgaGVyZSkuIFNvIEkgZG9u4oCZdCBzZWUgaG93IGEg Y29uc29saWRhdGVkIGRlbWFuZC1zaWRlIHZpZXcgZnJvbSBvcGVyYXRvcnMgd2hvIGFyZSByZWFs bHkgdHJ5aW5nIHRvIGludHJvZHVjZSBJUHY2ICBpbiBtb2JpbGUgY2FuIGhhcm0gYWRvcHRpb24g aW4gYW55IHdheS4NClJlZ2FyZHMsDQpOaWNrDQoNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9w cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRpDQpTZW50OiAw NiBPY3RvYmVyIDIwMTQgMDg6MzANClRvOiBJRVRGIERpc2N1c3Npb24NCkNjOiB2Nm9wc0BpZXRm Lm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IFdHOyBJRVRGLUFubm91bmNlDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXY2b3BzLW1vYmlsZS1kZXZpY2UtcHJv ZmlsZS0xMy50eHQ+IChBbiBJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDYgKElQdjYpIFByb2Zp bGUgZm9yIDNHUFAgTW9iaWxlIERldmljZXMpIHRvIEluZm9ybWF0aW9uYWwgUkZDDQoNCg0KDQpO T1RJQ0UgQU5EIERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzKSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5LCBkZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xv c2Ugb3IgdXNlIGZvciBhbnkgcHVycG9zZS4NCg0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5n IGFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdl IGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVu dHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2li aWxpdHkgdG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3Uu DQoNCkVFIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkg UmVnaXN0ZXJlZCBOdW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBU cmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEw IDlCVw0K --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE7E836OPE10MB06tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSBabmFrIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K c3Bhbi5UZWtzdGR5bWthWm5haw0KCXttc28tc3R5bGUtbmFtZToiVGVrc3QgZHlta2EgWm5hayI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uU3R5bHdpYWRvbW9j aWUtbWFpbDE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLkJhbGxvb25UZXh0LCBsaS5C YWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQiOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLlN0eWx3 aWFkb21vY2llLW1haWwyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5w bG4NCgl7bXNvLXN0eWxlLW5hbWU6cGxuO30NCnNwYW4ucHVuDQoJe21zby1zdHlsZS1uYW1lOnB1 bjt9DQpzcGFuLmhwcw0KCXttc28tc3R5bGUtbmFtZTpocHM7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExMzgzODQxMDQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRleHQ6 IiUxXC4lMlwuIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NTQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDo3Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjkwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMDguMHB0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3Rv cDoxMjYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoxMjYuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoxNDQuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoxNjIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjIuMHB0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxODAuMHB0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6ODg5MzQzMTQ2 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTY4NzEy MDAwIC0xNTc1MDkxODQ2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJY29sb3I6IzFGNDk3RDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjEyNTc5NzgzODY7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwMTQ3NTc3NCAtODE4MDEw MDE4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwyOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFqb3JpdHkgb2YgbW9kZXJuIHNtYXJ0cGhvbmVz IGZyb20gU29ueSwgSFRDLCBMRywgU2Ftc3VuZywgTm9raWEgV1A4LjEgYXJlIGNvbXBsaWFudCB3 aXRoIENMQVQmIzQzO05BVDY0L0ROUy9ETlM2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Ub2dldGhlciB3aXRoIE1pY2hhxYIgQ3plcndvbmthIHdlIGNyZWF0ZWQgZG9jdW1lbnQgd2l0 aCBtYW5kYXRvcnkgSVB2NiByZXF1aXJlbWVudHMsIGNsb3NlIGNvb3BlcmF0aW9uIHdpdGggdmVu ZG9ycyBzdWNjZWVkZWQgYW5kIHdlIG1hbmFnZWQgdG8gbGF1bmNoIGZpcnN0DQogdGVybWluYWwg KFhwZXJpYSBaMSkgaW4gU2VwdGVtYmVyIDIwMTMsIGFmdGVyIDEyIG1vbnRocyB3ZSBoYXZlIDEz JSBvZiBJUHY2IG9ubHkgbW9iaWxlIHVzZXJzIGluIGEgbmV0d29yay4gSWYgeW91IGFyZSBtb2Jp bGUgb3BlcmF0b3IgYW5kIHlvdSB0aGlua2luZyBhYm91dCBJUHY2IG1pZ3JhdGlvbiB5b3Ugd29u 4oCZdCBoYXZlIGFueSBwcm9ibGVtcyB3aXRoIFNtYXJ0cGhvbmVzIChleGNlcHQgSXBob25lcz1O TyBDTEFUIHN1cHBvcnQpIHRoZSB3YXkNCiBpcyBwYXZlZCBmb3IgeW91Li4uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHls ZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JTttc28tbGlz dDpsMiBsZXZlbDEgbGZvMiI+DQo8Yj5OZXR3b3JrIENvbmZpZ3VyYXRpb24gPC9iPig8Yj5DTEFU JiM0MztOQVQ2NCYjNDM7RE5TPC9iPik8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjwvYj5JbnRlcm5ldCBhY2Nl c3MgaXMgZG9uZSBieSBlc3RhYmxpc2hpbmcgb25lIGRlZGljYXRlZCBJUHY2LW9ubHkgUERQL1BE TiBjb250ZXh0LCBuZXR3b3JrIHN1cHBvcnRzIDQ2NHhsYXQgYXJjaGl0ZWN0dXJlIHdpdGggRE5T IER1YWwtU3RhY2sgKEROUzY0IGZlYXR1cmUgaXMgYXZhaWxhYmxlIG9ubHkgZm9yIGRvbWFpbiDi gJxpcHY0b25seS5hcnBh4oCdKSAtDQogUkZDIDY4NzcuIENMQVQgaW1wbGVtZW50YXRpb24gaXMg bWFuZGF0b3J5IGZvciBhbGwgZGV2aWNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAuMHB0O2xpbmUtaGVpZ2h0OjExNSU7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPGI+VUUsIENQRSB2ZW5kb3IgSVB2NiBtYW5kYXRv cnkgcmVxdWlyZW1lbnRzPG86cD48L286cD48L2I+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjEwLjBwdDttYXJnaW4tbGVmdDozNS40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDts aW5lLWhlaWdodDoxMTUlO21zby1saXN0OmwwIGxldmVsMiBsZm8zIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuMS48L3NwYW4+PC9iPjwh W2VuZGlmXT48Yj5EeW5hbWljIElQdjYgQWRkcmVzcyBBbGxvY2F0aW9uICYjNDM7IElJRCByYW5k b21seSBnZW5lcmF0ZWQ8L2I+IChwcml2YWN5IGFkZHJlc3MpICYjNDM7Jm5ic3A7IFVFIHNoYWxs IHVzZSB0aGUgSUlEIGdpdmVuIGluIFBEUCBhY3RpdmF0aW9uIHJlc3BvbnNlIG1lc3NhZ2UgdG8g Y29uZmlndXJlIGl0cyBMTEEgKDNHUFAgVFM8Yj4mbmJzcDs8L2I+DQo8YSBocmVmPSJodHRwOi8v d3d3LjNncHAub3JnL2Z0cC9TcGVjcy9hcmNoaXZlLzIzX3Nlcmllcy8yMy4wNjAiPjIzLjA2MDwv YT4pIDxhIGhyZWY9Imh0dHA6Ly93d3cuM2dwcC5vcmcvZnRwL1NwZWNzL2FyY2hpdmUvMjNfc2Vy aWVzLzIzLjA2MC8iPg0KaHR0cDovL3d3dy4zZ3BwLm9yZy9mdHAvU3BlY3MvYXJjaGl2ZS8yM19z ZXJpZXMvMjMuMDYwLzwvYT4uIDxiPjxvOnA+PC9vOnA+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MzUuNHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bGluZS1oZWlnaHQ6MTE1JTttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48Yj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjIuPC9zcGFuPjwvYj48 IVtlbmRpZl0+PGI+Q3VzdG9tZXIgU2lkZSBUcmFuc2xhdG9yIGZ1bmN0aW9uPC9iPiAoQ0xBVCkg bXVzdCBiZSBlbWJlZGRlZCAoc21hcnRwaG9uZS90YWJsZXQvcm91dGVyKSBhcyBwYXJ0IG9mIDQ2 NHhsYXQgYXJjaGl0ZWN0dXJlJm5ic3A7IFJGQyA2ODc3LiBUaGUgQ0xBVCBtdXN0IHN1cHBvcnQg SUNNUCwgVURQLCBUQ1AsIEdSRSBhbmQNCiBmcmFnbWVudGVkIHBhY2tldC4gPGI+Y2xhdGQuY29u ZjwvYj4mbmJzcDsgLSBtYXkgYmUgZ2VuZXJpYyB3aGVyZSB0aGUgZG9tYWluIGZvciBuYXQ2NCBw cmVmaXggZGlzY292ZXJ5IG11c3QgYmUg4oCcPHNwYW4gY2xhc3M9InBsbiI+aXB2NG9ubHk8L3Nw YW4+PHNwYW4gY2xhc3M9InB1biI+Ljwvc3Bhbj48c3BhbiBjbGFzcz0icGxuIj5hcnBhPC9zcGFu PjxzcGFuIGNsYXNzPSJwbG4iPuKAnTwvc3Bhbj4g4oCTJm5ic3A7IHN0YXRpYyBjb25maWd1cmF0 aW9uIG1heSBiZSByZXF1aXJlZC48Yj48bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48YSBocmVmPSJodHRwczovL2FuZHJv aWQuZ29vZ2xlc291cmNlLmNvbS9wbGF0Zm9ybS9leHRlcm5hbC9hbmRyb2lkLWNsYXQvIj5odHRw czovL2FuZHJvaWQuZ29vZ2xlc291cmNlLmNvbS9wbGF0Zm9ybS9leHRlcm5hbC9hbmRyb2lkLWNs YXQvPC9hPjxiPjxvOnA+PC9vOnA+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTox MC4wcHQ7bWFyZ2luLWxlZnQ6MzUuNHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6 MTE1JTttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Yj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjMuPC9zcGFuPjwvYj48IVtlbmRpZl0+PGI+ TVRVIHNpemUgJmFtcDsgZGV2aWNlIGludGVyZmFjZXMgLQ0KPC9iPklmIHRoZSBuZXR3b3JrIHNl bmQgTVRVIHNpemUgaW4gUkEgbWVzc2FnZSwgdGhlbiBkZXZpY2UgbXVzdCBzZXQgaXQgdG8gdGhl IHJhZGlvIGludGVyZmFjZSBvdGhlcndpc2Ugc2V0IHRoZSBkZWZhdWx0IHZhbHVlPTE1MDBCLiBU aGUgQ0xBVCBkZW1vbiB3aWxsIGNhbGN1bGF0ZSBNVFUgc2l6ZQ0KPHNwYW4gY2xhc3M9ImhwcyI+ PHNwYW4gbGFuZz0iRU4iPmF1dG9tYXRpY2FsbHk8L3NwYW4+PC9zcGFuPiBmb3IgaXRzIGludGVy ZmFjZXMgKGNsYXQgYW5kIGNsYXQ0KS48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHN0YXJ0PSIzIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMC4wcHQ7bGluZS1oZWlnaHQ6MTE1JTttc28tbGlzdDpsMCBsZXZl bDEgbGZvMyI+DQo8Yj5JUHY2IHRldGhlcmluZzwvYj4gLSB0aGUgQ0xBVCBoZWxwcyBEdWFsIFN0 YWNrIHRldGhlcmluZyBzb2x1dGlvbiBib3RoIFVTQi9XSUZJIG9uIHRoZSBkZXZpY2UgLCB3aGVu IEFQTiBpcyBJUHY2LW9ubHkuIFRoZSBHbG9iYWwgSVB2NiBhbmQgcHJpdmF0ZSBJUHY0IChjbGF0 KSBtdXN0IGJlIGVuYWJsZWQgb24gdGV0aGVyZWQgTEFOLjxiPjxvOnA+PC9vOnA+PC9iPjwvbGk+ PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNzgiPjxzcGFuIGxhbmc9IkVT Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Mjc4PC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFUyI+IChzY2VuYXJpbyAyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MzUuNHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bGluZS1oZWlnaHQ6MTE1JTttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48Yj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjEuPC9zcGFuPjwvYj48 IVtlbmRpZl0+PGI+UkEg4oCTDQo8L2I+ZGV2aWNlIHNlbmRzIFJBIG1lc3NhZ2UgdG8gdGV0aGVy ZWQgaG9zdCB3aXRoIElwdjYgcHJlZml4IGluZm9ybWF0aW9uLiBSb3V0ZXIgbGlmZXRpbWUgc2V0 PTkwMDAgc2Vjcy4gUm91dGVyIHNlbmRzIHBlcmlvZGljYWxseSBSQSBtZXNzYWdlIOKAkyBtYXgu IHZhbHVlIDkwMDAgc2Vjcy48Yj48bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjM1LjRwdDt0ZXh0LWluZGVudDotMTguMHB0O2xp bmUtaGVpZ2h0OjExNSU7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PGI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My4yLjwvc3Bhbj48L2I+PCFb ZW5kaWZdPjxiPkRIQ1B2NjwvYj4g4oCTIGRldmljZSBzZXJ2ZXIgcmVsYXlzIFBDTyBJcHY2IERO UydlcyBhZGRyZXNzZXMgdG8gdGV0aGVyZWQgaG9zdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206MTAuMHB0O21hcmdpbi1sZWZ0OjM1LjRwdDt0ZXh0LWluZGVudDot MTguMHB0O2xpbmUtaGVpZ2h0OjExNSU7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PGI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My4zLjwvc3Bh bj48L2I+PCFbZW5kaWZdPjxiPkRIQ1B2NDwvYj4g4oCTIGRldmljZSBzZXJ2ZXIgcmVsYXlzJm5i c3A7IHByaXZhdGUgSVB2NCBhZGRyZXNzIGFuZCBzZW5kIEROUyBJUHY0IChDTEFUIEROUy1wcm94 eSk8Yj48bzpwPjwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTAuMHB0 O21hcmdpbi1sZWZ0OjM1LjRwdDt0ZXh0LWluZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjExNSU7 bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My40Ljwvc3Bhbj48L2I+PCFbZW5kaWZdPjxiPlRldGhl cmluZyAmYW1wOyBNVFUgc2l6ZTwvYj4g4oCTIGRldmljZSBwcm9wYWdhdGVzIE1UVSBzaXplIDE1 MDBCIHRvIHRldGhlcmVkIGNsaWVudHMgaW50ZXJmYWNlcyAoIElwdjQmYW1wO0lwdjYpDQo8Yj48 bzpwPjwvbzpwPjwvYj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iNCIg dHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTAu MHB0O2xpbmUtaGVpZ2h0OjExNSU7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPGI+SVB2NiBM VEUgVUU8L2I+Jm5ic3A7IC0gdGhlIGRldmljZSBtdXN0IDxiPnNldCBFSVQgYml0PTEgaW4g4oCc SW5pdGlhbCBBdHRhY2jigJ08L2I+IG1lc3NhZ2UuPGI+PG86cD48L286cD48L2I+PC9saT48L29s Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Um9hbWluZzwvYj4gLSB3aGVuIEFQTiB3aXRoIElQ djYgcHJvdG9jb2wgZmFpbHMgaW4gcm9hbWluZyBpdCBtdXN0IGF1dG9tYXRpY2FsbHkgcmV2ZXJ0 IGJhY2sgQVBOIHByb3RvY29sIHRvIElQdjQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ T25lIHRoaW5nIGlzIHN0aWxsIG1pc3Npbmc8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4g4oCTIGRpZmZlcmVudCBBUE4gcHJvZmlsZXMoQVBOIG5h bWUmIzQzO1BEUA0KIHR5cGUpIGZvciByb2FtaW5nIOKAkywgdGhlcmUgYXJlIHR3byB1c2UgY2Fz ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV1aW50ZXJlbnQg4oCTICg8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkZSIj7igJxFVSBSb2FtaW5nIFJlZ3VsYXRpb24gSUlJ4oCdKSBJbnRlcm5ldA0KIEFQTiBh dmFpbGFibGUgaW4gVUUgY291bnRyaWVzIChWUExNTiBzdWJzY3JpYmVyIGlzIGFsbG93ZWQgdG8g dXNlIFZHR1NOIEFQTik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RlIiPuKAnFJvYW1pbmcgRmFsbGJhY2sgdG8gSVB2NOKAnSBjcmVhdGluZyBzZXBhcmF0 ZSByb2FtaW5nIHByb2ZpbGUgd2l0aCBBUE4gbmFtZS9QRFAgKG5vdyByb2FtaW5nIGZhbGxiYWNr IGlzIGJhc2VkIG9ubHkgb24gUERQIHR5cGUgQW5kcm9pZDQueC9XUDguMSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+SGVyZSBhcmUgdGhlIGJl bmVmaXRzIG9mIGV4dGVuZGluZyBBUE4gcHJvZmlsZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFQ TiBwcm9maWxlcyBhbmQgaXRzIOKAnHpvbmVz4oCdIEhQTE1OL1ZQTE1OIGNhbiBzZXBhcmF0ZSBJ UHY2IGZvcm0gSVB2NA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZXBhcmF0ZSBBUE4gZm9yIEhQTE1O IChJcHY2IG9ubHkgQVBOIGZvciBIUExNTik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlcGFyYXRlICZu YnNwO0FQTiBmb3IgVlBMTU4gcm9hbWluZyAoZmFsbGJhY2sgdG8gSVB2NCBiYXNlZCBvbiBBUE4g bmFtZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV1aW50ZXJuZXQgQVBOIGFzIHNlY29uZGFyeSByb2Ft aW5nIHByb2ZpbGUgZm9yIG1hbnVhbCBzZWxlY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG9t YXN6IEtvc3N1dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IlBMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEhlYXRsZXksIE5pY2sgW21haWx0bzpuaWNr LmhlYXRsZXlAZWUuY28udWtdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAw NywgMjAxNCAxMTozMSBBTTxicj4NCjxiPlRvOjwvYj4gTG9yZW56byBDb2xpdHRpOyBJRVRGIERp c2N1c3Npb248YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnIFdHOyBJRVRGLUFubm91bmNl PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll dGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTEzLnR4dCZndDsgKEFuIEludGVybmV0IFBy b3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNlcykg dG8gSW5mb3JtYXRpb25hbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+ Mi4gSSBzdGFuZCBieSBteSBlYXJsaWVyIGFzc2Vzc21lbnQgdGhhdCB0aGlzIGRvY3VtZW50J3Mg cmVxdWlyZW1lbnRzIGFyZSBvdmVyLWJyb2FkLCBhbmQgaW4gZmFjdCBzbyBicm9hZCBhcyB0byBo YXJtIGFkb3B0aW9uLiBUaGVyZSBtYXkgd2VsbCBiZSBvcGVyYXRvcnMgb3IgZGV2aWNlIGltcGxl bWVudGVycyB0aGF0IHNlZWluZw0KIHdpdGggc3VjaCBhIGhpZ2ggbnVtYmVyIG9mIHJlcXVpcmVt ZW50cyBtYXkgc2h5IGF3YXkgaW4gdGVycm9yIGFuZCB0aGluayB0aGF0IGRlcGxveWluZyBJUHY2 IGluIGEgbW9iaWxlIG5ldHdvcmsgaXMgYW4gaW1wb3NzaWJseSBoaWdoIGFtb3VudCBvZiB3b3Jr LiBUaGF0IHNhaWQsIGdpdmVuIHRoYXQgdGhpcyBkb2N1bWVudCBzYXlzIGNsZWFybHkgdGhhdCBp dCBpcyBub3QgYSBzdGFuZGFyZCwgYW5kIHRoYXQgY29tcGxpYW5jZSBpcyBub3QgcmVxdWlyZWQs DQogdGhlIGhhcm0gaXQgZG9lcyB3aWxsIGJlIGxpbWl0ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIG1heSB3ZWxsIGJlIG9wZXJhdG9ycyBhbmQgZGV2aWNlIGlt cGxlbWVudGVycyB0aGF0IHNlZSB0aGUgbWFueSBpbmRpdmlkdWFsIOKAnElQdjbigJ0gUkZDcyBh bmQgc2h5IGF3YXkuIFRyYW5zaXRpb25pbmcgdGVjaG5vbG9naWVzIGFyZSBzdGlsbA0KIHBlcmNl aXZlZCBhcyBpc3N1ZXMgZm9yIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhpcyBjcm9zcy1vcGVyYXRvciBkb2N1bWVudCBzdGF0ZXMg d2hhdCBpcyByZXF1aXJlZCBvbiB0ZXJtaW5hbHMgdG8gd29yayBpbiBhbGwgbWFqb3IvcHJlZGlj dGFibGUgSVB2NiBzY2VuYXJpb3MsIHRoZW4gaXQgaXMgZ2l2aW5nIHN1Y2ggcGVvcGxlDQogYSB2 aWV3IG9mIHdoYXQgYSDigJxoZWFsdGh5IGFuZCByb2J1c3TigJ0gdGVybWluYWwgaW1wbGVtZW50 YXRpb24gd291bGQgY29uc2lzdCBvZi4gSWYgdGhleSBhcmUgYWJsZSB0byBkZWxpdmVyIG9uIHRo ZXNlIHJlcXVpcmVtZW50cyB0aGVuIHRoZXkgY2FuIHN1cHBseSBhIHRlcm1pbmFsIHJlYWR5IGZv ciBhbGwgYnVzaW5lc3MgYXJlYXMgL2FsbCBvcGVyYXRvciBuZXR3b3JrIHNjZW5hcmlvcy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEl0IGNlcnRhaW5seSBz dG9wcyB0aGUgZmVlZGJhY2sgSeKAmXZlIGhhZCBmcm9tIGNlcnRhaW4gY29ybmVycyDigJx0aGF0 IG5vIG90aGVyIG9wZXJhdG9ycyBhcmUgYXNraW5nIGZvciBJUHY24oCdLCBhbmQg4oCcd2hhdCB5 b3UgYXJlIGFza2luZyBmb3IgaXMgYQ0KIHNpbmdsZSBvcGVyYXRvciByb2FkbWFwIHdoaWNoIHdl IHdvbuKAmXQgZG/igJ0uIFRoYXQgaGFzIGJlZW4gdGhlIHJlYWxpdHkgaGVyZSkuIFNvIEkgZG9u 4oCZdCBzZWUgaG93IGEgY29uc29saWRhdGVkIGRlbWFuZC1zaWRlIHZpZXcgZnJvbSBvcGVyYXRv cnMgd2hvIGFyZSByZWFsbHkgdHJ5aW5nIHRvIGludHJvZHVjZSBJUHY2ICZuYnNwO2luIG1vYmls ZSBjYW4gaGFybSBhZG9wdGlvbiBpbiBhbnkgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk5pY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHY2b3BzIFs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5M b3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gMDYgT2N0b2JlciAyMDE0IDA4OjMwPGJy Pg0KPGI+VG86PC9iPiBJRVRGIERpc2N1c3Npb248YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+IFdHOyBJRVRGLUFubm91bmNl PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll dGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTEzLnR4dCZndDsgKEFuIEludGVybmV0IFBy b3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNlcykg dG8gSW5mb3JtYXRpb25hbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5OT1RJQ0UgQU5EIERJU0NMQUlN RVI8YnI+DQpUaGlzIGUtbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5k ZWQgZm9yIHRoZSBhYm92ZS1uYW1lZCBwZXJzb24ocykuJm5ic3A7IElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxl dGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNl IGZvciBhbnkgcHVycG9zZS4mbmJzcDsNCjxicj4NCiZuYnNwOzxicj4NCldlIG1heSBtb25pdG9y IGFsbCBpbmNvbWluZyBhbmQgb3V0Z29pbmcgZW1haWxzIGluIGxpbmUgd2l0aCBjdXJyZW50IGxl Z2lzbGF0aW9uLiBXZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVuc3VyZSB0aGF0IHRoaXMgZW1haWwg YW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCBidXQgaXQgcmVtYWlucyB5 b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFkdmVyc2Vs eSBhZmZlY3QgeW91Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPkVFIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzPGJyPg0K Q29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogMDIzODIxNjE8YnI+DQpSZWdpc3RlcmVkIE9mZmlj ZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9y ZHNoaXJlLCBBTDEwIDlCVzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_A0BB7AD89EA705449C486BDB5FDCBC7B0EE7E836OPE10MB06tpgkco_-- From nobody Wed Oct 8 11:28:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61611ACE18 for ; Wed, 8 Oct 2014 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRewwKFqrzXA for ; Wed, 8 Oct 2014 11:28:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D094D1ACDE8 for ; Wed, 8 Oct 2014 11:28:40 -0700 (PDT) Received: from [2001:5c0:1000:a::69d] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XbvyW-0005D6-Bj; Wed, 08 Oct 2014 20:28:37 +0200 Message-ID: <54358246.4000201@gont.com.ar> Date: Wed, 08 Oct 2014 15:28:22 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Joe Touch , Tim Chown References: <542A36AC.9030203@gont.com.ar> <542C81B7.10601@isi.edu> <99A3738D-954C-4A75-8055-E30D0D73DD80@ecs.soton.ac.uk> <542C8595.6080809@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE1C0C7@ITSNT440.iowa.uiowa.edu> <542D695A.3070506@isi.edu> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DE22159@ITSNT440.iowa.uiowa.edu> <542EAFEF.30607@gont.com.ar> <542EF0BA.2070604@isi.edu> <08B266AA-2C78-4C21-BF76-F4B64C9B56CC@ecs.soton.ac.uk> <5432B4E1.1050908@isi.edu> In-Reply-To: <5432B4E1.1050908@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cCl2_ok1lM15ar9bTE71CLCgbtk Cc: IPv6 Operations , V6ops Chairs , "draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org" Subject: Re: [v6ops] IPv6 Extension Headers in the Real World X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 18:28:43 -0000 On 10/06/2014 12:27 PM, Joe Touch wrote: > > Although I appreciate that everyone thinks that "this can be > coordinated", we're seeing ample evidence to the contrary. It's useful > to note here that NEITHER DOC REFERENCES THE OTHER, despite being > written by the same author (which begs the question of "end run"). Joe, if you feel like making an ad-hominem accusation, at the very least state what the basis of your accusations are. This is not the first time you do it. Last recent one was based on seconding Fred Baker's claim that I had requested adoption of this document to two set of wg chairs -- which was simply *not true*. Making such assertions in public, based on your own personal assumption's (or someone else's) (and without apologizing in those cases where it is easy to prove that something wasn't true), does not seem like a good way forward or even fair. That said, there are different sets of authors in each doc that you mentioned. I happen to be a co-author of all such documents. But I'm not "the author". If you think that one document should reference another, but did not, maybe it was just an error? Maybe when writing the I-D, the other document had not yet been written? Maybe something else other than a conspiracy theory? If you infer some sort of Machiavellian plan regarding this document, I just say "there isn't any". If you wonder, this is how each I-D was born: the eh-filtering I-D is simply an IPv6 version of RFC7126. We got RFC7126 done, and the IPv6 part was missing. That's how this I-D was born. OTOH, draft-gont-v6ops-ipv6-ehs-in-real-world was born (later) when trying to codify and summarize what we had been discussing at the IEPG meetings (for more than a year now). > If this is left to the WGs, then the WGs need to decide if they can > manage each of these documents in the isolation the context that already > has been allowed to exist and is already promoted by the author - or if > that can *only* happen in a single doc. As noted quite a few times, there have been many cases where there's has been overlap among wg groups. For instance, anything that has to do with ipv6 opsec can fit either v6ops or opsec. I personally don't see that as a problem. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Oct 8 11:47:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70B1ACEA5 for ; Wed, 8 Oct 2014 11:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jSRNpHQXFG9 for ; Wed, 8 Oct 2014 11:47:46 -0700 (PDT) Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by ietfa.amsl.com (Postfix) with SMTP id 123EE1ACEA2 for ; Wed, 8 Oct 2014 11:47:44 -0700 (PDT) Received: (qmail 83770 messnum 13110404 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 8 Oct 2014 18:47:43 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mail02.svc.cra.dublin.eircom.net (qp 83770) with SMTP; 8 Oct 2014 18:47:43 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 0ine1p00e0mJ9Tz01inhm8; Wed, 08 Oct 2014 19:47:43 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2B8324A7-3369-440F-8CD8-43764537CCFE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ross Chandler In-Reply-To: Date: Wed, 8 Oct 2014 19:47:40 +0100 Message-Id: References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> To: Kossut Tomasz - Hurt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WqZiYRX0YSDx9_cKgGZPizidzUQ Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 18:47:49 -0000 --Apple-Mail=_2B8324A7-3369-440F-8CD8-43764537CCFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 8 Oct 2014, at 14:52, Kossut Tomasz - Hurt = wrote: > Hi, > Majority of modern smartphones from Sony, HTC, LG, Samsung, Nokia = WP8.1 are compliant with CLAT+NAT64/DNS/DNS64 > Together with Micha=C5=82 Czerwonka we created document with mandatory = IPv6 requirements, close cooperation with vendors succeeded and we = managed to launch first terminal (Xperia Z1) in September 2013, after 12 = months we have 13% of IPv6 only mobile users in a network. If you are = mobile operator and you thinking about IPv6 migration you won=E2=80=99t = have any problems with Smartphones (except Iphones=3DNO CLAT support) = the way is paved for you... > =20 > Network Configuration (CLAT+NAT64+DNS) > Internet access is done by establishing one dedicated IPv6-only = PDP/PDN context, network supports 464xlat architecture with DNS = Dual-Stack (DNS64 feature is available only for domain = =E2=80=9Cipv4only.arpa=E2=80=9D) - RFC 6877. CLAT implementation is = mandatory for all devices > =20 > UE, CPE vendor IPv6 mandatory requirements > 2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy = address) + UE shall use the IID given in PDP activation response = message to configure its LLA (3GPP TS = 23.060)http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/. >=20 > 2.2.Customer Side Translator function (CLAT) must be embedded = (smartphone/tablet/router) as part of 464xlat architecture RFC 6877. = The CLAT must support ICMP, UDP, TCP, GRE and fragmented packet. = clatd.conf - may be generic where the domain for nat64 prefix discovery = must be =E2=80=9Cipv4only.arpa=E2=80=9D =E2=80=93 static configuration = may be required. >=20 > https://android.googlesource.com/platform/external/android-clat/ > 2.3.MTU size & device interfaces - If the network send MTU size in RA = message, then device must set it to the radio interface otherwise set = the default value=3D1500B. The CLAT demon will calculate MTU size = automatically for its interfaces (clat and clat4). >=20 > IPv6 tethering - the CLAT helps Dual Stack tethering solution both = USB/WIFI on the device , when APN is IPv6-only. The Global IPv6 and = private IPv4 (clat) must be enabled on tethered LAN. > http://tools.ietf.org/html/rfc7278 (scenario 2) > 3.1.RA =E2=80=93 device sends RA message to tethered host with Ipv6 = prefix information. Router lifetime set=3D9000 secs. Router sends = periodically RA message =E2=80=93 max. value 9000 secs. >=20 > 3.2.DHCPv6 =E2=80=93 device server relays PCO Ipv6 DNS'es addresses to = tethered hosts. >=20 > 3.3.DHCPv4 =E2=80=93 device server relays private IPv4 address and = send DNS IPv4 (CLAT DNS-proxy) >=20 > 3.4.Tethering & MTU size =E2=80=93 device propagates MTU size 1500B to = tethered clients interfaces ( Ipv4&Ipv6) >=20 > IPv6 LTE UE - the device must set EIT bit=3D1 in =E2=80=9CInitial = Attach=E2=80=9D message. > Roaming - when APN with IPv6 protocol fails in roaming it must = automatically revert back APN protocol to IPv4 Hi Tomasz, Nice post. Regarding the EIT bit=3D1, are all the above vendors setting that or any = not setting it? I haven=E2=80=99t had to explicitly request that in any = of the smartphone UEs I=E2=80=99ve tested. It just worked.=20 Is the automatic fallback, when roaming, from APN protocol IPv6 to APN = protocol IPv4 when there=E2=80=99s a problem with IPv6 something you = _already_ have with your UEs or a desired behaviour?=20 I don=E2=80=99t see fallback to IPv4 when the network or HLR/HSS denies = IPv6. The RIL only fallbacks from IPv4v6 to IPv4, or parallel IPv4 and = IPv6.=20 BR Ross > One thing is still missing =E2=80=93 different APN profiles(APN = name+PDP type) for roaming =E2=80=93, there are two use cases: > Euinterent =E2=80=93 (=E2=80=9CEU Roaming Regulation III=E2=80=9D) = Internet APN available in UE countries (VPLMN subscriber is allowed to = use VGGSN APN) > =E2=80=9CRoaming Fallback to IPv4=E2=80=9D creating separate roaming = profile with APN name/PDP (now roaming fallback is based only on PDP = type Android4.x/WP8.1) > =20 > Here are the benefits of extending APN profiles: > =20 > - APN profiles and its =E2=80=9Czones=E2=80=9D HPLMN/VPLMN can = separate IPv6 form IPv4 > - Separate APN for HPLMN (Ipv6 only APN for HPLMN) > - Separate APN for VPLMN roaming (fallback to IPv4 based on APN = name) > - Euinternet APN as secondary roaming profile for manual = selection > =20 > Best Regards, > Tomasz Kossut > =20 > =20 > From: Heatley, Nick [mailto:nick.heatley@ee.co.uk]=20 > Sent: Tuesday, October 07, 2014 11:31 AM > To: Lorenzo Colitti; IETF Discussion > Cc: v6ops@ietf.org WG; IETF-Announce > Subject: Re: [v6ops] Last Call: = (An Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > 2. I stand by my earlier assessment that this document's requirements = are over-broad, and in fact so broad as to harm adoption. There may well = be operators or device implementers that seeing with such a high number = of requirements may shy away in terror and think that deploying IPv6 in = a mobile network is an impossibly high amount of work. That said, given = that this document says clearly that it is not a standard, and that = compliance is not required, the harm it does will be limited. > =20 > There may well be operators and device implementers that see the many = individual =E2=80=9CIPv6=E2=80=9D RFCs and shy away. Transitioning = technologies are still perceived as issues for the network. > If this cross-operator document states what is required on terminals = to work in all major/predictable IPv6 scenarios, then it is giving such = people a view of what a =E2=80=9Chealthy and robust=E2=80=9D terminal = implementation would consist of. If they are able to deliver on these = requirements then they can supply a terminal ready for all business = areas /all operator network scenarios. > (It certainly stops the feedback I=E2=80=99ve had from certain corners = =E2=80=9Cthat no other operators are asking for IPv6=E2=80=9D, and = =E2=80=9Cwhat you are asking for is a single operator roadmap which we = won=E2=80=99t do=E2=80=9D. That has been the reality here). So I don=E2=80= =99t see how a consolidated demand-side view from operators who are = really trying to introduce IPv6 in mobile can harm adoption in any way. > Regards, > Nick > =20 > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti > Sent: 06 October 2014 08:30 > To: IETF Discussion > Cc: v6ops@ietf.org WG; IETF-Announce > Subject: Re: [v6ops] Last Call: = (An Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > =20 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the = above-named person(s). If you are not the intended recipient, notify = the sender immediately, delete this email from your system and do not = disclose or use for any purpose. =20 > =20 > We may monitor all incoming and outgoing emails in line with current = legislation. We have taken steps to ensure that this email and = attachments are free from any virus, but it remains your responsibility = to ensure that viruses do not adversely affect you. >=20 > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_2B8324A7-3369-440F-8CD8-43764537CCFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 8 Oct 2014, at 14:52, = Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com> = wrote:

Hi,
Majority of modern smartphones = from Sony, HTC, LG, Samsung, Nokia WP8.1 are compliant with = CLAT+NAT64/DNS/DNS64
Together with Micha=C5=82 = Czerwonka we created document with mandatory IPv6 requirements, close = cooperation with vendors succeeded and we managed to launch first = terminal (Xperia Z1) in September 2013, after 12 months we have 13% of = IPv6 only mobile users in a network. If you are mobile operator and you = thinking about IPv6 migration you won=E2=80=99t have any problems with = Smartphones (except Iphones=3DNO CLAT support) the way is paved for = you...
 
  1. Network Configuration (CLAT+NAT64+DNS)
Internet = access is done by establishing one dedicated IPv6-only PDP/PDN context, = network supports 464xlat architecture with DNS Dual-Stack (DNS64 feature = is available only for domain =E2=80=9Cipv4only.arpa=E2=80=9D) - RFC = 6877. CLAT implementation is mandatory for all = devices
 
  1. UE, CPE vendor IPv6 mandatory = requirements

2.1.Dynamic IPv6 Address Allocation + IID randomly = generated (privacy = address) +  UE shall use the IID given in PDP activation response = message to configure its LLA (3GPP TS  23.060)http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/.

2.2.Customer Side = Translator function (CLAT) must be embedded = (smartphone/tablet/router) as part of 464xlat architecture  RFC = 6877. The CLAT must support ICMP, UDP, TCP, GRE and fragmented = packet. clatd.conf  - = may be generic where the domain for nat64 prefix discovery must be = =E2=80=9Cipv4only.arpa=E2=80=9D =E2=80=93  static = configuration may be required.

2.3.MTU size = & device interfaces - If the network send MTU = size in RA message, then device must set it to the radio interface = otherwise set the default value=3D1500B. The CLAT demon will calculate = MTU size automatically for its interfaces (clat = and clat4).

  1. IPv6 tethering - the CLAT helps Dual Stack = tethering solution both USB/WIFI on the device , when APN is IPv6-only. = The Global IPv6 and private IPv4 (clat) must be enabled on tethered = LAN.

3.1.RA =E2=80=93 device sends RA message = to tethered host with Ipv6 prefix information. Router lifetime set=3D9000 = secs. Router sends periodically RA message =E2=80=93 max. value 9000 = secs.

3.2.DHCPv6 =E2=80=93 device server = relays PCO Ipv6 DNS'es addresses to tethered hosts.

3.3.DHCPv4 =E2=80=93 device server = relays  private IPv4 address and send DNS IPv4 (CLAT = DNS-proxy)

3.4.Tethering = & MTU size =E2=80= =93 device propagates MTU size 1500B to tethered clients interfaces ( = Ipv4&Ipv6)

  1. IPv6 LTE UE  - the device = must set EIT bit=3D1 = in =E2=80=9CInitial Attach=E2=80=9D message.
Roaming - when APN with IPv6 = protocol fails in roaming it must automatically revert back APN protocol = to IPv4

Hi = Tomasz,

Nice = post.

Regarding the EIT bit=3D1, are all the = above vendors setting that or any not setting it? I haven=E2=80=99t had = to explicitly request that in any of the smartphone UEs I=E2=80=99ve = tested. It just worked. 

Is the automatic = fallback, when roaming, from APN protocol IPv6 to APN protocol IPv4 when = there=E2=80=99s a problem with IPv6 something you _already_ have with = your UEs or a desired behaviour? 
I don=E2=80=99t see = fallback to IPv4 when the network or HLR/HSS denies IPv6. The RIL only = fallbacks from IPv4v6 to IPv4, or parallel IPv4 and = IPv6. 

BR
Ross

One thing is still = missing =E2=80=93 different APN = profiles(APN name+PDP type) for roaming =E2=80=93, there are two use = cases:
Euinterent =E2=80=93 (=E2=80=9CE= U Roaming Regulation III=E2=80=9D) Internet APN available in UE = countries (VPLMN subscriber is allowed to use VGGSN = APN)
=E2=80=9CRoaming Fallback to IPv4=E2=80=9D creating separate = roaming profile with APN name/PDP (now roaming fallback is based only on = PDP type Android4.x/WP8.1)
 
Here are the benefits of extending APN = profiles:
 
-       APN profiles and its =E2=80=9Czones=E2=80=9D = HPLMN/VPLMN can separate IPv6 form IPv4
-       Separate APN for HPLMN (Ipv6 only APN for = HPLMN)
-       Separate  APN for VPLMN roaming (fallback to = IPv4 based on APN name)
-       Euinternet APN as secondary roaming profile for = manual selection
 
Best = Regards,
Tomasz Kossut
 
 
From: Heatley, Nick [mailto:nick.heatley@ee.co.uk] 
Sent: Tuesday, October 07, 2014 = 11:31 AM
To: Lorenzo Colitti; IETF = Discussion
Cc: v6ops@ietf.org WG; = IETF-Announce
Subject: Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet = Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to = Informational RFC
 
2. I stand by my earlier assessment that this document's = requirements are over-broad, and in fact so broad as to harm adoption. = There may well be operators or device implementers that seeing with such = a high number of requirements may shy away in terror and think that = deploying IPv6 in a mobile network is an impossibly high amount of work. = That said, given that this document says clearly that it is not a = standard, and that compliance is not required, the harm it does will be = limited.
 
There may = well be operators and device implementers that see the many individual = =E2=80=9CIPv6=E2=80=9D RFCs and shy away. Transitioning technologies are = still perceived as issues for the network.
If this = cross-operator document states what is required on terminals to work in = all major/predictable IPv6 scenarios, then it is giving such people a = view of what a =E2=80=9Chealthy and robust=E2=80=9D terminal = implementation would consist of. If they are able to deliver on these = requirements then they can supply a terminal ready for all business = areas /all operator network scenarios.
(It = certainly stops the feedback I=E2=80=99ve had from certain corners = =E2=80=9Cthat no other operators are asking for IPv6=E2=80=9D, and = =E2=80=9Cwhat you are asking for is a single operator roadmap which we = won=E2=80=99t do=E2=80=9D. That has been the reality here). So I don=E2=80= =99t see how a consolidated demand-side view from operators who are = really trying to introduce IPv6  in mobile can harm adoption in any = way.
Regards,
Nick
 
 
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti
Sent: 06 October 2014 = 08:30
To: IETF= Discussion
Cc: v6ops@ietf.org WG; = IETF-Announce
Subject: Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet = Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to = Informational RFC
 
 

NOTICE AND DISCLAIMER
This e-mail = (including any attachments) is intended for the above-named = person(s).  If you are not the intended recipient, notify the = sender immediately, delete this email from your system and do not = disclose or use for any purpose.  
 
We may = monitor all incoming and outgoing emails in line with current = legislation. We have taken steps to ensure that this email and = attachments are free from any virus, but it remains your responsibility = to ensure that viruses do not adversely affect = you.

EE Limited
Registered in England and Wales
Company = Registered Number: 02382161
Registered Office Address: Trident Place, = Mosquito Way, Hatfield, Hertfordshire, AL10 = 9BW

___________________________________________= ____
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_2B8324A7-3369-440F-8CD8-43764537CCFE-- From nobody Wed Oct 8 13:44:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4688D1A01EF; Wed, 8 Oct 2014 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rv7t9XbhrXN; Wed, 8 Oct 2014 13:44:19 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EFE1A02FE; Wed, 8 Oct 2014 13:44:18 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so9306929lam.4 for ; Wed, 08 Oct 2014 13:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EPfxswTH9xAH3A/0bE0D28XHzzoUt3EFoso9oycOvHw=; b=WpUAChHKUMIVWX9OD/Q0H2tTAyeVlLjATCyaLy0DjTIJiXg0Xo92w+qCJvdYL6NRYb 8a4ZY/Rv0fdbpcODzuT0KhslhXrOBPtxpcvGaeag56Syul2fwaH1PuY8Oo0M2nVMIbGZ vuEqL6ZgoL31iJD4dvGBoy6ezyjg6MYKcqVzaKk+eSgDzGyhTe6ogg/LX15zfzXGNnI4 cjqYIn/H3i27x5SteMYOP7LztNn5r0NLbZMfIsej/RNZ+MjxaxHR/RJ58Dq2YZtOSZGD 6Dt1GFvhobBvDoaWy9LEFFcWplCW/ZE+6A1ybbotIkBQTX31UQjj8Foacn15+7nypT29 LlMg== X-Received: by 10.152.45.7 with SMTP id i7mr14208646lam.74.1412801057145; Wed, 08 Oct 2014 13:44:17 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:5d31:c20a:b688:8eaf? ([2001:1bc8:101:f101:5d31:c20a:b688:8eaf]) by mx.google.com with ESMTPSA id xe10sm350424lbb.37.2014.10.08.13.44.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 13:44:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Jouni In-Reply-To: Date: Wed, 8 Oct 2014 23:44:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1F26FEA5-D8D0-41B0-AC39-7EB9F5241FFD@gmail.com> References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> <6536E263028723489CCD5B6821D4B21303BDD125@UK30S005EXS06.EEAD.EEINT.CO.UK> To: Kossut Tomasz - Hurt X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8a1rGPC73jWZ-xln4HBSwzGzh_c Cc: "v6ops@ietf.org WG" , IETF Discussion , IETF-Announce Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 20:44:22 -0000 Hi Kossut, Few questions just for my clarification.. See inline.. On Oct 8, 2014, at 4:52 PM, Kossut Tomasz - Hurt wrote: > Hi, > Majority of modern smartphones from Sony, HTC, LG, Samsung, Nokia = WP8.1 are compliant with CLAT+NAT64/DNS/DNS64 > Together with Micha=C5=82 Czerwonka we created document with mandatory = IPv6 requirements, close cooperation with vendors succeeded and we = managed to launch first terminal (Xperia Z1) in September 2013, after 12 = months we have 13% of IPv6 only mobile users in a network. If you are = mobile operator and you thinking about IPv6 migration you won=E2=80=99t = have any problems with Smartphones (except Iphones=3DNO CLAT support) = the way is paved for you... > =20 > =E2=80=A2 Network Configuration (CLAT+NAT64+DNS) > Internet access is done by establishing one dedicated IPv6-only = PDP/PDN context, network supports 464xlat architecture with DNS = Dual-Stack (DNS64 feature is available only for domain = =E2=80=9Cipv4only.arpa=E2=80=9D) - RFC 6877. CLAT implementation is = mandatory for all devices > =20 > =E2=80=A2 UE, CPE vendor IPv6 mandatory requirements > 2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy = address) + UE shall use the IID given in PDP activation response = message to configure its LLA (3GPP TS 23.060) = http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/. >=20 > 2.2.Customer Side Translator function (CLAT) must be embedded = (smartphone/tablet/router) as part of 464xlat architecture RFC 6877. = The CLAT must support ICMP, UDP, TCP, GRE and fragmented packet. = clatd.conf - may be generic where the domain for nat64 prefix discovery = must be =E2=80=9Cipv4only.arpa=E2=80=9D =E2=80=93 static configuration = may be required. >=20 > https://android.googlesource.com/platform/external/android-clat/ > 2.3.MTU size & device interfaces - If the network send MTU size in RA = message, then device must set it to the radio interface otherwise set = the default value=3D1500B. The CLAT demon will calculate MTU size = automatically for its interfaces (clat and clat4). Why aren't you using (in an UE case) the "safe" default MTU sizes = defined in TS23.060 when there is no MTU sent in an RA? > =E2=80=A2 IPv6 tethering - the CLAT helps Dual Stack tethering = solution both USB/WIFI on the device , when APN is IPv6-only. The Global = IPv6 and private IPv4 (clat) must be enabled on tethered LAN. > http://tools.ietf.org/html/rfc7278 (scenario 2) > 3.1.RA =E2=80=93 device sends RA message to tethered host with Ipv6 = prefix information. Router lifetime set=3D9000 secs. Router sends = periodically RA message =E2=80=93 max. value 9000 secs. >=20 > 3.2.DHCPv6 =E2=80=93 device server relays PCO Ipv6 DNS'es addresses to = tethered hosts. >=20 > 3.3.DHCPv4 =E2=80=93 device server relays private IPv4 address and = send DNS IPv4 (CLAT DNS-proxy) >=20 > 3.4.Tethering & MTU size =E2=80=93 device propagates MTU size 1500B to = tethered clients interfaces ( Ipv4&Ipv6) >=20 > =E2=80=A2 IPv6 LTE UE - the device must set EIT bit=3D1 in = =E2=80=9CInitial Attach=E2=80=9D message. You mean PDN Connectivity Request message, right? Anyway, what does EIT setting have to do with IPv6? Just curious.. - Jouni > Roaming - when APN with IPv6 protocol fails in roaming it must = automatically revert back APN protocol to IPv4 > =20 > One thing is still missing =E2=80=93 different APN profiles(APN = name+PDP type) for roaming =E2=80=93, there are two use cases: > Euinterent =E2=80=93 (=E2=80=9CEU Roaming Regulation III=E2=80=9D) = Internet APN available in UE countries (VPLMN subscriber is allowed to = use VGGSN APN) > =E2=80=9CRoaming Fallback to IPv4=E2=80=9D creating separate roaming = profile with APN name/PDP (now roaming fallback is based only on PDP = type Android4.x/WP8.1) > =20 > Here are the benefits of extending APN profiles: > =20 > - APN profiles and its =E2=80=9Czones=E2=80=9D HPLMN/VPLMN can = separate IPv6 form IPv4 > - Separate APN for HPLMN (Ipv6 only APN for HPLMN) > - Separate APN for VPLMN roaming (fallback to IPv4 based on APN = name) > - Euinternet APN as secondary roaming profile for manual = selection > =20 > Best Regards, > Tomasz Kossut > =20 > =20 > From: Heatley, Nick [mailto:nick.heatley@ee.co.uk]=20 > Sent: Tuesday, October 07, 2014 11:31 AM > To: Lorenzo Colitti; IETF Discussion > Cc: v6ops@ietf.org WG; IETF-Announce > Subject: Re: [v6ops] Last Call: = (An Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > 2. I stand by my earlier assessment that this document's requirements = are over-broad, and in fact so broad as to harm adoption. There may well = be operators or device implementers that seeing with such a high number = of requirements may shy away in terror and think that deploying IPv6 in = a mobile network is an impossibly high amount of work. That said, given = that this document says clearly that it is not a standard, and that = compliance is not required, the harm it does will be limited. > =20 > There may well be operators and device implementers that see the many = individual =E2=80=9CIPv6=E2=80=9D RFCs and shy away. Transitioning = technologies are still perceived as issues for the network. > If this cross-operator document states what is required on terminals = to work in all major/predictable IPv6 scenarios, then it is giving such = people a view of what a =E2=80=9Chealthy and robust=E2=80=9D terminal = implementation would consist of. If they are able to deliver on these = requirements then they can supply a terminal ready for all business = areas /all operator network scenarios. > (It certainly stops the feedback I=E2=80=99ve had from certain corners = =E2=80=9Cthat no other operators are asking for IPv6=E2=80=9D, and = =E2=80=9Cwhat you are asking for is a single operator roadmap which we = won=E2=80=99t do=E2=80=9D. That has been the reality here). So I don=E2=80= =99t see how a consolidated demand-side view from operators who are = really trying to introduce IPv6 in mobile can harm adoption in any way. > Regards, > Nick > =20 > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo = Colitti > Sent: 06 October 2014 08:30 > To: IETF Discussion > Cc: v6ops@ietf.org WG; IETF-Announce > Subject: Re: [v6ops] Last Call: = (An Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > =20 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the = above-named person(s). If you are not the intended recipient, notify = the sender immediately, delete this email from your system and do not = disclose or use for any purpose. =20 > =20 > We may monitor all incoming and outgoing emails in line with current = legislation. We have taken steps to ensure that this email and = attachments are free from any virus, but it remains your responsibility = to ensure that viruses do not adversely affect you. >=20 > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, = Hertfordshire, AL10 9BW >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 9 01:04:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADD41ABD35 for ; Thu, 9 Oct 2014 01:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gNVe61xwOu9 for ; Thu, 9 Oct 2014 01:04:30 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:2::28]) by ietfa.amsl.com (Postfix) with ESMTP id BF9C81ABC75 for ; Thu, 9 Oct 2014 01:04:29 -0700 (PDT) Received: from [IPv6:2403:2000:1:3:5b1:f15e:63cc:1da4] (unknown [IPv6:2403:2000:1:3:5b1:f15e:63cc:1da4]) by inc.inetcore.com (Postfix) with ESMTPSA id 4BA182E3B94; Thu, 9 Oct 2014 17:04:28 +0900 (JST) Message-ID: <54364189.5080905@inetcore.com> Date: Thu, 09 Oct 2014 17:04:25 +0900 From: Ruri Hiromi Organization: INTEC Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29.1 MIME-Version: 1.0 To: "Fred Baker (fred)" , lee@asgard.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ckEb2jjqoL18KkQKaFcWC5-8AE8 Cc: IPv6 Operations Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 08:04:32 -0000 Dear chairs, Hi, I submitted "draft-jpcert-ipv6vullnerability-check-00" today. If v6ops gives a 3 to 5 minutes for me, I would like to talk about this. http://datatracker.ietf.org/doc/draft-jpcert-ipv6vullnerability-check/ Regards, P.S. I am still working on this.... until the deadline comes... On 2014/10/07 9:09, Fred Baker (fred) wrote: > As I mentioned last week, Lee and I are pulling together an agenda for IETF 91. The drop-dead date for new or updated drafts is 27 October, and frankly it will work better if drafts arrive earlier - as we are looking for working group commentary on them. > > Current state of play: > > IESG: > Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 > Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis > > IETF Last Call: > Sep 26 draft-ietf-v6ops-mobile-device-profile > > Working Group Document updated since IETF: > Sep 18 draft-ietf-v6ops-design-choices > > Individual Submission updated since IETF: > Aug 24 draft-v6ops-pmtud-ecmp-problem > On list, Ray Hunter suggests someone write "a draft summarizing the ICMP PTB problem" > Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world > There has been some discussion on-list. > Sep 15 draft-anderson-v6ops-siit-dc-2xlat > No list commentary > Sep 18 draft-elkins-v6ops-multicast-virtual-nodes > Some commentary, not supportive > Sep 18 draft-wang-v6ops-xlat-prefix-discovery > A fair amount of discussion, mostly anti-NAT. > Sep 25 draft-ybai-v6ops-ipv6-for-openstack > no list commentary > Oct 5 draft-anderson-v6ops-siit-dc > Some list commentary > > Working Group Document NOT updated since IETF: > Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem > Jul 4 draft-ietf-v6ops-ula-usage-recommendations > > Individual Submission NOT updated since IETF: > Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node > Jul 3 draft-liu-v6ops-running-multiple-prefixes > Jul 4 draft-sun-v6ops-xlat-multi > Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x > Jul 20 draft-wang-v6ops-flow-label-refelction > Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance > > more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- --------------- Ruri Hiromi INTEC Inc. From nobody Thu Oct 9 04:48:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18C1ACDB3 for ; Thu, 9 Oct 2014 04:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3SW4GHweeOe for ; Thu, 9 Oct 2014 04:48:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900EC1ACDE9 for ; Thu, 9 Oct 2014 04:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3561; q=dns/txt; s=iport; t=1412855323; x=1414064923; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EG46Ta8l60EiqGlgZRGhosnwz05euivxFDNsRC8p+wE=; b=Y+MBQdHAvQWqDmTxO+4xhD+0qk/TqkGnleuW8pW+7JycE1Fblis6LV/o /1EvJ3yIvR1b/9HS1PgfmqN6ZSEVzdaZTXjG5f0Pcw4MYO/3z1CQStxTw jMlF50gqyOhCx69hkqXISzahwqvjopCZCwdvr9rzUhYvMfSGU8JYJDvOj w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFANN0NlStJA2G/2dsb2JhbABfgw5TWASDAsgKDIdLAoEJFgF7hAMBAQEDAQEBAR4BTAsFCwIBCBgpAwInCyUCBA4FDogoCA2UHZxIAZRVAReQRAeCdDmBHgWGLYtMggyBT2eHEIFqlCeDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="asc'?scan'208";a="85405728" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 09 Oct 2014 11:48:42 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s99Bmg0j010181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 11:48:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 06:48:42 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: [v6ops] Preparing IETF 91 agenda Thread-Index: AQHP47b4rWr63+YQEk+vrd0E4JUuYA== Date: Thu, 9 Oct 2014 11:48:41 +0000 Message-ID: References: <54364189.5080905@inetcore.com> In-Reply-To: <54364189.5080905@inetcore.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_21A3EDE8-EBE5-4669-A31B-D009ECEC69F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sC7H8qcULBlYluSrbcHRRjrjhcw Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 11:48:45 -0000 --Apple-Mail=_21A3EDE8-EBE5-4669-A31B-D009ECEC69F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp I would be interested in working group opinions on this note. Is it = useful to the operators? On Oct 9, 2014, at 1:04 AM, Ruri Hiromi wrote: > Dear chairs, >=20 > Hi, > I submitted "draft-jpcert-ipv6vullnerability-check-00" today. > If v6ops gives a 3 to 5 minutes for me, I would like to talk about = this. >=20 > http://datatracker.ietf.org/doc/draft-jpcert-ipv6vullnerability-check/ >=20 > Regards, >=20 > P.S. I am still working on this.... until the deadline comes... >=20 > On 2014/10/07 9:09, Fred Baker (fred) wrote: >> As I mentioned last week, Lee and I are pulling together an agenda = for IETF 91. The drop-dead date for new or updated drafts is 27 October, = and frankly it will work better if drafts arrive earlier - as we are = looking for working group commentary on them. >>=20 >> Current state of play: >>=20 >> IESG: >> Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 >> Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis >>=20 >> IETF Last Call: >> Sep 26 draft-ietf-v6ops-mobile-device-profile >>=20 >> Working Group Document updated since IETF: >> Sep 18 draft-ietf-v6ops-design-choices >>=20 >> Individual Submission updated since IETF: >> Aug 24 draft-v6ops-pmtud-ecmp-problem >> On list, Ray Hunter suggests someone write "a draft = summarizing the ICMP PTB problem" >> Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world >> There has been some discussion on-list.=20 >> Sep 15 draft-anderson-v6ops-siit-dc-2xlat >> No list commentary >> Sep 18 draft-elkins-v6ops-multicast-virtual-nodes >> Some commentary, not supportive >> Sep 18 draft-wang-v6ops-xlat-prefix-discovery >> A fair amount of discussion, mostly anti-NAT. >> Sep 25 draft-ybai-v6ops-ipv6-for-openstack >> no list commentary >> Oct 5 draft-anderson-v6ops-siit-dc >> Some list commentary >>=20 >> Working Group Document NOT updated since IETF: >> Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem >> Jul 4 draft-ietf-v6ops-ula-usage-recommendations >>=20 >> Individual Submission NOT updated since IETF: >> Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >> Jul 3 draft-liu-v6ops-running-multiple-prefixes >> Jul 4 draft-sun-v6ops-xlat-multi >> Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x >> Jul 20 draft-wang-v6ops-flow-label-refelction >> Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance >>=20 >> more data at = http://datatracker.ietf.org/doc/search/?sort=3Dstatus&activedrafts=3Don&na= me=3Dv6ops >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > --=20 > --------------- > Ruri Hiromi > INTEC Inc. --Apple-Mail=_21A3EDE8-EBE5-4669-A31B-D009ECEC69F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUNnYXbjEdbHIsm0MRAhrXAJ434ZDumAv+hFmFSBAemNP50jVaQACgpqdm sRrHadR+HCznmSoUzbV97VY= =QRYB -----END PGP SIGNATURE----- --Apple-Mail=_21A3EDE8-EBE5-4669-A31B-D009ECEC69F3-- From nobody Thu Oct 9 05:00:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBDB1ACDF0 for ; Thu, 9 Oct 2014 05:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h8YlyGb4yNi for ; Thu, 9 Oct 2014 05:00:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00BB1ACDF1 for ; Thu, 9 Oct 2014 05:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2942; q=dns/txt; s=iport; t=1412856050; x=1414065650; h=from:to:subject:date:message-id:references:mime-version; bh=i/q24yV7CDvUSGFD1rI7dxFyLw8m7Ap96Ug6XNRKrJA=; b=CZhcZrtnTz11E5oGcHdN7CoXpA+MK90Fb5P8/3FDzoD3hfskpf2mo+JA vT9FKYsV1EVWaqhlXAad5BtewgHXx4Yx+KyKsFhRwK7t17oLIiuwG2AG5 5H1+DXz7P7VpUwtks0pMfMm59SxO7ei4wAZsQi6JpQZWyOzCfKaffAqQC Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAIt4NlStJA2D/2dsb2JhbABfgw5TWATLDAqHTYELFgF7hAMBAQEDAQEBAWsQCwIBGQMBAi8nCxQHAggCBBMJBYgoCA3FGQEXkDMTgjtTJIEeBZF5ggyBT2eHEIEuPIMKikyGUYNjbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="asc'?scan'208";a="358780809" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 09 Oct 2014 12:00:50 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s99C0nKH018541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Oct 2014 12:00:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 07:00:49 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: I-D Action: draft-jpcert-ipv6vullnerability-check-00.txt Thread-Index: AQHP45Ze67e89wN4c0ee51sxYZxYtw== Date: Thu, 9 Oct 2014 12:00:48 +0000 Message-ID: <52ED8309-7490-4AE1-8C9F-51B645254218@cisco.com> References: <20141009075455.32250.16196.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_3036E2D1-A419-49BD-921A-B45A08EABADE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wjxslR74JM0FIiZbaTpeKxbkaW4 Subject: [v6ops] Fwd: I-D Action: draft-jpcert-ipv6vullnerability-check-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 12:00:53 -0000 --Apple-Mail=_3036E2D1-A419-49BD-921A-B45A08EABADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Here is the formal announcement of JPCERT=92s draft. > From: > Subject: I-D Action: draft-jpcert-ipv6vullnerability-check-00.txt > Date: October 9, 2014 at 12:54:55 AM PDT > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Introducing IPv6 vulnerability test program = in Japan > Authors : Shikano Keisuke > Yoshiaki Kitaguchi > Kenichi Nagami > Masataka Kosugi > Ruri Hiromi > Filename : draft-jpcert-ipv6vullnerability-check-00.txt > Pages : 11 > Date : 2014-10-09 >=20 > Abstract: > Japan Computer Emergency Response Team Coordination Center, known > as JPCERT/CC have been researching about vulnerability in use of = IPv6 > and provided the information toward vendors in Japan. They also > verified to occur the security incident with several products. >=20 > In 2013, JPCERT/CC called for vendors to participate their IPv6 > security program. JPCERT/CC collects the results of equipments and > open to the public for an user reference of procurement. >=20 > In this document we describe about the program to share the > experimental activity. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-jpcert-ipv6vullnerability-check/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jpcert-ipv6vullnerability-check-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_3036E2D1-A419-49BD-921A-B45A08EABADE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUNnjvbjEdbHIsm0MRAsVMAJ92Ow3H/aENZB9r7o332J7lk9aL+gCgu6ZM JnmEdsMYm4HeSK6V00MjY2c= =C1xG -----END PGP SIGNATURE----- --Apple-Mail=_3036E2D1-A419-49BD-921A-B45A08EABADE-- From nobody Sat Oct 11 03:04:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6DE1A01FA for ; Sat, 11 Oct 2014 03:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXbRjgxnPyEN for ; Sat, 11 Oct 2014 03:04:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A201A01E1 for ; Sat, 11 Oct 2014 03:04:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK99508; Sat, 11 Oct 2014 10:04:14 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 11 Oct 2014 11:04:13 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 11 Oct 2014 18:04:06 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: Multiple IPv6 Prefixes Operational Considerations-//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-02.txt Thread-Index: AQHP5Tqxj8uTlwjbUEKBFAsb+32D7A== Date: Sat, 11 Oct 2014 10:04:05 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589D52CE@nkgeml506-mbx.china.huawei.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.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E_Np2NmveMsW9blAx1Bth27tIbo Subject: [v6ops] Multiple IPv6 Prefixes Operational Considerations-//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 10:04:17 -0000 SGksIGFsbA0KDQpXZSd2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCkFz IGRpc2N1c3NlZCBpbiBMb25kb24sIHdlIG1vZGlmaWVkIGl0IHRvIGEgc2V0IG9mIG9wZXJhdGlv bmFsIGd1aWRhbmNlIGluc3RlYWQgb2YgYSBzZXQgb2YgcHJvYmxlbSBzdGF0ZW1lbnRzLg0KDQpQ bGVhc2UgaGF2ZSBhIHJldmlldyBhbmQgY29tbWVudCB3aGV0aGVyIHlvdSB0aGluayBpdCBpcyBh IHVzZWZ1bCB3b3JrIGluIHRoaXMgd29ya2luZyBncm91cC4NCk1hbnkgdGhhbmtzIQ0KDQpCZXN0 IHJlZ2FyZHMsDQpCaW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogU2F0dXJkYXksIE9jdG9iZXIgMTEsIDIwMTQgNjowMSBQTQ0KVG86IEJveWFuZzsgU2hl bmcgSmlhbmc7IExpdWJpbmcgKExlbyk7IFNoZW5nIEppYW5nOyBCb3lhbmc7IExpdWJpbmcgKExl bykNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LXY2b3Bz LXJ1bm5pbmctbXVsdGlwbGUtcHJlZml4ZXMtMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWxpdS12Nm9wcy1ydW5uaW5nLW11bHRpcGxlLXByZWZpeGVzLTAyLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1saXUtdjZvcHMtcnVubmluZy1tdWx0 aXBsZS1wcmVmaXhlcw0KUmV2aXNpb246CTAyDQpUaXRsZToJCUNvbnNpZGVyYXRpb25zIGZvciBS dW5uaW5nIE11bHRpcGxlIElQdjYgUHJlZml4ZXMNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMTEN Ckdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEyDQpVUkw6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LXY2b3BzLXJ1 bm5pbmctbXVsdGlwbGUtcHJlZml4ZXMtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXY2b3BzLXJ1bm5pbmctbXVsdGlwbGUt cHJlZml4ZXMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbGl1LXY2b3BzLXJ1bm5pbmctbXVsdGlwbGUtcHJlZml4ZXMtMDINCkRpZmY6ICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saXUtdjZvcHMtcnVubmlu Zy1tdWx0aXBsZS1wcmVmaXhlcy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIHNldmVyYWwgdHlwaWNhbCBtdWx0aXBsZSBwcmVmaXhlcyB1c2UgY2FzZXMuDQogICBU aGVuIGFuYWx5emVzIHBvdGVudGlhbCBvcGVyYXRpb25hbCBpc3N1ZXMgYW5kIHByb3ZpZGVzIG9w ZXJhdGlvbmFsDQogICBjb25zaWRlcmF0aW9ucyBvZiBydW5uaW5nIG11bHRpcGxlIHByZWZpeGVz Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sun Oct 12 03:16:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654211A0149; Sun, 12 Oct 2014 03:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TufYTeLNmasE; Sun, 12 Oct 2014 03:16:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D56A01A8A4B; Sun, 12 Oct 2014 03:16:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141012101630.17092.28381.idtracker@ietfa.amsl.com> Date: Sun, 12 Oct 2014 03:16:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vgccmWtX-I58Wfoz07d5Q4YHxs8 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 10:16:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Roaming Behavior Analysis Authors : Gang Chen Hui Deng Dave Michaud Jouni Korhonen Mohamed Boucadair Vizdal Ales Filename : draft-ietf-v6ops-ipv6-roaming-analysis-06.txt Pages : 19 Date : 2014-10-12 Abstract: This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 12 21:48:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F6C1A0146; Thu, 9 Oct 2014 21:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_BASE64_TEXT=1.741, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz5R8YnnAzvh; Thu, 9 Oct 2014 21:59:20 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0351A0103; Thu, 9 Oct 2014 21:59:20 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so1015201pab.30 for ; Thu, 09 Oct 2014 21:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:mime-version:message-id :content-type:content-transfer-encoding; bh=TrjpQfp2up6VfYBCTzDScd3g7Gkzsv43hlZ0lHxNzvU=; b=PCQ2RaOL2j6lF+fSeoOPzaf7XahLiF2PCcFjkZCpN8W4ln08/FsTqSDL67YWipS/Yx icZGDZgtoFDufROIFCBiXIt08rShIEbXGhKXiTtwL32kq7hV+jWhLPXhxjkcXihC32hf UH7ZXgtAp8SKu2FHfMrny4XUBJMGRLKlUyDyvW2PJsGTPQtKKqQ8Gfzo4ulZd2eNRTKW aw2CmOmehVIU7kro861opDJU0Wuv1kM4gWm91LwGaz+tuMl7KsYdL/tGFgedFHJAI3r/ 8oJHRw1tY6PGXg6wUUXfpJYqRxqzpUBbUnlLAWFpfEjuFrFJsV99SIfsrc2cTxX3Ea/z g54g== X-Received: by 10.69.17.234 with SMTP id gh10mr2780718pbd.0.1412917160470; Thu, 09 Oct 2014 21:59:20 -0700 (PDT) Received: from netlab-PC ([166.111.68.231]) by mx.google.com with ESMTPSA id rj8sm2076070pdb.55.2014.10.09.21.59.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 Oct 2014 21:59:19 -0700 (PDT) Date: Fri, 10 Oct 2014 12:59:17 +0800 From: "Yuchi Chen" To: gvandeve X-Priority: 3 X-GUID: 5CDC0BB9-3AAF-4FB9-A566-40DFC379B51B X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201410101259128179113@gmail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/U_NzLhS0owk1Oymh4jJa1V8-RUI X-Mailman-Approved-At: Sun, 12 Oct 2014 21:48:21 -0700 Cc: v6ops , opsec Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chenycmx List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 04:59:22 -0000 SGkgYWxsLA0KIA0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBmb3IgdGhpcyBkcmFmdC4gSU1PLCB0 aGlzIHNlZW1zIGxpa2UgdGltZWx5IGFkdmljZSBjb25jZXJuaW5nIHRoZSByZWNlbnQgZGF0YSBv biBmaWx0ZXJpbmcgb2YgcGFja2V0cyB3aXRoIGV4dGVuc2lvbiBoZWFkZXJzLg0KDQpCZXN0IHJl Z2FyZHMhDQotLS0tLS0tLS0tLS0tLQ0KWXVjaGkgQ2hlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBPUFNFQyBbbWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHdW50ZXIgVmFuIGRlIFZlbGRlIChndmFuZGV2ZSkNClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAwOCwgMjAxNCA2OjIxIFBNDQpUbzogb3BzZWNAaWV0Zi5vcmcNCkNjOiB2Nm9w cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT1BTRUNdIENhbGwgZm9yIFdH IGFkb3B0aW9uIC0gUmVjb21tZW5kYXRpb25zIG9uIEZpbHRlcmluZyBvZiBJUHY2IFBhY2tldHMg Q29udGFpbmluZyBJUHY2IEV4dGVuc2lvbiBIZWFkZXJzDQogDQpEZWFyIGFsbCwNCiANCk1hbnkg dGhhbmtzIGZvciB5b3VyIGlucHV0IG9uIHRoaXMgcmVxdWVzdC4NCk9QU0VDIGNoYWlycyB3aWxs IGxvb2sgYXQgdGhlIHJlY2VpdmVkIGlucHV0IGFuZCBzZWUgdG9nZXRoZXIgd2l0aCB0aGUgdjZv cHMgY2hhaXJzIGhvdyB0aGUgSVB2NiBFSCB3b3JrIGNvdWxkIHByb2dyZXNzLg0KIA0KS2luZCBS ZWdhcmRzLA0KRy8NCiANCiANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHdW50 ZXIgVmFuIGRlIFZlbGRlIChndmFuZGV2ZSkgDQpTZW50OiAyNCBTZXB0ZW1iZXIgMjAxNCAxMToy OA0KVG86IG9wc2VjQGlldGYub3JnDQpTdWJqZWN0OiBDYWxsIGZvciBXRyBhZG9wdGlvbiAtIFJl Y29tbWVuZGF0aW9ucyBvbiBGaWx0ZXJpbmcgb2YgSVB2NiBQYWNrZXRzIENvbnRhaW5pbmcgSVB2 NiBFeHRlbnNpb24gSGVhZGVycw0KIA0KRGVhciwNCiANClBsZWFzZSBmaW5kIHRoaXMgcmVxdWVz dCBmb3IgV0cgYWRvcHRpb24gZm9yICJSZWNvbW1lbmRhdGlvbnMgb24gRmlsdGVyaW5nIG9mIElQ djYgUGFja2V0cyBDb250YWluaW5nIElQdjYgRXh0ZW5zaW9uIEhlYWRlcnMiDQpUaGUgYXV0aG9y cyBvZiB0aGUgd29yayBleHBsaWNpdGx5IGFza2VkIGZvciAiQ2FsbCBmb3IgV0cgYWRvcHRpb24i IGluIGl0cyBjdXJyZW50IHN0YXRlLiANCiANCkxhdGVzdCBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6 DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb250LW9wc2VjLWlwdjYtZWgtZmls dGVyaW5nLTAyIA0KIA0KKDEpIERvIHlvdSBzdXBwb3J0IGZvciBhZG9wdGluZyB0aGUgZHJhZnQg YXMgT1BTRUMgV0cgaXRlbT8NCiANClRoaXMgY2FsbCBmb3IgV0cgYWRvcHRpb24gd2lsbCBlbmQg OCBPY3RvYmVyIDIwMTQuDQogDQpLaW5kIFJlZ2FyZHMsDQpPUFNFQyBjaGFpcnMNCiANCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNFQyBtYWlsaW5n IGxpc3QNCk9QU0VDQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2VjDQo= From nobody Sun Oct 12 23:57:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A721A88A5; Sun, 12 Oct 2014 23:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKDlKDwsqVYI; Sun, 12 Oct 2014 23:57:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204081A88A4; Sun, 12 Oct 2014 23:57:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,708,1406592000"; d="scan'208";a="204593986" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Oct 2014 06:57:30 +0000 Received: from dhcp-10-61-101-249.cisco.com (dhcp-10-61-101-249.cisco.com [10.61.101.249]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9D6vSOh015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 06:57:30 GMT Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 In-Reply-To: <201410101259128179113@gmail.com> Date: Mon, 13 Oct 2014 08:57:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> References: <201410101259128179113@gmail.com> To: opsec , v6ops X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pus6dMo6aD-8y8cIc375zK7kypk Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 06:57:34 -0000 shouldn't this be a draft authored by operators? giving operational = recommendations coming out of... well, actual operations? cheers, Ole > On 10 Oct 2014, at 6:59 , Yuchi Chen wrote: >=20 > Hi all, >=20 > I support the adoption for this draft. IMO, this seems like timely = advice concerning the recent data on filtering of packets with extension = headers. >=20 > Best regards! > -------------- > Yuchi Chen >=20 >=20 > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de = Velde (gvandeve) > Sent: Wednesday, October 08, 2014 6:21 PM > To: opsec@ietf.org > Cc: v6ops-chairs@tools.ietf.org > Subject: Re: [OPSEC] Call for WG adoption - Recommendations on = Filtering of IPv6 Packets Containing IPv6 Extension Headers >=20 > Dear all, >=20 > Many thanks for your input on this request. > OPSEC chairs will look at the received input and see together with the = v6ops chairs how the IPv6 EH work could progress. >=20 > Kind Regards, > G/ >=20 >=20 > -----Original Message----- > From: Gunter Van de Velde (gvandeve)=20 > Sent: 24 September 2014 11:28 > To: opsec@ietf.org > Subject: Call for WG adoption - Recommendations on Filtering of IPv6 = Packets Containing IPv6 Extension Headers >=20 > Dear, >=20 > Please find this request for WG adoption for "Recommendations on = Filtering of IPv6 Packets Containing IPv6 Extension Headers" > The authors of the work explicitly asked for "Call for WG adoption" in = its current state.=20 >=20 > Latest draft can be found at: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02=20 >=20 > (1) Do you support for adopting the draft as OPSEC WG item? >=20 > This call for WG adoption will end 8 October 2014. >=20 > Kind Regards, > OPSEC chairs >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Oct 13 00:06:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3801A88B8 for ; Mon, 13 Oct 2014 00:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j4kPmAIqJXb for ; Mon, 13 Oct 2014 00:05:55 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8293F1A88BA for ; Mon, 13 Oct 2014 00:05:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 30421A2; Mon, 13 Oct 2014 09:05:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413183953; bh=WpboaLv73zkyJUQFJklmu8DoLEFAONyMvbTupzSniXU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=q4Neq81Yi6OzInYQNBs7wAVN49LCBy39zC2Zw2USBylglsfgHVUaR3nfXf/OBsXJX Im+cFxuA6Uxbw2SUGGnhuLpDLi2Ow6H7evZX1KT+8HNbCTmvIWrkW85VpzOEIX2W9d D5JXJ73MrXmwVyr+3H/S2yLgKdzttJHw6C1MB9Ik= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2BADBA1; Mon, 13 Oct 2014 09:05:53 +0200 (CEST) Date: Mon, 13 Oct 2014 09:05:53 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: Message-ID: References: <54364189.5080905@inetcore.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KOOpvh27amzeWfQ8wtC_I7Guurg Cc: IPv6 Operations Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 07:06:01 -0000 My opinion is that having test suites available as FOSS would be great. The tools look like they're of the kind already freely available, but actually setting up tests that operators and end users can run against their equipment is of great help. I encourage freely available tests of all kinds. The document lists tests performed but doesn't say if the tools will be available, so that's a question from me to the author. I would like to see protocol fuzzers etc also be available, if possible. We have way too few of these freely available. On Thu, 9 Oct 2014, Fred Baker (fred) wrote: > I would be interested in working group opinions on this note. Is it useful to the operators? > > On Oct 9, 2014, at 1:04 AM, Ruri Hiromi wrote: > >> Dear chairs, >> >> Hi, >> I submitted "draft-jpcert-ipv6vullnerability-check-00" today. >> If v6ops gives a 3 to 5 minutes for me, I would like to talk about this. >> >> http://datatracker.ietf.org/doc/draft-jpcert-ipv6vullnerability-check/ >> >> Regards, >> >> P.S. I am still working on this.... until the deadline comes... >> >> On 2014/10/07 9:09, Fred Baker (fred) wrote: >>> As I mentioned last week, Lee and I are pulling together an agenda for IETF 91. The drop-dead date for new or updated drafts is 27 October, and frankly it will work better if drafts arrive earlier - as we are looking for working group commentary on them. >>> >>> Current state of play: >>> >>> IESG: >>> Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 >>> Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis >>> >>> IETF Last Call: >>> Sep 26 draft-ietf-v6ops-mobile-device-profile >>> >>> Working Group Document updated since IETF: >>> Sep 18 draft-ietf-v6ops-design-choices >>> >>> Individual Submission updated since IETF: >>> Aug 24 draft-v6ops-pmtud-ecmp-problem >>> On list, Ray Hunter suggests someone write "a draft summarizing the ICMP PTB problem" >>> Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world >>> There has been some discussion on-list. >>> Sep 15 draft-anderson-v6ops-siit-dc-2xlat >>> No list commentary >>> Sep 18 draft-elkins-v6ops-multicast-virtual-nodes >>> Some commentary, not supportive >>> Sep 18 draft-wang-v6ops-xlat-prefix-discovery >>> A fair amount of discussion, mostly anti-NAT. >>> Sep 25 draft-ybai-v6ops-ipv6-for-openstack >>> no list commentary >>> Oct 5 draft-anderson-v6ops-siit-dc >>> Some list commentary >>> >>> Working Group Document NOT updated since IETF: >>> Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem >>> Jul 4 draft-ietf-v6ops-ula-usage-recommendations >>> >>> Individual Submission NOT updated since IETF: >>> Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >>> Jul 3 draft-liu-v6ops-running-multiple-prefixes >>> Jul 4 draft-sun-v6ops-xlat-multi >>> Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x >>> Jul 20 draft-wang-v6ops-flow-label-refelction >>> Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance >>> >>> more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> -- >> --------------- >> Ruri Hiromi >> INTEC Inc. > > -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 13 00:09:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07A1A88B8; Mon, 13 Oct 2014 00:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVPYXJOdvZkW; Mon, 13 Oct 2014 00:09:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C174E1A88B7; Mon, 13 Oct 2014 00:09:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5480FA2; Mon, 13 Oct 2014 09:09:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413184182; bh=Zi+2HUs7osJLXnyvwxcUB0fhNs/A0NdHtZDNT2y8G18=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QTQ8vLSOkxK7ZPCiSkmqpoxC0hOLGt31dYko7l1YpwRF7npkXaSdg5B5ZMGP84HFo dvLrepntDjGMtCnuAplWUHulYxfLe45PskhhgMQiZlNyJKnnLPJ7DXIA3NTkaKTNcw Jq6mTevTUvF089XqXIbpEK3XMXgIFtMKp4DFetVk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4A242A1; Mon, 13 Oct 2014 09:09:42 +0200 (CEST) Date: Mon, 13 Oct 2014 09:09:42 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6LBwVagd-FjNLZJ2DQlWlCPijqI Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 07:09:45 -0000 On Mon, 13 Oct 2014, Ole Troan wrote: > shouldn't this be a draft authored by operators? giving operational > recommendations coming out of... well, actual operations? Well, another way of looking at this is that operators just want things to work as well as they can, so they need guidance from vendors and protocol designers. Isn't this a BCOP style document? I believe at least one of the authors is active in one or more BCOP group. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 13 00:15:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3B1A88B4; Mon, 13 Oct 2014 00:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qOcfZzA5CmF; Mon, 13 Oct 2014 00:15:08 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417191A1AC2; Mon, 13 Oct 2014 00:15:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANF6O1StJssW/2dsb2JhbABb1xQCgSsBfYQDAQEDAR0dPxALDi0LVwaISQjDagEBAQEBAQEBAQEBAQEBAQEBAQEBAReQEjMHgy2BHgEEs1yCNIFFO4J5AQEB X-IronPort-AV: E=Sophos;i="5.04,708,1406592000"; d="scan'208";a="204609670" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Oct 2014 07:15:05 +0000 Received: from dhcp-10-61-101-249.cisco.com (dhcp-10-61-101-249.cisco.com [10.61.101.249]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9D7F1WO028207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 07:15:05 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ole Troan In-Reply-To: Date: Mon, 13 Oct 2014 09:15:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sLKO4oHbLdQWHiMuOkgcdJoaRqM Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 07:15:09 -0000 >> shouldn't this be a draft authored by operators? giving operational = recommendations coming out of... well, actual operations? >=20 > Well, another way of looking at this is that operators just want = things to work as well as they can, so they need guidance from vendors = and protocol designers. >=20 > Isn't this a BCOP style document? I believe at least one of the = authors is active in one or more BCOP group. the protocol designer's recommendation does appear pretty clear, = RFC2460: "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." my point is that I don't think the IETF should be making recommendations = about how they should run their network, and certainly not make = recommendations that are at odds with the functioning of the protocol. cheers, Ole From nobody Mon Oct 13 00:32:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4C81A88B9; Mon, 13 Oct 2014 00:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geltaRjASGVL; Mon, 13 Oct 2014 00:31:56 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12511A88B7; Mon, 13 Oct 2014 00:31:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1FD46A2; Mon, 13 Oct 2014 09:31:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413185515; bh=C93cgaL71FWfshnw2cV7UkBeS+OK7DzylvzHdzVUUv8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WOQjD+g8DhFCu7GWEtIfiR25PtwdhFD1voTmzW4zrn+6SGTWSMuGt469xSaeDbZP4 pUmyScwRbWyk5nSHyPWitAA4P3V9D8AwaHPebyqc+rcm6jwyWe2mEZMe4zsBNIbYhr K4UhPAIaA4xcvrjDtSvBkIrtlU33n+S136VYaOEE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 15056A1; Mon, 13 Oct 2014 09:31:55 +0200 (CEST) Date: Mon, 13 Oct 2014 09:31:55 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rswykNx_VpeZUpU-hPzuEx2sVZc Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 07:31:58 -0000 On Mon, 13 Oct 2014, Ole Troan wrote: >>> shouldn't this be a draft authored by operators? giving operational recommendations coming out of... well, actual operations? >> >> Well, another way of looking at this is that operators just want things to work as well as they can, so they need guidance from vendors and protocol designers. >> >> Isn't this a BCOP style document? I believe at least one of the authors is active in one or more BCOP group. > > the protocol designer's recommendation does appear pretty clear, RFC2460: > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header." > > my point is that I don't think the IETF should be making recommendations about how they should run their network, and certainly not make recommendations that are at odds with the functioning of the protocol. You mean you don't want non-operators in the IETF to make recommendations? The way I see it is that vendors are making equipment based on customer requirements. Since a lot of vendor equipment obviously inspect packets, including those with extension headers along the way (probably to do ACLs), then this equipment is already violating the functioning of the protocol (which of course is nothing new). My opinion is that it's better to look at common implementation and document and give recommendations where this differs from the blueprints. What I don't like is that if we follow along this path we're basically saying "extension headers don't work on the Internet" which has the implication that fewer will use them, meaning the vendors that don't follow the protocol designer intention has little downside, and thus perpetuating the problem. I don't know how to make it right though. I would like to see extension headers working well, but I also understand that people want to be able to do filtering. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 13 07:38:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE3B1A0107 for ; Mon, 13 Oct 2014 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMXLTNyGHqyr for ; Mon, 13 Oct 2014 07:38:05 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106761A00F2 for ; Mon, 13 Oct 2014 07:38:05 -0700 (PDT) Received: (qmail 1234 invoked from network); 13 Oct 2014 07:38:02 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Oct 2014 07:38:02 -0700 Date: Mon, 13 Oct 2014 07:38:02 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Mikael Abrahamsson In-Reply-To: Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RPUjJywkFxhuvN69i1HltWD0owA Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:38:06 -0000 On Mon, 13 Oct 2014, Mikael Abrahamsson wrote: > On Mon, 13 Oct 2014, Ole Troan wrote: > > > > shouldn't this be a draft authored by operators? giving operational > > > > recommendations coming out of... well, actual operations? > > > > > > Well, another way of looking at this is that operators just want things to > > > work as well as they can, so they need guidance from vendors and protocol > > > designers. > > > > > > Isn't this a BCOP style document? I believe at least one of the authors is > > > active in one or more BCOP group. > > > > the protocol designer's recommendation does appear pretty clear, RFC2460: > > > > "With one exception, extension headers are not examined or processed > > by any node along a packet's delivery path, until the packet reaches > > the node (or each of the set of nodes, in the case of multicast) > > identified in the Destination Address field of the IPv6 header." RFC 7045, a standards-track document, explicitly changes that. The subject draft does not make any recommendations that contradict RC 7045. It supplements RFC 7045 where the latter does not fully nail down the behaviour. There is also draft-gont-6man-ipv6-opt-transmit, which (if approved) will do the same for options that RFC 7045 does for extension headers. Same commens wrt that. > You mean you don't want non-operators in the IETF to make recommendations? > > The way I see it is that vendors are making equipment based on customer > requirements. Since a lot of vendor equipment obviously inspect packets, > including those with extension headers along the way (probably to do ACLs), > then this equipment is already violating the functioning of the protocol > (which of course is nothing new). > > My opinion is that it's better to look at common implementation and document > and give recommendations where this differs from the blueprints. > > What I don't like is that if we follow along this path we're basically saying > "extension headers don't work on the Internet" which has the implication that > fewer will use them, meaning the vendors that don't follow the protocol > designer intention has little downside, and thus perpetuating the problem. > > I don't know how to make it right though. I would like to see extension > headers working well, but I also understand that people want to be able to do > filtering. RFC 7045 revises IPv6 to acknowledge the reality of packet inspection by forwarding devices, but lit levies requirements that, if followed, should make the behaviour far less destructive. The sibject draft complements it with operational advice that is much in the same spirit. //cmh From nobody Mon Oct 13 12:25:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119B1A8BB5; Mon, 13 Oct 2014 12:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6pKTYckgEgF; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704291A8BBE; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so6095955pdi.33 for ; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uANDhjnajAxB+G0iTTKDjFc/2UwgJbv+WiZfnXBIz6o=; b=VGGnGi2bp6AAmBpZ39vhDtNcir5uY9vlFW/UFiwQGVQqceVwKMK8JSGBH6E0n1/LFm wMCA7nDbDBgEEM25zzff8SY6N9LWtknRXdJfw7Yz4RJKAxTICMOSvil10FRQnh1lq5Vc A31k1DnAH5FRFf+YAW+/p7KAtG1J2NBmL9Oi55BvLN4RH1PHjeGZjkPe8znOezwEtx6W fMR2rD4fea3/Gzg/e2qrp77J9CacJVQ+/aFHeGOT4kBE/2b1uIY4rsKNaApD9sERcOe4 czs1gMwuOdPzzCW5+6EUYFHE4osZOCs4cB7BGKsbc5oHY6Dn35LQals3awdDO5i71bZa hA/w== X-Received: by 10.70.5.164 with SMTP id t4mr587173pdt.48.1413228293094; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) Received: from [192.168.178.23] (75.196.69.111.dynamic.snap.net.nz. [111.69.196.75]) by mx.google.com with ESMTPSA id n2sm11980158pdh.30.2014.10.13.12.24.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 12:24:51 -0700 (PDT) Message-ID: <543C2700.3060404@gmail.com> Date: Tue, 14 Oct 2014 08:24:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mpshtS0QIQ7WEW1BTJABbSyD_KE Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 19:25:03 -0000 On 14/10/2014 03:38, C. M. Heard wrote: > On Mon, 13 Oct 2014, Mikael Abrahamsson wrote: >> On Mon, 13 Oct 2014, Ole Troan wrote: >>>>> shouldn't this be a draft authored by operators? giving operational >>>>> recommendations coming out of... well, actual operations? >>>> Well, another way of looking at this is that operators just want things to >>>> work as well as they can, so they need guidance from vendors and protocol >>>> designers. >>>> >>>> Isn't this a BCOP style document? I believe at least one of the authors is >>>> active in one or more BCOP group. >>> the protocol designer's recommendation does appear pretty clear, RFC2460: >>> >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." > > RFC 7045, a standards-track document, explicitly changes that. The > subject draft does not make any recommendations that contradict > RC 7045. It supplements RFC 7045 where the latter does not fully > nail down the behaviour. > > There is also draft-gont-6man-ipv6-opt-transmit, which (if > approved) will do the same for options that RFC 7045 does for > extension headers. Same commens wrt that. > >> You mean you don't want non-operators in the IETF to make recommendations? >> >> The way I see it is that vendors are making equipment based on customer >> requirements. Since a lot of vendor equipment obviously inspect packets, >> including those with extension headers along the way (probably to do ACLs), >> then this equipment is already violating the functioning of the protocol >> (which of course is nothing new). >> >> My opinion is that it's better to look at common implementation and document >> and give recommendations where this differs from the blueprints. >> >> What I don't like is that if we follow along this path we're basically saying >> "extension headers don't work on the Internet" which has the implication that >> fewer will use them, meaning the vendors that don't follow the protocol >> designer intention has little downside, and thus perpetuating the problem. >> >> I don't know how to make it right though. I would like to see extension >> headers working well, but I also understand that people want to be able to do >> filtering. > > RFC 7045 revises IPv6 to acknowledge the reality of packet > inspection by forwarding devices, but lit levies requirements that, > if followed, should make the behaviour far less destructive. The > sibject draft complements it with operational advice that is much in > the same spirit. Exactly. I believe this draft, and the options draft, are *exactly* what the IETF should do (and why we have an E in our name instead of an S; we are not the Internet Standards Task Force). If our standards are unrealistic, we should be the ones to do something about it... Brian From nobody Mon Oct 13 13:04:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886891A001D; Mon, 13 Oct 2014 13:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJKn3Gbo8AQS; Mon, 13 Oct 2014 13:04:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73ED01A000E; Mon, 13 Oct 2014 13:04:51 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9DK3JTU013429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 13:03:20 -0700 (PDT) Message-ID: <543C3008.80506@isi.edu> Date: Mon, 13 Oct 2014 13:03:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> In-Reply-To: <543C2700.3060404@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vTWvRaEXi9VjTGY0--CD76XONWg Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:04:54 -0000 On 10/13/2014 12:24 PM, Brian E Carpenter wrote: ... > Exactly. I believe this draft, and the options draft, are *exactly* what > the IETF should do (and why we have an E in our name instead of an S; > we are not the Internet Standards Task Force). If our standards are > unrealistic, we should be the ones to do something about it... If it's that our standards are unrealistic, it would be useful to address this as changes to the standards. Joe From nobody Mon Oct 13 13:47:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D5F1A008F for ; Mon, 13 Oct 2014 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARG6XkiHim0v for ; Mon, 13 Oct 2014 13:47:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B341D1A001B for ; Mon, 13 Oct 2014 13:47:26 -0700 (PDT) Received: (qmail 18264 invoked from network); 13 Oct 2014 13:47:19 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Oct 2014 13:47:19 -0700 Date: Mon, 13 Oct 2014 13:47:19 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Joe Touch In-Reply-To: <543C3008.80506@isi.edu> Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D2ZWjZjf_my7iSvQNOTiJSL1hqw Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:47:28 -0000 On Mon, 13 Oct 2014, Joe Touch wrote: > On 10/13/2014 12:24 PM, Brian E Carpenter wrote: > ... > > Exactly. I believe this draft, and the options draft, are *exactly* what > > the IETF should do (and why we have an E in our name instead of an S; > > we are not the Internet Standards Task Force). If our standards are > > unrealistic, we should be the ones to do something about it... > > If it's that our standards are unrealistic, it would be useful to > address this as changes to the standards. That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front page. Similarly, draft-gont-6man-ipv6-opt-transmit (the options draft referred to above) has "Updates: 2460 (if approved)" in its front page. //cmh From nobody Mon Oct 13 13:57:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F941A0072; Mon, 13 Oct 2014 13:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmLvetGoN83h; Mon, 13 Oct 2014 13:57:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAAB1A000E; Mon, 13 Oct 2014 13:57:29 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9DKukUE022063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 13:56:46 -0700 (PDT) Message-ID: <543C3C8E.3010405@isi.edu> Date: Mon, 13 Oct 2014 13:56:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jh47z48xwLBDq316iCbrHMb4oMs Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:57:30 -0000 On 10/13/2014 1:47 PM, C. M. Heard wrote: > On Mon, 13 Oct 2014, Joe Touch wrote: >> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >> ... >>> Exactly. I believe this draft, and the options draft, are *exactly* what >>> the IETF should do (and why we have an E in our name instead of an S; >>> we are not the Internet Standards Task Force). If our standards are >>> unrealistic, we should be the ones to do something about it... >> >> If it's that our standards are unrealistic, it would be useful to >> address this as changes to the standards. > > That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front > page. Similarly, draft-gont-6man-ipv6-opt-transmit (the options > draft referred to above) has "Updates: 2460 (if approved)" in its > front page. Right, but it's not what either this doc (draft-gont-opsec-ipv6-eh-filtering) or draft-gont-v6ops-ipv6-ehs-in-real-world does. I've raised this issue before. Joe From nobody Mon Oct 13 17:52:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E437A1A1A73 for ; Mon, 13 Oct 2014 17:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fruetjt6Vo1u for ; Mon, 13 Oct 2014 17:52:13 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:2::28]) by ietfa.amsl.com (Postfix) with ESMTP id DC7371A1A74 for ; Mon, 13 Oct 2014 17:52:10 -0700 (PDT) Received: from [IPv6:2403:2000:1:3:a64e:31ff:fe26:a6cc] (unknown [IPv6:2403:2000:1:3:a64e:31ff:fe26:a6cc]) by inc.inetcore.com (Postfix) with ESMTPSA id CA21F2DD091; Tue, 14 Oct 2014 09:52:08 +0900 (JST) Message-ID: <543C73B8.4060601@inetcore.com> Date: Tue, 14 Oct 2014 09:52:08 +0900 From: Ruri Hiromi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29.1 MIME-Version: 1.0 To: Mikael Abrahamsson References: <54364189.5080905@inetcore.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oKVrjjBQ277knDkN1Xi8E2SJE-k Cc: IPv6 Operations Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:52:16 -0000 Thanks for the comment. Yes, the tool is free to obtain. But to keep healthy use of the tool, JPCERT/CC currently provides it based on requests from Vendors.(and requester has to sign a kind of an agreement of use policy document) We think a product will also be available in the end of this year. This is my personal concern, the tool needs to be customized for automatic testing and showing more easy to understandable dialogue and so on. Regards, On 2014/10/13 16:05, Mikael Abrahamsson wrote: > > My opinion is that having test suites available as FOSS would be great. > The tools look like they're of the kind already freely available, but > actually setting up tests that operators and end users can run against > their equipment is of great help. I encourage freely available tests of > all kinds. > > The document lists tests performed but doesn't say if the tools will be > available, so that's a question from me to the author. > > I would like to see protocol fuzzers etc also be available, if possible. > We have way too few of these freely available. > > On Thu, 9 Oct 2014, Fred Baker (fred) wrote: > >> I would be interested in working group opinions on this note. Is it >> useful to the operators? >> >> On Oct 9, 2014, at 1:04 AM, Ruri Hiromi wrote: >> >>> Dear chairs, >>> >>> Hi, >>> I submitted "draft-jpcert-ipv6vullnerability-check-00" today. >>> If v6ops gives a 3 to 5 minutes for me, I would like to talk about this. >>> >>> http://datatracker.ietf.org/doc/draft-jpcert-ipv6vullnerability-check/ >>> >>> Regards, >>> >>> P.S. I am still working on this.... until the deadline comes... >>> >>> On 2014/10/07 9:09, Fred Baker (fred) wrote: >>>> As I mentioned last week, Lee and I are pulling together an agenda >>>> for IETF 91. The drop-dead date for new or updated drafts is 27 >>>> October, and frankly it will work better if drafts arrive earlier - >>>> as we are looking for working group commentary on them. >>>> >>>> Current state of play: >>>> >>>> IESG: >>>> Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 >>>> Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis >>>> >>>> IETF Last Call: >>>> Sep 26 draft-ietf-v6ops-mobile-device-profile >>>> >>>> Working Group Document updated since IETF: >>>> Sep 18 draft-ietf-v6ops-design-choices >>>> >>>> Individual Submission updated since IETF: >>>> Aug 24 draft-v6ops-pmtud-ecmp-problem >>>> On list, Ray Hunter suggests someone write "a draft >>>> summarizing the ICMP PTB problem" >>>> Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world >>>> There has been some discussion on-list. >>>> Sep 15 draft-anderson-v6ops-siit-dc-2xlat >>>> No list commentary >>>> Sep 18 draft-elkins-v6ops-multicast-virtual-nodes >>>> Some commentary, not supportive >>>> Sep 18 draft-wang-v6ops-xlat-prefix-discovery >>>> A fair amount of discussion, mostly anti-NAT. >>>> Sep 25 draft-ybai-v6ops-ipv6-for-openstack >>>> no list commentary >>>> Oct 5 draft-anderson-v6ops-siit-dc >>>> Some list commentary >>>> >>>> Working Group Document NOT updated since IETF: >>>> Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem >>>> Jul 4 draft-ietf-v6ops-ula-usage-recommendations >>>> >>>> Individual Submission NOT updated since IETF: >>>> Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node >>>> Jul 3 draft-liu-v6ops-running-multiple-prefixes >>>> Jul 4 draft-sun-v6ops-xlat-multi >>>> Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x >>>> Jul 20 draft-wang-v6ops-flow-label-refelction >>>> Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance >>>> >>>> more data at >>>> http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> >>> -- >>> --------------- >>> Ruri Hiromi >>> INTEC Inc. >> >> > -- =================================== 株式会社インテック 先端技術研究所　研究開発部 廣海（ひろみ）緑里 From nobody Mon Oct 13 22:33:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDB71A6F99; Mon, 13 Oct 2014 22:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIKYGZ1E1VWa; Mon, 13 Oct 2014 22:33:45 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6DF1A6F97; Mon, 13 Oct 2014 22:33:45 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9E5XMA8098544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 05:33:22 GMT (envelope-from joelja@bogus.com) Message-ID: <543CB5B4.9030203@bogus.com> Date: Mon, 13 Oct 2014 22:33:40 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Joe Touch , Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> In-Reply-To: <543C3008.80506@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zAPCI0zZXLc8tO9lTn8-qt6AYJk Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 05:33:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/13/14 1:03 PM, Joe Touch wrote: >=20 >=20 > On 10/13/2014 12:24 PM, Brian E Carpenter wrote: > ... >> Exactly. I believe this draft, and the options draft, are *exactly* wh= at >> the IETF should do (and why we have an E in our name instead of an S; >> we are not the Internet Standards Task Force). If our standards are >> unrealistic, we should be the ones to do something about it... >=20 > If it's that our standards are unrealistic, it would be useful to > address this as changes to the standards. It's not entirely unrealistic to expect a consensus about observed reality to emerge from ops before it evolves into protocol maintenance. The working groups remit doesn't involve changing standards so frankly that's right out. joel > Joe >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ8tbQACgkQ8AA1q7Z/VrLLugCbB17qU13wwbj71vgebYV1bPdD 9OAAnjpSBWlsmwCct6RwsH72uUMxFRp/ =DtgR -----END PGP SIGNATURE----- --CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI-- From nobody Mon Oct 13 23:51:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2290F1A6FC0; Mon, 13 Oct 2014 23:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLaUUehOLmTl; Mon, 13 Oct 2014 23:51:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8471A6FBB; Mon, 13 Oct 2014 23:51:49 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-50.lsanca.dsl-w.verizon.net [71.103.148.50]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9E6otns011920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 23:51:04 -0700 (PDT) Message-ID: <543CC7D1.7080602@isi.edu> Date: Mon, 13 Oct 2014 23:50:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: joel jaeggli , Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543CB5B4.9030203@bogus.com> In-Reply-To: <543CB5B4.9030203@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a6zFRLhpupt5XQqZxOfFMXMcrYU Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 06:51:50 -0000 On 10/13/2014 10:33 PM, joel jaeggli wrote: > On 10/13/14 1:03 PM, Joe Touch wrote: >> >> >> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >> ... >>> Exactly. I believe this draft, and the options draft, are *exactly* what >>> the IETF should do (and why we have an E in our name instead of an S; >>> we are not the Internet Standards Task Force). If our standards are >>> unrealistic, we should be the ones to do something about it... >> >> If it's that our standards are unrealistic, it would be useful to >> address this as changes to the standards. > > It's not entirely unrealistic to expect a consensus about observed > reality to emerge from ops before it evolves into protocol maintenance. Observed reality doesn't include recommendations. And if observed reality requires consensus, I doubt you're describing anything that involves either observation or reality. Joe From nobody Tue Oct 14 00:02:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0835B1A6FC0; Tue, 14 Oct 2014 00:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvXhGMTLoQwP; Tue, 14 Oct 2014 00:02:25 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9B91A6FBE; Tue, 14 Oct 2014 00:02:25 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9E722xB098881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 07:02:03 GMT (envelope-from joelja@bogus.com) Message-ID: <543CCA7D.6060900@bogus.com> Date: Tue, 14 Oct 2014 00:02:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Joe Touch , Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543CB5B4.9030203@bogus.com> <543CC7D1.7080602@isi.edu> In-Reply-To: <543CC7D1.7080602@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KNCpzbvdn2BzkByWVvSb6OyFqfw Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 07:02:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/13/14 11:50 PM, Joe Touch wrote: >=20 >=20 > On 10/13/2014 10:33 PM, joel jaeggli wrote: >> On 10/13/14 1:03 PM, Joe Touch wrote: >>> >>> >>> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >>> ... >>>> Exactly. I believe this draft, and the options draft, are *exactly* = what >>>> the IETF should do (and why we have an E in our name instead of an S= ; >>>> we are not the Internet Standards Task Force). If our standards are >>>> unrealistic, we should be the ones to do something about it... >>> >>> If it's that our standards are unrealistic, it would be useful to >>> address this as changes to the standards. >> >> It's not entirely unrealistic to expect a consensus about observed >> reality to emerge from ops before it evolves into protocol maintenance= =2E >=20 > Observed reality doesn't include recommendations. >=20 > And if observed reality requires consensus, I doubt you're describing > anything that involves either observation or reality. =2E.. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. =2E.. > Joe >=20 --wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ8yn4ACgkQ8AA1q7Z/VrIYkACfZtjcSsgg6KWosvVxWmCZftrh Hl0An1d7UFi1HIEF2NEQ5nsJp1eP9OTu =bibc -----END PGP SIGNATURE----- --wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo-- From nobody Tue Oct 14 02:54:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85C81A7010; Tue, 14 Oct 2014 02:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjmMr90j8eH7; Tue, 14 Oct 2014 02:54:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE141A7011; Tue, 14 Oct 2014 02:54:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014095406.9779.82116.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 02:54:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/myk3z0VnTv2Y3DqoFXkkio2RkH0 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:54:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : DHCPv6/SLAAC Address Configuration Interaction Problem Statement Authors : Bing Liu Sheng Jiang Ron Bonica Xiangyang Gong Wendong Wang Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt Pages : 12 Date : 2014-10-14 Abstract: The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating which autoconfiguration mechanisms are available to on- link hosts. These are the M, O and A flags. The M, O and A flags are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also describes operational problems that divergent behaviors cause. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 07:05:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79A61A8872 for ; Tue, 14 Oct 2014 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExbASEVy-kWe for ; Tue, 14 Oct 2014 07:05:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF431A8868 for ; Tue, 14 Oct 2014 07:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3047; q=dns/txt; s=iport; t=1413295516; x=1414505116; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PSbBa1NGULmHjq3p06f5ZRKjulQPi3brwcOQbvAsiCU=; b=F1cQXwaaLtygeD4cusyA2kqUu3r/G77Jm2iAUjUbv2K/dy7vbtnvRTf7 Wg4pweSmIVQNmpnXNibIbLVOwVVMVsEBMWBG2czXst1r7lEj4eFwjqYTf 9x/tafi2bbqV8hYRJyia4DD0p2FLx119TO2X0EWogoyVJOADmZiANPB3C 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFALEsPVStJV2d/2dsb2JhbABbgw5TUwUEzCoMh0sCgRMWAX2EAwEBAwEBAQFrGwIBCEYnCyUCBBMJBYgoCAgFxkABAQEBAQEBAQEBAQEBAQEBAQEBGZBHBYMtgR4FkXmCDIFPZ4cQgS48gwqKTIZRg3dsAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,717,1406592000"; d="asc'?scan'208";a="363154735" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 14 Oct 2014 14:05:16 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9EE5GVt022175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 Oct 2014 14:05:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 09:05:16 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt Thread-Index: AQHP57fgUo80lHMVHUCgBU7BONE+6g== Date: Tue, 14 Oct 2014 14:05:15 +0000 Message-ID: References: <20141014095406.9779.82116.idtracker@ietfa.amsl.com> In-Reply-To: <20141014095406.9779.82116.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.100.149] Content-Type: multipart/signed; boundary="Apple-Mail=_471E019C-CABC-4D27-A2EE-0F364EF248F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-mOld1lCACeD5SWkxE00aY4jd8s Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 14:05:19 -0000 --Apple-Mail=_471E019C-CABC-4D27-A2EE-0F364EF248F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors tell me that they have largely rewritten this draft but not = changed the technical content, and would like working group review. https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem On Oct 14, 2014, at 2:54 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : DHCPv6/SLAAC Address Configuration = Interaction Problem Statement > Authors : Bing Liu > Sheng Jiang > Ron Bonica > Xiangyang Gong > Wendong Wang > Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt > Pages : 12 > Date : 2014-10-14 >=20 > Abstract: > The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router > Advertisement (RA) message. The RA message contains three flags, > indicating which autoconfiguration mechanisms are available to on- > link hosts. These are the M, O and A flags. The M, O and A flags > are advisory, not prescriptive. >=20 > This document describes divergent host behaviors observed in popular > operating systems. It also describes operational problems that > divergent behaviors cause. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-02 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-problem-0= 2 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_471E019C-CABC-4D27-A2EE-0F364EF248F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUPS2abjEdbHIsm0MRAu28AKDmcLLyJseMQCSDuuBZrW6eChpQGQCg+CL/ 5zP8epZ213MUZKxgLYxd6g0= =pMVK -----END PGP SIGNATURE----- --Apple-Mail=_471E019C-CABC-4D27-A2EE-0F364EF248F6-- From nobody Tue Oct 14 08:23:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473AE1A88D0 for ; Tue, 14 Oct 2014 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EmQfLNBaDHX for ; Tue, 14 Oct 2014 08:23:21 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FE31A88EE for ; Tue, 14 Oct 2014 08:23:21 -0700 (PDT) Received: (qmail 31413 invoked from network); 14 Oct 2014 08:23:17 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Oct 2014 08:23:17 -0700 Date: Tue, 14 Oct 2014 08:23:17 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Joe Touch In-Reply-To: <543C3C8E.3010405@isi.edu> Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543C3C8E.3010405@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PIpYEo74hcl_5Db9xiBs2eX6ch8 Cc: opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:23:22 -0000 On Mon, 13 Oct 2014, Joe Touch wrote: > On 10/13/2014 1:47 PM, C. M. Heard wrote: > > On Mon, 13 Oct 2014, Joe Touch wrote: > >> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: > >> ... > >>> Exactly. I believe this draft, and the options draft, are *exactly* what > >>> the IETF should do (and why we have an E in our name instead of an S; > >>> we are not the Internet Standards Task Force). If our standards are > >>> unrealistic, we should be the ones to do something about it... > >> > >> If it's that our standards are unrealistic, it would be useful to > >> address this as changes to the standards. > > > > That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front > > page. Similarly, draft-gont-6man-ipv6-opt-transmit (the options > > draft referred to above) has "Updates: 2460 (if approved)" in its > > front page. > > Right, but it's not what either this doc > (draft-gont-opsec-ipv6-eh-filtering) or > draft-gont-v6ops-ipv6-ehs-in-real-world does. > > I've raised this issue before. If I correctly understand the intent, draft-gont-opsec-ipv6-eh-filtering is not supposed to make any recommendations that contravene RFC 2460 as updated by RFC 7045 and draft-gont-6man-ipv6-opt-transmit. If you see something specific where it does so please point it out. I didn't find anything like that when I reviewed the document. //cmh From nobody Tue Oct 14 15:47:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E421A000C; Tue, 14 Oct 2014 15:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGtUEq9zhuVT; Tue, 14 Oct 2014 15:47:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCE71A0019; Tue, 14 Oct 2014 15:47:05 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9EMkqxb009604; Tue, 14 Oct 2014 23:46:52 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s9EMkqxb009604 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1413326815; bh=aN4Dx8qZz9jTsemKEUGKeTA/79Y=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UQ8vJp4yDSnajAQUddYmZKm/EhXSOqxINEP40UO3Xhcn81kno+YHtGPcQe3SGCBEM GldF75Fi8U0uhhdKVz/HuDdCaYxqG61rUatZMqFxup57vce7U9IfLB0njc7dFr+ure UHgmXK+9PfvYyCSghmhpkOq2N6BRTZ4dsky8Td5s= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q9DNkq17613133797Z ret-id none; Tue, 14 Oct 2014 23:46:54 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9EMkdQ6018707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Oct 2014 23:46:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <543CCA7D.6060900@bogus.com> Date: Tue, 14 Oct 2014 23:46:39 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543CB5B4.9030203@bogus.com> <543CC7D1.7080602@isi.edu> <543CCA7D.6060900@bogus.com> <9FAF4D5B-217D-40E8-997A-924B05CF045D@ecs.soton.ac.uk> To: joel jaeggli X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q9DNkq176131337900; tid=q9DNkq17613133797Z; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s9EMkqxb009604 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/G_xrTGuMLT2oScj-l0JLiY74aT0 Cc: "C. M. Heard" , opsec , v6ops Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 22:47:09 -0000 On 14 Oct 2014, at 08:02, joel jaeggli wrote: > On 10/13/14 11:50 PM, Joe Touch wrote: >>=20 >>=20 >> On 10/13/2014 10:33 PM, joel jaeggli wrote: >>> On 10/13/14 1:03 PM, Joe Touch wrote: >>>>=20 >>>>=20 >>>> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >>>> ... >>>>> Exactly. I believe this draft, and the options draft, are = *exactly* what >>>>> the IETF should do (and why we have an E in our name instead of an = S; >>>>> we are not the Internet Standards Task Force). If our standards = are >>>>> unrealistic, we should be the ones to do something about it... >>>>=20 >>>> If it's that our standards are unrealistic, it would be useful to >>>> address this as changes to the standards. >>>=20 >>> It's not entirely unrealistic to expect a consensus about observed >>> reality to emerge from ops before it evolves into protocol = maintenance. >>=20 >> Observed reality doesn't include recommendations. >>=20 >> And if observed reality requires consensus, I doubt you're describing >> anything that involves either observation or reality. >=20 > ... >=20 > The goals of the v6ops working group are: >=20 > 1. Solicit input from network operators and users to identify > operational issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. These issues > will be documented in Informational or BCP RFCs, or in > Internet-Drafts. >=20 > This work should primarily be conducted by those areas and WGs > which are responsible and best fit to analyze these problems, but > v6ops may also cooperate in focusing such work. >=20 > 2. Publish Informational or BCP RFCs that identify potential security > risks in the operation of shared IPv4/IPv6 networks, and document > operational practices to eliminate or mitigate those risks. >=20 > This work will be done in cooperation with the Security area and > other relevant areas or working groups. >=20 > 3. As a particular instance of (1) and (2), provide feedback to > the IPv6 WG regarding portions of the IPv6 specifications that > cause, or are likely to cause, operational or security concerns, > and work with the IPv6 WG to resolve those concerns. This feedback > will be published in Internet-Drafts or RFCs. > ... =85 which suggests publishing the observations / problem statement in = one draft in v6ops, and then progressing recommendations in a separate = document in conjuction with opsec seems perfectly reasonable? I=92m puzzled by the length of this conversation / debate=85 Tim= From nobody Tue Oct 14 18:21:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83261A010E for ; Tue, 14 Oct 2014 18:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTWzGek9DfsJ for ; Tue, 14 Oct 2014 18:21:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6461A0105 for ; Tue, 14 Oct 2014 18:21:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKO06541; Wed, 15 Oct 2014 01:20:58 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Oct 2014 02:20:58 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 09:20:50 +0800 From: "Liubing (Leo)" To: "Fred Baker (fred)" , IPv6 Operations Thread-Topic: I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt Thread-Index: AQHP55TWRrHydRhzZkWt3SYgFPrSO5wvGnuAgAE+FbA= Date: Wed, 15 Oct 2014 01:20:49 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589D7F68@nkgeml506-mbx.china.huawei.com> References: <20141014095406.9779.82116.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T5tYn3qoQR3XGiNapaXGNLYk73g Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 01:21:05 -0000 Hi Dear Chairs & all, Thanks for Fred's notification. As discussed in last IETF, the main issue was the readability. So we almost= re-wrote the whole document to make the content more concise and largely i= mprove the language.=20 For the technical aspect, there is no essential change. The main revision i= s adding tests of some latest operating systems (Win 8.1; Ubuntu 14.04; iOS= 8; OSX 10.9). The operational problems part was also simplified to be more= concrete. The authors believe this version is ready for WGLC. Your comments would be appreciated. Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred= ) > Sent: Tuesday, October 14, 2014 10:05 PM > To: IPv6 Operations > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt >=20 > The authors tell me that they have largely rewritten this draft but not > changed the technical content, and would like working group review. >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem >=20 > On Oct 14, 2014, at 2:54 AM, internet-drafts@ietf.org wrote: >=20 > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations Working Group of the I= ETF. > > > > Title : DHCPv6/SLAAC Address Configuration > Interaction Problem Statement > > Authors : Bing Liu > > Sheng Jiang > > Ron Bonica > > Xiangyang Gong > > Wendong Wang > > Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-02.txt > > Pages : 12 > > Date : 2014-10-14 > > > > Abstract: > > The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router > > Advertisement (RA) message. The RA message contains three flags, > > indicating which autoconfiguration mechanisms are available to on- > > link hosts. These are the M, O and A flags. The M, O and A flags > > are advisory, not prescriptive. > > > > This document describes divergent host behaviors observed in popular > > operating systems. It also describes operational problems that > > divergent behaviors cause. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem > > / > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-proble= m > > -02 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Oct 15 05:29:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663A81A6EF8; Wed, 15 Oct 2014 05:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By1W2EU2bYwf; Wed, 15 Oct 2014 05:29:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BDA1A1F70; Wed, 15 Oct 2014 05:29:37 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:bdfd:214d:a71:4d8c] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9FCRROk053916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 14:27:27 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 15 Oct 2014 14:29:25 +0200 To: v6ops@ietf.org, grow@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0out998rceF2MX0M3t9bZkMKz2s Subject: [v6ops] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:29:39 -0000 We are all familiar with PA (provider aggregatable) and PI (provider = independent) address space. But it turns out a new type of IPv6 address = space is starting to show up, which I'll call organization = deaggregatable (OD) address space (until someone suggests a better = name). How it works is like this: a large organization obtains a large block of = IPv6 address space, either as a very large PI block or by becoming a = local internet registry (LIR) and getting a regular LIR assignment = directly from one of the five regional registries. However, rather than = advertising that block in BGP as a single prefix, or perhaps a handful = of prefixes, like an ISP would, they subdivide this block within the = organization and then many subunits advertise subprefixes though = different ISPs. The aggregate may or may not be advertised. The advantage to the organization is that they have provider independent = address space that they'll never have to renumber out of, as well as = having a single prefix that identifies all of the organization, which = makes filtering easy. There seem to be two types of organizations that do this: geographically = dispersed ones that advertise subprefixes in different locations, such = as multinationals, and organizations with very independent subunits but = with more limited geographical scope, such as national governments. This practice, especially if/when it becomes more common, presents two = challenges: 1. Large numbers of prefixes may show up in the global routing table. = For instance, there is a number plan for all of the German government, = which could potentially inject more than 5000 municipality prefixes into = the global IPv6 routing table. 2. Filtering. If people want to avoid large numbers of deaggregates in = their routing tables, they may employ some kind of filtering, especially = if the deaggregates are very long prefixes. This means that packets are = no longer reliably delivered to the place announcing a more specific = prefix. Ideally, a set of best practices would be developed that strike a good = balance between the needs of large organizations and the needs of the = global routing system, and allow everyone to predict the consequences of = different kinds of behavior and thus avoid unpleasant surprises. These are some of the things that could go into such best practices: - A well-understood maximum prefix length for IPv6, similar to /24 for = IPv4. - An understanding of how the service providers that provide = connectivity to multiple subunits of a large organization can work = together in order to maximize availability and minimize costs for the = organization, the service providers and other network operators. - A way to provide a point of last resort where traffic for the = aggregate can be sent to if more specifics are filtered. - A set of communities that indicate whether a prefix is a more specific = that is covered by an aggregate and/or is safe to filter without loss of = connectivity. - A set of communities that indicate geographical origin of prefixes so = remote more specific prefixes can be filtered while local prefixes are = kept. - Guidelines for reserving address space in address plans. Is it better = to have free space reserved so existing prefixes can grow, or keep = reserved space together so tight prefix length filters are possible and = reserved space isn't broken up into small pieces? Please note that I'm crosspositing this to v6ops and grow initially. If = the chairs have any guidance on which working group is more appropriate = for this discussion, please let us know and we can drop the other one. Also note that I haven't been following discussions in both wgs = recently, so if this has been discussed previously, my apologies. Last but not least, this treads on RIR policy. But in my opinion, this = is foremost a technical matter with global implications and as such is = best discussed within the IETF rather than in the five respective policy = development forums.= From nobody Wed Oct 15 05:44:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAC11A1B74; Wed, 15 Oct 2014 05:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6REXdMSOmW0; Wed, 15 Oct 2014 05:43:56 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8617D1A01AA; Wed, 15 Oct 2014 05:43:56 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:bdfd:214d:a71:4d8c] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9FCfkIm054018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 14:41:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Iljitsch van Beijnum In-Reply-To: <543E6B66.5050803@inex.ie> Date: Wed, 15 Oct 2014 14:43:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <543E6B66.5050803@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0k-WLk-I0ZtJQJYSYaILZCCk0eE Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:43:59 -0000 On 15 Oct 2014, at 14:41, Nick Hilliard wrote: >> There seem to be two types of organizations that do this: = geographically >> dispersed ones that advertise subprefixes in different locations, = such >> as multinationals, and organizations with very independent subunits = but >> with more limited geographical scope, such as national governments. > and organisations who have a requirement for traffic engineering, = whether this requirement is real or imaginary - there are well known = examples of each. Right, we should probably add that. Although I wouldn't expect an organization to deaggregate down to = hundreds or thousands of more specifics just for traffic engineering.= From nobody Wed Oct 15 06:45:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB4A1A6F47; Wed, 15 Oct 2014 05:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c5_uFfMDMXW; Wed, 15 Oct 2014 05:41:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3AC1A6F41; Wed, 15 Oct 2014 05:41:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9FCfBEc036309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 13:41:33 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <543E6B66.5050803@inex.ie> Date: Wed, 15 Oct 2014 13:41:10 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Iljitsch van Beijnum , v6ops@ietf.org, grow@ietf.org References: In-Reply-To: X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/j9b49u89H9RU4s81M7GXt42-apE X-Mailman-Approved-At: Wed, 15 Oct 2014 06:45:34 -0700 Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:41:42 -0000 On 15/10/2014 13:29, Iljitsch van Beijnum wrote: > There seem to be two types of organizations that do this: geographically > dispersed ones that advertise subprefixes in different locations, such > as multinationals, and organizations with very independent subunits but > with more limited geographical scope, such as national governments. and organisations who have a requirement for traffic engineering, whether this requirement is real or imaginary - there are well known examples of each. Nick From nobody Wed Oct 15 06:45:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F31E1A1B94; Wed, 15 Oct 2014 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4LMTC4QbAhy; Wed, 15 Oct 2014 05:47:03 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8169D1A1B8B; Wed, 15 Oct 2014 05:47:03 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9FCl1sY036579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Oct 2014 13:47:01 +0100 (IST) (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <543E6CC3.5020202@inex.ie> Date: Wed, 15 Oct 2014 13:46:59 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <543E6B66.5050803@inex.ie> In-Reply-To: X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/cuYeFK-KJMEwWimEHbcENctiBgw X-Mailman-Approved-At: Wed, 15 Oct 2014 06:45:35 -0700 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 12:47:05 -0000 On 15/10/2014 13:43, Iljitsch van Beijnum wrote: > Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering. probably not no, but on the basis of visibility into IXP announcements with prefix analysis to see what's going on, some organisations do spectacularly bizarre things with no possible rational explanation. Nick From nobody Wed Oct 15 08:14:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4C1A86DE; Wed, 15 Oct 2014 08:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr69Pfi49-7y; Wed, 15 Oct 2014 08:14:15 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5248B1A8546; Wed, 15 Oct 2014 08:14:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 39FB61B8305; Wed, 15 Oct 2014 08:14:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 31AD553E076; Wed, 15 Oct 2014 08:14:09 -0700 (PDT) Received: from [192.168.1.63] (71.201.198.58) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Oct 2014 08:14:08 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Wed, 15 Oct 2014 10:14:02 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5B13739D-5BFD-467C-8DF0-D391508EB5C0@nominum.com> References: To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.201.198.58] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Oy6r8CXvCxM0r2fZIdtAnoReKpE Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:14:18 -0000 On Oct 15, 2014, at 7:29 AM, Iljitsch van Beijnum = wrote: > However, rather than advertising that block in BGP as a single prefix, = or perhaps a handful of prefixes, like an ISP would, they subdivide this = block within the organization and then many subunits advertise = subprefixes though different ISPs. The aggregate may or may not be = advertised. Yuck. Has anybody done an analysis of how this works with RPKI? = Seems like an obvious attack surface if the RPKI isn't present or isn't = done right. From nobody Wed Oct 15 11:03:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1621A8AAB for ; Wed, 15 Oct 2014 11:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn2gHjFqb7rv for ; Wed, 15 Oct 2014 11:03:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847971A1AB5 for ; Wed, 15 Oct 2014 11:03:53 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so13726035wid.0 for ; Wed, 15 Oct 2014 11:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=p93Qh5k3a6OAXBp7YKeISKzbh1IPvnj02E0i1wjAKgs=; b=iDhI31y3BOlNi+6cm35IazSoo36MYoetIQIf4w78BVAjYp0QEz3vZKLc4lEMY3MWr0 GghIZfTYTWaElo9jolmSH9aJ6yDclkulMklwZxMROzpOn04t+4/CcDrx5cT+WuL17AbZ zObAbrOdqbszyrN8A8WO3SetzaKL/Y9oYURyO6AuFUkREXcDNbyUFgNxvxwz2R6o2KmG uyCUjX87bPnWHo71kYXd1PN+NIhMVT6GgMA5YYH6LZC1DlBBRPxgOVzAZ1Ouqh2+GkyC t+e8nsyZ7PkruKLOnCC5RiJqy6uJ33XT1jEh02dIxAcCH9dw3Co/3ZW4zKnmQW/g351N AK+A== MIME-Version: 1.0 X-Received: by 10.180.218.230 with SMTP id pj6mr13743766wic.62.1413396232049; Wed, 15 Oct 2014 11:03:52 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.195.13.83 with HTTP; Wed, 15 Oct 2014 11:03:51 -0700 (PDT) In-Reply-To: References: <54364189.5080905@inetcore.com> Date: Wed, 15 Oct 2014 11:03:51 -0700 X-Google-Sender-Auth: EwN-VAONFnHrW1mg_2GWIg-_MBo Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1nuGsJfgyQmcQxGg4iDtQ-e761A Cc: IPv6 Operations Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:03:56 -0000 At Thu, 9 Oct 2014 11:48:41 +0000, "Fred Baker (fred)" wrote: > I would be interested in working group opinions on this note. Is it useful to the operators? I'm not a (professional) operator, but from a quick read of the draft I found it useful and worth a meeting slot for discussions. -- JINMEI, Tatuya From nobody Wed Oct 15 11:09:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FA31A9030; Wed, 15 Oct 2014 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B09n08DygVuv; Wed, 15 Oct 2014 11:09:09 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5CF1A902D; Wed, 15 Oct 2014 11:09:07 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so1664967pdb.31 for ; Wed, 15 Oct 2014 11:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x6BvnyTAB7PXtpzAbmQjnp9ecnbpTsw8Sr/UlAnbM/0=; b=PHgGZUiYKWzLMe4JeBIQTHsF9rVJqf/35T7M31rQG69HgrOF2vNnSvZCZDnAXNwhg0 M6TKW0o2DXx3z7WpGN8hRySxEg8/ibOonc6fXXPcu9fdBEU/3EabGwcTqn3i2r6fWB1T WUb5NsOYjjxTeSNQi8+TMb4U4o3wwAd7j23wOLSoOCXXrhv9fb89Qr8Y4JeOu9kHqCVW pt5/ykwEk6HMtd/gRmAZ341NoubrkDZL08r3xNIySyVkN9yZMQ2Q00B1IYxt8eIWbbkz b7cIRlm05t8xxaaGf6YNLJ+nJZsBXXLJCt4Fn2Y4sVcw+pogVMD4L1MSx7yKkXwDIGfC 8OLA== X-Received: by 10.70.94.199 with SMTP id de7mr14446802pdb.3.1413396546741; Wed, 15 Oct 2014 11:09:06 -0700 (PDT) Received: from [172.17.1.55] (219-89-120-188.adsl.xtra.co.nz. [219.89.120.188]) by mx.google.com with ESMTPSA id sa6sm17305650pbb.29.2014.10.15.11.09.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 11:09:05 -0700 (PDT) Message-ID: <543EB83E.9010301@gmail.com> Date: Thu, 16 Oct 2014 07:09:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <543E6B66.5050803@inex.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gjIksTWxydiM2I14tJPJkleQVOE Cc: v6ops@ietf.org, Nick Hilliard , grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:09:16 -0000 On 16/10/2014 01:43, Iljitsch van Beijnum wrote: > On 15 Oct 2014, at 14:41, Nick Hilliard wrote: > >>> There seem to be two types of organizations that do this: geographically >>> dispersed ones that advertise subprefixes in different locations, such >>> as multinationals, and organizations with very independent subunits but >>> with more limited geographical scope, such as national governments. > >> and organisations who have a requirement for traffic engineering, whether this requirement is real or imaginary - there are well known examples of each. > > Right, we should probably add that. > > Although I wouldn't expect an organization to deaggregate down to hundreds or thousands of more specifics just for traffic engineering. Not to hundreds, but I would expect a large multinational with operations in most countries to deaggregate down to something close to one per country, to keep its traffic patterns reasonably local. That's nothing new. Brian From nobody Wed Oct 15 15:26:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC81ACDDD; Wed, 15 Oct 2014 15:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7XFtB27xd6r; Wed, 15 Oct 2014 15:04:36 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B711ACDC6; Wed, 15 Oct 2014 15:04:35 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so1721712vcb.24 for ; Wed, 15 Oct 2014 15:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Us4QXQ88bVisLNU5vQSRHP9Tc3AMKGO93gn6ZFpeW4s=; b=qxyQdjCY7g1yg7DjIJ5SCQBzsExNdV1epTXQnjXm9u8l4L/yHIItMvV/OOO3uf+xwX v4B2+ee51xikQ6KbCvHXxD900XIxrmaWu7mJx6wrBTbcO6mdjaJfqzRoxfpqJCbSLaLv 6cM4YNUBy+ogRsGDhQkMNRkoV0BdXPzeTX0Z0sibHRXRaE+qcUDiuWR3YxP4XHFNO5P1 2JuMnMxVn98xC8n1m6KblDi4dcHorAEvss0EyXlM+gtD7pte96VEeaoyIsBCG4VedFhS TswPoatfDrYeYVD+B6UyfU+Wp4Sl77r18VFAXleJdnVMNH08rrdm92XRbet1SiwwbY9I acdg== MIME-Version: 1.0 X-Received: by 10.52.170.4 with SMTP id ai4mr3649599vdc.48.1413410674132; Wed, 15 Oct 2014 15:04:34 -0700 (PDT) Received: by 10.220.186.193 with HTTP; Wed, 15 Oct 2014 15:04:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Oct 2014 18:04:33 -0400 Message-ID: From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V5WBZb0r4oGRZCxnCKRZYaDBHbI X-Mailman-Approved-At: Wed, 15 Oct 2014 15:26:48 -0700 Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 22:04:43 -0000 (man mac-mail and gmail don't play well... I'm not re-formatting this, sorr= y) On Wed, Oct 15, 2014 at 8:29 AM, Iljitsch van Beijnum wrote: > We are all familiar with PA (provider aggregatable) and PI (provider inde= pendent) address space. But it turns out a new type of IPv6 address space i= s starting to show up, which I'll call organization deaggregatable (OD) add= ress space (until someone suggests a better name). > your OD sounds like (from reading below) like what PI is for, or ... OD =3D=3D PI, from what i can tell. > How it works is like this: a large organization obtains a large block of = IPv6 address space, either as a very large PI block or by becoming a local = internet registry (LIR) and getting a regular LIR assignment directly from = one of the five regional registries. However, rather than advertising that = block in BGP as a single prefix, or perhaps a handful of prefixes, like an = ISP would, they subdivide this block within the organization and then many = subunits advertise subprefixes though different ISPs. The aggregate may or = may not be advertised. > sure, this is what enterprises are sort of forced into in the v6 world. They MAY have a contiguous backbone behind their ISP links, or may not. They MAY have ASN for some/all of their sites, they may not. They have v6 address space for each office (say a /48 for instance from a larger /) and they've gotten agreement from their various ISPs to announce the 48's to the world. > The advantage to the organization is that they have provider independent = address space that they'll never have to renumber out of, as well as having= a single prefix that identifies all of the organization, which makes filte= ring easy. > yup > There seem to be two types of organizations that do this: geographically = dispersed ones that advertise subprefixes in different locations, such as m= ultinationals, and organizations with very independent subunits but with mo= re limited geographical scope, such as national governments. > ok, not clear how the type-o-org matters here. "People do this, see the routing table." > This practice, especially if/when it becomes more common, presents two ch= allenges: > > 1. Large numbers of prefixes may show up in the global routing table. For= instance, there is a number plan for all of the German government, which c= ould potentially inject more than 5000 municipality prefixes into the globa= l IPv6 routing table. > ok <1% growth. > 2. Filtering. If people want to avoid large numbers of deaggregates in th= eir routing tables, they may employ some kind of filtering, especially if t= he deaggregates are very long prefixes. This means that packets are no long= er reliably delivered to the place announcing a more specific prefix. > ok, maybe.. but this depends a bunch on what upstream setup is used as well. It seems that if there is arbitrary filtering other solutions will work themselves out (announce aggregate, keep all sites connected to a single/small-set of isps, etc). it's messy, but... > Ideally, a set of best practices would be developed that strike a good ba= lance between the needs of large organizations and the needs of the global = routing system, and allow everyone to predict the consequences of different= kinds of behavior and thus avoid unpleasant surprises. > i feel like we sort of have that already, or we know how the global table works and people live within those constraints. > These are some of the things that could go into such best practices: > > - A well-understood maximum prefix length for IPv6, similar to /24 for IP= v4. > do we want to draw that line in the sand though? I think so far 'let operations folks work that out' has worked out pretty well. There's no official standard in v4, why would we want one in v6? > - An understanding of how the service providers that provide connectivity= to multiple subunits of a large organization can work together in order to= maximize availability and minimize costs for the organization, the service= providers and other network operators. > "cannibalize customers from your neighbors" isn't what you're looking for here, eh? I think TODAY there isn't a problem (nothing is broken, yet) so it's a bit hard to talk about the 'right' answer here. (sure we could take a guess, but...) > - A way to provide a point of last resort where traffic for the aggregate= can be sent to if more specifics are filtered. > this, to me, is the 'headquarters' facility announces the aggregate and maintains a tunneled path to their subunits out over the world. you could slice/dice this in a number of other ways, clearly. I'm not sure more complexity is good though. > - A set of communities that indicate whether a prefix is a more specific = that is covered by an aggregate and/or is safe to filter without loss of co= nnectivity. > so, add communities to global routes, because people don't strip these in ingress as a matter of best practice? (if you don't you REALLY should consider it, i think) > - A set of communities that indicate geographical origin of prefixes so r= emote more specific prefixes can be filtered while local prefixes are kept. > we ran over the geo-prefix rat in SIDR, I don't know that running over it again is especially great for time management. (see terry manderson's geo-data-rpki presentations/drafts, in stockholm and 1/2 meetings after/around then) > - Guidelines for reserving address space in address plans. Is it better t= o have free space reserved so existing prefixes can grow, or keep reserved = space together so tight prefix length filters are possible and reserved spa= ce isn't broken up into small pieces? > uhm... this is a bit of a religious debate isn't it? You'd also be imposing the 'one true way' on people who generally have issues with that sort of thing. Not to mention how does excel manage ipv6 prefix splitting? :) > Please note that I'm crosspositing this to v6ops and grow initially. If t= he chairs have any guidance on which working group is more appropriate for = this discussion, please let us know and we can drop the other one. > > Also note that I haven't been following discussions in both wgs recently,= so if this has been discussed previously, my apologies. > > Last but not least, this treads on RIR policy. But in my opinion, this is= foremost a technical matter with global implications and as such is best d= iscussed within the IETF rather than in the five respective policy developm= ent forums. i don't see it hitting RIR policy so much, sinc ethe RIR's absolved themselves of 'routability' of prefixes long ago. 'if you can't reach your shiney new allocation it ain't ARIN's problem'. -chris > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From nobody Wed Oct 15 22:43:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1831A026E; Wed, 15 Oct 2014 22:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHzgESvDbuUU; Wed, 15 Oct 2014 22:43:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 610301A86F3; Wed, 15 Oct 2014 22:43:29 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9G5fmZq013027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Oct 2014 22:41:48 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9G5fmZq013027 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1413438109; bh=22HPwOwtaLd0/tn+kro7+mY61GI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=j9LUkWLzYObsPy89e0IRHd3b9TU+nqpVRc9zprtV6hd++Nuz+6ZjeVMAmNnKIhoLa RWSg66Ytj1rQ9PvS5bBtED6Pn+axduQm79HieVYUF1R6/IkX/UjlYg1GSHqZ9Unmxl TACGZQHRqQvoEV1kKjJokH80/qSWXLrg780OyoRI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: Date: Wed, 15 Oct 2014 22:41:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DB6393A-D039-4998-AC07-6868BEE5B20B@delong.com> References: To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 15 Oct 2014 22:41:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mucGK31nze5eEiRcOX7nYa09g0I Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 05:43:31 -0000 On Oct 15, 2014, at 05:29 , Iljitsch van Beijnum = wrote: > We are all familiar with PA (provider aggregatable) and PI (provider = independent) address space. But it turns out a new type of IPv6 address = space is starting to show up, which I'll call organization = deaggregatable (OD) address space (until someone suggests a better = name). >=20 > How it works is like this: a large organization obtains a large block = of IPv6 address space, either as a very large PI block or by becoming a = local internet registry (LIR) and getting a regular LIR assignment = directly from one of the five regional registries. However, rather than = advertising that block in BGP as a single prefix, or perhaps a handful = of prefixes, like an ISP would, they subdivide this block within the = organization and then many subunits advertise subprefixes though = different ISPs. The aggregate may or may not be advertised. >=20 > The advantage to the organization is that they have provider = independent address space that they'll never have to renumber out of, as = well as having a single prefix that identifies all of the organization, = which makes filtering easy. >=20 > There seem to be two types of organizations that do this: = geographically dispersed ones that advertise subprefixes in different = locations, such as multinationals, and organizations with very = independent subunits but with more limited geographical scope, such as = national governments. >=20 > This practice, especially if/when it becomes more common, presents two = challenges: >=20 > 1. Large numbers of prefixes may show up in the global routing table. = For instance, there is a number plan for all of the German government, = which could potentially inject more than 5000 municipality prefixes into = the global IPv6 routing table. How would this differ from 500 multihomed municipal governments getting = PI space? > 2. Filtering. If people want to avoid large numbers of deaggregates in = their routing tables, they may employ some kind of filtering, especially = if the deaggregates are very long prefixes. This means that packets are = no longer reliably delivered to the place announcing a more specific = prefix. I would think that if/when this becomes an issue, the organizations = engaging in the behavior will take the necessary steps to get the = traffic they care about. Seems to me that this is the desirable situation as some form of = equilibrium will be reached where organizations limit their deaggregates = to something they can get adequately routed and operators will limit = their routing tables to something they can handle. > Ideally, a set of best practices would be developed that strike a good = balance between the needs of large organizations and the needs of the = global routing system, and allow everyone to predict the consequences of = different kinds of behavior and thus avoid unpleasant surprises. Hard to develop a set of best practices for this that would have any = real longevity. The boundary between usable routing table maximum size = and oblivion is a moving target. We don't have sufficient experience = with this problem in the IPv6 space to really know how far it will = extend. > These are some of the things that could go into such best practices: >=20 > - A well-understood maximum prefix length for IPv6, similar to /24 for = IPv4. I don't think this helps. The /48 seems to pretty much already be there = as a de-facto answer to this question. However, 2^45 routes (unicast is = a /3) is probably beyond the capability of any router yet available. > - An understanding of how the service providers that provide = connectivity to multiple subunits of a large organization can work = together in order to maximize availability and minimize costs for the = organization, the service providers and other network operators. If you can find answers to this question, they would certainly be = beneficial to the community, but I think that scope extends well beyond = the deaggregation issue described here and that would be only one aspect = of such a document. > - A way to provide a point of last resort where traffic for the = aggregate can be sent to if more specifics are filtered. There are many ways to do this. Ranging from the simple build a network = of tunnels between your sites and anchor the aggregate as a less = specific from a few key sites to much more elaborate solutions. These = solutions seem to me to be reasonably well known to most network = engineers. I don't think a document rehashing them in yet another place = is of any particular benefit. > - A set of communities that indicate whether a prefix is a more = specific that is covered by an aggregate and/or is safe to filter = without loss of connectivity. This seems like a reasonably good idea... If you write up an ID for = v6ops to do this one simple thing, I would support it. > - A set of communities that indicate geographical origin of prefixes = so remote more specific prefixes can be filtered while local prefixes = are kept. Since geography !=3D topology (and dramatically so in some cases), I = think this would do more harm than good in many cases. > - Guidelines for reserving address space in address plans. Is it = better to have free space reserved so existing prefixes can grow, or = keep reserved space together so tight prefix length filters are possible = and reserved space isn't broken up into small pieces? There are many documents describing various ways to do sparse allocation = and allocation by bisection for IPv6. I have written some that have = achieved some distribution. RIPE has one or two at least. I don't think = having the IETF rewrite yet another one is particularly useful. > Please note that I'm crosspositing this to v6ops and grow initially. = If the chairs have any guidance on which working group is more = appropriate for this discussion, please let us know and we can drop the = other one. The one tidbit that strikes me as useful is, IMHO, something that = belongs in v6ops. YMMV. > Last but not least, this treads on RIR policy. But in my opinion, this = is foremost a technical matter with global implications and as such is = best discussed within the IETF rather than in the five respective policy = development forums. I don't think anything proposed above really treads on RIR policy. It = makes recommendations for utilization of address space by end-user = organizations, but does not make any attempt to set policy for how those = addresses are acquired or what amount of space should be granted in = response to such a request. I'm pretty sure I'm one of the most RIR-oriented people on the planet in = any such discussion, so I think you're safe in that regard. (I was, = after-all, the leader of the original RIR rebellion against oppressive = IETF policies regarding PI for end-users in IPv6). Owen From nobody Wed Oct 15 23:53:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5E61A036C; Wed, 15 Oct 2014 23:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7wRCyWCEKum; Wed, 15 Oct 2014 23:53:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5A51A0369; Wed, 15 Oct 2014 23:53:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E987DA1; Thu, 16 Oct 2014 08:53:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413442418; bh=K6ZleZyn8+485eJ0FtSmL+FmKRLnCMSM4rN/yjjvjkg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=V/64vD8wyvjy3cTN1z01hgUIAQhyAqvTyrTMBwE0gyZWwwVeorYDha9MWAVEIkoFr fnuZHhAp1YYSJN//pm9mRdPIRYDVtUBCIu+eP83LAASpDa1cm9k3YtFRkqbNWL5FVh w4oTcHc/kixmLTP9qKOiPARdzM2Hdl9oBhiYzPGY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E2F809F; Thu, 16 Oct 2014 08:53:38 +0200 (CEST) Date: Thu, 16 Oct 2014 08:53:38 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <543EB83E.9010301@gmail.com> Message-ID: References: <543E6B66.5050803@inex.ie> <543EB83E.9010301@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UH8G1o1ZK6R2PcqKlhtVg0XnVSk Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 06:53:42 -0000 On Thu, 16 Oct 2014, Brian E Carpenter wrote: > Not to hundreds, but I would expect a large multinational with > operations in most countries to deaggregate down to something close to > one per country, to keep its traffic patterns reasonably local. That's > nothing new. Breakouts done from PA space is normal in ARIN-land, but it's less common in RIPE land for instance. We need to make sure renumbering is easy, otherwise we're going to see more and more entries going into the DFZ BGP table. The /24 boundary and IPv4 scarcity was a natural hindrance for this in IPv4, we need to create equal "hindrance" for de-aggregation in IPv6 otherwise I fear that we're going to sit with millions of routes in IPv6 DFZ in 10-20 years. Unless of course this is a cheaper way of handling things than making renumbering possible. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Oct 16 02:41:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1151A6FE9; Thu, 16 Oct 2014 02:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1ZnICz2zEet; Thu, 16 Oct 2014 02:41:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB061A904D; Thu, 16 Oct 2014 02:41:09 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5562:b8bc:1f02:25a8] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9G9cx1h059811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 11:38:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 16 Oct 2014 11:40:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/05V1iGMDutGzHd9psnfbZeAk93U Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:41:14 -0000 On 16 Oct 2014, at 0:04, Christopher Morrow = wrote: >> This practice, especially if/when it becomes more common, presents = two challenges: >> 1. Large numbers of prefixes may show up in the global routing table. = For instance, there is a number plan for all of the German government, = which could potentially inject more than 5000 municipality prefixes into = the global IPv6 routing table. > ok <1% growth. What do you mean? >> Ideally, a set of best practices would be developed that strike a = good balance between the needs of large organizations and the needs of = the global routing system, and allow everyone to predict the = consequences of different kinds of behavior and thus avoid unpleasant = surprises. > i feel like we sort of have that already, or we know how the global > table works and people live within those constraints. I've only heard from a few people who do this / want to do this so far, = but from what I hear they really want some clarity in this area. = Spending a lot of time and money to set all of this up and then = discovering your prefixes are filtered is rather suboptimal. Iljitsch From nobody Thu Oct 16 02:44:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455DE1A19FE; Thu, 16 Oct 2014 02:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2IjirTlETVZ; Thu, 16 Oct 2014 02:44:02 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE051A19F6; Thu, 16 Oct 2014 02:44:02 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5562:b8bc:1f02:25a8] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9G9ejiP059851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 11:41:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 16 Oct 2014 11:43:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> References: To: v6ops@ietf.org, grow@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qzvFl16X8NIM-lT8dNGC50K079s Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:44:06 -0000 Let me address a few points that were brought up by different people. Renumbering: We had great plans for making renumbering easy in the early days of = IPv6. Remember A6 records and bitlabels in the DNS? But none of that = went anywhere. The problem isn't so much that we can't push a prefix = down the network or update the DNS (although both of these still have = challenges associated with them), but that addresses tend to get = hardcoded all over the place, starting with firewalls all the way up to = homegrown applications. I don't think renumbering addresses this issue, = although it could help steer some smaller organizations away from PI. A prefix length limit for the IPv6 DFZ: Someone mentioned that this didn't work in IPv6. When Sprint decided to = make that /18, that didn't really work. But there's a de facto /24 limit = that everyone understands. With IPv6, that would translate into a /48. = Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop = against accidental/malicious IPv6 routing table explosion this doesn't = help. Even exploding a /28 or so into individual /48s would kill the = IPv6 DFZ. What COULD work is to have prefix length limits depending on the = allocation size by the RIRs. Something like: 2100::/16 -> /48 2200::/16 -> /32 2200::/15 -> /29 However, for this to work well the RIRs would have to group allocations = of the same size into separate blocks, with the result that it would no = longer be possible to reserve space to grow an allocation. (Things like = allocating a /48 but reserving a /44 reduce the opportunities for prefix = length filtering because now the strictest filter you can make allows 16 = x as many prefixes worst case than average case. The worst and average = case need to be as close together as possible.) I'd say that allowing two or three extra bits for traffic engineering = for PA blocks would be good. So for the part of the IPv6 space where = /29s are allocated, allow /31s or /32s. As traffic engineering incoming = traffic by deaggregation requires that different parts of the aggregate = all generate similar levels of incoming traffic, this wouldn't usually = work for organizations using PI so I'd say don't allow deaggregating = below /48. Geographic communities: I know this is controversial. "Topology ain't geography". Actually, most = of the time there is a significant correlation. If all German cities = inject a more specific, do you really need to hear those in Tokyo or = Seattle? Just send the traffic to Europe as per the aggregate and let = them figure it out there. Compiling a list of communities that identify regions/countries/cities = would allow for experimentation in this place without any downsides that = I can see. Don't like this? Filter the communities. There's a handy list = that you can copy and paste into your filter. Injecting an aggregate as a point of last resort: I think this can be done today and probably is done today. But a = document describing how to do it would probably be helpful. I'm thinking = along the following lines: The AoLR (Aggregate of Last Resort) service would entail a service = provider announcing the aggregate without necessarily providing = connectivity towards all the places announcing more specifics covered by = the aggregate. So if ISP A announces the AoLR and ISP B provides = connectivity to a more specific, ISP C would send traffic to A as per = the aggregate and then A would immediately hand it over to B. So as part of the AoLR service, a service provider would agree to accept = all more specifics that fall under the aggregate (up to an agreed prefix = length) from all the networks providing connectivity towards those more = specifics. This would be an attractive service for tier-1s to provide, = because presumably, they peer with everyone everywhere, so in the case = where they receive the traffic over peering and need to deliver it to = another service provider over peering, this could probably happen in the = same city, so they wouldn't carry the traffic over long distances. But = the (sub-)organization(s) in question still gets to buy connectivity = from a wider range of smaller service providers. In practice an organization would contract two or more service providers = to provide the AoLR service for redundancy. Wouldn't they just get PI: Yes. That's why I think it's important to find a way to give these = organizations what they need in a way that keeps the IPv6 DFZ growth on = a workable trajectory. AS numbers: BGP assumes that an AS always has internal connectivity. This can be = accomplished using tunnels, but it's much better to simply have separate = AS numbers for each subunit. Would it make sense to allocate ranges of = AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's = no lack of numbers, and this would allow tools to be developed to work = on CIDR-like AS number ranges in the future. From nobody Thu Oct 16 03:43:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7430F1ACFF5; Thu, 16 Oct 2014 03:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W44rJJ4RvA3H; Thu, 16 Oct 2014 03:43:34 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0991ACFFA; Thu, 16 Oct 2014 03:43:33 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9GAhUgO050301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 11:43:30 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <543FA152.4080907@foobar.org> Date: Thu, 16 Oct 2014 11:43:30 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum , v6ops@ietf.org, grow@ietf.org References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-ico2IkCDV4-McL7cIvsqi_5xwk Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 10:43:36 -0000 On 16/10/2014 10:43, Iljitsch van Beijnum wrote: > Yes. That's why I think it's important to find a way to give these > organizations what they need in a way that keeps the IPv6 DFZ growth on > a workable trajectory. This brings up a more general issue: IPv6 dfz growth for the last several years has been linear. > https://ripe68.ripe.net/presentations/156-2014-05-12-bgp2013.pdf Even if the curves go the wrong way for a couple of years, there isn't an issue of much concern here, at least in the short to medium term, and probably not the longer term either. Nick From nobody Thu Oct 16 06:18:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4567E1A1BA3; Thu, 16 Oct 2014 06:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz4gpolqypAD; Thu, 16 Oct 2014 06:18:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366A11A1BA0; Thu, 16 Oct 2014 06:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1413465526; x=1414675126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=q96tiCibrSArwwp4CXNjQLTudCP0HYEB4xuTFZntR/E=; b=DRJ7vflvsBlGzNkJ314tVByBGPLvANe3lRgmF6IMcdJFaqcb4a4IMYYH 1HRGyB1s7xgI/jOR9Hx23SHgwwkTXnfrgMAIB3uoyhY36Mg8dby2hWzJM pyqr0qyf+UlfL0gOgsrU46sogXhW4aLxn3W3BXK1yoh+4FPKVK+xY7fBl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOvEP1StJV2b/2dsb2JhbABbgw6BL9NqAoEUFgF9hAMBAQQnUhACAQhGMiUCBAENBYg+ykgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkBozB4RLAQSLI4RAghyLWJYcg3dsgQgkHIECAQEB X-IronPort-AV: E=Sophos;i="5.04,732,1406592000"; d="scan'208";a="87481529" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 16 Oct 2014 13:18:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9GDIj8Q015856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 13:18:45 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.127]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 08:18:44 -0500 From: "Alvaro Retana (aretana)" To: Ted Lemon , Iljitsch van Beijnum Thread-Topic: [GROW] [v6ops] Deaggregation by large organizations Thread-Index: AQHP6IqzJ0bq5e0sx0KpNLmfoN9dGpwyxxcA Date: Thu, 16 Oct 2014 13:18:44 +0000 Message-ID: References: <5B13739D-5BFD-467C-8DF0-D391508EB5C0@nominum.com> In-Reply-To: <5B13739D-5BFD-467C-8DF0-D391508EB5C0@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <456526549296BE41AFC508FC513085C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iY30z23gH-nUU0ffCfBSEyCSWBI Cc: "v6ops@ietf.org" , "grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:18:49 -0000 On 10/15/14, 11:14 AM, "Ted Lemon" wrote: >On Oct 15, 2014, at 7:29 AM, Iljitsch van Beijnum >wrote: >> However, rather than advertising that block in BGP as a single prefix, >>or perhaps a handful of prefixes, like an ISP would, they subdivide this >>block within the organization and then many subunits advertise >>subprefixes though different ISPs. The aggregate may or may not be >>advertised. > >Yuck. Has anybody done an analysis of how this works with RPKI? Seems >like an obvious attack surface if the RPKI isn't present or isn't done >right. Yup. I don=B9t have an analysis, but it is a common discussion point when creating ROAs: what should the ROA cover? Both the max-length of the advertisement and the origin ASNs could result in a =B3validated=B2 attack. On one hand, creating ROAs that cover exactly what is advertised reduces the surface, but it can result in a higher operational cost and maybe some hassle if something different (like a more specific) needs to be advertised *right now*. OTOH, creating a more =B3flexible=B2 ROA (2100::5/= 32 -> /48, for example) provides more operational flexibility, but it may in fact open up the door to =B3valid=B2 announcements. I=B9ve worked with LACNIC in some of their RPKI deployments in Latin Americ= a and I suspect that a significant number of people opt for the =B3flexible ROA=B2..even after we explain the risks. LACNIC may have some insight in what is being created right now (with the caveat of course that there=B9s just one place in the world that is in fact filtering). Alvaro. From nobody Thu Oct 16 07:11:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56471A1A70; Thu, 16 Oct 2014 07:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV7sjSidVp_o; Thu, 16 Oct 2014 07:11:44 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572421A1A37; Thu, 16 Oct 2014 07:11:43 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so2814588lbi.39 for ; Thu, 16 Oct 2014 07:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=swMeA9grUx06Ljtj2Pcpcz8kKPET8I6JLTVFmrZ6V1I=; b=OrI0Fe3HFHgrP8UifWBwkayTDjbWkclC+QpjJe5sYc0MCn/dD2KTZY8g0EQjUrTnF/ PyNhj8rUN1cUfQx0NmqlOfogJwTDy7dVKzyyY06rsAb0ZzYcbfZdQJIY3b1B192HLjWy KwBvTChVxIQRanduOJdaolkcxGLtZI16mrGwhOL8S5SpdgNFOQ4SJeTl7MHggmFYTJyx TsNC17dpxdPCyNILR8OTIwwkLFi4mlYIb2txURjw6axvQGhY3h5G/qcBX30Y7n2VfpRJ mTDk2+H+RxmNO/53mBnoYalALUE4gnQo6qPBrUKMG8zqSpV4YttBkMMi03hmzq8jk898 oOvg== MIME-Version: 1.0 X-Received: by 10.152.45.105 with SMTP id l9mr1859321lam.69.1413468701582; Thu, 16 Oct 2014 07:11:41 -0700 (PDT) Received: by 10.152.88.17 with HTTP; Thu, 16 Oct 2014 07:11:41 -0700 (PDT) In-Reply-To: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> Date: Thu, 16 Oct 2014 10:11:41 -0400 Message-ID: From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SdRB0iH4LpHeafr60_fLilzy5NQ Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:11:46 -0000 On Thu, Oct 16, 2014 at 5:40 AM, Iljitsch van Beijnum wrote: > On 16 Oct 2014, at 0:04, Christopher Morrow wrote: > >>> This practice, especially if/when it becomes more common, presents two = challenges: > >>> 1. Large numbers of prefixes may show up in the global routing table. F= or instance, there is a number plan for all of the German government, which= could potentially inject more than 5000 municipality prefixes into the glo= bal IPv6 routing table. > >> ok <1% growth. > > What do you mean? 5000 is less than 1% of 540k... (I think, math is hard and all that busines= s) for the (since someone else shot me a note behind the scenes about this as well) forseable future we'll have v4 + v6 to deal with in a DFZ device, so call it even at 540k routes today in the table, your 5k extra is less than 1% of that. >>> Ideally, a set of best practices would be developed that strike a good = balance between the needs of large organizations and the needs of the globa= l routing system, and allow everyone to predict the consequences of differe= nt kinds of behavior and thus avoid unpleasant surprises. > >> i feel like we sort of have that already, or we know how the global >> table works and people live within those constraints. > > I've only heard from a few people who do this / want to do this so far, b= ut from what I hear they really want some clarity in this area. Spending a = lot of time and money to set all of this up and then discovering your prefi= xes are filtered is rather suboptimal. > So, some folk thought: "Hey, not announcing my aggregate and not providing connectivity between the aggregate announcement and the little islands I created is a grand plan!" and were surprised when things went badly... Do you want a document that says: "Sure, announce your aggregate as a bunch of de-aggs, and be sure there's a fall back ASIDE FROM ::/0 which has reachability to your islands, if you want to be sure to not run afoul of random isp route filtering." From nobody Thu Oct 16 07:37:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59461A1AF2 for ; Thu, 16 Oct 2014 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix1Vncv87u8J for ; Thu, 16 Oct 2014 07:37:46 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416201A1A7F for ; Thu, 16 Oct 2014 07:37:44 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5673B60792 for ; Thu, 16 Oct 2014 16:37:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2C757602FF for ; Thu, 16 Oct 2014 16:37:43 +0200 (CEST) Received: (qmail 92260 invoked by uid 1007); 16 Oct 2014 16:37:43 +0200 Date: Thu, 16 Oct 2014 16:37:43 +0200 From: Gert Doering To: Christopher Morrow Message-ID: <20141016143743.GC31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JKGQip0PdKrv0BWRssh81rGVjaA Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:37:48 -0000 Hi, On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote: > So, some folk thought: "Hey, not announcing my aggregate and not > providing connectivity between the aggregate announcement and the > little islands I created is a grand plan!" and were surprised when > things went badly... > > Do you want a document that says: > "Sure, announce your aggregate as a bunch of de-aggs, and be sure > there's a fall back ASIDE FROM ::/0 which has reachability to your > islands, if you want to be sure to not run afoul of random isp route > filtering." A strong message to that extent would be good :-) - coupled with some recommendations how the conflicting goals ("I want all ISPs in my neighbourhood to use optimal routing" vs. "someone in Asia might not be interested in all in 5k routes for german municipality") could be solved. I get that question fairly often from "largish networks", and so far, I always have to answer "there is no routing police, so it's hard to say what is allowed on the Internet and what not" - which is a humorous way to say "there is no consensus here what consists 'good' and 'responsible'"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Oct 16 07:45:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984321A1BB4; Thu, 16 Oct 2014 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3cNmpnda6s1; Thu, 16 Oct 2014 07:45:25 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45F31A1BA9; Thu, 16 Oct 2014 07:45:24 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so2792579vcb.17 for ; Thu, 16 Oct 2014 07:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hvkL3deYj8F2qyrWFvLwOeD/vC2Xu8FjEE33zT1EPpE=; b=p8QYnSv9eXn2wRvghj9LwUuzjA6b/ckQ2xhcKhmEn+PnQbHJdHBxh2cdZf+AUpU31F EvnEc7RaC5jwOuPefzirMf2qWZhwVUOEgh9aa/7ZJzl8k979vBrEcnSyG6ey9B645fB9 8LQrSYQXr2AobODHVJsx8jSfwZda57MGOpqcSTCb5jzss9ClYVcVgzxTtjgvlFFsQvku tN23vn+7qUHC/MgGNOQQaIM6O46lWYCB0kaO6utp1S/CE7ygXg/NmqmUNpx9R+Yko/Zk EjX7lrYOG1QQt5tFQ3xEY5ehUYAkP2DAozyEf2cOisv0tXtnsnpO5x2KX5wK+mq0VOba x6Ow== MIME-Version: 1.0 X-Received: by 10.52.34.42 with SMTP id w10mr1194665vdi.57.1413470723927; Thu, 16 Oct 2014 07:45:23 -0700 (PDT) Received: by 10.220.186.193 with HTTP; Thu, 16 Oct 2014 07:45:23 -0700 (PDT) In-Reply-To: <20141016143743.GC31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> Date: Thu, 16 Oct 2014 10:45:23 -0400 Message-ID: From: Christopher Morrow To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VX6iCCdG0dK_f4Kc_kJqgRxCnlE Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:45:26 -0000 On Thu, Oct 16, 2014 at 10:37 AM, Gert Doering wrote: > Hi, > > On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote: >> So, some folk thought: "Hey, not announcing my aggregate and not >> providing connectivity between the aggregate announcement and the >> little islands I created is a grand plan!" and were surprised when >> things went badly... >> >> Do you want a document that says: >> "Sure, announce your aggregate as a bunch of de-aggs, and be sure >> there's a fall back ASIDE FROM ::/0 which has reachability to your >> islands, if you want to be sure to not run afoul of random isp route >> filtering." > > A strong message to that extent would be good :-) - coupled with > some recommendations how the conflicting goals ("I want all ISPs in > my neighbourhood to use optimal routing" vs. "someone in Asia might > not be interested in all in 5k routes for german municipality") > could be solved. > ok, perhaps iljitsch can drop some text into a document so we can get a good read going and decide whether or not GROW wants to spend cycles on it? The problem exists in v4 and v6 and likely will persist in whatever comes next. It's directly related to routing operations work on the global intertubes, so it SEEMS like GROW is the 'right place' to discuss this... we can't go anywhere without text and a draft though. > I get that question fairly often from "largish networks", and so far, > I always have to answer "there is no routing police, so it's hard to > say what is allowed on the Internet and what not" - which is a humorous > way to say "there is no consensus here what consists 'good' and > 'responsible'"... I sort of don't want there to be 'routing police' though :( In a way this whole debate sounds like something a 'cisco training class' (or other example) would have covered, or should cover. I suppose it's fairly experiential at this point though. From nobody Thu Oct 16 07:59:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DE91A1BF2 for ; Thu, 16 Oct 2014 07:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoVDBaYxNWd4 for ; Thu, 16 Oct 2014 07:59:34 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DCC1A1BC0 for ; Thu, 16 Oct 2014 07:59:33 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B50B160352 for ; Thu, 16 Oct 2014 16:59:31 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8139160139 for ; Thu, 16 Oct 2014 16:59:31 +0200 (CEST) Received: (qmail 97967 invoked by uid 1007); 16 Oct 2014 16:59:31 +0200 Date: Thu, 16 Oct 2014 16:59:31 +0200 From: Gert Doering To: Christopher Morrow Message-ID: <20141016145931.GE31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E+PR0/1ruOTysuoe" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RTCSK45CtLiQTGtTYb72TG8s1cw Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:59:38 -0000 --E+PR0/1ruOTysuoe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Oct 16, 2014 at 10:45:23AM -0400, Christopher Morrow wrote: > > A strong message to that extent would be good :-) - coupled with > > some recommendations how the conflicting goals ("I want all ISPs in > > my neighbourhood to use optimal routing" vs. "someone in Asia might > > not be interested in all in 5k routes for german municipality") > > could be solved. >=20 > ok, perhaps iljitsch can drop some text into a document so we can get > a good read going and decide whether or not GROW wants to spend cycles > on it? That would be nice (as I see the problem but have no cycles to write something useful). > The problem exists in v4 and v6 and likely will persist in whatever > comes next. It's directly related to routing operations work on the > global intertubes, so it SEEMS like GROW is the 'right place' to > discuss this... we can't go anywhere without text and a draft though. It seems to be made worse by the fact that "this" can be done more easily with IPv6, as you just can't get enough v4 space to subdivide it into 5000 globally visible prefixes today - and those entities that discover the "must have reliability! must have independence!" mantra *now* will hit the v6 space... (given that I see this argument in this dimension more often from governmental structures who have been hiding behind single-IPv4-NAT so far). > > I get that question fairly often from "largish networks", and so far, > > I always have to answer "there is no routing police, so it's hard to > > say what is allowed on the Internet and what not" - which is a humorous > > way to say "there is no consensus here what consists 'good' and > > 'responsible'"... >=20 > I sort of don't want there to be 'routing police' though :( In a way > this whole debate sounds like something a 'cisco training class' (or > other example) would have covered, or should cover. I suppose it's > fairly experiential at this point though. I *do* want a routing police, in the sense that "the operator community" agrees on what is considered "good" and "bad" behaviour, so end users can ask someone (me, Iljitsch, ...) what to do in their network planning, and we can tell them - if you do *this*, it's "guaranteed" to work - if you do *that*, you can be sure that you will be filtered while today, I have to tell them - well, today it is likely to work, but it might stop working tomorrow, and there is no document that you could show around to those that break your connectivity to show them that "you are doing the right thin= g" ISPs develop their own guidelines on prefix-length filtering, some with better understanding on what they want to achieve, others by using 10 year old example documents for never-updated filters... So, yes, guidance, please :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --E+PR0/1ruOTysuoe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVD/dU99WwGXkzn/FAQI9oxAAmiOZy3vvE8LJvSYU3l8keVjtm5tPe/1n qBfAikwfvZV5TCiOdGKjrTJ2Ojw4IN9M3jo6TjNptwpp9nHacPleNlt9BkH+UDOL 4L4dpDkbarPciH5EK/65QuBPrrA5h+bxGsqilPHc/EZmJi1zuGzhjBVv++96/s4s pOI2p8dEzVORkRHPWAcncfqcPMzi0sot3LJA/lFKgf2z8PdSdd3581koHvmH832V JigAez9rp71Qk3AORF99fvK3bheLZvCrOJni9Cdl4w4YP65toxsRryo0+zfw2kXb UgLGmbRIcZbrHlZal/jsXYngVMPfO77Gx8I4aeLy8efMYjRDENZxyKGoVYQsrLUb 9UTfJXdBkWIExbTQiHrOCtMwW+BdJz/WLnnl1kN+wQhlV8ZyR8sSOKNd9TTlt4dZ W0n3/n8krmEFtzkMU47NECJGzVAklnCWQkqXJ3zlPbxp5ao5HVX7e6wVAnHzxcyW 2q4wlFFzpRmq3girTGcyqubBMSprf6FVXH+gi6OR8wjtPfGV7CpbmhaZrsai0Uan zn7cac9kMFP7ieY2JgywD8Y94pPvjB/gkKloCXdCW1SBHgiO+QgMcqmUADLSaK1I R90Zukkh5slU49iw5qAFUSdER1juUrk0XzzlP1OGXE2kaobjHJPlaXJTrgX05td2 qQVdzWC85M0= =lBU2 -----END PGP SIGNATURE----- --E+PR0/1ruOTysuoe-- From nobody Thu Oct 16 08:21:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917741A1BF4; Thu, 16 Oct 2014 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G7Bp6ewaNpx; Thu, 16 Oct 2014 08:20:50 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096AE1A1BC0; Thu, 16 Oct 2014 08:20:49 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so2987968lbg.14 for ; Thu, 16 Oct 2014 08:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0z89qqxScjReCiBUtpWo2m1Ear8fCavMT5ERJCQBDG8=; b=APu+EcIntC06Lsdc+mskwVrdOO3YzvuRE1XILCauxRWX4v/sUWGVuiL77HwQFDdpkW tYWLaf3qXRaWht8ckCYFc6BXGGEvpZ3HzAq3dGyT6SqkIO5BUBXPAeuCUul5PIQOKq99 CwiCmqHXa5D8QIyq2UDL33Z5pMV//sIhOsf6+bK/zbfy4LEAooAHbVg/hfcH0q4I0kEX xEnpedxLKy2lKtG35qB+cNySyefjLW2o5nwGNtFnfCLLIY4kDkCyxls0b0FlJvMMFtPl nc6VNHIlvoxuX3LyGazkaO0DnKCQQrp50YBk7ihN+DMbnxVstFTcIZXddYWKUmh0hUCg WTKg== MIME-Version: 1.0 X-Received: by 10.153.11.133 with SMTP id ei5mr2291514lad.75.1413472848218; Thu, 16 Oct 2014 08:20:48 -0700 (PDT) Received: by 10.152.88.17 with HTTP; Thu, 16 Oct 2014 08:20:48 -0700 (PDT) In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Date: Thu, 16 Oct 2014 11:20:48 -0400 Message-ID: From: Christopher Morrow To: Iljitsch van Beijnum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2w6utCLJCxUlvESqYxPhleNO4zw Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:20:54 -0000 (apologies for again not reformatting apple-mail->gmail issues) On Thu, Oct 16, 2014 at 5:43 AM, Iljitsch van Beijnum wrote: > Let me address a few points that were brought up by different people. > > Renumbering: I think the renumbering ship sailed, and like the titanic had a bad voyage. You seem to agree. > A prefix length limit for the IPv6 DFZ: > > Someone mentioned that this didn't work in IPv6. When Sprint decided to m= ake that /18, that didn't really work. But there's a de facto /24 limit tha= t everyone understands. With IPv6, that would translate into a /48. Obviously no router can hold 2^48 or 2^45 I suppose there's a question about: "Is a /24 a LAN (/64) or a SITE (/48)" to be answered still. I believe SITE works better, but :) prefixes, so as a backstop against accidental/malicious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s would kill the IPv6 DFZ. mostly this is from motherhood + apple-pie bgp neighbor configs though, right? (max-prefix in particular). > What COULD work is to have prefix length limits depending on the allocati= on size by the RIRs. Something like: > > 2100::/16 -> /48 > 2200::/16 -> /32 > 2200::/15 -> /29 This looks, to me, like the 'PA space is >=3D /32, PI >=3D /48' in each region's PA/PI splits... which ends up being fairly stable and fairly simple prefix-list/etc configs on devices, right? so that seems kind of sane even. I had thought the cymru folk had something like this in their templates: isn't what I was looking for, sadly...and is the only sort of ipv6 / route-filter related thing I quickly find on their site... perhaps some room for improvement in this area exists. Should that be an IETF action or 'get the defacto standards/bcop folk to update their docs based on the best shared wisdom' ? > > However, for this to work well the RIRs would have to group allocations o= f the same size into separate blocks, with the result that it would no long= er be possible to reserve space to grow an allocation. (Things like allocat= ing a /48 but reserving a /44 reduce the opportunities for prefix length fi= ltering because now the strictest filter you can make allows 16 x as many p= refixes worst case than average case. The worst and average case need to be= as close together as possible.) > my impression (and I stopped paying close attention to ARIN at least 2+ yrs ago) was that RIR's were allocating PA from one large (/23?) block per RIR and PI from a different... For my work-location-provider: 2620:0:1000::/40 - PI /40 2001:4860::/32 - PA /32 2607:F8B0::/32 - PA /32 doesn't delineate the difference between 2001:4800::/23 and 2600::/12 and 2620::/23 ... bummer. I suppose this though: is meant to delineate the differences as 'allocation blocks' vs 'assignment blocks'... (I didn't search the same sort of stuff out on ripe/apnic/etc...) > I'd say that allowing two or three extra bits for traffic engineering for= PA blocks would be good. So for the part of the IPv6 space where /29s are = allocated, allow /31s or /32s. As traffic engineering incoming traffic by d= eaggregation requires that different parts of the aggregate all generate si= milar levels of incoming traffic, this wouldn't usually work for organizati= ons using PI so I'd say don't allow deaggregating below /48. > sure, this gets into the above 'give me a default understanding of the iana -> rir ranges + RIR purposes (alloc/assign) and add +N bits for TE. It's not quite answering the other part of your question about: "What will the DE gov't do? how will they run their new shiney network such that they don't have reachability concerns?" > Geographic communities: > > I know this is controversial. "Topology ain't geography". Actually, most = of the time there is a significant correlation. If all German cities inject= a more specific, do you really need to hear those in Tokyo or Seattle? Jus= t send the traffic to Europe as per the aggregate and let them figure it ou= t there. > this argues for the DE gov't having 1 ISP's for all their cities and putting the aggregate into BGP as well with the more specifics no-export'd from the ISP, not for communities, which won't reliably make it across AS boundaries. > Compiling a list of communities that identify regions/countries/cities wo= uld allow for experimentation in this place without any downsides that I ca= n see. Don't like this? Filter the communities. There's a handy list that y= ou can copy and paste into your filter. > > Injecting an aggregate as a point of last resort: > > I think this can be done today and probably is done today. But a document= describing how to do it would probably be helpful. I'm thinking along the = following lines: > ok > The AoLR (Aggregate of Last Resort) service would entail a service provid= er announcing the aggregate without necessarily providing connectivity towa= rds all the places announcing more specifics covered by the aggregate. So i= f ISP A announces the AoLR and ISP B provides connectivity to a more specif= ic, ISP C would send traffic to A as per the aggregate and then A would imm= ediately hand it over to B. > > So as part of the AoLR service, a service provider would agree to accept = all more specifics that fall under the aggregate (up to an agreed prefix le= ngth) from all the networks providing connectivity towards those more speci= fics. This would be an attractive service for tier-1s to provide, because p= resumably, they peer with everyone everywhere, so in the case where they re= ceive the traffic over peering and need to deliver it to another service pr= ovider over peering, this could probably happen in the same city, so they w= ouldn't carry the traffic over long distances. But the (sub-)organization(s= ) in question still gets to buy connectivity from a wider range of smaller = service providers. > > In practice an organization would contract two or more service providers = to provide the AoLR service for redundancy. > this doesn't sound unreasonable, make txt pls appear in draft form, then email that to grow@ and see what debate happens there. > Wouldn't they just get PI: > > Yes. That's why I think it's important to find a way to give these organi= zations what they need in a way that keeps the IPv6 DFZ growth on a workabl= e trajectory. > > AS numbers: > > BGP assumes that an AS always has internal connectivity. This can be acco= mplished using tunnels, but it's much better to simply have separate AS num= bers for each subunit. Would it make sense to allocate ranges of AS numbers= to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of nu= mbers, and this would allow tools to be developed to work on CIDR-like AS n= umber ranges in the future. > it seems like the AS here is really not relevant, unless you were thinking that: "AS is a proxy for GEO data." (or AS =3D=3D SITE) One thought is that AS provides the mapping to 'authoritative entity for the routing policy surrounding/using the prefixes originated by the AS in question', so is it simpler to remember: "DE govt is AS65534" or "DE gov't could be one of 160 AS numbers" (a range might help, but ranges imply some idea about growth in the future. Would you have planned for RU to add Crimea?) The AoLR (or 'how to be an enterprise that participates in the global routing system') seems like a good start though. -chris From nobody Thu Oct 16 08:25:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3371A2119 for ; Thu, 16 Oct 2014 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATs2eiLxheXN for ; Thu, 16 Oct 2014 08:25:08 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C0F1A1C00 for ; Thu, 16 Oct 2014 08:25:07 -0700 (PDT) Received: from [2001:c08:3700:ffff::48d] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XemvB-000384-8N; Thu, 16 Oct 2014 17:24:57 +0200 Message-ID: <543FDA8D.6010301@si6networks.com> Date: Thu, 16 Oct 2014 11:47:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Fred Baker (fred)" , IPv6 Operations References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oklRXIZrKwRCvfCpiL7A7a7UAzQ Subject: Re: [v6ops] Preparing IETF 91 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:25:11 -0000 Hi, Fred, We'd like to request a slot for discussing: Filename: draft-gont-v6ops-ipv6-ehs-in-real-world. Presenters: Jen Linkova & Fernando Gont Thanks, Fernando On 10/06/2014 09:09 PM, Fred Baker (fred) wrote: > As I mentioned last week, Lee and I are pulling together an agenda for IETF 91. The drop-dead date for new or updated drafts is 27 October, and frankly it will work better if drafts arrive earlier - as we are looking for working group commentary on them. > > Current state of play: > > IESG: > Jul 31 draft-ietf-v6ops-enterprise-incremental-ipv6 > Sep 1 draft-ietf-v6ops-ipv6-roaming-analysis > > IETF Last Call: > Sep 26 draft-ietf-v6ops-mobile-device-profile > > Working Group Document updated since IETF: > Sep 18 draft-ietf-v6ops-design-choices > > Individual Submission updated since IETF: > Aug 24 draft-v6ops-pmtud-ecmp-problem > On list, Ray Hunter suggests someone write "a draft summarizing the ICMP PTB problem" > Sep 10 draft-gont-v6ops-ipv6-ehs-in-real-world > There has been some discussion on-list. > Sep 15 draft-anderson-v6ops-siit-dc-2xlat > No list commentary > Sep 18 draft-elkins-v6ops-multicast-virtual-nodes > Some commentary, not supportive > Sep 18 draft-wang-v6ops-xlat-prefix-discovery > A fair amount of discussion, mostly anti-NAT. > Sep 25 draft-ybai-v6ops-ipv6-for-openstack > no list commentary > Oct 5 draft-anderson-v6ops-siit-dc > Some list commentary > > Working Group Document NOT updated since IETF: > Jun 18 draft-ietf-v6ops-dhcpv6-slaac-problem > Jul 4 draft-ietf-v6ops-ula-usage-recommendations > > Individual Submission NOT updated since IETF: > Apr 7 draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node > Jul 3 draft-liu-v6ops-running-multiple-prefixes > Jul 4 draft-sun-v6ops-xlat-multi > Jul 4 draft-yourtchenko-chown-rupik-v6ops-dad-3x > Jul 20 draft-wang-v6ops-flow-label-refelction > Jul 21 draft-liu-v6ops-dhcpv6-slaac-guidance > > more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Oct 16 08:38:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E21A1BCC; Thu, 16 Oct 2014 08:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt4URGXSivKK; Thu, 16 Oct 2014 08:38:27 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27691A1BAE; Thu, 16 Oct 2014 08:38:27 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9GFc34F015472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 15:38:03 GMT (envelope-from joelja@bogus.com) Message-ID: <543FE66F.9020309@bogus.com> Date: Thu, 16 Oct 2014 08:38:23 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Gert Doering , Christopher Morrow References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> <20141016145931.GE31092@Space.Net> In-Reply-To: <20141016145931.GE31092@Space.Net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KaTt10DIjXVilQLhKdal5UVH2Cxo0bRu7" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p9YSH5vAMBnNW_HVRBt-0_uTxJo Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:38:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KaTt10DIjXVilQLhKdal5UVH2Cxo0bRu7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/16/14 7:59 AM, Gert Doering wrote: > Hi, >=20 > On Thu, Oct 16, 2014 at 10:45:23AM -0400, Christopher Morrow wrote: >>> A strong message to that extent would be good :-) - coupled with >>> some recommendations how the conflicting goals ("I want all ISPs in >>> my neighbourhood to use optimal routing" vs. "someone in Asia might >>> not be interested in all in 5k routes for german municipality") >>> could be solved. >> >> ok, perhaps iljitsch can drop some text into a document so we can get >> a good read going and decide whether or not GROW wants to spend cycles= >> on it? >=20 > That would be nice (as I see the problem but have no cycles to write > something useful). >=20 >> The problem exists in v4 and v6 and likely will persist in whatever >> comes next. It's directly related to routing operations work on the >> global intertubes, so it SEEMS like GROW is the 'right place' to >> discuss this... we can't go anywhere without text and a draft though. >=20 > It seems to be made worse by the fact that "this" can be done more > easily with IPv6, as you just can't get enough v4 space to subdivide > it into 5000 globally visible prefixes today - and those entities that > discover the "must have reliability! must have independence!" mantra > *now* will hit the v6 space... (given that I see this argument in this= > dimension more often from governmental structures who have been hiding > behind single-IPv4-NAT so far). The number of autonomous systems present in the internet is a good proxy for the number of organizations that find this necessary. It is not a proxy for the number of prefixes each of those ASes choose to advertise though somewhat less than half of those ASNs advertise one prefix only. http://www.cidr-report.org/cgi-bin/plot?file=3D%2fvar%2fdata%2fbgp%2fas2.= 0%2fbgp-as-count%2etxt&start=3D0&end=3D1413472455&width=3D0%2e9&height=3D= 0%2e3&with=3Dstep&ylabel=3DAS+Count >>> I get that question fairly often from "largish networks", and so far,= >>> I always have to answer "there is no routing police, so it's hard to >>> say what is allowed on the Internet and what not" - which is a humoro= us >>> way to say "there is no consensus here what consists 'good' and >>> 'responsible'"... >> >> I sort of don't want there to be 'routing police' though :( In a way >> this whole debate sounds like something a 'cisco training class' (or >> other example) would have covered, or should cover. I suppose it's >> fairly experiential at this point though. >=20 > I *do* want a routing police, in the sense that "the operator community= " > agrees on what is considered "good" and "bad" behaviour, so end users > can ask someone (me, Iljitsch, ...) what to do in their network plannin= g, > and we can tell them >=20 > - if you do *this*, it's "guaranteed" to work > - if you do *that*, you can be sure that you will be filtered >=20 > while today, I have to tell them >=20 > - well, today it is likely to work, but it might stop working tomorro= w, > and there is no document that you could show around to those that > break your connectivity to show them that "you are doing the right = thing" >=20 > ISPs develop their own guidelines on prefix-length filtering, some with= > better understanding on what they want to achieve, others by using 10 y= ear > old example documents for never-updated filters... >=20 > So, yes, guidance, please :-) >=20 > Gert Doering > -- NetMaster >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --KaTt10DIjXVilQLhKdal5UVH2Cxo0bRu7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ/5m8ACgkQ8AA1q7Z/VrIRLQCfWIzFHvoJ54WDiTeNUHG1aDIn MFcAnR0IHyFWOs2HspR6NEkvzzsgtLII =8QaC -----END PGP SIGNATURE----- --KaTt10DIjXVilQLhKdal5UVH2Cxo0bRu7-- From nobody Thu Oct 16 08:48:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CAC1A6FF2; Thu, 16 Oct 2014 08:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkxuAjd4hQsU; Thu, 16 Oct 2014 08:48:16 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795F81A6FF1; Thu, 16 Oct 2014 08:47:55 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:8c56:a593:2e64:be71] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9GFjUch061718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 17:45:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Iljitsch van Beijnum In-Reply-To: <543FA152.4080907@foobar.org> Date: Thu, 16 Oct 2014 17:47:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Mn5RqZC5PpHEryesUQM-aYQPw2U Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:48:18 -0000 On 16 Oct 2014, at 12:43, Nick Hilliard wrote: > This brings up a more general issue: IPv6 dfz growth for the last several > years has been linear. >> https://ripe68.ripe.net/presentations/156-2014-05-12-bgp2013.pdf Growth in IPv6 more specifics was 57% last year... From nobody Thu Oct 16 09:05:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738C61A8721; Thu, 16 Oct 2014 09:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA99192_UCdE; Thu, 16 Oct 2014 09:05:45 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500DF1A8724; Thu, 16 Oct 2014 09:05:45 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9GG578A062450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 17:05:27 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <543FECB3.9070600@foobar.org> Date: Thu, 16 Oct 2014 17:05:07 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> In-Reply-To: <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gvyAnXlTYy4RInRImep7f2SzJ4E Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:05:47 -0000 On 16/10/2014 16:47, Iljitsch van Beijnum wrote: > Growth in IPv6 more specifics was 57% last year... 1y is an interesting data point, but shouldn't form the basis for a new policy. What does the aggregate:more-specifics ratio look like over the last 5-8 years? Nick From nobody Thu Oct 16 09:21:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D61A7014; Thu, 16 Oct 2014 09:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKvAOnkzZ41W; Thu, 16 Oct 2014 09:21:32 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5601A872F; Thu, 16 Oct 2014 09:21:32 -0700 (PDT) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 39D4D1008871F; Thu, 16 Oct 2014 16:21:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1413476489; bh=NwhUznQzqUKXw3h1NygKffgDb1b/MElhR+7e+1Fyquw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=K8nUaxhary2/s2/wulB47qe3jsi1wkYzJrFwt0NQRBnxjbpKYoVP5o6aZtCJneKKl Cuh7uU66Yo5zMo+dGFkP5FKwDEh1XtKg1T6FlHgN2GaNTcOxpMwED9QtHEYN/NAMA6 oNHw/v6fgBx26ghTa/EprKPa1TSROcQ4Cbrh/i6T8Hf7oRHwkz0cTDVQ1JQYVtNtl5 Qtocf+tE8bzbzy/s+l6lk2TfKVqERIEwK7UxDqkiT99+M/ATjMyeleeNrsQeNmBCCu K2IGhYG2EQQPop/bJf8+ANjTyZJKkpL7bDCnhx7n8jOm/Fc+6IlEW79BSTkJ8HHqBS 30ok3uQb6crMQ== Message-ID: <543FF084.6010409@massar.ch> Date: Thu, 16 Oct 2014 18:21:24 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Christopher Morrow References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CX6VfZEjCxPSnDQ8eLoDpYcXS6A Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:21:38 -0000 On 2014-10-16 17:20, Christopher Morrow wrote: [..] > This looks, to me, like the 'PA space is >= /32, PI >= /48' in each > region's PA/PI splits... which ends up being fairly stable and fairly > simple prefix-list/etc configs on devices, right? so that seems kind > of sane even. You are looking for: http://www.space.net/~gert/RIPE/ipv6-filters.html "Update: 2002/09/25. Gert Dring: initial version." Folks have been using that for 12 years already... Greets, Jeroen From nobody Thu Oct 16 09:27:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A221A87AB; Thu, 16 Oct 2014 09:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ket8oclLPc20; Thu, 16 Oct 2014 09:26:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3227E1A876E; Thu, 16 Oct 2014 09:26:50 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:8c56:a593:2e64:be71] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9GGOPUL061933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2014 18:24:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Iljitsch van Beijnum In-Reply-To: <543FECB3.9070600@foobar.org> Date: Thu, 16 Oct 2014 18:26:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9193455D-4666-454B-981C-ABA3B1B42342@muada.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <543FECB3.9070600@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3BfkC8x9DYgztGFZJw5nQv8uSpo Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:26:57 -0000 On 16 Oct 2014, at 18:05, Nick Hilliard wrote: >> Growth in IPv6 more specifics was 57% last year... > 1y is an interesting data point, but shouldn't form the basis for a = new > policy. What does the aggregate:more-specifics ratio look like over = the > last 5-8 years? I haven't checked, but obviously the percentage growth was large and the = absolute growth small. But look at the v4 table. It's a mess, and we have no way to clean it = up. Fortunately we can just decommission IPv4 in the foreseeable future. = No such luck with IPv6, though, it'll be around for decades to come. And = the good thing is that there's so much address space that we CAN make = tradeoffs that will keep the routing table healthy, where we weren't in = the position to do that with IPv4. It's much better to spend some time = making sure we don't repeat the IPv4 mistakes and/or add some new ones = rather than wait 10 years and find ourselves in an untenable situation. Also, from the vantage point of someone who has all their prefixes = routed life is good, but there are also people who run into (the = possibility) of filtering. A clear message about what can and can't be = expected to work with IPv6 would help them a lot.= From nobody Thu Oct 16 09:46:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704E21A0121; Thu, 16 Oct 2014 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqrU1doB3tH7; Thu, 16 Oct 2014 09:45:52 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AA31A00FD; Thu, 16 Oct 2014 09:45:51 -0700 (PDT) Received: from mh1.ernw.net (unknown [IPv6:fd00:2001:0:d001::10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 0640515EC29; Thu, 16 Oct 2014 18:45:49 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id D8690461; Thu, 16 Oct 2014 18:45:48 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 37D25C4874; Thu, 16 Oct 2014 18:22:57 +0200 (CEST) Date: Thu, 16 Oct 2014 18:22:57 +0200 From: Enno Rey To: v6ops@ietf.org, grow@ietf.org Message-ID: <20141016162257.GH44748@ernw.de> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/embEzAmIyuuDzWufCEwV8yUYHlA Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:46:11 -0000 X-List-Received-Date: Thu, 16 Oct 2014 16:46:11 -0000 Hi, On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote: > > So, some folk thought: "Hey, not announcing my aggregate and not > providing connectivity between the aggregate announcement and the > little islands I created is a grand plan!" and were surprised when > things went badly... well, $FOLK might have good reasons to act in that way, based on their business models and network design. to put it equally bluntly, those folks wonder: "hey, we pay a hell lot of money to our uplink providers and they fail to deliver what we contracted, that is transporting our traffic". see the examples in https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu Oct 16 09:48:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38B61A0006; Thu, 16 Oct 2014 09:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOedHpDGrIph; Thu, 16 Oct 2014 09:48:08 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AADA1A015B; Thu, 16 Oct 2014 09:48:08 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9GGlfro065268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 17:48:01 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <543FF6AD.80703@foobar.org> Date: Thu, 16 Oct 2014 17:47:41 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <543FECB3.9070600@foobar.org> <9193455D-4666-454B-981C-ABA3B1B42342@muada.com> In-Reply-To: <9193455D-4666-454B-981C-ABA3B1B42342@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gpwqB44KKI5FyoQSfz92_m11r5c Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:48:11 -0000 On 16/10/2014 17:26, Iljitsch van Beijnum wrote: > I haven't checked, but obviously the percentage growth was large and the > absolute growth small. not obvious: please post data. Nick From nobody Thu Oct 16 09:56:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F721A0154; Thu, 16 Oct 2014 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPA2AR89ppL6; Thu, 16 Oct 2014 09:56:38 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0FE1A00E9; Thu, 16 Oct 2014 09:56:38 -0700 (PDT) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 633891008B2D0; Thu, 16 Oct 2014 16:56:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1413478595; bh=BfJm2YMMEYwWeeydv3SC8L59R8l2DEogrOAbZEbpOzI=; h=Date:From:To:Subject:References:In-Reply-To; b=edYslRITJGAPyZz89Sw0QHtimjB4sQw/aPdJlCATKgZuYVcJMRsGURPtELAhPBld5 nPg37SAnDFYzDAdaYE1A/kAiAlVvyarq2lQj8gy8/EmgQQpp0JhHMtXtWiRpzDMlY0 syxy/J0zmSYWVD8wHvzDu2e2u2J1IQiGzQaxKq0xq8rkIm0998UfpkTPOg1N69VGyq HIroJ0or6A5MXZZbFHpX/+3ui7MUM2PmsGalf+pyLnLuPvazFaL418c6GzeLAeEwr9 sCaakyMmO9bcJl+jJnrOZKh49HXOlRh038Xx+LPHVcHV1TbaCNSiI7ysRNdDcHLuoS lSwKmluZfXrNw== Message-ID: <543FF8C0.9040900@massar.ch> Date: Thu, 16 Oct 2014 18:56:32 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Enno Rey , v6ops@ietf.org, grow@ietf.org References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> In-Reply-To: <20141016162257.GH44748@ernw.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NX9FObmxz-YF6S_7UVScPIhmoCg Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:56:40 -0000 On 2014-10-16 18:22, Enno Rey wrote: > Hi, > > On Thu, Oct 16, 2014 at 10:11:41AM -0400, Christopher Morrow wrote: > >> >> So, some folk thought: "Hey, not announcing my aggregate and not >> providing connectivity between the aggregate announcement and the >> little islands I created is a grand plan!" and were surprised when >> things went badly... > > well, $FOLK might have good reasons to act in that way, based on their business models and network design. > > to put it equally bluntly, those folks wonder: "hey, we pay a hell lot of money to our uplink providers and they fail to deliver what we contracted, that is transporting our traffic". > see the examples in https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf. There is a reason why there are PA and PI blocks... or you know, pay for transiting the aggregate... Greets, Jeroen From nobody Thu Oct 16 10:16:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757E11A1A30; Thu, 16 Oct 2014 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd6bqnb46fQ9; Thu, 16 Oct 2014 10:16:00 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85ECB1A0262; Thu, 16 Oct 2014 10:16:00 -0700 (PDT) Received: from mh1.ernw.net (unknown [IPv6:fd00:2001:0:d001::10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 1610B15EC29; Thu, 16 Oct 2014 19:15:58 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id CBD6C48C; Thu, 16 Oct 2014 19:15:57 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 20644C4876; Thu, 16 Oct 2014 18:53:06 +0200 (CEST) Date: Thu, 16 Oct 2014 18:53:06 +0200 From: Enno Rey To: v6ops@ietf.org, grow@ietf.org Message-ID: <20141016165306.GA44951@ernw.de> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> <543FF8C0.9040900@massar.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543FF8C0.9040900@massar.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JsYyYjKRZcFCLeiAM0eSo2gtq5E Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:16:02 -0000 Hi, On Thu, Oct 16, 2014 at 06:56:32PM +0200, Jeroen Massar wrote: > > to put it equally bluntly, those folks wonder: "hey, we pay a hell lot of money to our uplink providers and they fail to deliver what we contracted, that is transporting our traffic". > > see the examples in https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf. > > There is a reason why there are PA and PI blocks... or you know, pay for > transiting the aggregate... well ... yes. not sure to what extent $RIRs act accordingly (have been involved in requesting resources from all five of them in the past and can tell you 1st hand that there's quite some encouraging $LARGE_ENTERPRISES to bec ome LIRs, in one way or the other). there must be a reason, why - as far as I can tell - _pretty much all_ large German companies have joined the elitist LIR club in the last two years, preparing their IPv6 depl oyment. RIRs are happily playing that game which is exactly why debate & consensus are needed (and probably Iljitsch brought this to BCOP). that said, $FOLK would pay for it. $YOUR_EMPLOYER has a product with "we guarantee routing your IPv6 more specifics up to /48 for a monthly $FEE" property? Let me know, I'm sure many $FOLKs would be interested in that. leaving them "in the dark" and dependent on the goodwill of (my personal perspective, based on statistics from RIPE RIS: outdated) strict filtering doesn't help anybody. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu Oct 16 11:04:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F051A033B; Thu, 16 Oct 2014 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj6EnDh8qp2f; Thu, 16 Oct 2014 11:03:57 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 719CD1A0275; Thu, 16 Oct 2014 11:03:57 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9GHxcJb024214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 10:59:38 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9GHxcJb024214 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1413482378; bh=mmc9CYg08EBU1zvpiieeM8c+Zvs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LRMSddJfg7WmyMw60UynwBkBwUbou7AmPpHKWOrH0IszFGCS4BSJmldhlR9tZzqpL SdD0sq/fTk5Uu2ASL3CU0j3oCQrWiNxwULlffsyMDBGxf97Ee8nAl2vu4vMNkSn+/n C25wlsJdhwIjaxUa8IKGU61Ox4D022bo9RXM9zTs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Date: Thu, 16 Oct 2014 10:59:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 16 Oct 2014 10:59:38 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/q_6rDdNwwl8r4cyqQXVvh2ZYcJI Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:04:00 -0000 On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum = wrote: > Let me address a few points that were brought up by different people. >=20 > Renumbering: >=20 > We had great plans for making renumbering easy in the early days of = IPv6. Remember A6 records and bitlabels in the DNS? But none of that = went anywhere. The problem isn't so much that we can't push a prefix = down the network or update the DNS (although both of these still have = challenges associated with them), but that addresses tend to get = hardcoded all over the place, starting with firewalls all the way up to = homegrown applications. I don't think renumbering addresses this issue, = although it could help steer some smaller organizations away from PI. They never went anywhere because they focused on solving the easy part = of the renumbering problem while utterly and completely ignoring the = hard part. Easy part: Changing your stuff. Hard part: Updating all of the prefix lists, filters, firewall rules, = VPN configurations, and other configuration elements in systems not = under your control that contain your prefixes (partner VPNs, peer = routers, etc.). NONE of the things proposed in those days did anything at all to address = the hard part. > A prefix length limit for the IPv6 DFZ: >=20 > Someone mentioned that this didn't work in IPv6. When Sprint decided = to make that /18, that didn't really work. But there's a de facto /24 = limit that everyone understands. With IPv6, that would translate into a = /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a = backstop against accidental/malicious IPv6 routing table explosion this = doesn't help. Even exploding a /28 or so into individual /48s would kill = the IPv6 DFZ. >=20 > What COULD work is to have prefix length limits depending on the = allocation size by the RIRs. Something like: >=20 > 2100::/16 -> /48 > 2200::/16 -> /32 > 2200::/15 -> /29 Because the 4.3 billion routes in the first category won't be a problem = somehow? Also, 2200::/16 and 2200::/15 overlap. Did you mean 2300::/16? If I = apply longest match rule to what you've put above, that's the effective = result. If you meant something else, I'm not sure how to divine that = from what you wrote. > However, for this to work well the RIRs would have to group = allocations of the same size into separate blocks, with the result that = it would no longer be possible to reserve space to grow an allocation. = (Things like allocating a /48 but reserving a /44 reduce the = opportunities for prefix length filtering because now the strictest = filter you can make allows 16 x as many prefixes worst case than average = case. The worst and average case need to be as close together as = possible.) I think overall, that would be worse than what we have today. > I'd say that allowing two or three extra bits for traffic engineering = for PA blocks would be good. So for the part of the IPv6 space where = /29s are allocated, allow /31s or /32s. As traffic engineering incoming = traffic by deaggregation requires that different parts of the aggregate = all generate similar levels of incoming traffic, this wouldn't usually = work for organizations using PI so I'd say don't allow deaggregating = below /48. What about multihomed customers? Do you want all multihomed customers to = be forced into getting their space directly from RIRs and not from LIRs? There are currently many cases where organizations obtain a /48 (or = larger) from their ISP and subsequently choose to connect to an = additional ISP and advertise the PA space as an independent route = through both ISPs. Many ISPs cooperate in this process and allow this = behavior. It does not change the number of routes in the routing table, = but it can be less expensive for the customer if they choose to go that = way. Obviously, at their first renumbering event, it makes sense for them to = renumber into PI, but this can prevent them from having to undergo = renumbering while they remain connected to the initial provider without = actually affecting the global routing table any more than getting PI = would. > Geographic communities: >=20 > I know this is controversial. "Topology ain't geography". Actually, = most of the time there is a significant correlation. If all German = cities inject a more specific, do you really need to hear those in Tokyo = or Seattle? Just send the traffic to Europe as per the aggregate and let = them figure it out there. Spend much time in Asia or Africa or the Caribbean? Sure, in the case of Germany, you probably don't need them in Tokyo or = Seattle. OTOH, if you get a bunch of more specifics coming out of = Rwanda, it might actually be significant to have them in Germany, Paris, = and Brussels. Where, exactly would you draw these lines and how would you go about = handling the necessary exceptions? Europe and the US are rich with exchange points and peering density. The = rest of the world, less so to varying degrees resulting in more = significant differences between topology and geography, often in ways = that are not necessarily obvious. > Compiling a list of communities that identify regions/countries/cities = would allow for experimentation in this place without any downsides that = I can see. Don't like this? Filter the communities. There's a handy list = that you can copy and paste into your filter. For these communities to be useful, they'd have to be transitive and = people would have to agree to apply them to their prefixes. What happens = in the case of "vigilante" tagging where some other AS decides to start = applying these tags to my routes even though I specifically don't want = that? > Injecting an aggregate as a point of last resort: >=20 > I think this can be done today and probably is done today. But a = document describing how to do it would probably be helpful. I'm thinking = along the following lines: It is already BCP for networks that have the ability to do so. It's not = a separate service or anything, you just source the aggregate from one = or more locations where you have the ability to forward the traffic as = needed. > The AoLR (Aggregate of Last Resort) service would entail a service = provider announcing the aggregate without necessarily providing = connectivity towards all the places announcing more specifics covered by = the aggregate. So if ISP A announces the AoLR and ISP B provides = connectivity to a more specific, ISP C would send traffic to A as per = the aggregate and then A would immediately hand it over to B. This assumes that A: 1. Is willing ot accept the more specifics from B. 2. Is willing to provide (likely unbillable) transit for = the customer in question. 3. Has a peering relationship with all ISP Bs for the given = customer. In my experience, ISPs are usually hesitant to take responsibility for = forwarding traffic they can't bill in some way. Item 3 is an even more difficult problem to solve. Most organizations, instead of depending on such a service simply build = the necessary tunnels to provide their own AoLR capabilities as needed = when they don't have internal circuits for the task. > So as part of the AoLR service, a service provider would agree to = accept all more specifics that fall under the aggregate (up to an agreed = prefix length) from all the networks providing connectivity towards = those more specifics. This would be an attractive service for tier-1s to = provide, because presumably, they peer with everyone everywhere, so in = the case where they receive the traffic over peering and need to deliver = it to another service provider over peering, this could probably happen = in the same city, so they wouldn't carry the traffic over long = distances. But the (sub-)organization(s) in question still gets to buy = connectivity from a wider range of smaller service providers. Tier-1s in my experience not only don't usually peer with everyone = everywhere, they often try to avoid peering with anyone they consider = "beneath them" as a tactic to try and force those organizations to buy = services from them. Again, I don't see the ISPs wanting to do what you describe since there = would be cost, but little benefit to them. > In practice an organization would contract two or more service = providers to provide the AoLR service for redundancy. >=20 > Wouldn't they just get PI: >=20 > Yes. That's why I think it's important to find a way to give these = organizations what they need in a way that keeps the IPv6 DFZ growth on = a workable trajectory. I think the IPv6 DFZ growth is already on a workable trajectory. If we = could eliminate the massive IPv4 routing table, then IPv6 is nowhere = near outpacing router memory capacity growth for the foreseeable future. The problem is surviving in the interim while we need IPv4 on a global = basis. The reality is that I think IPv4 routing table bloat is = eventually going to be the primary driver for IPv6 adoption. I think = this will occur much faster than most people imagine because I believe = that the fragmentation of the IPv4 table in the transfer market is going = to make IPv4 routing progressively more untenable until it essentially = collapses under its own weight. At that point, the remaining laggards = will scramble to deploy IPv6 as quickly as possible and the IPv4 table = will, largely, evaporate rather quickly. > AS numbers: >=20 > BGP assumes that an AS always has internal connectivity. This can be = accomplished using tunnels, but it's much better to simply have separate = AS numbers for each subunit. Would it make sense to allocate ranges of = AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's = no lack of numbers, and this would allow tools to be developed to work = on CIDR-like AS number ranges in the future. Yes... I'm all for going back to the definition of an AS as a contiguous = collection of networks with an identical routing policy. With 32 bits, I = think we have enough ASNs to accomplish this globally. Owen From nobody Thu Oct 16 11:14:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9B41A7031; Thu, 16 Oct 2014 11:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOOanNUWQ3ma; Thu, 16 Oct 2014 11:14:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7A1A6FF3; Thu, 16 Oct 2014 11:14:28 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9GIAn3j025148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 11:10:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9GIAn3j025148 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1413483049; bh=oljAnwt8ClpwGGgtu4fGA2fcNfw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=P6fhQoxVpTC2Lje7ardePyiO53Wh0DlDMpqMU4p3pUWURo10yIwjZvCRZC1pvw4TV XRVv5CVkMPqH34+n0hXl8bWaE2GsqYSAx/MmtBtps1dAu1DrulDyI4gD5c+JkIFDhE Sve9qrf87nxwa+fiGOBD/2p2c5cY2xqSRjhlm3xM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <20141016145931.GE31092@Space.Net> Date: Thu, 16 Oct 2014 11:10:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4275E715-7B1A-459C-BFF7-41EC71466817@delong.com> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> <20141016145931.GE31092@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 16 Oct 2014 11:10:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/t4D64ERfjwMG2WIKz_U3ULUIGqA Cc: Christopher Morrow , "grow@ietf.org grow@ietf.org" , IPv6 Operations Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:14:30 -0000 On Oct 16, 2014, at 07:59 , Gert Doering wrote: > Hi, >=20 > On Thu, Oct 16, 2014 at 10:45:23AM -0400, Christopher Morrow wrote: >>> A strong message to that extent would be good :-) - coupled with >>> some recommendations how the conflicting goals ("I want all ISPs in >>> my neighbourhood to use optimal routing" vs. "someone in Asia might >>> not be interested in all in 5k routes for german municipality") >>> could be solved. >>=20 >> ok, perhaps iljitsch can drop some text into a document so we can get >> a good read going and decide whether or not GROW wants to spend = cycles >> on it? >=20 > That would be nice (as I see the problem but have no cycles to write > something useful). >=20 >> The problem exists in v4 and v6 and likely will persist in whatever >> comes next. It's directly related to routing operations work on the >> global intertubes, so it SEEMS like GROW is the 'right place' to >> discuss this... we can't go anywhere without text and a draft though. >=20 > It seems to be made worse by the fact that "this" can be done more > easily with IPv6, as you just can't get enough v4 space to subdivide > it into 5000 globally visible prefixes today - and those entities that > discover the "must have reliability! must have independence!" mantra > *now* will hit the v6 space... (given that I see this argument in = this > dimension more often from governmental structures who have been hiding > behind single-IPv4-NAT so far). ARIN still has some /12s available and so does AfriNIC, so that isn't entirely true, but yes, mostly true if you discount the possibility of = picking up /12 or larger on the transfer market and deaggregating that (which I am pretty sure is coming soon to a router near you). > I *do* want a routing police, in the sense that "the operator = community" > agrees on what is considered "good" and "bad" behaviour, so end users > can ask someone (me, Iljitsch, ...) what to do in their network = planning, > and we can tell them I'd like a pony. > - if you do *this*, it's "guaranteed" to work > - if you do *that*, you can be sure that you will be filtered >=20 > while today, I have to tell them >=20 > - well, today it is likely to work, but it might stop working = tomorrow, > and there is no document that you could show around to those that > break your connectivity to show them that "you are doing the right = thing" We've had various attempts at this in the past. At one point, the = document said "RIRs will not issue PI prefixes in IPv6". That didn't meet the needs of = the operator community, so it changed. Any such document will be subject to "This is what was correct as of the = date of publication. It may stop working tomorrow." A better way to address this would be for more people to understand that = the concept that there is such a thing as "the internet" is a myth. In = reality, "The internet" is a collection of independently owned and operated networks with = competing and conflicting goals that happen to have (at least for the moment) = agreed on certain operational matters to a sufficient degree that traffic mostly = is able to get from any point A to nearly any point B as permitted by various = intermediate policies. > ISPs develop their own guidelines on prefix-length filtering, some = with > better understanding on what they want to achieve, others by using 10 = year > old example documents for never-updated filters... >=20 > So, yes, guidance, please :-) You do realize that any guidance provided in the document we create = today will meet the definition of "10 year old example documents for = never-updated filters" in about 10 years? Owen > have you enabled IPv6 on something today...? Of course... Have you? From nobody Thu Oct 16 11:38:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7C1A011E for ; Thu, 16 Oct 2014 11:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u43V-rX55BUb for ; Thu, 16 Oct 2014 11:38:03 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F391A6FF3 for ; Thu, 16 Oct 2014 11:38:02 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 06AE760828 for ; Thu, 16 Oct 2014 20:38:01 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BD39460298 for ; Thu, 16 Oct 2014 20:38:00 +0200 (CEST) Received: (qmail 48958 invoked by uid 1007); 16 Oct 2014 20:38:00 +0200 Date: Thu, 16 Oct 2014 20:38:00 +0200 From: Gert Doering To: Owen DeLong Message-ID: <20141016183800.GJ31092@Space.Net> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016143743.GC31092@Space.Net> <20141016145931.GE31092@Space.Net> <4275E715-7B1A-459C-BFF7-41EC71466817@delong.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bP6p79NgLGpD5at2" Content-Disposition: inline In-Reply-To: <4275E715-7B1A-459C-BFF7-41EC71466817@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-FMlxXiuWwLKekSHvDINtAIofuU Cc: Christopher Morrow , "grow@ietf.org grow@ietf.org" , IPv6 Operations Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:38:10 -0000 --bP6p79NgLGpD5at2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Oct 16, 2014 at 11:10:35AM -0700, Owen DeLong wrote: > A better way to address this would be for more people to understand that = the > concept that there is such a thing as "the internet" is a myth. In realit= y, "The internet" > is a collection of independently owned and operated networks with competi= ng > and conflicting goals that happen to have (at least for the moment) agree= d on > certain operational matters to a sufficient degree that traffic mostly is= able to > get from any point A to nearly any point B as permitted by various interm= ediate > policies. Well, while I understand and get that, "nuts and bolts" companies seem to expect that some sort of standards should govern, and if they give their money to someone who promises them "connection to the Internet", this=20 implies "their customers wherever in the world can use this thing to talk to them"... So, what is the message we want to send them? "Get a X.25 port instead, this Internet thingie isn't reliable enough for real world business"? =20 Surely not. > > have you enabled IPv6 on something today...? > Of course... Have you? Today, I don't think so, unfortunately (was busy with DANE). But just=20 yesterday, and the week before :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --bP6p79NgLGpD5at2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVEAQiN9WwGXkzn/FAQLsuQ/9FBxarANn1rg3i/77/s0/x+DCju8vKgRf g0EOyPT4NWYccTfPY37CfARiF+d/KhP+dns+k4aIYo4ihHWJzUDMe7dq9gqe+p7y a90lGxx4rZAhR4Xh2ltUWghHfjF1WWXUZg6+f9jSkPtzM3l+ER6F40cXRxMYmwQ+ /COQVx0DxkHtw+dQkIVGMZf5O7NP+cA41aLF4TMiZSqf2xdSncVV1sZtHN1eP0LM U1iGZATbiMlxybXydQ5TG3qwoF5EeIbtAJ42/wya/3i20ScuM0IlUMIlQbSO/g0A 0bQ3xh2qQC2aaLpY2HBqUEUOrcyO2Ya65Nl7LUeeWCJMMem83hnOsKzr2YlCOpHu OuI9KrUM6aGNLCUmW/do0Q7op1Hk0ZPP5SfyHLcKQXZzA56+QKrtovl3K6kV2DpT cgN55Cs4L99xXoJPPHV8BpYGAnHQAQQkn5s8f0jXIz87v9xzKDA+58QfEn3rD60V ojfBlxpRqONZqWEFS7awMymwCtt8HAkP3AjrrULfUwVMV0cEl9jMfLZIMYMRaeS+ g1YRzh3WSNF03cGQJZP+DaL7/TXLxfDNEA+0ewAhuq8iZsJVOnSyjoSyKeEvwYg9 7M+DxybRoPJScYLXC7bPS2q/cuNrm487wFJJUf2gMCZmbDHd1lqH4B/P00ogTnJF uqX7MugMolY= =DM/C -----END PGP SIGNATURE----- --bP6p79NgLGpD5at2-- From nobody Thu Oct 16 11:40:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AE21A6FF3; Thu, 16 Oct 2014 11:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdksYcfIuU7v; Thu, 16 Oct 2014 11:40:43 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921B01A01FA; Thu, 16 Oct 2014 11:40:43 -0700 (PDT) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 4397F1008B2D4; Thu, 16 Oct 2014 18:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1413484840; bh=y6V4KJDmWxsRvG3RG/BtFrX78JW3TJXFKSi5phfCbzA=; h=Date:From:To:Subject:References:In-Reply-To; b=V7lEYBrWXT79GSHzhijaIHA5sggmf1WNrhStDqNDOv88RVGB2MBWXIjfwECkJxTE2 BYxfeG7vmJ9QRHax8fpxJuNdzE7dBkg+WSjTV9U3roNML/K8wgRcBPjK5EVccqZIko 0aS5Vh8MB+D8vYuZo3pHrHAFrEnNrlC0t+jTwvHtniNofcq3XR0NiF652Elw582coD vnvtTgIugdH98B/7MiW1lkDzhjZb5fiFkiybdzujU7mqDNE0x7UxTdzoyibRLPjK5n PLN2wIfhOZ9YHIrjtOZg5MqJIMCFcD8aTBtHnWFZZTLQeeiJ4z2f0ZyCWeqAqofZWa NvVY+h4mckORg== Message-ID: <54401125.8060607@massar.ch> Date: Thu, 16 Oct 2014 20:40:37 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Enno Rey , v6ops@ietf.org, grow@ietf.org References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> <543FF8C0.9040900@massar.ch> <20141016165306.GA44951@ernw.de> In-Reply-To: <20141016165306.GA44951@ernw.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XZ_wnjWHBHN41MdJ59TSebgk0sA Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:40:46 -0000 On 2014-10-16 18:53, Enno Rey wrote: > Hi, > > On Thu, Oct 16, 2014 at 06:56:32PM +0200, Jeroen Massar wrote: >>> to put it equally bluntly, those folks wonder: "hey, we pay a >>> hell lot of money to our uplink providers and they fail to >>> deliver what we contracted, that is transporting our traffic". >>> see the examples in >>> https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf. >> >> >>> >>> There is a reason why there are PA and PI blocks... or you know, >>> pay for transiting the aggregate... > > well ... yes. not sure to what extent $RIRs act accordingly (have > been involved in requesting resources from all five of them in the > past and can tell you 1st hand that there's quite some encouraging > $LARGE_ENTERPRISES to bec ome LIRs, in one way or the other). As you are the consultant, your job to get them there right? Nothing the IETF can do about that part. > there > must be a reason, why - as far as I can tell - _pretty much all_ > large German companies have joined the elitist LIR club in the last > two years, preparing their IPv6 depl oyment. Because they all wanted a /32 PA for near zero paperwork. > RIRs are happily playing > that game which is exactly why debate & consensus are needed (and > probably Iljitsch brought this to BCOP). > > that said, $FOLK would pay for it. The numbers in your slides show that those companies have more than enough "resources" to be able to set up a proper network or let some transit backhaul the traffic. No need to de-aggregate and burden the rest of the world with that though. I would blame the consultant for hinting at the wrong solution for their enterprise... Greets, Jeroen From nobody Thu Oct 16 11:58:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EE31A879B; Thu, 16 Oct 2014 11:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_sTX9e78dIa; Thu, 16 Oct 2014 11:58:54 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576151A8789; Thu, 16 Oct 2014 11:58:54 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id le20so3099404vcb.25 for ; Thu, 16 Oct 2014 11:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+XBSFpZPuT1w4sUEMyXPilipwEjcMcLEcpC5U6jTbqk=; b=frwPiScVG3PX6j7PNsv3Oxh9m+Q7TBnQ7HzoflZUv0qQr50C2GVRUOqvXN4JllwOBz ox8s/ZuBwCPMn50AsqhoYbwBTupzkNH+iDi0atM+Nm7KuzDD6sGv1DQCejf6md9xs8kL PxH2JvjHebgCvkR44JwHu1tltIREZ5LwujPX4Lq1lq4mHkWQIcU99n/wlbKpt3Txjwl/ oT/NHfShoc13FvACXsLVeCLK43RUu5gieGkv5/nHca+ICGTzEEIhzj0sH4dYMZSSZVPc iwT7Ti9wD2N/dBVplFZ/Kwko+hzqvJsRgIv+uVu3W0izqyt8oXVO+IJfHtJGWaWHWWy4 C/rg== MIME-Version: 1.0 X-Received: by 10.52.19.134 with SMTP id f6mr2396243vde.75.1413485933402; Thu, 16 Oct 2014 11:58:53 -0700 (PDT) Received: by 10.220.186.193 with HTTP; Thu, 16 Oct 2014 11:58:52 -0700 (PDT) In-Reply-To: <54401125.8060607@massar.ch> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> <543FF8C0.9040900@massar.ch> <20141016165306.GA44951@ernw.de> <54401125.8060607@massar.ch> Date: Thu, 16 Oct 2014 14:58:52 -0400 Message-ID: From: Christopher Morrow To: Jeroen Massar Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/upbpwk1nfDq_5tVxBFug00eNELU Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:58:55 -0000 On Thu, Oct 16, 2014 at 2:40 PM, Jeroen Massar wrote: > On 2014-10-16 18:53, Enno Rey wrote: >> there >> must be a reason, why - as far as I can tell - _pretty much all_ >> large German companies have joined the elitist LIR club in the last >> two years, preparing their IPv6 depl oyment. > > Because they all wanted a /32 PA for near zero paperwork. prior to the 'ipv6 pi' rules changes I think many/some/a-few large corporations essentially (to get PI) just said: "Yes, my IT department is a 'service provider' to the rest of the company, can I haz /32?" see HP as an example of this (from my memory of their reasoning) From nobody Thu Oct 16 12:16:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BD01AD065; Thu, 16 Oct 2014 04:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV0JrLOkOiip; Thu, 16 Oct 2014 04:39:21 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359011A1A66; Thu, 16 Oct 2014 04:39:20 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:53944 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XejOn-0007BF-3Z; Thu, 16 Oct 2014 11:39:17 +0000 From: "Russ White" To: "'Iljitsch van Beijnum'" , , References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> In-Reply-To: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> Date: Thu, 16 Oct 2014 07:39:14 -0400 Message-ID: <011101cfe935$d0e8a600$72b9f200$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIU7+zpyiakeI4w4w1+I7Zew5YFCQFFO9hQm55hjDA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/l8CRTbscdBXbIPjsYMBl37eT6Ms X-Mailman-Approved-At: Thu, 16 Oct 2014 12:16:35 -0700 Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:39:24 -0000 > Injecting an aggregate as a point of last resort: > > I think this can be done today and probably is done today. But a document > describing how to do it would probably be helpful. I'm thinking along the > following lines: > > The AoLR (Aggregate of Last Resort) service would entail a service provider > announcing the aggregate without necessarily providing connectivity towards > all the places announcing more specifics covered by the aggregate. So if ISP A > announces the AoLR and ISP B provides connectivity to a more specific, ISP C > would send traffic to A as per the aggregate and then A would immediately > hand it over to B. Or perhaps something simpler would work here -- bounding longest match. :-) Russ From nobody Thu Oct 16 12:16:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AAB1A1B3B; Thu, 16 Oct 2014 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah4RS5sb71kd; Thu, 16 Oct 2014 06:03:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73251A1A71; Thu, 16 Oct 2014 06:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1038; q=dns/txt; s=iport; t=1413464591; x=1414674191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pQaPuBfw6UB84xzbSeq8E7XP/WpVKeHVctphtZyvev4=; b=OSR6DLXgpFn0/fBzcJhabSpsXcNa3hbX4vcZx3C0HYPwXzs58jSxb82X otozRmK7uGynVoDPyuC6e95LR5WUTZxCcd/T1Igd3gYGs+LLv3P2W9F0x snHsVcIOY7pigGLbHiZdIRmwutn5oJOw9HAOPVIE85zHVR4WdBiqF5nUR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFnBP1StJA2D/2dsb2JhbABbgw5TXMwch00CgRUWAX2EAwEBBHkQAgEIRiERJQIEAQ0FiCoDEQ3DZQ2GPQEBAQEBAQEDAQEBAQEBHI4ZggEzB4RLAQSPY4IchEaFAYIRgWyNWoZWg3dsgQYFPYECAQEB X-IronPort-AV: E=Sophos;i="5.04,732,1406592000"; d="scan'208";a="363798526" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 16 Oct 2014 13:03:10 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9GD3AAT016522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 13:03:10 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.127]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 08:03:10 -0500 From: "Alvaro Retana (aretana)" To: Christopher Morrow , Iljitsch van Beijnum Thread-Topic: [GROW] Deaggregation by large organizations Thread-Index: AQHP6HO0Yw6tGmdMOUO+hU2KqJts6JwyCuqAgAC3/IA= Date: Thu, 16 Oct 2014 13:03:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sWcndehyx8olYF5w3-1j2ErA-4o X-Mailman-Approved-At: Thu, 16 Oct 2014 12:16:35 -0700 Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:03:12 -0000 On 10/15/14, 6:04 PM, "Christopher Morrow" wrote: >> >>- A set of communities that indicate whether a prefix is a more specific >>that is covered by an aggregate and/or is safe to filter without loss of >>connectivity. >> > >so, add communities to global routes, because people don't strip these >in ingress as a matter of best practice? (if you don't you REALLY >should consider it, i think) Right.. Even if we could make the communities not be stripped (not proposing that), the originator would still not know the policy between any two ASNs =8B not even the receive policy of its direct neighbor! So the originator still couldn=B9t guarantee that the route is in fact covered= . The only way to determine coverage and no connectivity loss is on the receive side. There you can look at the incoming routes and determine how the routes overlap and mark them appropriately according to local policy. http://tools.ietf.org/html/draft-white-grow-overlapping-routes Alvaro. From nobody Thu Oct 16 12:52:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8E71A88A7; Thu, 16 Oct 2014 12:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KdBnrukJa_H; Thu, 16 Oct 2014 12:52:08 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AF71A87A0; Thu, 16 Oct 2014 12:52:07 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9GJpbAm066914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 20:51:58 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <544021CA.90602@foobar.org> Date: Thu, 16 Oct 2014 20:51:38 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Enno Rey , v6ops@ietf.org, grow@ietf.org References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> <543FF8C0.9040900@massar.ch> <20141016165306.GA44951@ernw.de> In-Reply-To: <20141016165306.GA44951@ernw.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V5UeexFd7uMITBn4pp51Jb034Xw Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:52:10 -0000 On 16/10/2014 17:53, Enno Rey wrote: > not sure to what extent $RIRs act accordingly (have been involved in > requesting resources from all five of them in the past and can tell you > 1st hand that there's quite some encouraging $LARGE_ENTERPRISES to > become LIRs, in one way or the other). there must be a reason, why - as > far as I can tell - _pretty much all_ large German companies have joined > the elitist LIR club in the last two years, preparing their IPv6 > deployment. RIRs are happily playing that game which is exactly why > debate & consensus are needed (and probably Iljitsch brought this to > BCOP). > > that said, $FOLK would pay for it. $YOUR_EMPLOYER has a product with "we > guarantee routing your IPv6 more specifics up to /48 for a monthly $FEE" > property? Let me know, I'm sure many $FOLKs would be interested in that. > leaving them "in the dark" and dependent on the goodwill of (my personal > perspective, based on statistics from RIPE RIS: outdated) strict > filtering doesn't help anybody. this whole email ... isn't even wrong. Nick From nobody Thu Oct 16 13:05:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5711A88D4; Thu, 16 Oct 2014 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvr66D-WEvef; Thu, 16 Oct 2014 13:05:35 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1980D1A8862; Thu, 16 Oct 2014 13:05:34 -0700 (PDT) Received: from mh1.ernw.net (unknown [IPv6:fd00:2001:0:d001::10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id C13C815EC29; Thu, 16 Oct 2014 22:05:32 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 6E9B64E0; Thu, 16 Oct 2014 22:05:32 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 76AD9C4876; Thu, 16 Oct 2014 21:42:40 +0200 (CEST) Date: Thu, 16 Oct 2014 21:42:40 +0200 From: Enno Rey To: v6ops@ietf.org, grow@ietf.org Message-ID: <20141016194240.GB45422@ernw.de> References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> <543FF8C0.9040900@massar.ch> <20141016165306.GA44951@ernw.de> <54401125.8060607@massar.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54401125.8060607@massar.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gS2CG7Y2Yly2XNIWpnJpluhLbt8 Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:05:38 -0000 Hi, On Thu, Oct 16, 2014 at 08:40:37PM +0200, Jeroen Massar wrote: > >>> > >>> There is a reason why there are PA and PI blocks... or you know, > >>> pay for transiting the aggregate... > > > > well ... yes. not sure to what extent $RIRs act accordingly (have > > been involved in requesting resources from all five of them in the > > past and can tell you 1st hand that there's quite some encouraging > > $LARGE_ENTERPRISES to bec ome LIRs, in one way or the other). > > As you are the consultant, your job to get them there right? > > Nothing the IETF can do about that part. Iljitsch initially submitted this to BCOP... which could be a place to discuss it. that said, you're fully right, IETF has never cared for "enterprise needs" (not implying they should, just noting), and hence - imho - done quite some harm to global IPv6 deployment. but that's another topic. > > > there > > must be a reason, why - as far as I can tell - _pretty much all_ > > large German companies have joined the elitist LIR club in the last > > two years, preparing their IPv6 depl oyment. > > Because they all wanted a /32 PA for near zero paperwork. or because RIRs encouraged them to do so, in several ways? potential reasoning I leave up to the imagination of the reader... > > > RIRs are happily playing > > that game which is exactly why debate & consensus are needed (and > > probably Iljitsch brought this to BCOP). > > > > that said, $FOLK would pay for it. > > The numbers in your slides show that those companies have more than > enough "resources" to be able to set up a proper network or let some > transit backhaul the traffic. thanks for the generous advice what a "proper network" is. much appreciated. > > No need to de-aggregate and burden the rest of the world with that though. > > I would blame the consultant for hinting at the wrong solution for their > enterprise... given all those organizations do the same silly stuff, seems they are all consulted to by a unified group of consultants not possessing your enormous amount of wisdom and of large scale enterprise network experience. so what's your practical advice to solve the apparent dilemma Iljitsch pointed out and thereby substantial contribution to the debate? thanks in advance & have a good one Enno > > Greets, > Jeroen -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu Oct 16 13:08:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE01A887E; Thu, 16 Oct 2014 13:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lpV8wvdcI9Z; Thu, 16 Oct 2014 13:08:23 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DE71A802F; Thu, 16 Oct 2014 13:08:23 -0700 (PDT) Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 40D4A1008B2AB; Thu, 16 Oct 2014 20:08:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1413490099; bh=g1I/ATtPjmZFlcQWwB9CGyjuojrz1GQWdJoZE9h3VFU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=FQCKA24YgD/K2GsKUlnFKMhiV4Do3MuweW98Iun3tNojog51yIXWDUNUQcaUDjGK0 fTUcdeX5Y3harLDtR7+WT+YbqlVzIgAUsKa0kEDAvi1XGduZ8kx9cTvevogTBNem2H /cN4KDDeB348aoxnJDCZxzHUayihSPDgnH07m0yr9Xwemzf6xRx/fcgR57bhjhl6oK c09ENKyOwmpFcn+g+Q/j2EltSudr+jProO05yQppgOjq+IyHkIDg8JqgoRChL24gLS 14fRHrKEO76sURGjqnaWyMQatGfq2KuCx5GSOCnhdpPp/QJRlixwOLD1mVxAae3uE8 CsxkX1GLKrF8Q== Message-ID: <544025B0.108@massar.ch> Date: Thu, 16 Oct 2014 22:08:16 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Christopher Morrow References: <903173CE-64D6-4FE5-98DB-B408C9586A02@muada.com> <20141016162257.GH44748@ernw.de> <543FF8C0.9040900@massar.ch> <20141016165306.GA44951@ernw.de> <54401125.8060607@massar.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tKEtvWBtm05YEgoZ7eHmwnK123M Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:08:26 -0000 On 2014-10-16 20:58, Christopher Morrow wrote: > On Thu, Oct 16, 2014 at 2:40 PM, Jeroen Massar wrote: >> On 2014-10-16 18:53, Enno Rey wrote: >>> there >>> must be a reason, why - as far as I can tell - _pretty much all_ >>> large German companies have joined the elitist LIR club in the last >>> two years, preparing their IPv6 depl oyment. >> >> Because they all wanted a /32 PA for near zero paperwork. > > prior to the 'ipv6 pi' rules changes I think many/some/a-few large > corporations essentially (to get PI) just said: "Yes, my IT department > is a 'service provider' to the rest of the company, can I haz /32?" I was refering above to companies that would be fine with a /48 or even a /40 or similar. In the end though, it does not matter if they have a /32 or a /40 or a /48; all those will use 1 routing slot. The only case it will use more is when they de-aggregate... > see HP as an example of this (from my memory of their reasoning) HP and other similar companies likely need more than a /32 if they do proper hierarchical routing between their sites... Hence why quite a few companies have requested multiple prefixes from multiple RIRs... Greets, Jeroen From nobody Thu Oct 16 14:16:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0271A0263; Thu, 16 Oct 2014 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5jUaUMyA8GY; Thu, 16 Oct 2014 14:16:43 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD261A87AC; Thu, 16 Oct 2014 14:16:42 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9GLG9I6067548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 22:16:29 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <54403599.6040205@foobar.org> Date: Thu, 16 Oct 2014 22:16:09 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Iljitsch van Beijnum References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> In-Reply-To: <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_hG3rzaJHYyvbyIbDGjMCka4yxI Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:16:45 -0000 On 16/10/2014 16:47, Iljitsch van Beijnum wrote: > Growth in IPv6 more specifics was 57% last year... Here's a graph which shows the percentage of more-specifics between 2003 and today from Geoff Huston's web site: http://goo.gl/QA0xud Eyeballing the graph, it's not clear where the figure of 57% came from. In terms of trajectories, there doesn't seem to be a major problem either. Nick From nobody Thu Oct 16 16:35:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049351A9029; Thu, 16 Oct 2014 16:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_REALLY=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZZBefDcmZaW; Thu, 16 Oct 2014 16:35:40 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BB31A9023; Thu, 16 Oct 2014 16:35:40 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id AA93E1FCB05; Thu, 16 Oct 2014 23:35:35 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3D489160058; Thu, 16 Oct 2014 23:38:40 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id BC5EE160056; Thu, 16 Oct 2014 23:38:39 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1B73521A106C; Fri, 17 Oct 2014 10:35:33 +1100 (EST) To: Owen DeLong From: Mark Andrews References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> In-reply-to: Your message of "Thu, 16 Oct 2014 10:59:24 -0700." Date: Fri, 17 Oct 2014 10:35:32 +1100 Message-Id: <20141016233533.1B73521A106C@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DJ_KeT-4jzfGzssjLGVZrcYhYqM Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 23:35:43 -0000 In message , Owen DeLong writes: > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum wrote: > > > Let me address a few points that were brought up by different people. > > > > Renumbering: > > > > We had great plans for making renumbering easy in the early days of IPv6. Remember A6 records and bit > labels in the DNS? But none of that went anywhere. The problem isn't so much that we can't push a prefi > x down the network or update the DNS (although both of these still have challenges associated with them > ), but that addresses tend to get hardcoded all over the place, starting with firewalls all the way up > to homegrown applications. I don't think renumbering addresses this issue, although it could help steer > some smaller organizations away from PI. > > They never went anywhere because they focused on solving the easy part of the renumbering problem while > utterly and completely ignoring the hard part. > > Easy part: Changing your stuff. > Hard part: Updating all of the prefix lists, filters, firewall rules, VPN configurations, and other con > figuration elements in systems not under your control that contain your prefixes (partner VPNs, peer ro > uters, etc.). Owen this a collective response to the list. Not all that hard at all. Just send signed update requests. I did that with email over a decade ago. You just have to have something listening for them that verifies the signature and updates the system. Write a draft "Remote Firewall Update Request Protocol" and submit it. The alternative is stop worrying about the remote address and use security at the application layer. Or complain to your vendor that you can't use a hostname in the configuration file element. In many cases it doesn't require anything more than looking up a address in the DNS before the operation. Yes, I need to fix the masters clause in named to support this. We already do something similar for NOTIFY messages so it is possible to do this. For masters clauses there is a bootstrap problem to deal with but it is not impossible. Just sending periodic NOTIFY messages will work. Named has had support to do this for 1 1/2 decades now to allow for a a stealth master behind a dial on demand link. It would send a notify periodically. That would bring up the line. The slave would refresh and transfer if required. When that was complete the idle timer on link would drop it. This just used standard signalling designed by the IETF in a different way. Stop expecting someone else to *find* and fix these issues for you. You know what the issues are. Ask your vendors to fix them. If they need to co-ordinate they should know where to go to do it. Mark > NONE of the things proposed in those days did anything at all to address the hard part. > > > A prefix length limit for the IPv6 DFZ: > > > > Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't re > ally work. But there's a de facto /24 limit that everyone understands. With IPv6, that would translate > into a /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop against accidental/mal > icious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s > would kill the IPv6 DFZ. > > > > What COULD work is to have prefix length limits depending on the allocation size by the RIRs. Somethi > ng like: > > > > 2100::/16 -> /48 > > 2200::/16 -> /32 > > 2200::/15 -> /29 > > Because the 4.3 billion routes in the first category won't be a problem somehow? > > Also, 2200::/16 and 2200::/15 overlap. Did you mean 2300::/16? If I apply longest match rule to what yo > u've put above, that's the effective result. If you meant something else, I'm not sure how to divine th > at from what you wrote. > > > However, for this to work well the RIRs would have to group allocations of the same size into separat > e blocks, with the result that it would no longer be possible to reserve space to grow an allocation. ( > Things like allocating a /48 but reserving a /44 reduce the opportunities for prefix length filtering b > ecause now the strictest filter you can make allows 16 x as many prefixes worst case than average case. > The worst and average case need to be as close together as possible.) > > I think overall, that would be worse than what we have today. > > > I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So > for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic engineering in > coming traffic by deaggregation requires that different parts of the aggregate all generate similar lev > els of incoming traffic, this wouldn't usually work for organizations using PI so I'd say don't allow d > eaggregating below /48. > > What about multihomed customers? Do you want all multihomed customers to be forced into getting their s > pace directly from RIRs and not from LIRs? > > There are currently many cases where organizations obtain a /48 (or larger) from their ISP and subseque > ntly choose to connect to an additional ISP and advertise the PA space as an independent route through > both ISPs. Many ISPs cooperate in this process and allow this behavior. It does not change the number o > f routes in the routing table, but it can be less expensive for the customer if they choose to go that > way. > > Obviously, at their first renumbering event, it makes sense for them to renumber into PI, but this can > prevent them from having to undergo renumbering while they remain connected to the initial provider wit > hout actually affecting the global routing table any more than getting PI would. > > > Geographic communities: > > > > I know this is controversial. "Topology ain't geography". Actually, most of the time there is a signi > ficant correlation. If all German cities inject a more specific, do you really need to hear those in To > kyo or Seattle? Just send the traffic to Europe as per the aggregate and let them figure it out there. > > Spend much time in Asia or Africa or the Caribbean? > > Sure, in the case of Germany, you probably don't need them in Tokyo or Seattle. OTOH, if you get a bunc > h of more specifics coming out of Rwanda, it might actually be significant to have them in Germany, Par > is, and Brussels. > > Where, exactly would you draw these lines and how would you go about handling the necessary exceptions? > > Europe and the US are rich with exchange points and peering density. The rest of the world, less so to > varying degrees resulting in more significant differences between topology and geography, often in ways > that are not necessarily obvious. > > > Compiling a list of communities that identify regions/countries/cities would allow for experimentatio > n in this place without any downsides that I can see. Don't like this? Filter the communities. There's > a handy list that you can copy and paste into your filter. > > For these communities to be useful, they'd have to be transitive and people would have to agree to appl > y them to their prefixes. What happens in the case of "vigilante" tagging where some other AS decides t > o start applying these tags to my routes even though I specifically don't want that? > > > Injecting an aggregate as a point of last resort: > > > > I think this can be done today and probably is done today. But a document describing how to do it wou > ld probably be helpful. I'm thinking along the following lines: > > It is already BCP for networks that have the ability to do so. It's not a separate service or anything, > you just source the aggregate from one or more locations where you have the ability to forward the tra > ffic as needed. > > > The AoLR (Aggregate of Last Resort) service would entail a service provider announcing the aggregate > without necessarily providing connectivity towards all the places announcing more specifics covered by > the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity to a more specific, ISP C > would send traffic to A as per the aggregate and then A would immediately hand it over to B. > > This assumes that A: > 1. Is willing ot accept the more specifics from B. > 2. Is willing to provide (likely unbillable) transit for the customer in question. > 3. Has a peering relationship with all ISP Bs for the given customer. > > In my experience, ISPs are usually hesitant to take responsibility for forwarding traffic they can't bi > ll in some way. > > Item 3 is an even more difficult problem to solve. > > Most organizations, instead of depending on such a service simply build the necessary tunnels to provid > e their own AoLR capabilities as needed when they don't have internal circuits for the task. > > > So as part of the AoLR service, a service provider would agree to accept all more specifics that fall > under the aggregate (up to an agreed prefix length) from all the networks providing connectivity towar > ds those more specifics. This would be an attractive service for tier-1s to provide, because presumably > , they peer with everyone everywhere, so in the case where they receive the traffic over peering and ne > ed to deliver it to another service provider over peering, this could probably happen in the same city, > so they wouldn't carry the traffic over long distances. But the (sub-)organization(s) in question stil > l gets to buy connectivity from a wider range of smaller service providers. > > Tier-1s in my experience not only don't usually peer with everyone everywhere, they often try to avoid > peering with anyone they consider "beneath them" as a tactic to try and force those organizations to bu > y services from them. > > Again, I don't see the ISPs wanting to do what you describe since there would be cost, but little benef > it to them. > > > In practice an organization would contract two or more service providers to provide the AoLR service > for redundancy. > > > > Wouldn't they just get PI: > > > > Yes. That's why I think it's important to find a way to give these organizations what they need in a > way that keeps the IPv6 DFZ growth on a workable trajectory. > > I think the IPv6 DFZ growth is already on a workable trajectory. If we could eliminate the massive IPv4 > routing table, then IPv6 is nowhere near outpacing router memory capacity growth for the foreseeable f > uture. > > The problem is surviving in the interim while we need IPv4 on a global basis. The reality is that I thi > nk IPv4 routing table bloat is eventually going to be the primary driver for IPv6 adoption. I think thi > s will occur much faster than most people imagine because I believe that the fragmentation of the IPv4 > table in the transfer market is going to make IPv4 routing progressively more untenable until it essent > ially collapses under its own weight. At that point, the remaining laggards will scramble to deploy IPv > 6 as quickly as possible and the IPv4 table will, largely, evaporate rather quickly. > > > AS numbers: > > > > BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but > it's much better to simply have separate AS numbers for each subunit. Would it make sense to allocate r > anges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of numbers, an > d this would allow tools to be developed to work on CIDR-like AS number ranges in the future. > > Yes... I'm all for going back to the definition of an AS as a contiguous collection of networks with an > identical routing policy. With 32 bits, I think we have enough ASNs to accomplish this globally. > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Oct 16 17:59:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D31B1A907B; Thu, 16 Oct 2014 17:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZPc8-i3EsDv; Thu, 16 Oct 2014 17:59:08 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78271A907A; Thu, 16 Oct 2014 17:59:08 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id v1so2498145yhn.7 for ; Thu, 16 Oct 2014 17:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6m1IiPjY0EAbxmlkV6Y+wJnYo3ZQbWYNlm/TxEoKzXI=; b=tRQqqauG0XRuKVHSpRttzPq3VFH91sKrHxMkqJHSYqqbNknJfAkWAA0eT4hlYPIuNF 0Im7z9dqjhYdOXgJdAkq2gYJiBHr5kCjS+7bfjMC18gFXuiotUH9z+MceQVSKxVMYXgs BMVGcwYj+aQ7vUTtFTzC0r/vH4igdF96QVsJxZtSHWhJ1VNYT/TUxk1/3ADs3Y8XvwUW Qes/TQdvjBGf7er+CKVQJsNmM7shWa7iN2CvM5tFSpkXK8Z84fbq9D6mNngNhaQ4P+oA koP0TqyXVG60haOUzvadvgwcNGIHhEfd++QdteqXaiAdpndeUoCSKc+C7xwx9pfHzg8q lPTw== MIME-Version: 1.0 X-Received: by 10.236.66.103 with SMTP id g67mr6394596yhd.61.1413507547980; Thu, 16 Oct 2014 17:59:07 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.170.168.87 with HTTP; Thu, 16 Oct 2014 17:59:07 -0700 (PDT) In-Reply-To: <20141016233533.1B73521A106C@rock.dv.isc.org> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> Date: Thu, 16 Oct 2014 17:59:07 -0700 X-Google-Sender-Auth: Fjn6Ha-7ywoAp9waPiFjLrf7w0I Message-ID: From: Matthew Petach To: Mark Andrews Content-Type: multipart/alternative; boundary=089e013a14fa48fd43050593df5a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kDZ0JiDEnp4vPG83z4fGHUrnyU0 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:59:10 -0000 --089e013a14fa48fd43050593df5a Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews wrote: > > In message , Owen DeLong > writes: > > > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum > wrote: > > > > > Let me address a few points that were brought up by different people. > > > > > > Renumbering: > > > > > > We had great plans for making renumbering easy in the early days of > IPv6. Remember A6 records and bit > > labels in the DNS? But none of that went anywhere. The problem isn't so > much that we can't push a prefi > > x down the network or update the DNS (although both of these still have > challenges associated with them > > ), but that addresses tend to get hardcoded all over the place, starting > with firewalls all the way up > > to homegrown applications. I don't think renumbering addresses this > issue, although it could help steer > > some smaller organizations away from PI. > > > > They never went anywhere because they focused on solving the easy part > of the renumbering problem while > > utterly and completely ignoring the hard part. > > > > Easy part: Changing your stuff. > > Hard part: Updating all of the prefix lists, filters, firewall rules, > VPN configurations, and other con > > figuration elements in systems not under your control that contain your > prefixes (partner VPNs, peer ro > > uters, etc.). > > Owen this a collective response to the list. > > Not all that hard at all. Just send signed update requests. I did > that with email over a decade ago. You just have to have something > listening for them that verifies the signature and updates the > system. > > Write a draft "Remote Firewall Update Request Protocol" and submit > it. > > The alternative is stop worrying about the remote address and use > security at the application layer. > > Or complain to your vendor that you can't use a hostname in the > configuration file element. In many cases it doesn't require > anything more than looking up a address in the DNS before the > operation. Yes, I need to fix the masters clause in named to support > this. We already do something similar for NOTIFY messages so it > is possible to do this. > > For masters clauses there is a bootstrap problem to deal with but > it is not impossible. Just sending periodic NOTIFY messages will > work. Named has had support to do this for 1 1/2 decades now to > allow for a a stealth master behind a dial on demand link. It would > send a notify periodically. That would bring up the line. The > slave would refresh and transfer if required. When that was complete > the idle timer on link would drop it. > > This just used standard signalling designed by the IETF in a different > way. > > Stop expecting someone else to *find* and fix these issues for you. > You know what the issues are. Ask your vendors to fix them. If > they need to co-ordinate they should know where to go to do it. > Or, y'know, we could just get PI space, multihome via BGP, and save ourselves all that headache... ...just sayin'... Matt --089e013a14fa48fd43050593df5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews <marka@isc.org> wrote:

In message <A7F6BEA0-BCDD-4197-B6CB-7EB8797ACA9C@delong.com>, Owen DeLong= writes:
>
> On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <iljitsch@muada.com> wrote:
>
> > Let me address a few points that were brought up by different peo= ple.
> >
> > Renumbering:
> >
> > We had great plans for making renumbering easy in the early days = of IPv6. Remember A6 records and bit
> labels in the DNS? But none of that went anywhere. The problem isn'= ;t so much that we can't push a prefi
> x down the network or update the DNS (although both of these still hav= e challenges associated with them
> ), but that addresses tend to get hardcoded all over the place, starti= ng with firewalls all the way up
> to homegrown applications. I don't think renumbering addresses thi= s issue, although it could help steer
>=C2=A0 some smaller organizations away from PI.
>
> They never went anywhere because they focused on solving the easy part= of the renumbering problem while
>=C2=A0 utterly and completely ignoring the hard part.
>
> Easy part: Changing your stuff.
> Hard part: Updating all of the prefix lists, filters, firewall rules, = VPN configurations, and other con
> figuration elements in systems not under your control that contain you= r prefixes (partner VPNs, peer ro
> uters, etc.).

Owen this a collective response to the list.

Not all that hard at all.=C2=A0 Just send signed update requests.=C2=A0 I d= id
that with email over a decade ago.=C2=A0 You just have to have something listening for them that verifies the signature and updates the
system.

Write a draft "Remote Firewall Update Request Protocol" and submi= t
it.

The alternative is stop worrying about the remote address and use
security at the application layer.

Or complain to your vendor that you can't use a hostname in the
configuration file element.=C2=A0 In many cases it doesn't require
anything more than looking up a address in the DNS before the
operation.=C2=A0 Yes, I need to fix the masters clause in named to support<= br> this.=C2=A0 We already do something similar for NOTIFY messages so it
is possible to do this.

For masters clauses there is a bootstrap problem to deal with but
it is not impossible.=C2=A0 Just sending periodic NOTIFY messages will
work.=C2=A0 Named has had support to do this for 1 1/2 decades now to
allow for a a stealth master behind a dial on demand link.=C2=A0 It would send a notify periodically.=C2=A0 That would bring up the line.=C2=A0 The slave would refresh and transfer if required.=C2=A0 When that was complete<= br> the idle timer on link would drop it.

This just used standard signalling designed by the IETF in a different
way.

Stop expecting someone else to *find* and fix these issues for you.
You know what the issues are.=C2=A0 Ask your vendors to fix them.=C2=A0 If<= br> they need to co-ordinate they should know where to go to do it.

Or, y'know, we could just get PI space,
mul= tihome via BGP, and save ourselves
all that headache...

...just sayin'...

Matt
--089e013a14fa48fd43050593df5a-- From nobody Thu Oct 16 18:03:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADD31A9088; Thu, 16 Oct 2014 18:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmNVWcFShSjj; Thu, 16 Oct 2014 18:03:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 031691A9087; Thu, 16 Oct 2014 18:03:24 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9H0wWS7024770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 17:58:32 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9H0wWS7024770 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1413507512; bh=vBazpTOI2PSOIggsLZB3e6KD/jQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=W7lCgTrjKpBGEdASL6rCXJyxlGGajghHQITDYXprmQuXjVk+7QG39tx7xnvVEcUrn 7rFLX6y/2xEPChEGmpPrwm+XkNUDbLx28NJkRT7/YAHSu/yZ8b3njro35cqZnSZRag G3nKiwfSswBZyU/wtD74EIHpeyB0cSvSGj0H/yks= Content-Type: multipart/alternative; boundary="Apple-Mail=_426DF50B-6FE6-4B57-8239-A846958E32F5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Owen DeLong In-Reply-To: <20141016233533.1B73521A106C@rock.dv.isc.org> Date: Thu, 16 Oct 2014 17:58:15 -0700 Message-Id: <142A1C5B-33C8-4A44-8DE0-11FC3D88D1D5@delong.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 16 Oct 2014 17:58:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o7qSuIf1UHE4ep5R2zFpxDh7ins Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:03:30 -0000 --Apple-Mail=_426DF50B-6FE6-4B57-8239-A846958E32F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 16, 2014, at 16:35 , Mark Andrews wrote: >=20 > In message , Owen = DeLong writes: >>=20 >> On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum = wrote: >>=20 >>> Let me address a few points that were brought up by different = people. >>>=20 >>> Renumbering: >>>=20 >>> We had great plans for making renumbering easy in the early days of = IPv6. Remember A6 records and bit >> labels in the DNS? But none of that went anywhere. The problem isn't = so much that we can't push a prefi >> x down the network or update the DNS (although both of these still = have challenges associated with them >> ), but that addresses tend to get hardcoded all over the place, = starting with firewalls all the way up=20 >> to homegrown applications. I don't think renumbering addresses this = issue, although it could help steer >> some smaller organizations away from PI. >>=20 >> They never went anywhere because they focused on solving the easy = part of the renumbering problem while >> utterly and completely ignoring the hard part. >>=20 >> Easy part: Changing your stuff. >> Hard part: Updating all of the prefix lists, filters, firewall rules, = VPN configurations, and other con >> figuration elements in systems not under your control that contain = your prefixes (partner VPNs, peer ro >> uters, etc.). >=20 > Owen this a collective response to the list. >=20 > Not all that hard at all. Just send signed update requests. I did > that with email over a decade ago. You just have to have something > listening for them that verifies the signature and updates the > system. No, you have to have all your {customers, suppliers, partners, etc.} = implement a compatible system of listeners that can configure their equipment on = the basis of those requests. > Write a draft "Remote Firewall Update Request Protocol" and submit > it. I don't have time to engage in this, but I think such a thing would be a more useful use of IETF time than what has been proposed in the earlier discussions in this thread. I still question whether it would get widely adopted, but having it documented would at least be a good first step. > The alternative is stop worrying about the remote address and use > security at the application layer. Again, not a solution unless you can achieve ubiquitous deployment of such a scenario. > Or complain to your vendor that you can't use a hostname in the > configuration file element. In many cases it doesn't require > anything more than looking up a address in the DNS before the > operation. Yes, I need to fix the masters clause in named to support > this. We already do something similar for NOTIFY messages so it > is possible to do this. It's not my vendor that's at issue here. I can configure whatever I = bought from my vendor. Convincing my {customers', suppliers', partners'} = vendors to listen to me is, well, unlikely. Convincing my {customers, suppliers, = partners} to make demands of their vendors on my behalf is slightly less likely. > For masters clauses there is a bootstrap problem to deal with but > it is not impossible. Just sending periodic NOTIFY messages will > work. Named has had support to do this for 1 1/2 decades now to > allow for a a stealth master behind a dial on demand link. It would > send a notify periodically. That would bring up the line. The > slave would refresh and transfer if required. When that was complete > the idle timer on link would drop it. Less concerned about that than the above issues. Do you really think = that partner A wants to allow partner B to send signed messages to modify his firewall configuratoin? Who is liable for what happens to partner A if = partner B's private key gets compromised? The transitive trust involved in such = a scenario is not something I have found to be widely accepted by = enterprise security people. > This just used standard signalling designed by the IETF in a different > way. >=20 > Stop expecting someone else to *find* and fix these issues for you. > You know what the issues are. Ask your vendors to fix them. If > they need to co-ordinate they should know where to go to do it. I don't expect them to get fixed. They've been widely known for years. = They're not easy problems to solve and there isn't money commensurate with their = difficulty available to solve them. Further, the human interface problems involved = are probably just as difficult if not more so than the technical hurdles, so even if = the technology were miraculously solved, it might not matter. Owen --Apple-Mail=_426DF50B-6FE6-4B57-8239-A846958E32F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 16, 2014, at 16:35 , Mark = Andrews <marka@isc.org> = wrote:


In message <A7F6BEA0-B= CDD-4197-B6CB-7EB8797ACA9C@delong.com>, Owen DeLong = writes:

On Oct 16, 2014, at 02:43 , = Iljitsch van Beijnum <iljitsch@muada.com> = wrote:

Let me address a few points that = were brought up by different people.

Renumbering:

We had = great plans for making renumbering easy in the early days of IPv6. = Remember A6 records and bit
labels in the DNS? But none = of that went anywhere. The problem isn't so much that we can't push a = prefi
x down the network or update the DNS (although both of these = still have challenges associated with them
), but that addresses tend = to get hardcoded all over the place, starting with firewalls all the way = up 
to homegrown = applications. I don't think renumbering addresses this issue, although = it could help steer
some smaller organizations away from = PI.

They never went anywhere because they focused on solving the = easy part of the renumbering problem while
utterly and completely = ignoring the hard part.

Easy part: Changing your stuff.
Hard = part: Updating all of the prefix lists, filters, firewall rules, VPN = configurations, and other con
figuration elements in systems not = under your control that contain your prefixes (partner VPNs, peer = ro
uters, etc.).

Owen this a collective response = to the list.

Not all that hard at all.  Just send signed = update requests.  I did
that with email over a decade ago. =  You just have to have something
listening for them that = verifies the signature and updates = the
system.

No, you have to have = all your {customers, suppliers, partners, etc.} implement
a = compatible system of listeners that can configure their equipment on the = basis
of those requests.

Write a draft "Remote Firewall Update = Request Protocol" and = submit
it.

I don't have time to = engage in this, but I think such a thing would be a
more = useful use of IETF time than what has been proposed in the = earlier
discussions in this thread. I still question whether = it would get widely
adopted, but having it documented would at = least be a good first step.

The = alternative is stop worrying about the remote address and = use
security at the application = layer.

Again, not a solution unless = you can achieve ubiquitous deployment of
such a = scenario.

Or = complain to your vendor that you can't use a hostname in = the
configuration file element.  In many cases it doesn't = require
anything more than looking up a address in the DNS before = the
operation.  Yes, I need to fix the masters clause in named = to support
this.  We already do something similar for NOTIFY = messages so it
is possible to do = this.

It's not my vendor that's at = issue here. I can configure whatever I bought
from my vendor. = Convincing my {customers', suppliers', partners'} vendors
to = listen to me is, well, unlikely. Convincing my {customers, suppliers, = partners}
to make demands of their vendors on my behalf is = slightly less likely.

For = masters clauses there is a bootstrap problem to deal with but
it is = not impossible.  Just sending periodic NOTIFY messages = will
work.  Named has had support to do this for 1 1/2 decades = now to
allow for a a stealth master behind a dial on demand link. =  It would
send a notify periodically.  That would bring up = the line.  The
slave would refresh and transfer if required. =  When that was complete
the idle timer on link would drop = it.

Less concerned about that than = the above issues. Do you really think that
partner A wants to = allow partner B to send signed messages to modify his
firewall = configuratoin? Who is liable for what happens to partner A if = partner
B's private key gets compromised? The transitive trust = involved in such a
scenario is not something I have found to = be widely accepted by enterprise
security = people.

This = just used standard signalling designed by the IETF in a = different
way.

Stop expecting someone else to *find* and fix = these issues for you.
You know what the issues are.  Ask your = vendors to fix them.  If
they need to co-ordinate they should = know where to go to do it.

I don't = expect them to get fixed. They've been widely known for years. They're = not
easy problems to solve and there isn't money commensurate = with their difficulty
available to solve them. Further, the = human interface problems involved are probably
just as = difficult if not more so than the technical hurdles, so even if the = technology
were miraculously solved, it might not = matter.

Owen


= --Apple-Mail=_426DF50B-6FE6-4B57-8239-A846958E32F5-- From nobody Thu Oct 16 18:06:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBD81A9089; Thu, 16 Oct 2014 18:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5SHoW9sZU2t; Thu, 16 Oct 2014 18:06:02 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E71C1A908B; Thu, 16 Oct 2014 18:06:00 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id E8DBC349415; Fri, 17 Oct 2014 01:05:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 141BB160058; Fri, 17 Oct 2014 01:09:00 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A6111160056; Fri, 17 Oct 2014 01:08:59 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9682921A4D54; Fri, 17 Oct 2014 12:05:52 +1100 (EST) To: Matthew Petach From: Mark Andrews References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> In-reply-to: Your message of "Thu, 16 Oct 2014 17:59:07 -0700." Date: Fri, 17 Oct 2014 12:05:52 +1100 Message-Id: <20141017010552.9682921A4D54@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RR6wLZoPzFVn_2ff5iInvyZ7ABE Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:06:04 -0000 In message , Matthew Petach writes: > --089e013a14fa48fd43050593df5a > Content-Type: text/plain; charset=UTF-8 > > On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews wrote: > > > > > In message , Owen DeLong > > writes: > > > > > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum > > wrote: > > > > > > > Let me address a few points that were brought up by different people. > > > > > > > > Renumbering: > > > > > > > > We had great plans for making renumbering easy in the early days of > > IPv6. Remember A6 records and bit > > > labels in the DNS? But none of that went anywhere. The problem isn't so > > much that we can't push a prefi > > > x down the network or update the DNS (although both of these still have > > challenges associated with them > > > ), but that addresses tend to get hardcoded all over the place, starting > > with firewalls all the way up > > > to homegrown applications. I don't think renumbering addresses this > > issue, although it could help steer > > > some smaller organizations away from PI. > > > > > > They never went anywhere because they focused on solving the easy part > > of the renumbering problem while > > > utterly and completely ignoring the hard part. > > > > > > Easy part: Changing your stuff. > > > Hard part: Updating all of the prefix lists, filters, firewall rules, > > VPN configurations, and other con > > > figuration elements in systems not under your control that contain your > > prefixes (partner VPNs, peer ro > > > uters, etc.). > > > > Owen this a collective response to the list. > > > > Not all that hard at all. Just send signed update requests. I did > > that with email over a decade ago. You just have to have something > > listening for them that verifies the signature and updates the > > system. > > > > Write a draft "Remote Firewall Update Request Protocol" and submit > > it. > > > > The alternative is stop worrying about the remote address and use > > security at the application layer. > > > > Or complain to your vendor that you can't use a hostname in the > > configuration file element. In many cases it doesn't require > > anything more than looking up a address in the DNS before the > > operation. Yes, I need to fix the masters clause in named to support > > this. We already do something similar for NOTIFY messages so it > > is possible to do this. > > > > For masters clauses there is a bootstrap problem to deal with but > > it is not impossible. Just sending periodic NOTIFY messages will > > work. Named has had support to do this for 1 1/2 decades now to > > allow for a a stealth master behind a dial on demand link. It would > > send a notify periodically. That would bring up the line. The > > slave would refresh and transfer if required. When that was complete > > the idle timer on link would drop it. > > > > This just used standard signalling designed by the IETF in a different > > way. > > > > Stop expecting someone else to *find* and fix these issues for you. > > You know what the issues are. Ask your vendors to fix them. If > > they need to co-ordinate they should know where to go to do it. > > > > Or, y'know, we could just get PI space, > multihome via BGP, and save ourselves > all that headache... > > ...just sayin'... > > Matt And when we can support 40 billion routes, PI becomes a viable solution. Yes, this is the level that PI needs to be able to scale to for it to be a actual solution. Yes, mutiple routes for every single person on the planet. Until then we need to work towards making renumbering work so PI isn't needed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Oct 16 18:18:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDCB1A89C6; Thu, 16 Oct 2014 18:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9gkH_pC5QyE; Thu, 16 Oct 2014 18:18:36 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BBD1A8820; Thu, 16 Oct 2014 18:18:35 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id f73so2530061yha.33 for ; Thu, 16 Oct 2014 18:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=i0yXQE4ctnxh8MB9s4fuDuRYed12/gDqKTKkvg2Ax/U=; b=FDAEI3Wv+iKmMCzadvoJ/4uhOTkP0ucH6vzam2ZxNDqxnFIGiBueWzYmni/nty8vaz c5Glpvi9E6QO75NBDDp+QEfKWk7lpUsQyHW6ClZkCwC3yQnpRjYmVp92BRKngbbsbM6u A2cXJXBD8/pFSaC3i/NuFmiY+LZ3hThOd4vnCBc79V6MMOMNobi+ad7pb8tUBpw/xozq 5BpxXkfzPlgSplPRgBa0Edq1UHCWi4dpKWkcLYrnbX1i8AWX2ewc1ZfFIJaFUzgvk7iP CNuf2zRstJOCyIhg8f1E+rciG6Cvw34YyXrtAD1fRsCkRchRnCD3vGXgQv/fn3Xt6RFF TGjg== MIME-Version: 1.0 X-Received: by 10.236.19.138 with SMTP id n10mr6575236yhn.55.1413508714898; Thu, 16 Oct 2014 18:18:34 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.170.168.87 with HTTP; Thu, 16 Oct 2014 18:18:34 -0700 (PDT) In-Reply-To: <20141017010552.9682921A4D54@rock.dv.isc.org> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> <20141017010552.9682921A4D54@rock.dv.isc.org> Date: Thu, 16 Oct 2014 18:18:34 -0700 X-Google-Sender-Auth: LtXMQMV-vfzJoV3zNoCaLy7Kv2g Message-ID: From: Matthew Petach To: Mark Andrews Content-Type: multipart/alternative; boundary=089e0160befad6aa910505942458 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3AYnomooCkwqNZk1uXv0LOu0X3M Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:18:38 -0000 --089e0160befad6aa910505942458 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 6:05 PM, Mark Andrews wrote: > > In message r7UdeStcqFjiQRO_Vt1hfR_T4oyTW5FD-eD1ATEXpc6A@mail.gmail.com>, Matthew > Petach writes: > > --089e013a14fa48fd43050593df5a > > Content-Type: text/plain; charset=UTF-8 > > > > On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews wrote: > > > > > > > > In message , Owen > DeLong > > > writes: > > > > > > > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum > > > > wrote: > > > > > > > > > Let me address a few points that were brought up by different > people. > > > > > > > > > > Renumbering: > > > > > > > > > > We had great plans for making renumbering easy in the early days of > > > IPv6. Remember A6 records and bit > > > > labels in the DNS? But none of that went anywhere. The problem isn't > so > > > much that we can't push a prefi > > > > x down the network or update the DNS (although both of these still > have > > > challenges associated with them > > > > ), but that addresses tend to get hardcoded all over the place, > starting > > > with firewalls all the way up > > > > to homegrown applications. I don't think renumbering addresses this > > > issue, although it could help steer > > > > some smaller organizations away from PI. > > > > > > > > They never went anywhere because they focused on solving the easy > part > > > of the renumbering problem while > > > > utterly and completely ignoring the hard part. > > > > > > > > Easy part: Changing your stuff. > > > > Hard part: Updating all of the prefix lists, filters, firewall rules, > > > VPN configurations, and other con > > > > figuration elements in systems not under your control that contain > your > > > prefixes (partner VPNs, peer ro > > > > uters, etc.). > > > > > > Owen this a collective response to the list. > > > > > > Not all that hard at all. Just send signed update requests. I did > > > that with email over a decade ago. You just have to have something > > > listening for them that verifies the signature and updates the > > > system. > > > > > > Write a draft "Remote Firewall Update Request Protocol" and submit > > > it. > > > > > > The alternative is stop worrying about the remote address and use > > > security at the application layer. > > > > > > Or complain to your vendor that you can't use a hostname in the > > > configuration file element. In many cases it doesn't require > > > anything more than looking up a address in the DNS before the > > > operation. Yes, I need to fix the masters clause in named to support > > > this. We already do something similar for NOTIFY messages so it > > > is possible to do this. > > > > > > For masters clauses there is a bootstrap problem to deal with but > > > it is not impossible. Just sending periodic NOTIFY messages will > > > work. Named has had support to do this for 1 1/2 decades now to > > > allow for a a stealth master behind a dial on demand link. It would > > > send a notify periodically. That would bring up the line. The > > > slave would refresh and transfer if required. When that was complete > > > the idle timer on link would drop it. > > > > > > This just used standard signalling designed by the IETF in a different > > > way. > > > > > > Stop expecting someone else to *find* and fix these issues for you. > > > You know what the issues are. Ask your vendors to fix them. If > > > they need to co-ordinate they should know where to go to do it. > > > > > > > Or, y'know, we could just get PI space, > > multihome via BGP, and save ourselves > > all that headache... > > > > ...just sayin'... > > > > Matt > > And when we can support 40 billion routes, PI becomes a viable > solution. Yes, this is the level that PI needs to be able to scale > to for it to be a actual solution. Yes, mutiple routes for every > single person on the planet. > > Until then we need to work towards making renumbering work so PI > isn't needed. > The probability of us figuring out how to scale the routing table to handle 40 billion prefixes is orders of magnitude more likely than solving the headaches associated with dynamic host renumbering. That ship has done gone and sailed, hit the proverbial iceberg, and is gathering barnacles at the bottom of the ocean. It is an ex-solution. It is pushing up the daisies. It has gone to meet its working group. It is no more. (with apologies to Monty Python) Matt > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > --089e0160befad6aa910505942458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 6:05 PM, Mark Andrews <marka@isc.org> wrote:

In message <CAEmG1=3Dr7UdeStcqFjiQRO_Vt1hfR_T4oyTW5FD-eD1ATEXpc6A@ma= il.gmail.com>, Matthew Petach writes:
> --089e013a14fa48fd43050593df5a
> Content-Type: text/plain; charset=3DUTF-8
>
> On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews <marka@isc.org> wrote:
>
> >
> > In message <A7F6BEA0-BCDD-4197-B6CB-7EB8797ACA9C@delong.com>, O= wen DeLong
> > writes:
> > >
> > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <iljitsch@muada.com>
> > wrote:
> > >
> > > > Let me address a few points that were brought up by dif= ferent people.
> > > >
> > > > Renumbering:
> > > >
> > > > We had great plans for making renumbering easy in the e= arly days of
> > IPv6. Remember A6 records and bit
> > > labels in the DNS? But none of that went anywhere. The probl= em isn't so
> > much that we can't push a prefi
> > > x down the network or update the DNS (although both of these= still have
> > challenges associated with them
> > > ), but that addresses tend to get hardcoded all over the pla= ce, starting
> > with firewalls all the way up
> > > to homegrown applications. I don't think renumbering add= resses this
> > issue, although it could help steer
> > >=C2=A0 some smaller organizations away from PI.
> > >
> > > They never went anywhere because they focused on solving the= easy part
> > of the renumbering problem while
> > >=C2=A0 utterly and completely ignoring the hard part.
> > >
> > > Easy part: Changing your stuff.
> > > Hard part: Updating all of the prefix lists, filters, firewa= ll rules,
> > VPN configurations, and other con
> > > figuration elements in systems not under your control that c= ontain your
> > prefixes (partner VPNs, peer ro
> > > uters, etc.).
> >
> > Owen this a collective response to the list.
> >
> > Not all that hard at all.=C2=A0 Just send signed update requests.= =C2=A0 I did
> > that with email over a decade ago.=C2=A0 You just have to have so= mething
> > listening for them that verifies the signature and updates the > > system.
> >
> > Write a draft "Remote Firewall Update Request Protocol"= and submit
> > it.
> >
> > The alternative is stop worrying about the remote address and use=
> > security at the application layer.
> >
> > Or complain to your vendor that you can't use a hostname in t= he
> > configuration file element.=C2=A0 In many cases it doesn't re= quire
> > anything more than looking up a address in the DNS before the
> > operation.=C2=A0 Yes, I need to fix the masters clause in named t= o support
> > this.=C2=A0 We already do something similar for NOTIFY messages s= o it
> > is possible to do this.
> >
> > For masters clauses there is a bootstrap problem to deal with but=
> > it is not impossible.=C2=A0 Just sending periodic NOTIFY messages= will
> > work.=C2=A0 Named has had support to do this for 1 1/2 decades no= w to
> > allow for a a stealth master behind a dial on demand link.=C2=A0 = It would
> > send a notify periodically.=C2=A0 That would bring up the line.= =C2=A0 The
> > slave would refresh and transfer if required.=C2=A0 When that was= complete
> > the idle timer on link would drop it.
> >
> > This just used standard signalling designed by the IETF in a diff= erent
> > way.
> >
> > Stop expecting someone else to *find* and fix these issues for yo= u.
> > You know what the issues are.=C2=A0 Ask your vendors to fix them.= =C2=A0 If
> > they need to co-ordinate they should know where to go to do it. > >
>
> Or, y'know, we could just get PI space,
> multihome via BGP, and save ourselves
> all that headache...
>
> ...just sayin'...
>
> Matt

And when we can support 40 billion routes, PI becomes a viable<= br> solution.=C2=A0 Yes, this is the level that PI needs to be able to scale to for it to be a actual solution.=C2=A0 Yes, mutiple routes for every
single person on the planet.

Until then we need to work towards making renumbering work so PI
isn't needed.


The probability o= f us figuring out how to scale
the routing table to handle 40 billion pr= efixes
is orders of magnitude more likely than solving
the headaches = associated with dynamic host
renumbering.=C2=A0 That ship has done gone = and
sailed, hit the proverbial iceberg, and is gathering
barnacles at= the bottom of the ocean.
It is an ex-solution.
It is pushing up the= daisies.
It has gone to meet its working group.
It is no more.

(with apologies to Monty Python)

=
Matt

=C2=A0

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0INTERNET: marka@isc.org


--089e0160befad6aa910505942458-- From nobody Fri Oct 17 02:11:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C81A9175; Fri, 17 Oct 2014 02:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UteV22rHdxV; Fri, 17 Oct 2014 02:11:02 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE731A916F; Fri, 17 Oct 2014 02:11:02 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E01A92AA0F; Fri, 17 Oct 2014 09:10:58 +0000 (GMT) Date: Fri, 17 Oct 2014 02:11:32 -0700 From: Marc Binderberger To: Nick Hilliard , Iljitsch van Beijnum Message-ID: <20141017021132122119.6274d1f2@sniff.de> In-Reply-To: <54403599.6040205@foobar.org> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/f7Xb3MM1lfN4qG2u_tECFX3LyHM Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 09:11:06 -0000 Hello Nick and Iljitsch, fairly stable baseline of 20-30%, which may be acceptable if it stays there. Although peaks of 70% (is the 100% a graph problem?) seem to be a reason _for_ filtering. Now what I'm wondering (1) is there a need to carry all the deaggregates? Because if you are far enough away they may "look the same as the aggregate". To use Iljitsch' example ... > I know this is controversial. "Topology ain't geography". Actually, most of > the time there is a significant correlation. If all German cities inject a > more specific, do you really need to hear those in Tokyo or Seattle? Just > send the traffic to Europe as per the aggregate and let them figure it out > there. ... it's likely that for an US ISP X, peering with European ISPs Y and Z who carry the various deaggregate plus aggregate from Germany, all the European prefixes have this peering router as next hop (let's say we have next-hop-self). What about BGP on this peering router doing some auto-aggregation in such a case? Has this been discussed? It would avoid geographic communities and would simply follow the BGP topology: if the deaggregates result in the same forwarding information than the aggregate just keep the aggregate. Your routing table would have deaggregates for your own region but only aggregates for the other, more distant regions. (2) the problem of ever-growing routing tables and de-aggregation is not new. After so many years I'm wondering if the answer is that this cannot be solved with BGP/routing alone (?) Otherwise you would have found a solution meanwhile :-) And we have the - understandable and growing - needs of Enterprises, who de-aggregate their PA addresses when they are LIR, or request PI addresses per location. Combining this, should the de-aggregation step not be done with a different technology? LISP comes to my mind (biased, as I'm working on it) or in general a "de-aggregation overlay". The overlay would need gateways to the BGP world and would announce one aggregate prefix only while the de-aggregate prefixes would be limited to the particular Enterprise overlay network and would not show up in BGP. Regards, Marc On Thu, 16 Oct 2014 22:16:09 +0100, Nick Hilliard wrote: > On 16/10/2014 16:47, Iljitsch van Beijnum wrote: >> Growth in IPv6 more specifics was 57% last year... > > Here's a graph which shows the percentage of more-specifics between 2003 > and today from Geoff Huston's web site: > > http://goo.gl/QA0xud > > Eyeballing the graph, it's not clear where the figure of 57% came from. In > terms of trajectories, there doesn't seem to be a major problem either. > > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Oct 17 05:22:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101C31ACD26; Fri, 17 Oct 2014 05:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSQkv8uzbdJB; Fri, 17 Oct 2014 05:22:17 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14E81AC3B1; Fri, 17 Oct 2014 05:22:16 -0700 (PDT) Received: from [192.168.178.23] (5356888C.cm-6-7c.dynamic.ziggo.nl [83.86.136.140]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9HCK7VH070099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 14:20:07 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <20141017021132122119.6274d1f2@sniff.de> Date: Fri, 17 Oct 2014 14:22:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <20141017021132122119.6274d1f2@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0tINgA9DPL9AJm6nRr7Yjw5JerA Cc: IPv6 Operations , "grow@ietf.org grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:22:21 -0000 On 17 Oct 2014, at 11:11, Marc Binderberger wrote: >> If all German cities inject a=20 >> more specific, do you really need to hear those in Tokyo or Seattle? = Just=20 >> send the traffic to Europe as per the aggregate and let them figure = it out=20 >> there. > ... it's likely that for an US ISP X, peering with European ISPs Y and = Z who=20 > carry the various deaggregate plus aggregate from Germany, all the = European=20 > prefixes have this peering router as next hop (let's say we have=20 > next-hop-self). > What about BGP on this peering router doing some auto-aggregation in = such a=20 > case? Has this been discussed? It would avoid geographic communities = and=20 > would simply follow the BGP topology: if the deaggregates result in = the same=20 > forwarding information than the aggregate just keep the aggregate. Yes, this would be another way to address the issue. However, this = introduces a new complication: the presence of prefix Y in the table = depends on the presence of prefix X. Currently, that's taboo in BGP. Note that filtering according to geographic communities could be done = within an AS, removing the need for inter-AS coordination (beyond = propagating the communities). So for instance a network that spans the = US could carry European more specifics on the east coast and Asian more = specifics on the west coast, if they feel that having both sets of more = specifics everywhere would inflate their routing tables too much. > (2) the problem of ever-growing routing tables and de-aggregation is = not new.=20 > After so many years I'm wondering if the answer is that this cannot be = solved=20 > with BGP/routing alone Look at the work in the IRTF routing research group. There are = possibilities to address this, but so far there's always been = significant resistance against the tradeoffs such solutions would = require. Iljitsch= From nobody Fri Oct 17 09:58:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7DF1A026E; Fri, 17 Oct 2014 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVu1UTTxgu2O; Fri, 17 Oct 2014 09:58:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E6A1A1B68; Fri, 17 Oct 2014 09:58:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XfArY-0008TT-Nq; Fri, 17 Oct 2014 16:58:49 +0000 Date: Fri, 17 Oct 2014 09:58:48 -0700 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <54403599.6040205@foobar.org> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jl9y95C1fLORj8cXWpTxo_MTX5w Cc: V6 Ops List , grow Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:58:52 -0000 [ not pickin' on you, nick ] trying to find protein in this whole thread. in the long run, why will v6 not suffer the same deaggregation which is about half of the v4 routing table? maybe if we start filtering now. but we know how well that went in ipv4 when their suits called our suits and said "we pay you to let us contact . 96 more bits, no magic (and 64 of those bits are allocated to relative vacuum) randy From nobody Fri Oct 17 10:08:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47AB1A1B59 for ; Fri, 17 Oct 2014 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrWE-1SUsbf9 for ; Fri, 17 Oct 2014 10:08:02 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75C11A1AEA for ; Fri, 17 Oct 2014 10:08:01 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DA02660785 for ; Fri, 17 Oct 2014 19:07:59 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 986BF6031D for ; Fri, 17 Oct 2014 19:07:59 +0200 (CEST) Received: (qmail 14600 invoked by uid 1007); 17 Oct 2014 19:07:59 +0200 Date: Fri, 17 Oct 2014 19:07:59 +0200 From: Gert Doering To: Nick Hilliard Message-ID: <20141017170759.GS31092@Space.Net> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <543FECB3.9070600@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543FECB3.9070600@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4_JpPVhcWYgpHtX7KIu0BnGl_W8 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:08:05 -0000 Hi, On Thu, Oct 16, 2014 at 05:05:07PM +0100, Nick Hilliard wrote: > On 16/10/2014 16:47, Iljitsch van Beijnum wrote: > > Growth in IPv6 more specifics was 57% last year... > > 1y is an interesting data point, but shouldn't form the basis for a new > policy. What does the aggregate:more-specifics ratio look like over the > last 5-8 years? http://www.space.net/~gert/RIPE/weekly/2014/41/ has a breakdown "last year" and "last 5 years" of "LIR exact", "LIR more-specific", "non-LIR" (=PI), "non-LIR more-specifics" - look for the heading "Routing Table by Class of Prefix". The "LIR exact" curve is fairly linear, while the "more specific" curve is growing stronger than linear. No predictions here, though. (You've propably seen this slide deck before - it's the "IPv6 routing table talk" numbers fed into a daily-updated cronjob) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Oct 17 11:13:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D51A0024; Fri, 17 Oct 2014 11:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjCrIuBqKBHa; Fri, 17 Oct 2014 11:13:21 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A5A1A0007; Fri, 17 Oct 2014 11:13:21 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so1265605pab.32 for ; Fri, 17 Oct 2014 11:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VQNm2xOzkzYlFPFffXy7w/wd+lSnI8LW1x/YpjC+rGg=; b=NjxuD/kbuJQIllK9pOQL3/LvTOH9vkDTfb++gQbP1ojdTqjnLW6okKGQu7Uf9soYEB TQHAKKERvhiayKTy2hcYZadRMK8+8NDNAGQUbpEvcQJGoXclIyFld4Ghz1H7dD53bEnR 4VcqusR3V1ZIev0GNlPLy9n+hRJykjwyNj5/ldT7SuTyM9ipAqqn5klDtcx4w0HOAXV0 ir1wvwT4226xT1T5p3bWjQYER1VnC4Irb5dYjn0zavPy6ZSX6wr8sVUpeThdtQQrOwYY ZegMO4J1LxJVIUn6bsiFkeMpOQy1DwFvLYO5TC6hIj579Ns0SQIAxMJrr7ZVwxcUrcJQ A6lw== X-Received: by 10.70.65.37 with SMTP id u5mr10178782pds.93.1413569601412; Fri, 17 Oct 2014 11:13:21 -0700 (PDT) Received: from [172.17.1.55] (219-89-120-188.adsl.xtra.co.nz. [219.89.120.188]) by mx.google.com with ESMTPSA id m1sm2149602pdm.53.2014.10.17.11.13.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 11:13:20 -0700 (PDT) Message-ID: <54415C47.20508@gmail.com> Date: Sat, 18 Oct 2014 07:13:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IFkoPzsXFNKwzlANeL1P7G0HfAI Cc: V6 Ops List , grow Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:13:23 -0000 On 18/10/2014 05:58, Randy Bush wrote: > [ not pickin' on you, nick ] > > trying to find protein in this whole thread. > > in the long run, why will v6 not suffer the reasons goes here> same deaggregation which is about half of the v4 > routing table? I see no reason why it will be fundamentally different unless sites start using the multi-prefix model of addressing, which would change the game by allowing a site to be in multiple aggregates simultaneously. I don't know exactly what impact that would have, but it would change the game. Alternatively we could abolish capitalism. Brian > > maybe if we start filtering now. but we know how well that went in ipv4 > when their suits called our suits and said "we pay you to let us contact > . > > 96 more bits, no magic (and 64 of those bits are allocated to relative > vacuum) > > randy > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Oct 17 11:18:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C986C1A0007; Fri, 17 Oct 2014 11:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8SKFDsbKec9; Fri, 17 Oct 2014 11:18:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC401A00BF; Fri, 17 Oct 2014 11:18:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XfC6z-0000Jk-Gr; Fri, 17 Oct 2014 18:18:49 +0000 Date: Fri, 17 Oct 2014 11:18:49 -0700 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <54415C47.20508@gmail.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <54415C47.20508@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v6LExTuFLa4S8yj7-SFveCCbTFM Cc: V6 Ops List , grow Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:18:54 -0000 >> in the long run, why will v6 not suffer the > reasons goes here> same deaggregation which is about half of the v4 >> routing table? > I see no reason why it will be fundamentally different unless sites > start using the multi-prefix model of addressing, which would change > the game by allowing a site to be in multiple aggregates > simultaneously. and deaggregate them all :( > Alternatively we could abolish capitalism. no, just capitalization randy From nobody Fri Oct 17 13:46:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA0B1A6FD2; Fri, 17 Oct 2014 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uaf4nAykKQQZ; Fri, 17 Oct 2014 13:46:19 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA85B1A0102; Fri, 17 Oct 2014 13:46:18 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9HKjfra080994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 21:46:02 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <54417FF4.3000907@foobar.org> Date: Fri, 17 Oct 2014 21:45:40 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Randy Bush References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oyxvUaCauqymhv9DKks2Ch-SeY0 Cc: V6 Ops List , grow Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 20:46:21 -0000 On 17/10/2014 17:58, Randy Bush wrote: > [ not pickin' on you, nick ] > > trying to find protein in this whole thread. thin pickings :-( > in the long run, why will v6 not suffer the reasons goes here> same deaggregation which is about half of the v4 > routing table? It might, but it won't matter as much because the number of baseline ipv6 allocations will be a whole pile lower. Here's why. 1. retrospectively: the RIR policies of not handing out piecemeal allocations based on 2Y policy means that most organisations will never need a second allocation outside their /32. If you look at existing RIR allocations, many of them are to the same organisations. Looking at: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt There are: 7564 LIRs with ipv4 allocations outside 185/8 19856 ipv4 allocations outside 185/8 so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses. Over all allocations, the numbers are 24416 allocations and 10134 LIRs. I.e. the last /8 policy has dramatically increased the number of LIRs with a single allocation. Possibly this is related to lack of PI space. RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate of 1.02. This includes last /8 assignments from RIPE's silly policy of requiring an ipv6 allocation for a last /8 assignment. This indicates that virtually all LIRs are staying within the bounds of their original allocations. This will reduce future pressure on the number of prefixes in the dfz. 2. in future: there are 10398 LIRs listed in alloclist. Of these, 7849 or almost exactly 75% of LIRs already have IPv6 allocations. So assuming that all RIPE LIRs will have an ipv6 allocation in future, that's growth from 8069 to ~10700 + one for each new LIR. 3. further deaggregation of the ipv4 dfz will be driven by the market economics of address holders splitting up their net blocks. 4. down the road, if we can get RIPE to stop its silly policy of requiring an ipv6 allocation in order to get an ipv4 allocation from the last /8, this will further reduce pressure on the overall number of allocations, which leads to: > maybe if we start filtering now. but we know how well that went in ipv4 > when their suits called our suits and said "we pay you to let us contact > . The baseline for starting to deaggregate will be much lower for ipv6 and there will be much less pressure in future to deaggregate. I haven't looked at the other RIR figures. No doubt they differ in numbers, but my hunch is that they tell a similar story. Nick From nobody Sat Oct 18 02:06:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0A1A1A80; Sat, 18 Oct 2014 02:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI0JJbrm_U_k; Sat, 18 Oct 2014 02:06:10 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1883A1A1A86; Sat, 18 Oct 2014 02:06:10 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id uq10so4058456igb.4 for ; Sat, 18 Oct 2014 02:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fn5piYhqt53H41EVfGeRbq9z7jxLZNueHOkN0XNVvZ0=; b=nciCk5wy1fvSNNOD9krMZtjCQVlttZbe7oCOAG3j10U5tVj88nAum1ry0PUNgJDSTa I8rOG6l0W6koi5Mspj8eyxuTR06PuDOmeJ6sOc3L9Y+3I0Woe2HzaW6FkG4gqQCqtble VLOsz0BXek171BoOkRG4JoJLDs80A0CFbVQ6o8pVp48JspeaMHKn+7OYf4BtVb9eBfv1 /X7NvyVvqO1FkTtgZBQRsnKhqFcOoGD5cPyVfFSfesQT8blau6hSQowvaCCLdhpGU8U9 9xlIUZCjNSMH4JUDg8r9RNjQ5ELdUrksjacrq3+SMkO6Rb2a1BSiwUPnS0hy6nUoW+mi RYIg== MIME-Version: 1.0 X-Received: by 10.107.172.210 with SMTP id v201mr14471606ioe.19.1413623169474; Sat, 18 Oct 2014 02:06:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Sat, 18 Oct 2014 02:06:09 -0700 (PDT) In-Reply-To: References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <20141017021132122119.6274d1f2@sniff.de> Date: Sat, 18 Oct 2014 11:06:09 +0200 X-Google-Sender-Auth: vfKs1cRGXkPe5ZtsicIEWpGMk9A Message-ID: From: Robert Raszuk To: Pedro Andres Aranda Gutierrez Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/telhPmz8-C9ehW8z1VwQDNCO6lk Cc: V6 Ops List , "grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 09:06:11 -0000 > IPv6 BPs could mandate best aggregates only. You can't *mandate* anything in BGP until you have a way to effectively enforce it regardless if this is v4 or v6 or v9. It is not the problem of folks in shorts and sandals who type in BGP policies, but as Randy said those in suits who care about their respective businesses. Today at most we can have Geoff very nicely illustrating the picture at next RIPE or NANOG. But he does not have a way to issue fine tickets to offenders :) Best, r. From nobody Sat Oct 18 03:09:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55001A1B8B; Sat, 18 Oct 2014 03:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L36mOX63ee6I; Sat, 18 Oct 2014 03:09:27 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DDE1A1B88; Sat, 18 Oct 2014 03:09:26 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::1d9]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9IA9LAg089085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Oct 2014 11:09:21 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::1d9] claimed to be cupcake.foobar.org Message-ID: <54423C50.5040801@foobar.org> Date: Sat, 18 Oct 2014 11:09:20 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Robert Raszuk , Pedro Andres Aranda Gutierrez References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <20141017021132122119.6274d1f2@sniff.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Xdtc0--6Y7WLXcyVv3nkA_NAij4 Cc: V6 Ops List , "grow@ietf.org" Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 10:09:30 -0000 On 18/10/2014 10:06, Robert Raszuk wrote: > You can't *mandate* anything in BGP until you have a way to > effectively enforce it regardless if this is v4 or v6 or v9. it's a common misconception that bgp is a stick to beat people with, and that the RIRs are the routing police. Nick From nobody Sun Oct 19 11:00:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9E21A1AA9 for ; Sun, 19 Oct 2014 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51yvJvkpo00q for ; Sun, 19 Oct 2014 11:00:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEABD1A19FE for ; Sun, 19 Oct 2014 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=634; q=dns/txt; s=iport; t=1413741604; x=1414951204; h=date:from:message-id:to:subject:cc; bh=7JS95kDRJ8jKyrLfgzh+vHnzUE01AzIzxu0uYXvF0N0=; b=T0emZ/4Gd14jwL37BHbdrB7YULQOBThqPX4GvzppRvxK/na4aKEROESt 1Xucacu4424sSDOIrZp2aN+A96jD6sslrFHMgdz8sgDeWtGyicbdqDwT5 ovId42k95VXRzBfHqgf2MpGiRGdt3xP0uf2MgekT8MjvtnMYFFnTuojl0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEJAFH6Q1StJV2b/2dsb2JhbABbgwtTWbw4AY9dh06BEBYBfYUCPDSJHwENv1EBAQEHAQEBAR6QUR2ENQWLYopkiEM8gwqDLYl+hAGEF4MXAQEB X-IronPort-AV: E=Sophos;i="5.04,749,1406592000"; d="scan'208";a="364579956" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 19 Oct 2014 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9JI02Qh018399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Oct 2014 18:00:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s9JI02pZ029922; Sun, 19 Oct 2014 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s9JI02XP029920; Sun, 19 Oct 2014 11:00:02 -0700 Date: Sun, 19 Oct 2014 11:00:02 -0700 From: fred@cisco.com Message-Id: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lQiBJpv1o6Bb2UMq1fb7e-PIB-c Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 18:00:06 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun Oct 19 15:54:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3059F1A1A0D; Sun, 19 Oct 2014 15:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBxvBZV9lQfR; Sun, 19 Oct 2014 15:54:07 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58FC1A0673; Sun, 19 Oct 2014 15:54:06 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9JMreFi034296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 19 Oct 2014 22:53:40 GMT (envelope-from joelja@bogus.com) Message-ID: <54444107.2000908@bogus.com> Date: Sun, 19 Oct 2014 15:53:59 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> In-Reply-To: <20141002154553.11969.98465.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7m8SH4QQttGT1LF7CfR7O497OCuBbiLgr" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P7pg87a-daShy95gmqIenbKiQzU Cc: v6ops@ietf.org, V6ops Chairs , "" Subject: Re: [v6ops] Last Call: (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 22:54:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7m8SH4QQttGT1LF7CfR7O497OCuBbiLgr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Summarizing What I see here. The concerns about the breadth or appropriateness of the document are well understood. The will never be entirely ameliorated but I think we can live with them. The substantial changes between the previous last call around draft 8 and the present one draft 13 produced something that I think with minor misgivings represents working group output and IETF consensus. Concerns with requirements for PCP exist related the privacy implications for such direct mappings, we were mindful of in the context of RFC 6887 which we saw fit to publish so I don't see a reason understanding that, that we would take PcP off the table at this time. I would characterize the consensus as good enough and would thank those who invested the time, in commenting and contributing. Thanks joel On 10/2/14 8:45 AM, The IESG wrote: >=20 > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Device= s' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-10-16. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > This is the second iteration of this document to be IETF Last Called ha= ving > previously been here at draft 04. Substantial changes to the document h= ave=20 > occurred inclusive of the removal of much of the normative language.=20 >=20 > Abstract >=20 >=20 > This document defines an IPv6 profile that a number of operators > recommend in order to connect 3GPP mobile devices to an IPv6-only or= > dual-stack wireless network (including 3GPP cellular network and IEE= E > 802.11 network). >=20 > This document defines a different profile than the one for general > connection to IPv6 cellular networks defined in the IPv6 for Third > Generation Partnership Project (3GPP) Cellular Hosts document. In > particular, this document identifies also features to deliver IPv4 > connectivity service over an IPv6-only transport. >=20 > Both hosts and devices with capability to share their WAN (Wide Area= > Network) connectivity are in scope. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/= >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/= ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 --7m8SH4QQttGT1LF7CfR7O497OCuBbiLgr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlREQQcACgkQ8AA1q7Z/VrLWEQCghOu5ozNwfi0kCx9a/yc2vKfG ascAoIe6rSc831dZHIGhQxuOm//faFbf =SfIY -----END PGP SIGNATURE----- --7m8SH4QQttGT1LF7CfR7O497OCuBbiLgr-- From nobody Sun Oct 19 19:46:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C758D1A1B03; Sun, 19 Oct 2014 19:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97TTwrnJ5rzG; Sun, 19 Oct 2014 19:46:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5731A1B17; Sun, 19 Oct 2014 19:46:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141020024620.21236.47625.idtracker@ietfa.amsl.com> Date: Sun, 19 Oct 2014 19:46:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7SamTZAHKSE1PrQ7fr8pVZSf3l0 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-roaming-analysis-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 02:46:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis of Failure Cases in IPv6 Roaming Scenarios Authors : Gang Chen Hui Deng Dave Michaud Jouni Korhonen Mohamed Boucadair Vizdal Ales Filename : draft-ietf-v6ops-ipv6-roaming-analysis-07.txt Pages : 19 Date : 2014-10-19 Abstract: This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-roaming-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-roaming-analysis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 20 11:13:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A355F1A8A08 for ; Mon, 20 Oct 2014 11:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqHVTVpiNyHT for ; Mon, 20 Oct 2014 11:13:00 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BADA1A8A86 for ; Mon, 20 Oct 2014 11:12:59 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so7094233wid.13 for ; Mon, 20 Oct 2014 11:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wd+RFhrdjbn0GbujmskFSfGVxys/YVN9QpUYECGRQr8=; b=CiG8fsih3k9RBCqtT87ryL498Wt94h9CoA8AqO5TXzJ9FKUbHZAGc51U+HBtEHL8+n Y3umTk9/ENPU1wDBd24NKdFxBtXn586CWRSBIncKQuO0/xOsu3TtyRkWJDw8cJdjs208 SIg8wtICnZ/9XM4v0vDpsXcKYLX8qFRzA8TxnH/GQiiqx02oDMrcxquR9GQ0twJ2Wo9D S9L1LWWBszS0zpeGXPx+QRe/WFL+xSCCCx8jc+dwNH9KHqQx8wwRpijqgn0ko9oF2TYW NiQrmqvFEaiWNTHh0DDU9v8gURNCGaqAvKtq/qWcU5RAgljTVIlsZmQYso16PdQHcEez tg1Q== MIME-Version: 1.0 X-Received: by 10.194.58.8 with SMTP id m8mr36129978wjq.43.1413828778605; Mon, 20 Oct 2014 11:12:58 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.79.202 with HTTP; Mon, 20 Oct 2014 11:12:58 -0700 (PDT) In-Reply-To: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> Date: Mon, 20 Oct 2014 11:12:58 -0700 X-Google-Sender-Auth: 6RY_UiLpe_mwbuzpko71ToveZyQ Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1z_4FiC2AbFo4TxbjCSfRb6i4dI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:13:01 -0000 At Sun, 19 Oct 2014 11:00:02 -0700, fred@cisco.com wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. I have a mixed feeling about the importance of the document. I personally don't think it worth publishing in its current form, although I wouldn't be opposed to it if the wg thinks it's useful. Vagueness and ambiguity regarding M, O, and A flags (especially the first two) are well known, and it's not surprising that different implementations behave differently. Since such a divergence can cause a critical operational issue, I see a value in documenting these. On the other hand, the specific issues described in Section 3.2 don't seem to be very critical to me. In the case described in Section 3.2.1, the host would only have link-local addresses. Such a host wouldn't be able to do many useful things anyway (potentially, there may be some interesting scenarios for a completely isolated, single-link, autonomous network with only link-local addresses, but I suspect there are many other fundamental issues to solve for such environments before we even worry about the M/O/A flags). The issues described in Section 3.2 seem to be caused largely because they switch the address configuration mechanism (SLAAC to DHCPv6 or vice versa) in addition to renumbering. While that could happen in theory, it seems to be a quite artificial discussion. Actually, I guess there should be more pragmatic examples of operational issues because of the described divergence and I wonder whether these minor cases are really the only things we can imagine (although I don't have a specific idea right now). If these sections can be revised with more convincing examples, I would be more supportive about publishing it. Some specific comments (mostly editorial and nits) on the draft text: - Section 1: The M, O and A flags are advisory, not prescriptive. In my understanding, the A flag is quite prescriptive. If a host implementation doesn't perform SLAAC for a prefix information option with A flag on, that implementation would be considered non-compliant. At the very least, the level of "advisory" vs "prescriptive" is much different between M,O and A, so listing all of them in this sentence seems to be misleading, if not simply incorrect. - Section 2.1: s/setting/settings/ [...] The following setting are all allowed: - Section 2.2: s/setting/settings/ [...] The following setting are all allowed: -- JINMEI, Tatuya From nobody Mon Oct 20 14:59:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18B81ACF64; Mon, 20 Oct 2014 14:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_PAIN=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8j-ztS9lvM8; Mon, 20 Oct 2014 14:59:06 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2451ACF6C; Mon, 20 Oct 2014 14:58:51 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id f73so4153771yha.5 for ; Mon, 20 Oct 2014 14:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IJSGlD0IcSaHmst6F14p+dAWasOywL3dCKWO3W7QG8g=; b=FnwHcJ/OASdfdTgpqCoZ7HbNAbO8a7eChVhEU/CnVgmwalp12ri6k2PBmhEHeoQRYL nRWBJZvsJ+k1bWm3J8I7Y4cuhls7x+nYf18tCV2I2AueN7vWzJDu8LSNDmUnK3swvA/B qWsW4f6O0mJjPSZAcRjAjs6wqtktzuoI8Acj0vF2g4N4b0lJrQTRXJO2V1XbRbg0PKA6 sVe4EH9ijU8xmA65Zb326dj8MmX/DsPY9wjom4kJtx8oGFomwIlPL0r9RQz5Fd9XzoJp KyTzhRTL0G3sJ5VZxget3xi5HxK1tiPtHWvpGpLXLDgqeaZSeJeDN/RrgxXrf8BnCuvS BE3Q== MIME-Version: 1.0 X-Received: by 10.220.97.72 with SMTP id k8mr25719389vcn.5.1413842330781; Mon, 20 Oct 2014 14:58:50 -0700 (PDT) Received: by 10.221.44.8 with HTTP; Mon, 20 Oct 2014 14:58:50 -0700 (PDT) In-Reply-To: <54417FF4.3000907@foobar.org> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <54417FF4.3000907@foobar.org> Date: Mon, 20 Oct 2014 17:58:50 -0400 Message-ID: From: Christopher Morrow To: Nick Hilliard Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5N9kMZvXmmNSf9ipC-Nf2Epyjfc Cc: V6 Ops List , grow Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:59:09 -0000 On Fri, Oct 17, 2014 at 4:45 PM, Nick Hilliard wrote: > On 17/10/2014 17:58, Randy Bush wrote: >> [ not pickin' on you, nick ] >> >> trying to find protein in this whole thread. > > thin pickings :-( > >> in the long run, why will v6 not suffer the > reasons goes here> same deaggregation which is about half of the v4 >> routing table? > > It might, but it won't matter as much because the number of baseline ipv6 > allocations will be a whole pile lower. Here's why. > > 1. retrospectively: the RIR policies of not handing out piecemeal > allocations based on 2Y policy means that most organisations will never > need a second allocation outside their /32. If you look at existing RIR > allocations, many of them are to the same organisations. Looking at: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > There are: > > 7564 LIRs with ipv4 allocations outside 185/8 > 19856 ipv4 allocations outside 185/8 > > so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses. wow, there are 4454 LIR allocations inside 185/8 :) with: 4568 distinct prefixes. (that's probably reasonably expected though) > Over all allocations, the numbers are 24416 allocations and 10134 LIRs. > I.e. the last /8 policy has dramatically increased the number of LIRs with > a single allocation. Possibly this is related to lack of PI space. is this also skewed because 'space is getting short, make sure to get your requests in NOW!' behavior? (or 'scarcity got people's attention') I guessed (so probably not the best judge for science) that 62/8 was being allocated for a longer bit of time, it seems: Apr 1997 -> Mar 2011 There are 671 allocations in this space though, across 457 LIRs or 1.49 prefixes/LIR... so it seems that the numbers oscillate a bit inside of the buckets, interesting I suppose. (perhaps not super germaine though) NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in their entries? 20121123 185.11.8.0/22 ALLOCATED PA 20101023 2a02:2718::/29 despite: inet6num: 2a02:2718::/29 netname: YE-PTC-20101023 descr: Public Telecommunication Corporation country: ye org: ORG-PTC4-RIPE admin-c: YAA330-RIPE admin-c: IIA13-RIPE tech-c: MRA220-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT > RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate > of 1.02. This includes last /8 assignments from RIPE's silly policy of > requiring an ipv6 allocation for a last /8 assignment. > > This indicates that virtually all LIRs are staying within the bounds of > their original allocations. This will reduce future pressure on the number > of prefixes in the dfz. I also wonder how much the spread of LIR/org really is? for MDN or other uses of 'oops, I need another /32'. > 2. in future: there are 10398 LIRs listed in alloclist. Of these, 7849 or > almost exactly 75% of LIRs already have IPv6 allocations. So assuming that > all RIPE LIRs will have an ipv6 allocation in future, that's growth from > 8069 to ~10700 + one for each new LIR. > > 3. further deaggregation of the ipv4 dfz will be driven by the market > economics of address holders splitting up their net blocks. > > 4. down the road, if we can get RIPE to stop its silly policy of requiring > an ipv6 allocation in order to get an ipv4 allocation from the last /8, > this will further reduce pressure on the overall number of allocations, > which leads to: > >> maybe if we start filtering now. but we know how well that went in ipv4 >> when their suits called our suits and said "we pay you to let us contact >> . > > The baseline for starting to deaggregate will be much lower for ipv6 and > there will be much less pressure in future to deaggregate. why is that? I thought geoff's numbers/reasons for deaggregation were linked more to TE (perceived or supposed) than anything else? (maybe a bunch of 'redistributed connected' as well) -chris > I haven't looked at the other RIR figures. No doubt they differ in > numbers, but my hunch is that they tell a similar story. > > Nick > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From nobody Mon Oct 20 15:09:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E61ACF18; Mon, 20 Oct 2014 15:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PAIN=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acN8Eh8bE0W9; Mon, 20 Oct 2014 15:08:15 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD4F1ACE89; Mon, 20 Oct 2014 15:08:14 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::1d9]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9KM84Uw021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 23:08:04 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::1d9] claimed to be cupcake.foobar.org Message-ID: <544587C3.10204@foobar.org> Date: Mon, 20 Oct 2014 23:08:03 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christopher Morrow References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <54417FF4.3000907@foobar.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KVUckREc1J9Iz-3vuTMshIJcwEw Cc: V6 Ops List , grow Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 22:08:17 -0000 On 20/10/2014 22:58, Christopher Morrow wrote: > NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in > their entries? because there are only two types of v6 blocks: ALLOCATED PA and ASSIGNED PA. The assignments aren't in that document and for v4, there are several types of status: ASSIGNED PA, ASSIGNED PI, ALLOCATED PA, ALLOCATED PI, EARLY REGISTRATION OR LIR-PARTITIONED. >> The baseline for starting to deaggregate will be much lower for ipv6 and >> there will be much less pressure in future to deaggregate. > > why is that? I thought geoff's numbers/reasons for deaggregation were > linked more to TE (perceived or supposed) than anything else? (maybe a > bunch of 'redistributed connected' as well) the baseline is lower because we're starting off with a situation where most LIRs have been allocated all the ipv6 address space they will ever need. The deaggregation pressure will be lower because the only deaggregation pressure will be from TE and there will be no need to slide-n-dice IPv6 address blocks in future asset sales, and no last /20 per RIR. IPv4 space has deaggregation pressure from last /8 assignments, from TE requirements and will have future pressure from asset sales. Once divided, the allocations will be impossible to reaggregate. Nick From nobody Mon Oct 20 15:41:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A751A00D6; Mon, 20 Oct 2014 15:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jCoQzWgasTB; Mon, 20 Oct 2014 15:41:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5941ACF8C; Mon, 20 Oct 2014 15:41:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XgLe6-00075y-8G; Mon, 20 Oct 2014 22:41:46 +0000 Date: Tue, 21 Oct 2014 07:41:43 +0900 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <544587C3.10204@foobar.org> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <54417FF4.3000907@foobar.org> <544587C3.10204@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uwTXJqKDWjl7C9Dci7L2zTrNYFc Cc: V6 Ops List , GROW List Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 22:41:49 -0000 > The deaggregation pressure will be lower because the only deaggregation > pressure will be from TE funny, that was not the case with v4 four years ago Luca Cittadini, Wolfgang M=C3=BChlbauer, Steve Uhlig, Randy Bush, Pierre Francois, Olaf Maennel, Evolution of Internet Address Space Deaggregation: Myths and Reality, in IEEE Journal on Selected Areas in Communications, Vol. 28, No. 8, October 2010. there seems to be a lot of deagg because of the perception that it reduces the threat of mis-origination of one's routes. asia/pac is the poster child for this but the competition is keen, see geoff's reports. tl;dr (from the abstract): The impact of =E2=80=9Cbad guys=E2=80=9D on routing table size growth a= nd BGP churn has not changed for the worse in recent years. Rather, it increases at the same pace as the Internet itself. randy From nobody Mon Oct 20 17:15:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51B01ACF96; Mon, 20 Oct 2014 17:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5iXCSwXDYVS; Mon, 20 Oct 2014 17:15:10 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFDA1ACF8B; Mon, 20 Oct 2014 17:15:09 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::1d9]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9L0Evli022647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 01:14:58 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::1d9] claimed to be cupcake.foobar.org Message-ID: <5445A581.5020903@foobar.org> Date: Tue, 21 Oct 2014 01:14:57 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Randy Bush References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <54417FF4.3000907@foobar.org> <544587C3.10204@foobar.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PImNwQJ3aQ_VoSe6FXKNZFPq4Do Cc: V6 Ops List , GROW List Subject: Re: [v6ops] [GROW] Deaggregation data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 00:15:11 -0000 On 20/10/2014 23:41, Randy Bush wrote: > there seems to be a lot of deagg because of the perception that it > reduces the threat of mis-origination of one's routes. asia/pac is the > poster child for this but the competition is keen, see geoff's reports. this could be highly entertaining in the ipv6 world. Nick From nobody Mon Oct 20 20:25:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582C61ACF94 for ; Mon, 20 Oct 2014 20:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HaQq8Fh1UWw for ; Mon, 20 Oct 2014 20:25:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2D51AD003 for ; Mon, 20 Oct 2014 20:25:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW13622; Tue, 21 Oct 2014 03:25:32 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 04:25:31 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 11:25:28 +0800 From: "Liubing (Leo)" To: =?gb2312?B?yfHD999f1NU=?= , "Fred Baker (fred)" Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w4xUoAgAEA2GA= Date: Tue, 21 Oct 2014 03:25:27 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589D977B@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jFDHQiDiiuVfX1WIxVzK6G4Q1Uc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 03:25:37 -0000 SGkgSmlubWVpLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgcmVwbGll cyBpbmxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgyfHD999f1NUNCj4g U2VudDogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCAyOjEzIEFNDQo+IFRvOiBGcmVkIEJha2Vy IChmcmVkKQ0KPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJh ZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbSBXR0xDDQo+IA0KPiBBdCBTdW4sIDE5 IE9jdCAyMDE0IDExOjAwOjAyIC0wNzAwLA0KPiBmcmVkQGNpc2NvLmNvbSB3cm90ZToNCj4gDQo+ ID4gVGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IG9mDQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1kaGNw djYtc2xhYWMtcHJvYmxlbS4NCj4gPiBQbGVhc2UgcmVhZCBpdCBub3cuIElmIHlvdSBmaW5kIG5p dHMgKHNwZWxsaW5nIGVycm9ycywgbWlub3Igc3VnZ2VzdGVkDQo+ID4gd29yZGluZyBjaGFuZ2Vz LCBldGMpLCBjb21tZW50IHRvIHRoZSBhdXRob3JzOyBpZiB5b3UgZmluZCBncmVhdGVyDQo+ID4g aXNzdWVzLCBzdWNoIGFzIGRpc2FncmVlaW5nIHdpdGggYSBzdGF0ZW1lbnQgb3IgZmluZGluZyBh ZGRpdGlvbmFsDQo+ID4gaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQsIHBsZWFzZSBw b3N0IHlvdXIgY29tbWVudHMgdG8gdGhlDQo+ID4gbGlzdC4NCj4gPg0KPiA+IFdlIGFyZSBsb29r aW5nIHNwZWNpZmljYWxseSBmb3IgY29tbWVudHMgb24gdGhlIGltcG9ydGFuY2Ugb2YgdGhlDQo+ ID4gZG9jdW1lbnQgYXMgd2VsbCBhcyBpdHMgY29udGVudC4gSWYgeW91IGhhdmUgcmVhZCB0aGUg ZG9jdW1lbnQgYW5kDQo+ID4gYmVsaWV2ZSBpdCB0byBiZSBvZiBvcGVyYXRpb25hbCB1dGlsaXR5 LCB0aGF0IGlzIGFsc28gYW4gaW1wb3J0YW50DQo+ID4gY29tbWVudCB0byBtYWtlLg0KPiANCj4g SSBoYXZlIGEgbWl4ZWQgZmVlbGluZyBhYm91dCB0aGUgaW1wb3J0YW5jZSBvZiB0aGUgZG9jdW1l bnQuICBJIHBlcnNvbmFsbHkNCj4gZG9uJ3QgdGhpbmsgaXQgd29ydGggcHVibGlzaGluZyBpbiBp dHMgY3VycmVudCBmb3JtLCBhbHRob3VnaCBJIHdvdWxkbid0IGJlDQo+IG9wcG9zZWQgdG8gaXQg aWYgdGhlIHdnIHRoaW5rcyBpdCdzIHVzZWZ1bC4NCj4gDQo+IFZhZ3VlbmVzcyBhbmQgYW1iaWd1 aXR5IHJlZ2FyZGluZyBNLCBPLCBhbmQgQSBmbGFncyAoZXNwZWNpYWxseSB0aGUgZmlyc3QgdHdv KQ0KPiBhcmUgd2VsbCBrbm93biwgYW5kIGl0J3Mgbm90IHN1cnByaXNpbmcgdGhhdCBkaWZmZXJl bnQgaW1wbGVtZW50YXRpb25zIGJlaGF2ZQ0KPiBkaWZmZXJlbnRseS4gIFNpbmNlIHN1Y2ggYSBk aXZlcmdlbmNlIGNhbiBjYXVzZSBhIGNyaXRpY2FsIG9wZXJhdGlvbmFsIGlzc3VlLCBJDQo+IHNl ZSBhIHZhbHVlIGluIGRvY3VtZW50aW5nIHRoZXNlLg0KW0JpbmddIEkgYmVsaWV2ZSBpdCBpcyB3 ZWxsIGtub3duIGFtb25nIHN0YW5kYXJkIGRldmVsb3BlcnMsIHBhcnRpY2lwYW50cyBhbmQgaW1w bGVtZW50ZXJzIHdobyBoYWQgcGFpZCBhdHRlbnRpb24gb24gaXQuIEhvd2V2ZXIsIHNpbmNlIHRo ZSBhbWJpZ3VpdHkgcHJvYmxlbSBpcyBub3Qgc28gZXhwbGljaXQgaW4gY3VycmVudCBzdGFuZGFy ZCwgdGhlIHZhc3QgYWRtaW5pc3RyYXRvcnMvb3BlcmF0b3JzIG91dCBJRVRGIG1pZ2h0IG5vdCBx dWl0ZSBmYW1pbGlhciB3aXRoIGl0LiBJIG9uY2UgdGFsa2VkIHdpdGggc29tZSBvcGVyYXRvciBw ZW9wbGUsIHRoZXkgd2VyZSBxdWl0ZSBjb25mdXNlZCBhYm91dCB0aGUgc2l0dWF0aW9uIHdoZW4g dGhleSBtZXQgdGhlIHByb2JsZW0gaW4gdGhlaXIgSVB2NiB0ZXN0YmVkIG5ldHdvcmtzLiANClNv LCBpZiB0aGVyZSBpcyBhbiBSRkMgZXhwbGljaXRseSBzdGF0aW5nIHRoZSBwcm9ibGVtcywgSSB0 aGluayBpdCB3b3VsZCBiZSBnb29kIGZvciBhZG1pbmlzdHJhdG9ycy9vcGVyYXRvcnMgdG8gbGVh cm4gdGhlIGZhY3QgYmVmb3JlIHRoZXkgYWN0dWFsbHkgZGVwbG95aW5nIHRoZSBuZXR3b3Jrcy4g QWxzbywgdGhlIGRvY3VtZW50IGNvdWxkIGJlIGEgZm9ybWFsIHJlZmVyZW5jZSBmb3IgcG90ZW50 aWFsIHN0YW5kYXJkIHdvcmsgaW4gdGhlIGZ1dHVyZSB0byBjbGVhciB0aGUgYW1iaWd1aXR5IGlu IGN1cnJlbnQgc3RhbmRhcmRzLg0KDQo+IE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgc3BlY2lmaWMg aXNzdWVzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMiBkb24ndCBzZWVtIHRvDQo+IGJlIHZlcnkg Y3JpdGljYWwgdG8gbWUuDQpbQmluZ10gSSBhZ3JlZSB0aGUgaXNzdWVzIG1pZ2h0IG5vdCBiZSBj cml0aWNhbCBmb3Igc29tZSBwZW9wbGUuIEJ1dCBtYXliZSB0aGV5IGFyZSBpbXBvcnRhbnQgY29u Y2VybnMgaW4gb3RoZXIgc2l0dWF0aW9ucy4gQ29uc2lkZXJpbmcgd2UgYXJlIGp1c3QgYXQgdGhl IGJlZ2lubmluZyBzdGFnZSBvZiBkZXBsb3lpbmcgSVB2NiwgSXQgbWlnaHQgYmUgaGFyZCBmb3Ig dXMgdG8ganVkZ2UgdGhlIGltcG9ydGFuY2UsIGJ1dCB3ZSBjb3VsZCBkb2N1bWVudCB0aGUgaXNz dWVzLCBhdCBsZWFzdCBpdCBpcyBub3QgaGFybWZ1bC4gDQoNCj4gSW4gdGhlIGNhc2UgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy4yLjEsIHRoZSBob3N0IHdvdWxkIG9ubHkgaGF2ZSBsaW5rLWxvY2Fs DQo+IGFkZHJlc3Nlcy4gDQpbQmluZ10gT3IgbWF5YmUgc2VsZi1nZW5lcmF0ZWQgVUxBcy4gKEJ1 dCBvZiBjb3Vyc2UsIGl0IGlzIG5vdCB0aGUgcG9pbnQgb2YgdGhpcyBkb2N1bWVudC4pDQoNCj4g U3VjaCBhIGhvc3Qgd291bGRuJ3QgYmUgYWJsZSB0byBkbyBtYW55IHVzZWZ1bCB0aGluZ3MgYW55 d2F5DQo+IChwb3RlbnRpYWxseSwgdGhlcmUgbWF5IGJlIHNvbWUgaW50ZXJlc3Rpbmcgc2NlbmFy aW9zIGZvciBhIGNvbXBsZXRlbHkNCj4gaXNvbGF0ZWQsIHNpbmdsZS1saW5rLCBhdXRvbm9tb3Vz IG5ldHdvcmsgd2l0aCBvbmx5IGxpbmstbG9jYWwgYWRkcmVzc2VzLCBidXQNCj4gSSBzdXNwZWN0 IHRoZXJlIGFyZSBtYW55IG90aGVyIGZ1bmRhbWVudGFsIGlzc3VlcyB0byBzb2x2ZSBmb3Igc3Vj aA0KPiBlbnZpcm9ubWVudHMgYmVmb3JlIHdlIGV2ZW4gd29ycnkgYWJvdXQgdGhlIE0vTy9BIGZs YWdzKS4NCltCaW5nXSBJIGFncmVlIHRoZXJlIHdvdWxkIGJlIG90aGVyIGZ1bmRhbWVudGFsIGlz c3VlcywgYnV0IHRoZSBPIGZsYWcgYmVoYXZpb3Igd291bGQgYWxzbyBleGlzdCBhbnl3YXkuDQoN Cj4gVGhlIGlzc3VlcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgc2VlbSB0byBiZSBjYXVzZWQg bGFyZ2VseSBiZWNhdXNlIHRoZXkNCj4gc3dpdGNoIHRoZSBhZGRyZXNzIGNvbmZpZ3VyYXRpb24g bWVjaGFuaXNtIChTTEFBQyB0byBESENQdjYgb3IgdmljZSB2ZXJzYSkNCj4gaW4gYWRkaXRpb24g dG8gcmVudW1iZXJpbmcuICBXaGlsZSB0aGF0IGNvdWxkIGhhcHBlbiBpbiB0aGVvcnksIGl0IHNl ZW1zIHRvDQo+IGJlIGEgcXVpdGUgYXJ0aWZpY2lhbCBkaXNjdXNzaW9uLg0KW0JpbmddIFRoZSBh ZGRyZXNzIGNvbmZpZ3VyYXRpb24gbWVjaGFuaXNtIHN3aXRjaGluZyBpcyBhIHNwZWNpZmljIGNh c2Ugb2YgcmVudW1iZXJpbmc7IGFub3RoZXIgb25lIGlzIHRvIGFkZCBhIG5ldyBhZGRyZXNzIGJ5 IERIQ1B2NiBmb3IgdGhlIGFscmVhZHkgU0xBQUMtY29uZmlndXJlZCBob3N0cyBvciB2aWNlIHZl cnNhLiBUaGVzZSB1c2UgY2FzZXMgbWlnaHQgaGFwcGVuIGluIGVudGVycHJpc2UgbmV0d29ya3Mg d2hlbiBjb21wYW5pZXMgc3BsaXQsIG1lcmdlLCBncm93LCByZWxvY2F0ZSwgb3IgcmVvcmdhbml6 ZS4gDQoNCj4gQWN0dWFsbHksIEkgZ3Vlc3MgdGhlcmUgc2hvdWxkIGJlIG1vcmUgcHJhZ21hdGlj IGV4YW1wbGVzIG9mIG9wZXJhdGlvbmFsDQo+IGlzc3VlcyBiZWNhdXNlIG9mIHRoZSBkZXNjcmli ZWQgZGl2ZXJnZW5jZSBhbmQgSSB3b25kZXIgd2hldGhlciB0aGVzZQ0KPiBtaW5vciBjYXNlcyBh cmUgcmVhbGx5IHRoZSBvbmx5IHRoaW5ncyB3ZSBjYW4gaW1hZ2luZSAoYWx0aG91Z2ggSSBkb24n dCBoYXZlDQo+IGEgc3BlY2lmaWMgaWRlYSByaWdodCBub3cpLiAgSWYgdGhlc2Ugc2VjdGlvbnMg Y2FuIGJlIHJldmlzZWQgd2l0aCBtb3JlDQo+IGNvbnZpbmNpbmcgZXhhbXBsZXMsIEkgd291bGQg YmUgbW9yZSBzdXBwb3J0aXZlIGFib3V0IHB1Ymxpc2hpbmcgaXQuDQpbQmluZ10gQ3VycmVudCBk cmFmdCBvbmx5IGRvY3VtZW50cyB0aGUgb3BlcmF0aW9uYWwgaXNzdWVzIGNhdXNlZCBieSBkaXZl cmdlbnQgYmVoYXZpb3JzIGlkZW50aWZpZWQgaW4gdGhlIHRlc3RzLiBJbiBBcHBlbmRpeCBCLCBp dCBkb2N1bWVudHMgYSBjb21wcmVoZW5zaXZlIGFuYWx5c2lzIG9mIHRoZSBhbWJpZ3VpdHkuIElm IHdlIG1hZGUgYSBwZXJtdXRhdGlvbiBhbmQgY29tYmluYXRpb24gb2YgdGhlIGRpdmVyZ2VuY2Ug ZGVyaXZlZCBmcm9tIHRoZSBhbWJpZ3VpdHkgYW5hbHlzaXMsIHRoZXJlIHdvdWxkIGJlIG90aGVy IGRpdmVyZ2VuY2UgdGhhdCBkaWQgbm90IGNvdmVyZWQgaW4gb3VyIGxpbWl0ZWQgdGVzdHMgKGZv Y3VzaW5nIG9uIGN1cnJlbnQgbWFpbnN0cmVhbSBkZXNrdG9wL3Bob25lIE9TZXMpLiBCdXQgc2lu Y2UgaXQgaXMgb25seSBpbiB0aGVvcnksIHdlIGp1c3QgbGVmdCBpdCBpbiB0aGUgYXBwZW5kaXgg YXMgYSBoaW50IHRvIHRoZSBhZG1pbmlzdHJhdG9ycy4NCg0KPiBTb21lIHNwZWNpZmljIGNvbW1l bnRzIChtb3N0bHkgZWRpdG9yaWFsIGFuZCBuaXRzKSBvbiB0aGUgZHJhZnQgdGV4dDoNCj4gDQo+ IC0gU2VjdGlvbiAxOg0KPiANCj4gICAgVGhlIE0sIE8gYW5kIEENCj4gICAgZmxhZ3MgYXJlIGFk dmlzb3J5LCBub3QgcHJlc2NyaXB0aXZlLg0KPiANCj4gICBJbiBteSB1bmRlcnN0YW5kaW5nLCB0 aGUgQSBmbGFnIGlzIHF1aXRlIHByZXNjcmlwdGl2ZS4gIElmIGEgaG9zdA0KPiAgIGltcGxlbWVu dGF0aW9uIGRvZXNuJ3QgcGVyZm9ybSBTTEFBQyBmb3IgYSBwcmVmaXggaW5mb3JtYXRpb24gb3B0 aW9uDQo+ICAgd2l0aCBBIGZsYWcgb24sIHRoYXQgaW1wbGVtZW50YXRpb24gd291bGQgYmUgY29u c2lkZXJlZA0KPiAgIG5vbi1jb21wbGlhbnQuICBBdCB0aGUgdmVyeSBsZWFzdCwgdGhlIGxldmVs IG9mICJhZHZpc29yeSIgdnMNCj4gICAicHJlc2NyaXB0aXZlIiBpcyBtdWNoIGRpZmZlcmVudCBi ZXR3ZWVuIE0sTyBhbmQgQSwgc28gbGlzdGluZyBhbGwNCj4gICBvZiB0aGVtIGluIHRoaXMgc2Vu dGVuY2Ugc2VlbXMgdG8gYmUgbWlzbGVhZGluZywgaWYgbm90IHNpbXBseQ0KPiAgIGluY29ycmVj dC4NCltCaW5nXSBBIGZsYWcgaW4gZGVmaW5pdGlvbiBpcyBub3QgcHJlc2NyaXB0aXZlLCBSRkM0 ODYyIG9ubHkgZXhwbGljaXRseSBkZWZpbmVkICIgSWYgdGhlIEF1dG9ub21vdXMgZmxhZyBpcyBu b3Qgc2V0LCBzaWxlbnRseSBpZ25vcmUgdGhlIFByZWZpeCBJbmZvcm1hdGlvbiBvcHRpb24uIiAN Ckhvd2V2ZXIsIEEgZmxhZyBpbiBpbXBsZW1lbnRhdGlvbnMgKGFzIHdlIHRlc3RlZCkgaXMgcHJl c2NyaXB0aXZlLCBhbmQgSSBhbHNvIGFncmVlIGl0IHNob3VsZCBiZS4gV2UgbWlnaHQgbmVlZCB0 byBiZSBkaXN0aW5ndWlzaCB0aGUgZGVzY3JpcHRpb24gYmV0d2VlbiB0aGUgQS9NL08gZmxhZ3Mu DQpUaGFua3MgZm9yIHRoZSBnb29kIHBvaW50Lg0KDQo+IC0gU2VjdGlvbiAyLjE6IHMvc2V0dGlu Zy9zZXR0aW5ncy8NCj4gDQo+ICAgIFsuLi5dICBUaGUgZm9sbG93aW5nIHNldHRpbmcgYXJlIGFs bCBhbGxvd2VkOg0KPiANCj4gLSBTZWN0aW9uIDIuMjogcy9zZXR0aW5nL3NldHRpbmdzLw0KPiAN Cj4gICAgWy4uLl0gIFRoZSBmb2xsb3dpbmcgc2V0dGluZyBhcmUgYWxsDQo+ICAgIGFsbG93ZWQ6 DQpbQmluZ10gV2UnbGwgcmV2aXNlIGFjY29yZGluZ2x5LiBUaGFuayB5b3UuDQoNCkJlc3QgcmVn YXJkcywNCkJpbmcNCg0KPiAtLQ0KPiBKSU5NRUksIFRhdHV5YQ0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0 DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMNCg== From nobody Mon Oct 20 23:38:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4711A1AD087; Mon, 20 Oct 2014 23:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybksqH9J6zP8; Mon, 20 Oct 2014 23:38:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E701AD068; Mon, 20 Oct 2014 23:38:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 23:38:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-SZQxPTqQCv5R2ubepb0hLn47Cg Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 06:38:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4) Authors : Ole Troan Brian Carpenter Filename : draft-ietf-v6ops-6to4-to-historic-06.txt Pages : 7 Date : 2014-10-20 Abstract: Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transition mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved to historic status. It also recommends that future products should not support 6to4 and that existing deployments should be reviewed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 21 03:30:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0D1A0372 for ; Tue, 21 Oct 2014 03:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aII6lP3HpXU3 for ; Tue, 21 Oct 2014 03:29:58 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC541A026A for ; Tue, 21 Oct 2014 03:29:57 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 782216079A for ; Tue, 21 Oct 2014 12:29:55 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 499A660788 for ; Tue, 21 Oct 2014 12:29:55 +0200 (CEST) Received: (qmail 56293 invoked by uid 1007); 21 Oct 2014 12:29:55 +0200 Date: Tue, 21 Oct 2014 12:29:55 +0200 From: Gert Doering To: v6ops@ietf.org Message-ID: <20141021102955.GA31092@Space.Net> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UndBt7dXm5ggqrIIejjOokU5j-A Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 10:30:01 -0000 Hiya, On Mon, Oct 20, 2014 at 11:38:29PM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4) > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-06.txt Support. Both for the cause as for the text as written. It's good to see a respin of the draft, taking into account recent developments in clients (HE) and networks (6rd) and making clear which parts are problematic, and which "similar-looking" parts are not (namely, 6rd, and non-relay-using 6to4 between two IPv4-only hosts) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Oct 21 04:01:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572391A19E2 for ; Tue, 21 Oct 2014 04:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7piAIm_XGdok for ; Tue, 21 Oct 2014 04:01:02 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7011A0636 for ; Tue, 21 Oct 2014 04:00:45 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9LB0Wmn028659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2014 12:00:37 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54463CCF.90905@foobar.org> Date: Tue, 21 Oct 2014 12:00:31 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> In-Reply-To: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/E3hjRGF5FyIgpbeRSv2REwrLl8M Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:01:04 -0000 On 21/10/2014 07:38, internet-drafts@ietf.org wrote: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet. This > document requests that RFC3056 and the companion document "An Anycast > Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved to > historic status. It also recommends that future products should not > support 6to4 and that existing deployments should be reviewed. support, with one suggestion. The current revision says: > The references to the 6to4 relay anycast addresses (192.88.99.0/24) > should be removed as soon as practical from the revision of the > Special Use IPv4 addresses [RFC6890]. As this prefix will be widely hard-coded in many places for the foreseeable future, it would probably be a good idea to prevent the relay prefix from being reassigned using the same proposed mechanism as for 2002::/16. Suggested new text: > 4. Deprecation > > This document formally deprecates the [RFC3056] 6to4 transition > mechanism, the IPv6 6to4 prefix (2002::/16), and the 6to4 relay anycast > prefix (192.88.99.0/24). These prefixes MUST NOT be reassigned for other > use except by a future IETF standards action. Nick From nobody Tue Oct 21 04:42:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873E21A1AF0 for ; Tue, 21 Oct 2014 04:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXbuCx-wQ4Tu for ; Tue, 21 Oct 2014 04:42:27 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19A91A1AEE for ; Tue, 21 Oct 2014 04:42:27 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so1104672igq.16 for ; Tue, 21 Oct 2014 04:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PvVzBcuoNglTskfzsAA5RIN88kNK10a9RUGoSWNyNP4=; b=ZH7aUPG9NWBt7ci9/HqPudx9Wwu8xBNTj7GjeTrDU+knt4hHpnUn5LlP0JbCKSbsq6 ZQEagc4KyajEk4E9PNLo7aR/As/ppOYtMPZPAK6uk9Ci9DxTajNyoTkBWdoKhbWwYMfx wzHrkyz2TXVH26w+mpDULO5l1ZGBalvbs5Y+7ABsBYga82RO294f2+5xznvMlkM/yPkE EB6lvJPODPLhYAZtLGxqvdcDXnSJlNc0z7fyJnXEZZofrbaW06RBMmTLuu2tri64NmkD VPLuL+UBGbLivtHUHS8go+5VnIXa8vO5U4kCGfSMQPMBEb9BKd/CwHISY8HmdyPAWfzC zmnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PvVzBcuoNglTskfzsAA5RIN88kNK10a9RUGoSWNyNP4=; b=PuC+JYRWwLi+JI1VJQdz/EX10W3oVRRTTxWLcQq4k1He4WZRdsFEfj+7i+Z59a+Z7b 6+wM9rSaMQtDT9dt3++3kzYydaWKaSRNM8hdfaMpe90N/E9UY7JVw7uYtbdEOjo2n6KK TWH3hVRCkJCM5NtYc1Mx9t4H5wx/Fc9StlCQy+m9ENJp4mm9jV94sv5jVMrfW/sELq3L +o76AB9pw3S4tH5PxGqAR4uxl1FJpRvG6yv3ODapmm7MafTgnZtO3eNIww1pQAmXSywR AtklQ4AjUUMX7C8elJLZ5uBA/lmXVTicpLZIDJHuB0nwSHTnkP8ohfe1tAE1NXVElT6h 6VcA== X-Gm-Message-State: ALoCoQmZ+8grWTtxIBMPTeSGZskjTbDTxJMeraXHUksKktkQFTP3m9o8GQTFSrWdfPCPej2h77yB X-Received: by 10.50.79.231 with SMTP id m7mr26020765igx.16.1413891747007; Tue, 21 Oct 2014 04:42:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.8.242 with HTTP; Tue, 21 Oct 2014 04:42:06 -0700 (PDT) In-Reply-To: References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Tue, 21 Oct 2014 20:42:06 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=089e013a06bc54f6ae0505ed536d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Vp2jwCBRRIS3zv3jL6psN3EzQUU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:42:30 -0000 --089e013a06bc54f6ae0505ed536d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 21, 2014 at 3:12 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > I have a mixed feeling about the importance of the document. I > personally don't think it worth publishing in its current form, > although I wouldn't be opposed to it if the wg thinks it's useful. > +1. The operational problems section boils down to one statement: "if you flash renumber, the results differ between operating systems" (i.e., section 3.2.2). That's a true statement, but pretty obvious from the preceding text. The only other operational problems statement, in section 3.2.1, is not very useful: if you don't have addresses via DHCPv6 or SLAAC, then there's little point getting other information from DHCP. For this to work at all, IP addresses must be configured manually, and if you're using manual configuration, you might as well configure other information manually as well. The rest of the draft before the appendix is a rehash of RFC 4862, which doesn't really add anything new. On the other hand, the appendix, which documents the behaviour of various OSes under different conditions, is useful. Given that, it would seem to make more sense for this document to focus only on the results of the investigation (i.e., only the appendix), and a concluding statement that notes that implementations differ in their behaviour, and that renumbering behaviour is substantially different. --089e013a06bc54f6ae0505ed536d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 21, 2014 at 3:12 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
I have a= mixed feeling about the importance of the document.=C2=A0 I
personally don't think it worth publishing in its current form,
although I wouldn't be opposed to it if the wg thinks it's useful.<= br>

+1. The operational problems section bo= ils down to one statement: "if you flash renumber, the results differ = between operating systems" (i.e., section 3.2.2). That's a true st= atement, but pretty obvious from the preceding text.

The only other operational problems statement, in section 3.2.1, is not = very useful: if you don't have addresses via DHCPv6 or SLAAC, then ther= e's little point getting other information from DHCP. For this to work = at all, IP addresses must be configured manually, and if you're using m= anual configuration, you might as well configure other information manually= as well.

The rest of the draft before the appendi= x is a rehash of RFC 4862, which doesn't really add anything new.
=

On the other hand, the appendix, which documents the be= haviour of various OSes under different conditions, is useful.
Given that, it would seem to make more sense for this document= to focus only on the results of the investigation (i.e., only the appendix= ), and a concluding statement that notes that implementations differ in the= ir behaviour, and that renumbering behaviour is substantially different.
--089e013a06bc54f6ae0505ed536d-- From nobody Tue Oct 21 06:32:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936591A6EE7 for ; Tue, 21 Oct 2014 06:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pKmGftcv2k4 for ; Tue, 21 Oct 2014 06:32:40 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id A7B061A3BA6 for ; Tue, 21 Oct 2014 06:32:35 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 21 Oct 2014 08:32:33 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f179.google.com [209.85.223.179] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f179.google.com with SMTP id ar1so1176101iec.38 for ; Tue, 21 Oct 2014 06:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HzfGeYmy5WPNamJFFsqIqaCE+R9m6j/uyCoWnZX0cpo=; b=n0vr/BVUjZCHhfB7W7y1M/VOwXJnjcm1AZKfQiTlyWRTyxlTfgE8xLZq7WQ059iYXw AlmB30ESMteiEdMO8UM9IBPFiY3vgwTcJweH+s+RSZpBP+GkT5+WOCw4Y0GUq3KCppBK nK+F1WQnCuc0Re+t1gCZVvSbr8uAT8tztj/zw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HzfGeYmy5WPNamJFFsqIqaCE+R9m6j/uyCoWnZX0cpo=; b=SsdwvgTvdjlXVaUXcpDakKCUQ/u8w3uYMz0bZx7gfydJRI8LweWipRZTF42RdDftMI ilnbIv/qfUIjk8CiOfUgezzYn7VasTuJJU6VtzGZWz4RBccFfBsRrei7eKgNYECmPYvv wSMzh7USOXEUuphPlHE+7CfmfFpxIkxfyPS6lcvU/mP+weXRL4lEGhR17gHUmHxY21bi Rb8yb6Az62fhDf2c+7vAjfWNlfbPJkMRtF8IHppjt1IWPwM6wqxd+k0/uRMsfEwqYy1X P/R6KCu2K4x+9gTNyS6YWeQHTkA2i+7Ea9HYzjrlrPcINUWW34RprX4OnYpq9VnluMr5 LMTw== X-Gm-Message-State: ALoCoQlxoyu3teU6uptuIdOBFVrBlZdilS7ZHAJQ7LV7SWb6FihXtCzG+XdpShXT3fzx8oD63nVzKyAJbCSS+I8NHemrWay7N8sduMtOXzeqZUdhDu4e2yqvZGwGA9rqqPjEpGecfWms X-Received: by 10.50.79.193 with SMTP id l1mr26979395igx.36.1413898353343; Tue, 21 Oct 2014 06:32:33 -0700 (PDT) X-Received: by 10.50.79.193 with SMTP id l1mr26979371igx.36.1413898353173; Tue, 21 Oct 2014 06:32:33 -0700 (PDT) Received: from oit201651646.local ([2601:2:5b00:675:59de:7f61:58b:2d1f]) by mx.google.com with ESMTPSA id f71sm6072908ioe.28.2014.10.21.06.32.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 06:32:31 -0700 (PDT) Message-ID: <5446606D.3080800@umn.edu> Date: Tue, 21 Oct 2014 08:32:29 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nick Hilliard , v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <54463CCF.90905@foobar.org> In-Reply-To: <54463CCF.90905@foobar.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H51n3hdVpcS5gxOg0bwHEZtBL0Y Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:32:43 -0000 On 10/21/14, 06:00 , Nick Hilliard wrote: > On 21/10/2014 07:38, internet-drafts@ietf.org wrote: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism has shown that the mechanism is >> unsuitable for widespread deployment and use in the Internet. This >> document requests that RFC3056 and the companion document "An Anycast >> Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved to >> historic status. It also recommends that future products should not >> support 6to4 and that existing deployments should be reviewed. > > support, with one suggestion. The current revision says: +1 >> The references to the 6to4 relay anycast addresses (192.88.99.0/24) >> should be removed as soon as practical from the revision of the >> Special Use IPv4 addresses [RFC6890]. > > As this prefix will be widely hard-coded in many places for the foreseeable > future, it would probably be a good idea to prevent the relay prefix from > being reassigned using the same proposed mechanism as for 2002::/16. > > Suggested new text: > >> 4. Deprecation >> >> This document formally deprecates the [RFC3056] 6to4 transition >> mechanism, the IPv6 6to4 prefix (2002::/16), and the 6to4 relay anycast >> prefix (192.88.99.0/24). These prefixes MUST NOT be reassigned for other >> use except by a future IETF standards action. +1 to the suggestion as well. However, there is an additional issue regarding the deprecation of the prefixes. Do the two prefixes immediately become BOGONs? And, should they be filtered as BOGONs? If NOT, then please provide specific guidance otherwise. If that is the intended result, then I would suggest beyond the current guidance to relay operators that there also should be guidance to general network operators that they deliberately consider when they should stop accepting routes for the two relay prefixes from outside there networks. Also, should only the routes be filtered? Should traffic be filtered too? Should you start with routes and then traffic later? Specifically, I'm concerned when groups like Team Cymru add these relay prefixes to their recommendations, and how that should occur. When this occurs there is likely to be a dramatic effect. I'm not sure specific guidance for a group like Team Cymru is needed within the draft, but it might not be a bad idea to talk that part through on the list. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Oct 21 06:44:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D61A6F15 for ; Tue, 21 Oct 2014 06:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7e3XxIU0lMw for ; Tue, 21 Oct 2014 06:44:05 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E73E1A6F2B for ; Tue, 21 Oct 2014 06:43:28 -0700 (PDT) Received: from [2a02:c0:2:4:1194:6:0:1000] (port=56672 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XgZig-0000Oz-Qs; Tue, 21 Oct 2014 15:43:26 +0200 Message-ID: <544662FE.2000709@fud.no> Date: Tue, 21 Oct 2014 15:43:26 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering , v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: <20141021102955.GA31092@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XH6ZUwlLmUrXll7ZenI0n-La0U4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:44:10 -0000 * Gert Doering >> Filename : draft-ietf-v6ops-6to4-to-historic-06.txt > > Support. Both for the cause as for the text as written. +1 Tore From nobody Tue Oct 21 06:58:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9901A3BA4 for ; Tue, 21 Oct 2014 06:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJPI-bKMS2KA for ; Tue, 21 Oct 2014 06:58:17 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B551A1C04 for ; Tue, 21 Oct 2014 06:58:16 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9LDwE3S030005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 14:58:14 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <54466675.5040309@foobar.org> Date: Tue, 21 Oct 2014 14:58:13 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Farmer , v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <54463CCF.90905@foobar.org> <5446606D.3080800@umn.edu> In-Reply-To: <5446606D.3080800@umn.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YP-ANtm0m58dIqd-j0u4ggq94Hg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:58:20 -0000 On 21/10/2014 14:32, David Farmer wrote: > Do the two prefixes immediately become BOGONs? >From what I read, no. If they did, the draft would be objectionable because it breaks stuff right now. > And, should they be filtered as BOGONs? If NOT, then please provide > specific guidance otherwise. There's guidance there: don't add any new relay servers; if you have one already, think about removing it and then think twice. Nick From nobody Tue Oct 21 07:31:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773CB1A6F7F for ; Tue, 21 Oct 2014 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kVen7sjHwyz for ; Tue, 21 Oct 2014 07:30:50 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1091A1B74 for ; Tue, 21 Oct 2014 07:30:49 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9LEUike012992; Tue, 21 Oct 2014 15:30:44 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s9LEUike012992 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1413901845; bh=OVgrdbUDYOgz8phBNe5mFiNNsgo=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=6BCzL83pcKPiCfPhYHVtMdyP4pUuTrJbFbsoYOGYYDixowOHeJHHsy1tqpxVlSgDP cOqxJmkG1DQxtxOgAsOQCbersIGUKh+CEwl4J9pvf3IkWJYfwaoz31bLkpWpusvE1J dcz1KMwB9ORcH5RUnY4nwaA+ZORvhq8kOVheSjoY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q9KFUi13112124348S ret-id none; Tue, 21 Oct 2014 15:30:44 +0100 Received: from [10.9.52.132] (b54gafwc1n1-ext.net.soton.ac.uk [152.78.0.25]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9LEUesm006539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Oct 2014 15:30:40 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C7B4CEC-6F84-4A62-A987-97FAA0A81EDA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <20141021102955.GA31092@Space.Net> Date: Tue, 21 Oct 2014 15:30:40 +0100 Message-ID: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q9KFUi131121243400; tid=q9KFUi13112124348S; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s9LEUike012992 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qVbJMSCPkqj8Yskry8PT4TbYXA8 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:30:53 -0000 --Apple-Mail=_6C7B4CEC-6F84-4A62-A987-97FAA0A81EDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tim On 21 Oct 2014, at 11:29, Gert Doering wrote: > Hiya, >=20 > On Mon, Oct 20, 2014 at 11:38:29PM -0700, internet-drafts@ietf.org = wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >>=20 >> Title : Deprecating Connection of IPv6 Domains via = IPv4 Clouds (6to4) >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-06.txt >=20 > Support. Both for the cause as for the text as written. >=20 > It's good to see a respin of the draft, taking into account recent > developments in clients (HE) and networks (6rd) and making clear which > parts are problematic, and which "similar-looking" parts are not > (namely, 6rd, and non-relay-using 6to4 between two IPv4-only hosts) Yes, very much so. In the last bullet point of section 3, might add =93, as is becoming = increasingly common as ISPs who are unable to acquire additional = globally unique IPv4 address space turn to CGN.=94 or words to that = affect. Anything to say about the use of the prefix in address selection policy = tables (noting that 3ffe::/16 is still cited there)? There=92s a paragraph at the end that says: "Peer-to-peer usage of the 6to4 mechanism, not depending on the anycast mechanism, might exist in the Internet, largely unknown to operators. This is harmless to third parties and the current document is not intended to prevent such traffic continuing." which is a little at odds with the Historic status for 3056? If it=92s = made historic, and support removed, it would harm them=85? Tim= --Apple-Mail=_6C7B4CEC-6F84-4A62-A987-97FAA0A81EDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Tim

On 21 Oct 2014, at 11:29, Gert Doering <gert@space.net> wrote:

Hiya,

On Mon, Oct 20, 2014 at 11:38:29PM -0700, internet-drafts@ietf.org = wrote:
A New Internet-Draft is available = from the on-line Internet-Drafts directories.
This draft is a work = item of the IPv6 Operations Working Group of the IETF.

=        Title =           : = Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
=        Authors =         : Ole Troan
=             &n= bsp;           &nbs= p;Brian Carpenter
Filename =        : = draft-ietf-v6ops-6to4-to-historic-06.txt

Support. =  Both for the cause as for the text as written.

It's good to = see a respin of the draft, taking into account recent
developments in = clients (HE) and networks (6rd) and making clear which
parts are = problematic, and which "similar-looking" parts are not
(namely, 6rd, = and non-relay-using 6to4 between two IPv4-only = hosts)

Yes, very much = so.

In the last bullet point of section 3, = might add =93, as is becoming increasingly common as ISPs who are unable = to acquire additional globally unique IPv4 address space turn to CGN.=94 = or words to that affect.

Anything to say about = the use of the prefix in address selection policy tables (noting that = 3ffe::/16 is still cited there)?

There=92s a = paragraph at the end that says:

  "Peer-to-peer usage of the 6to4 mechanism, not = depending on the
   anycast mechanism, might exist in =
the Internet, largely unknown to
   operators.  This is harmless to third parties and the current
   document is not intended to prevent such traffic =
continuing."

which is a little at odds = with the Historic status for 3056? If it=92s made historic, and support = removed, it would harm = them=85?

Tim
= --Apple-Mail=_6C7B4CEC-6F84-4A62-A987-97FAA0A81EDA-- From nobody Tue Oct 21 07:35:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9116A1A6F5D for ; Tue, 21 Oct 2014 07:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbwKdmgbL9CK for ; Tue, 21 Oct 2014 07:35:07 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF411A1B74 for ; Tue, 21 Oct 2014 07:35:07 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tp5so1327177ieb.18 for ; Tue, 21 Oct 2014 07:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vGn+7EYq9GK3BG3akl7oN8uhYiIpR6Mx2dnq21qSVSw=; b=kl58VHc3OjOh6U4pJ3pOEznArVFFg+OZ691EOelsH7BFIIXRyd8vYuT5YA1f9pVv3K Nx9IpsICM+lxFEU7oqIihbSMuwhQLcEn6dLqgheeTVZCagoSrFO2+egQI1ebo5lSwuDv E86k4UOKsz8DLHzBx3n9xwpp7+Cghyg4V6Jx4sxLAiVr4dcWW4Zj/DZimcfnaSudca/M bma1pD3Slrcje8sEuwEgKQk7K9t14aBFiXUaYhEBPLzoNuER/gvn3e6M4TECQ8p397vz mMnyg6sY+TUa6/yX6r0XoLeGboJzksUAYO23q7GiRDEy/Tu9sBa4Y31PsG8xEtFxS+iI PaDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vGn+7EYq9GK3BG3akl7oN8uhYiIpR6Mx2dnq21qSVSw=; b=R6yjM90upR/NiDlndcKlEkSJRSLsUdrAfEYkC33Jqboo1Oy5GtaynmnHrF4Rol6oFY TUuVd4RsdyVyF2nfBdFJUIc0ir09b13gy58Wrwj7QNuFE0/h1gNR2jDgswz9UNAUBSbW OcfLaVBaxbk71wzdU3khJAyJudQPDgr5tZR49jEYHujF3CtvtKbWSm3vfa07UvUkDNWk ajE5in3oWl2uIc1TZ/4bbj1UL/mFtkoAg9jgRIpUTxPd3m1sBucvuDHWa4/V6UbnXaqy BcsQpOZzWrVaptdozrWEXTSdmA+HeMcJ5RPYAPQZej8sa0ImSsOyo0PLgBjJhAamc8Wf pZNQ== X-Gm-Message-State: ALoCoQmr9RHhxnDPBjrGoKQ58cJI54aRpoGUSLpD8Z/czWjH3Gb7R5GiXpq4Nz0QkMpL4GeRn7Y/ X-Received: by 10.42.8.70 with SMTP id h6mr2890180ich.85.1413902106997; Tue, 21 Oct 2014 07:35:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.8.242 with HTTP; Tue, 21 Oct 2014 07:34:46 -0700 (PDT) In-Reply-To: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> From: Lorenzo Colitti Date: Tue, 21 Oct 2014 23:34:46 +0900 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=001a11349c7ad5eaa20505efbc55 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1AIIGrLu2cZdQ2_n0eYzH92XcxE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:35:08 -0000 --001a11349c7ad5eaa20505efbc55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown wrote: > There=E2=80=99s a paragraph at the end that says: > > "Peer-to-peer usage of the 6to4 mechanism, not depending on the > > anycast mechanism, might exist in the Internet, largely unknown to > operators. This is harmless to third parties and the current > document is not intended to prevent such traffic continuing." > > > which is a little at odds with the Historic status for 3056? If it=E2=80= =99s made > historic, and support removed, it would harm them=E2=80=A6? > Would it make sense to move only 3068 to historic, and not 3056? --001a11349c7ad5eaa20505efbc55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 21, 2014 at 11:30 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
The= re=E2=80=99s a paragraph at the end that says:

=C2= =A0 "Peer-to-peer usage of the 6to4 mech= anism, not depending on the
   anycast mechanism, m=
ight exist in the Internet, largely unknown to
   operators.  This is harmless to third parties and the current
   document is not intended to prevent such traffic continuing."=
;

which is a little at odds with the Historic stat= us for 3056? If it=E2=80=99s made historic, and support removed, it would h= arm them=E2=80=A6?

Would it mak= e sense to move only 3068 to historic, and not 3056?=C2=A0
--001a11349c7ad5eaa20505efbc55-- From nobody Tue Oct 21 07:39:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A301A6F0B for ; Tue, 21 Oct 2014 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOPEe2algQxV for ; Tue, 21 Oct 2014 07:39:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFA21A6F68 for ; Tue, 21 Oct 2014 07:39:06 -0700 (PDT) Received: from h229.viagenie.ca (h229.viagenie.ca [206.123.31.229]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 244D44038A for ; Tue, 21 Oct 2014 10:39:04 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_5B7575A8-2C31-4597-AF54-DD15C515A89A" Message-Id: <699DAB37-7B4C-4CD7-8FDF-F2E810F5858C@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 21 Oct 2014 10:39:03 -0400 References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <54463CCF.90905@foobar.org> <5446606D.3080800@umn.edu> To: v6ops@ietf.org In-Reply-To: <5446606D.3080800@umn.edu> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/H6gKcv1LKhk8pa2BNZJ7J8C4VRU Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:39:19 -0000 --Apple-Mail=_5B7575A8-2C31-4597-AF54-DD15C515A89A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 21, 2014, at 9:32 AM, David Farmer wrote: > On 10/21/14, 06:00 , Nick Hilliard wrote: >>=20 >> Suggested new text: >>=20 >>> 4. Deprecation >>>=20 >>> This document formally deprecates the [RFC3056] 6to4 transition >>> mechanism, the IPv6 6to4 prefix (2002::/16), and the 6to4 relay = anycast >>> prefix (192.88.99.0/24). These prefixes MUST NOT be reassigned for = other >>> use except by a future IETF standards action. >=20 > +1 to the suggestion as well. I support this document and Nick=92s new text.=20 > However, there is an additional issue regarding the deprecation of the = prefixes. Do the two prefixes immediately become BOGONs? And, should = they be filtered as BOGONs? If NOT, then please provide specific = guidance otherwise. My 2 cents: bogonize them asap.=20 > If that is the intended result, then I would suggest beyond the = current guidance to relay operators that there also should be guidance = to general network operators that they deliberately consider when they = should stop accepting routes for the two relay prefixes from outside = there networks. Also, should only the routes be filtered? Should = traffic be filtered too? Should you start with routes and then traffic = later? Another 2 cents: SHOULD both on route and traffic filtering. The faster = it fails the better imho. =20 JF --Apple-Mail=_5B7575A8-2C31-4597-AF54-DD15C515A89A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 21, 2014, at 9:32 AM, David = Farmer <farmer@umn.edu> = wrote:

On 10/21/14, 06:00 , Nick Hilliard = wrote:
Suggested new text:

4. Deprecation

This document formally deprecates = the [RFC3056] 6to4 transition
mechanism, the IPv6 6to4 prefix = (2002::/16), and the 6to4 relay anycast
prefix (192.88.99.0/24). = These prefixes MUST NOT be reassigned for other
use except by a = future IETF standards action.

+1 to the = suggestion as well.

I support = this document and Nick=92s new = text. 

However, there is an additional issue = regarding the deprecation of the prefixes.  Do the two prefixes = immediately become BOGONs?  And, should they be filtered as BOGONs? =  If NOT, then please provide specific guidance = otherwise.

My 2 cents: = bogonize them asap. 

If that is the intended result, then I = would suggest beyond the current guidance to relay operators that there = also should be guidance to general network operators that they = deliberately consider when they should stop accepting routes for the two = relay prefixes from outside there networks.  Also, should only the = routes be filtered?  Should traffic be filtered too?  Should = you start with routes and then traffic = later?

Another 2 cents: SHOULD both = on route and traffic filtering. The faster it fails the better imho. =  

JF


= --Apple-Mail=_5B7575A8-2C31-4597-AF54-DD15C515A89A-- From nobody Tue Oct 21 08:17:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1431A8744 for ; Tue, 21 Oct 2014 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVrrD8n8CXep for ; Tue, 21 Oct 2014 08:17:19 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003CC1A872A for ; Tue, 21 Oct 2014 08:17:18 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id r2so1499205igi.17 for ; Tue, 21 Oct 2014 08:17:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Iv7uwc0+ClShlsx52vjpYnKxCrs8vQf3qJoE7sjsHDA=; b=jUnj5b0ut6stG1UAMKbC3hbPYnG/IL6lEHhf+CJzxgrhxY6x1OCJzdBcFqc+EqYN2r 6YusnkBx6jzxB/swMHrAKMZkxSn8sBIhGzJFXVhR9cdidRQ4Q5RHrhV62Lekg6+4ZOFW xgSxb87peUrqyNRQdOnjHn7xX3/T++uRaeM2FEdy7oIVh6WvBbWMFfMECTT9MLtLP1yO WQazEr1EzFMOjh/P/p/92byEuQ+mb+uLxFg83SIK0Fw+zRVie8tLrAXxZ/WZBJDjyMPO 2Dm0TqqHLQ7NtMV1h1uEyndDV6cVNi6A154IzOtD1PWho6I92h1usY2dVZ33TXU2n9Uu drwA== X-Gm-Message-State: ALoCoQkVkxVxo5g3LeZlFSFOul6bco+HTyLFmkjn+80m/E0acnsWHuiVMr/ujOjOe9hYLzva0vxa X-Received: by 10.107.37.15 with SMTP id l15mr38276830iol.40.1413904638478; Tue, 21 Oct 2014 08:17:18 -0700 (PDT) Received: from Victors-MacBook-Pro.local ([67.224.83.162]) by mx.google.com with ESMTPSA id 199sm6201168ion.7.2014.10.21.08.17.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 08:17:17 -0700 (PDT) Message-ID: <544678F9.8050505@jvknet.com> Date: Tue, 21 Oct 2014 11:17:13 -0400 From: Victor Kuarsingh User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Lorenzo Colitti , Tim Chown References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050901010103050704040100" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wNzf0GScDtar_sBp4Nb382Y_QFc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:17:22 -0000 This is a multi-part message in MIME format. --------------050901010103050704040100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2014-10-21 10:34 AM, Lorenzo Colitti wrote: > On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown > wrote: > > Theres a paragraph at the end that says: > > "Peer-to-peer usage of the 6to4 mechanism, not depending on the > > anycast mechanism, might exist in the Internet, largely unknown to > operators. This is harmless to third parties and the current > document is not intended to prevent such traffic continuing." > > > which is a little at odds with the Historic status for 3056? If > its made historic, and support removed, it would harm them? > > > Would it make sense to move only 3068 to historic, and not 3056? That seems to make sense to me. regards, Victor K > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------050901010103050704040100 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 2014-10-21 10:34 AM, Lorenzo Colitti wrote:
On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Theres a paragraph at the end that says:

"Peer-to-peer usage of the 6to4 mechanism, not depending on the
   anycast mechanism, might exist in the Internet, largely unknown to
   operators.  This is harmless to third parties and the current
   document is not intended to prevent such traffic continuing."

which is a little at odds with the Historic status for 3056? If its made historic, and support removed, it would harm them?

Would it make sense to move only 3068 to historic, and not 3056?
That seems to make sense to me.

regards,

Victor K




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

--------------050901010103050704040100-- From nobody Tue Oct 21 08:45:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3DA1A87C7 for ; Tue, 21 Oct 2014 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j0RMGZKvDzP for ; Tue, 21 Oct 2014 08:44:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847F31A884E for ; Tue, 21 Oct 2014 08:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3209; q=dns/txt; s=iport; t=1413906253; x=1415115853; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VVcPIkTo5l8BtQOmHosA4pAX55qp6HKSjhN8WgSvqao=; b=gwZ2eXqgpg8zqt3zIyuj7WinC9c80eph88f67AiAFBCZkBWnCSdyZuAJ n0hBWyxH/0eGcvvTbZoC+5p8EUwQ81we4VTqmHNTGSpawXvgqz9Ri4ZHU JAWRe2J3IuuhjE3oB3J7jO3lpN4xoXQ+d76RKGZyRVIY8/gqH3ryRVS5+ A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADJxRlStJV2Y/2dsb2JhbABcgw5TUwUEzBoKh00CgREWAX2EAwEBAwEBAQFrGwIBCEYnCyUCBBMJBYgpCAgFw2oBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFMFgy2BHgWSAYIOgVBohxOBMDyDCopVhleDd2wBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,762,1406592000"; d="asc'?scan'208";a="89033225" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 21 Oct 2014 15:44:12 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9LFiCU0015597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 15:44:12 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.152]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 10:44:12 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP7UXcBWNC2ZrkvkuLW099oaA+Fw== Date: Tue, 21 Oct 2014 15:44:12 +0000 Message-ID: <026C20C3-7D92-4507-9B3D-1BC036EA8877@cisco.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> In-Reply-To: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.160] Content-Type: multipart/signed; boundary="Apple-Mail=_87A7B270-DA8E-47F6-85B3-AB5E48FAE117"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0idXsgq0ogeVpI6jW7ULF31W2_8 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:44:58 -0000 --Apple-Mail=_87A7B270-DA8E-47F6-85B3-AB5E48FAE117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It=92s good to see the commentary on this already. To recap: v6ops discussed this draft way back when and sent it to the IESG. The = IETF Last Call left at least one AD with the belief that there was, in = his words, =93no consensus supporting the proposed action=94, and the = IESG dropped it. If we choose to send it up again, I think we need to = make sure we have the right action (I note Lorenzo=92s question, whether = we should only deprecate one RFC, not two) and the arguments all = together. On Oct 20, 2014, at 11:38 PM, 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 IPv6 Operations Working Group of the = IETF. >=20 > Title : Deprecating Connection of IPv6 Domains via = IPv4 Clouds (6to4) > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-06.txt > Pages : 7 > Date : 2014-10-20 >=20 > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet. This > document requests that RFC3056 and the companion document "An = Anycast > Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved = to > historic status. It also recommends that future products should not > support 6to4 and that existing deployments should be reviewed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6to4-to-historic-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_87A7B270-DA8E-47F6-85B3-AB5E48FAE117 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFURn9NbjEdbHIsm0MRAq5EAJsFjT//MaGn0R69HlFYiXyyaRdQ5wCeNZd8 DuBl+IfMfAy9ur1wMppFY9Q= =MAMb -----END PGP SIGNATURE----- --Apple-Mail=_87A7B270-DA8E-47F6-85B3-AB5E48FAE117-- From nobody Tue Oct 21 09:05:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6381A88E6 for ; Tue, 21 Oct 2014 09:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jlwy0JByMEK for ; Tue, 21 Oct 2014 09:05:20 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1EF1A88E8 for ; Tue, 21 Oct 2014 09:05:19 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 21 Oct 2014 11:05:13 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f175.google.com [209.85.223.175] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f175.google.com with SMTP id at20so1535886iec.34 for ; Tue, 21 Oct 2014 09:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=51PbPCSHQXvAbT7puaPJQiouF9WgYTKxPeRmh3pDVzk=; b=WHv2FT00KlbBx3pI+laAs9XokrGN6f1e1TK5z/Hi6LnRmAgSdlfC3n9zQLyYBBcH7R mHsbgbEaqX3fpDLcf4YM3gdNQh3x/ja5cCtbB23q6p5sCJctTKsPwr9sDJF0Au7Kazfn wX5yRRk87JnARUz1OEpz6hMAYfQMSJRcPCnM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=51PbPCSHQXvAbT7puaPJQiouF9WgYTKxPeRmh3pDVzk=; b=mbi1lyoKv2hp8nDw0JYSrwtd+T48esLy3g9DsjfBiysRuHNfl5v9vP1Upy9E/U2lu7 rFd60COwcbhXt+4LMLcJL8Xh4r6ZA3wG+V4llrODYL3NXbNOSeNG9qP+9OD94D4m7bVU 1axr8zd3nEn4y+si3WfEP11lIhk/Le4fv+kamHB34ZaElbM21XVSOutZyI441RuENkjs UMKuy+Mt3oAD8RZ32Qva0qK6YCLOTPVaT77iJ+42NpZFRfxP4TByYmTpo1fd6v/OGzjE JuhJz1tb6r3jNV6cZwSDisAAhdM8eVr9imvZEC72UCU7vNC3yCK/k5h2VbtOlKUlKTHg txug== X-Gm-Message-State: ALoCoQnHs7cRyxWZB0j8qG2eTf1JrwnrGQdB+bwDpZ/bOUWsnAfiRTg72dEjU+k6CgXt3AcIdVh4V3HxCMdrHK23bVLLwYjDzF1r6pnDBYFCw6PVa8XPCtpZKzVhDF0DMzB2xJdYDWFh X-Received: by 10.42.62.129 with SMTP id y1mr33772762ich.19.1413907513054; Tue, 21 Oct 2014 09:05:13 -0700 (PDT) X-Received: by 10.42.62.129 with SMTP id y1mr33772724ich.19.1413907512830; Tue, 21 Oct 2014 09:05:12 -0700 (PDT) Received: from x-128-101-234-192.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:88f7:cf7d:b32b:6653]) by mx.google.com with ESMTPSA id kj6sm5577428igb.6.2014.10.21.09.05.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 09:05:11 -0700 (PDT) Message-ID: <54468436.40100@umn.edu> Date: Tue, 21 Oct 2014 11:05:10 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Lorenzo Colitti , Tim Chown References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BvgQ1CY9Jr06MVBLgBrlCc3aK-4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:05:21 -0000 On 10/21/14, 09:34 , Lorenzo Colitti wrote: > On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown > wrote: > > Theres a paragraph at the end that says: > > "Peer-to-peer usage of the 6to4 mechanism, not depending on the > > anycast mechanism, might exist in the Internet, largely unknown to > operators. This is harmless to third parties and the current > document is not intended to prevent such traffic continuing." > > > which is a little at odds with the Historic status for 3056? If its > made historic, and support removed, it would harm them? > > > Would it make sense to move only 3068 to historic, and not 3056? Yes, deprecate the 6to4 relay function, which means that only the 192.88.99.0/24 prefix would deprecated. 2002::/16 would remain valid but only in the context of peer-to-peer 6to4, and it therefore SHOULD NOT be advertised to the IPv6 global Internet. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Oct 21 09:13:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1061A88C1 for ; Tue, 21 Oct 2014 09:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe_kxC3AfbHD for ; Tue, 21 Oct 2014 09:12:58 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7441A876B for ; Tue, 21 Oct 2014 09:12:58 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 21 Oct 2014 11:12:56 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f174.google.com [209.85.213.174] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f174.google.com with SMTP id a13so1628620igq.13 for ; Tue, 21 Oct 2014 09:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=u1AaL/Hl2trd9Me3NXsLJ/eCYvCa7H/QiMLufPg4N/s=; b=AXRLHGk8MSa2fDGRi+dlWxQxlQeGCZQo4uvXEoopza/pILTWuWp/eQh/+4LOYcDpxS b4niSHf9cI1D2iJUeXVOfJAFPtsQUaKUoO0hf1cAcKuJGx8/syDxEbl/4BYfxLvCNU6Z /ufrGooO1E1AUGmdHa78zejXgcpxFaZTVaplQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=u1AaL/Hl2trd9Me3NXsLJ/eCYvCa7H/QiMLufPg4N/s=; b=DXbFBV77pUTGTEvnLb/CMO19xbZRuqpgZ5Kxs7UdNA/CvoQzSTGldXX5DmK/pSwvBy 1CDJuWczO4j4g7wkwdRiQ468ASba4DJMVZcON50ZsPabjjiqQb8iJNyEEk/vEIx+aCMX AsZdoMO4i/yfDYwvG5WHWeqvOTaM56AMI9uxVpUQuSOLdJHDYnAlCtemrfyQYLFhRUdZ HJva6J2L6b7XX5AnJA/Xj+lUOmFjXLtOO+gWW2YVDVDHIjlZK8KMASbzeScgc8HKRC/L nfBJZJYeztESQtwm84RQR3nwPEAbT5NyZ/QEPwwaipD11BWCHYeH1/2OkgX5F++rIjRS ETuQ== X-Gm-Message-State: ALoCoQmpzjS2V4UsHoZb8lWbFX+wNlO2p8iyd6TNTXPu1Ua7HpLGQcSSsUDSHu+eG7goS+QJmrBlRNg43zuJClfj7kIg1bin/L99qAD++Z+QhScuabHGA/A+/4O4RiKu6RnwUkkhGp4y X-Received: by 10.50.122.106 with SMTP id lr10mr27821265igb.32.1413907976096; Tue, 21 Oct 2014 09:12:56 -0700 (PDT) X-Received: by 10.50.122.106 with SMTP id lr10mr27821242igb.32.1413907975964; Tue, 21 Oct 2014 09:12:55 -0700 (PDT) Received: from x-128-101-234-192.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:88f7:cf7d:b32b:6653]) by mx.google.com with ESMTPSA id rp5sm5575600igb.20.2014.10.21.09.12.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 09:12:55 -0700 (PDT) Message-ID: <54468605.8000605@umn.edu> Date: Tue, 21 Oct 2014 11:12:53 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nick Hilliard , v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <54463CCF.90905@foobar.org> <5446606D.3080800@umn.edu> <54466675.5040309@foobar.org> In-Reply-To: <54466675.5040309@foobar.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ozBO3pRqMypWcvmVyUjTz5XA3zE Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:13:00 -0000 On 10/21/14, 08:58 , Nick Hilliard wrote: > On 21/10/2014 14:32, David Farmer wrote: >> Do the two prefixes immediately become BOGONs? > > From what I read, no. If they did, the draft would be objectionable > because it breaks stuff right now. For some, once the prefixes have been deprecated then they are by definition BOGONs and should be filtered, both the routes and the traffic. If that is not the intended result then either don't deprecate the prefixes or be explicit about how they should be treated. >> And, should they be filtered as BOGONs? If NOT, then please provide >> specific guidance otherwise. > > There's guidance there: don't add any new relay servers; if you have one > already, think about removing it and then think twice. Yea, the nuance you and I see will be missed by many if not most, so let's not be so nuanced, let's be very blunt and explicit about what to do and what not to do. Further, I don't think the only guidance should be to relay operators. As a network operator, when do I drop any routes for the relays at all? Is it preferred to be using a relay on the other side of the planet or to have no relay at all? Also, when we are down to one relay left what is suppose to happen, does that last operator get decide when the world no longer needs 6to4 relays? What if they never turn it off? Isn't what we are doing with this draft deciding that the world no longer needs 6to4 relays. If not then what is, I'm confused. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Oct 21 10:00:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0981A8ABC for ; Tue, 21 Oct 2014 10:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhRf7M52mJkx for ; Tue, 21 Oct 2014 10:00:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9408F1A0248 for ; Tue, 21 Oct 2014 10:00:44 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 21 Oct 2014 17:00:42 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Tue, 21 Oct 2014 17:00:41 +0000 From: Ronald Bonica To: Nick Hilliard , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP7PnJ41gHXIloY0eGKrB8AnzAKpw6YoKAgABjRRA= Date: Tue, 21 Oct 2014 17:00:38 +0000 Message-ID: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <54463CCF.90905@foobar.org> In-Reply-To: <54463CCF.90905@foobar.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(51704005)(199003)(24454002)(479174003)(120916001)(19580395003)(64706001)(4396001)(97736003)(76576001)(2501002)(99396003)(107046002)(2656002)(101416001)(19580405001)(106356001)(46102003)(87936001)(77096002)(86362001)(85306004)(99286002)(76482002)(107886001)(40100003)(106116001)(92566001)(15975445006)(108616004)(21056001)(230783001)(105586002)(80022003)(33646002)(20776003)(31966008)(66066001)(122556002)(95666004)(54356999)(50986999)(74316001)(85852003)(76176999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Q1tmH_TYZz_mS0NZpnvStXeTK84 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:00:47 -0000 Also support. > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Nick Hilliard > Sent: Tuesday, October 21, 2014 7:01 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt >=20 > On 21/10/2014 07:38, internet-drafts@ietf.org wrote: > > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > > (6to4)" IPv6 transition mechanism has shown that the mechanism is > > unsuitable for widespread deployment and use in the Internet. This > > document requests that RFC3056 and the companion document "An > Anycast > > Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved t= o > > historic status. It also recommends that future products should not > > support 6to4 and that existing deployments should be reviewed. >=20 > support, with one suggestion. The current revision says: >=20 > > The references to the 6to4 relay anycast addresses (192.88.99.0/24) > > should be removed as soon as practical from the revision of the > > Special Use IPv4 addresses [RFC6890]. >=20 > As this prefix will be widely hard-coded in many places for the foreseeab= le > future, it would probably be a good idea to prevent the relay prefix from > being reassigned using the same proposed mechanism as for 2002::/16. >=20 > Suggested new text: >=20 > > 4. Deprecation > > > > This document formally deprecates the [RFC3056] 6to4 transition > > mechanism, the IPv6 6to4 prefix (2002::/16), and the 6to4 relay > > anycast prefix (192.88.99.0/24). These prefixes MUST NOT be reassigned > > for other use except by a future IETF standards action. >=20 > Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 21 11:12:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3F01A870B for ; Tue, 21 Oct 2014 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz_QdaZSsF6Z for ; Tue, 21 Oct 2014 11:12:36 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1BD1A87BD for ; Tue, 21 Oct 2014 11:09:17 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id r20so2574582wiv.0 for ; Tue, 21 Oct 2014 11:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6aYFzchPU17hRRutCqcvWwUjphpFXAgskebKcxWPLk8=; b=nbpLKd6So0fXpyhheU7K0RZqpw7+xfGqFfERR4Ujzd6gWqrWgeWo/8uOjFFwrts+oR ChK+zeZta2vixazIFsSxzYeAUzcRj0ntaRsBwgZtLmPveKfBxGLZZtryvCNzd1cUxYVg YV6RvoxvdFS9DQ9G3fphFCEIJi1T6jDMvbR2borlm145PQjtP8nSM4YcXHl7qmvXz3R9 YMBkaVb1tyGq3Sr1w1wS7gFj7zckNTe9W1LuetWZfc/w/knp3p6wzoMQ9cPIGbiN2g7h T5MLF117wUIFdrjU4YGCMWw/fQkLENZWrkXaj/kgl21y/eedGnz2x1GfCn3yZbSoah4n bVxw== MIME-Version: 1.0 X-Received: by 10.194.58.8 with SMTP id m8mr4776876wjq.43.1413914954011; Tue, 21 Oct 2014 11:09:14 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.79.202 with HTTP; Tue, 21 Oct 2014 11:09:13 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45589D977B@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589D977B@nkgeml506-mbx.china.huawei.com> Date: Tue, 21 Oct 2014 11:09:13 -0700 X-Google-Sender-Auth: ngoOzXbeYTtp3FCepezAZI4labM Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/P_448-2RE9xEBN6oF4Bz-Sf-Gv0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:12:37 -0000 At Tue, 21 Oct 2014 03:25:27 +0000, "Liubing (Leo)" wrote: > > > We are looking specifically for comments on the importance of the > > > document as well as its content. If you have read the document and > > > believe it to be of operational utility, that is also an important > > > comment to make. > > > > I have a mixed feeling about the importance of the document. I persona= lly > > don't think it worth publishing in its current form, although I wouldn'= t be > > opposed to it if the wg thinks it's useful. > > > > Vagueness and ambiguity regarding M, O, and A flags (especially the fir= st two) > > are well known, and it's not surprising that different implementations = behave > > differently. Since such a divergence can cause a critical operational = issue, I > > see a value in documenting these. > [Bing] I believe it is well known among standard developers, participants= and implementers who had paid attention on it. However, since the ambiguit= y problem is not so explicit in current standard, the vast administrators/o= perators out IETF might not quite familiar with it. I once talked with some= operator people, they were quite confused about the situation when they me= t the problem in their IPv6 testbed networks. > So, if there is an RFC explicitly stating the problems, I think it would = be good for administrators/operators to learn the fact before they actually= deploying the networks. Also, the document could be a formal reference for= potential standard work in the future to clear the ambiguity in current st= andards. There are many ambiguous things (and possible behavior divergence as a result) in this world in general. Just because we have something ambiguous is not critical enough to me for the cost of publishing something formal such as an RFC; IMO we should have specific problems that the ambiguity and divergence can cause, and the problems should be critical enough. In its current form, the described problems seem to be too artificial, hypothetical, or minor to be important to me. And that's why I didn't regard this draft as that important. Overall, your response to this point doesn't change my impression. I understand different people can have different views on the importance, so I didn't intend to insist mine is the only correct view. I expressed it as the chairs explicitly asked for it, but if many others think it important enough, that's fine to me. -- JINMEI, Tatuya From nobody Tue Oct 21 12:10:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4D1A01AA for ; Tue, 21 Oct 2014 12:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUFIE1d1-m0k for ; Tue, 21 Oct 2014 12:10:23 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010791A0013 for ; Tue, 21 Oct 2014 12:10:22 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id r10so1923123pdi.38 for ; Tue, 21 Oct 2014 12:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fyhKDlVkjwvQ9hA7rheBph8HOdoqA5N/7Z3CSKvWNdU=; b=wBQiAZa51MH5+RW8veFo5qMPZxNIb0WOHNtq/SkPvoih+2e+z0whRDJmeW+coCHte/ VNyvWOdI/oyztpPmr42pFJ3f1FtCJJHMU6p9UX0+uNjjXKJZ7sAZi+ruSJJ+lHeQEckZ y5DdLtTJUoQ13+Pwyw1KDCDzNn/5YJQN6d2V5BfZvNNuslrlAqWfPdOdcWrurGs7UN30 zZzjARHR/LTJDU1au3mMy1geLb02yZHl7w9C5k5EhIXcW2Dfv0xRciIwP4fl/vNXK0qf F97eyV9JJAk8cWXLX6lI2X16fIxRJvwK2G96fOVp1AHi4atYELsXa/XmpomeT5ia+yEe x3sQ== X-Received: by 10.66.233.37 with SMTP id tt5mr37604791pac.11.1413918622611; Tue, 21 Oct 2014 12:10:22 -0700 (PDT) Received: from [192.168.178.23] (176.199.69.111.dynamic.snap.net.nz. [111.69.199.176]) by mx.google.com with ESMTPSA id qf3sm12421160pbc.96.2014.10.21.12.10.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 12:10:21 -0700 (PDT) Message-ID: <5446AFA0.2070008@gmail.com> Date: Wed, 22 Oct 2014 08:10:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <026C20C3-7D92-4507-9B3D-1BC036EA8877@cisco.com> In-Reply-To: <026C20C3-7D92-4507-9B3D-1BC036EA8877@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iCLxD43B0BI48lNU8aG8_O8B4P8 Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:10:25 -0000 On 22/10/2014 04:44, Fred Baker (fred) wrote: > It=E2=80=99s good to see the commentary on this already.=20 Yep. Fred, we may not need it, but could you reserve 15 minutes in the Honolulu agenda, in case opinions have not converged by then? It would have to be Monday morning as I have a clash Monday afternoon. > To recap: >=20 > v6ops discussed this draft way back when and sent it to the IESG. The I= ETF Last Call left at least one AD with the belief that there was, in his= words, =E2=80=9Cno consensus supporting the proposed action=E2=80=9D, an= d the IESG dropped it. If we choose to send it up again, I think we need = to make sure we have the right action (I note Lorenzo=E2=80=99s question,= whether we should only deprecate one RFC, not two) and the arguments all= together. I think reality has moved on since then. Brian > On Oct 20, 2014, at 11:38 PM, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the IPv6 Operations Working Group of the = IETF. >> >> Title : Deprecating Connection of IPv6 Domains via IP= v4 Clouds (6to4) >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-06.txt >> Pages : 7 >> Date : 2014-10-20 >> >> Abstract: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism has shown that the mechanism is >> unsuitable for widespread deployment and use in the Internet. This >> document requests that RFC3056 and the companion document "An Anycas= t >> Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved t= o >> historic status. It also recommends that future products should not= >> support 6to4 and that existing deployments should be reviewed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6to4-to-historic-0= 6 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 21 12:21:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4643F1A1A7D for ; Tue, 21 Oct 2014 12:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfuhWElzPenS for ; Tue, 21 Oct 2014 12:21:35 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFD81A19F9 for ; Tue, 21 Oct 2014 12:21:35 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id bj1so2038722pad.15 for ; Tue, 21 Oct 2014 12:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8qOCfXFcHhDvAm0JkYZrDuG0xRPcuhOwvMm/PFcUuxg=; b=kailWPMvo2l/q4l/AYn0YT/lN8xwt+JoLcbsH3SEe4Kg3SvcXOxLA88hbzeFZm8z5r fl/bNPoZr5a6BryDpiwjhYE6Zi817J4mvn82Lrgv3zq4rUHIn8pd5TL9AWav5Cj8dWC0 9qo70+RUFeFY66HPGZqNK0Wf9HV7wTHG8vK0Blwrjs9uKasq8bvhIJUVlWFDhqQ56Lt1 5jpYnmfd8KjmkCnKmGYVds+79nWgvK7iorZ+QAAQH7S2VaS2NoTijuHwGzFTx3q/wqtL 2RDohWFPWvHqJx86LdFfMKaf0+8eItOXIq+wfasFeSSGwvqw2lBW93aIJzrEeXSvDA/o FFEg== X-Received: by 10.68.100.69 with SMTP id ew5mr37498911pbb.84.1413919295171; Tue, 21 Oct 2014 12:21:35 -0700 (PDT) Received: from [192.168.178.23] (176.199.69.111.dynamic.snap.net.nz. [111.69.199.176]) by mx.google.com with ESMTPSA id ra4sm12713609pab.33.2014.10.21.12.21.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 12:21:33 -0700 (PDT) Message-ID: <5446B240.5090102@gmail.com> Date: Wed, 22 Oct 2014 08:21:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Farmer References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> <54468436.40100@umn.edu> In-Reply-To: <54468436.40100@umn.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RqWyGepQqZ15x5iSwSEjwa0FtQU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:21:37 -0000 On 22/10/2014 05:05, David Farmer wrote: > On 10/21/14, 09:34 , Lorenzo Colitti wrote: >> On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown > > wrote: >> >> There=E2=80=99s a paragraph at the end that says: >> >> "Peer-to-peer usage of the 6to4 mechanism, not depending on the= >> >> anycast mechanism, might exist in the Internet, largely >> unknown to >> operators. This is harmless to third parties and the current >> document is not intended to prevent such traffic continuing." >> >> >> which is a little at odds with the Historic status for 3056? If it= =E2=80=99s >> made historic, and support removed, it would harm them=E2=80=A6? >> >> >> Would it make sense to move only 3068 to historic, and not 3056? >=20 > Yes, deprecate the 6to4 relay function, which means that only the > 192.88.99.0/24 prefix would deprecated. 2002::/16 would remain valid > but only in the context of peer-to-peer 6to4, and it therefore SHOULD > NOT be advertised to the IPv6 global Internet. When I got my fingers on the XML file I found myself in two minds about this. Deprecating RFC 3056 sends a stronger message about future releases and deployments, but it does not stop existing systems from work= ing. Filtering 192.88.99.0/24 will break current usage 100% for affected clients, which is clean and simple. But filtering 2002::/16 in some places will insert black holes that break current usage for some servers and will look pretty random to clients. So I think my preference is - deprecate 3056 to get the message across - recommend filtering 192.88.99.0/24 so that clients see clean failure - do not recommend filtering 2002::/16 so that return paths still work. BTW, we changed the proposed status to BCP so that we can use normative language for such recommendations. Brian >=20 >=20 From nobody Tue Oct 21 16:50:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1770C1A883A for ; Tue, 21 Oct 2014 16:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCo7Kmgfrd4m for ; Tue, 21 Oct 2014 16:50:02 -0700 (PDT) Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by ietfa.amsl.com (Postfix) with SMTP id 031C81A8839 for ; Tue, 21 Oct 2014 16:50:01 -0700 (PDT) Received: (qmail 31645 messnum 12492526 invoked from network[213.94.190.15/avas03.vendorsvc.cra.dublin.eircom.net]); 21 Oct 2014 23:49:59 -0000 Received: from avas03.vendorsvc.cra.dublin.eircom.net (213.94.190.15) by mail06.svc.cra.dublin.eircom.net (qp 31645) with SMTP; 21 Oct 2014 23:49:59 -0000 Received: from [192.168.43.66] ([109.125.19.173]) by avas03.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 5zpt1p00K3k3DEM01zpzR4; Wed, 22 Oct 2014 00:49:59 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_29E0BA5E-3198-4136-B4A9-97931ACCDB56" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ross Chandler In-Reply-To: <544678F9.8050505@jvknet.com> Date: Wed, 22 Oct 2014 00:49:44 +0100 Message-Id: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> <544678F9.8050505@jvknet.com> To: Victor Kuarsingh X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/shbuYL4dWmdcs0_I3l7HX7Fs74Q Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:50:05 -0000 --Apple-Mail=_29E0BA5E-3198-4136-B4A9-97931ACCDB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 21 Oct 2014, at 16:17, Victor Kuarsingh wrote: >=20 >=20 > On 2014-10-21 10:34 AM, Lorenzo Colitti wrote: >> On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown > wrote: >> There=92s a paragraph at the end that says: >>=20 >> "Peer-to-peer usage of the 6to4 mechanism, not depending on the >> anycast mechanism, might exist in the Internet, largely unknown to >> operators. This is harmless to third parties and the current >> document is not intended to prevent such traffic continuing." >>=20 >> which is a little at odds with the Historic status for 3056? If it=92s = made historic, and support removed, it would harm them=85? >>=20 >> Would it make sense to move only 3068 to historic, and not 3056?=20 > That seems to make sense to me. >=20 +1 historic for 3068 Would like there to be a clear recommendation to filter 192.88.99.0/24 = and 2002::/16 coming in from the Internet DFZ. +1 to Section 4 of = http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 = Regards Ross --Apple-Mail=_29E0BA5E-3198-4136-B4A9-97931ACCDB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 21 Oct 2014, at 16:17, Victor Kuarsingh <victor@jvknet.com> = wrote:

=20 =20

On 2014-10-21 10:34 AM, Lorenzo = Colitti wrote:
On Tue, Oct 21, 2014 at 11:30 PM, = Tim Chown <tjc@ecs.soton.ac.uk> wrote:
There=92s a paragraph at the end that = says:

  "Peer-to-peer usage of the 6to4 mechanism, not depending on = the
   anycast mechanism, might exist in the =
Internet, largely unknown to
   operators.  This is harmless to third parties and the current
   document is not intended to prevent such traffic =
continuing."

which is a little at odds with the = Historic status for 3056? If it=92s made historic, and support = removed, it would harm them=85?

Would it make sense to move only 3068 to = historic, and not 3056?
That seems to make sense to me.

+1  historic for = 3068

Would like there to be a =  clear recommendation to filter 192.88.99.0/24 and  2002::/16 = coming in from the Internet DFZ.


Regards
Ross

= --Apple-Mail=_29E0BA5E-3198-4136-B4A9-97931ACCDB56-- From nobody Tue Oct 21 17:09:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8B1A8844 for ; Tue, 21 Oct 2014 17:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsxZaawxO7F8 for ; Tue, 21 Oct 2014 17:09:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C601A883D for ; Tue, 21 Oct 2014 17:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1326; q=dns/txt; s=iport; t=1413936571; x=1415146171; h=from:to:subject:date:message-id:mime-version; bh=g9aGALRmlNNZ6h9ooB4echk+CmZy7ggSsV4TSuLxEG4=; b=eei9KTj8n2E8Lml6qyf0ypuIgzjZcYDDmRQ1FUPz4iXVhTLZuQ32C3Pf ayEpcbRTGQE3QYnbegg9SNmY8UyMOnz4aBacNTFfonrA3ghP6qgLD7p1p e2ilRqoSoGOKIQT1r2r7odE1RApSJJT5EAF9u4EDMwpzJsKceW3aWiTHR A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPH0RlStJA2I/2dsb2JhbABcgw5TWQPNBIhiFgF9hAmBCwGBACcEHAWIMQ2heKQuAQEIAQEBAQEdlAuBHgWSAYIOgVCHe5Ylg3iCNIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,765,1406592000"; d="asc'?scan'208";a="362160725" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 22 Oct 2014 00:09:31 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9M09V1I031986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Oct 2014 00:09:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.152]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 19:09:30 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: IETF 91 Preliminary Agenda Thread-Index: AQHP7Yxz7v9HiFtOkki/JfgGZeAWXA== Date: Wed, 22 Oct 2014 00:09:30 +0000 Message-ID: <4DF01B41-B1E8-4740-931E-708096732F04@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.160] Content-Type: multipart/signed; boundary="Apple-Mail=_4575D0CA-404E-4DEE-AC76-3081977CC10D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/t4A-PZhBRUGbsun5IQS6CFkAgS8 Subject: [v6ops] IETF 91 Preliminary Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:09:37 -0000 --Apple-Mail=_4575D0CA-404E-4DEE-AC76-3081977CC10D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Lee and I have come up with a draft agenda. It has two documents on it = that have not yet been updated; if they aren=92t updated by the filing = deadline, we=92ll be taking them off the agenda. If new drafts are filed = by the deadline and we see working group interest, we will adjust for = that as well. The filing deadline is 2014-10-27 (Monday) UTC 23:59. http://www.ietf.org/proceedings/91/agenda/agenda-91-v6ops Draft authors, we need to know whom to expect to be presenting, and we = need whatever slides you expect to use. We are planning about half an = hour per draft, which we expect to be at least half discussion. --Apple-Mail=_4575D0CA-404E-4DEE-AC76-3081977CC10D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFURvW5bjEdbHIsm0MRApTSAJwOSRomxB6zf1NCE7scl0vOk982ZQCbBeQ7 iLnxCutFDBBktHBS7rIUt7Y= =/MQw -----END PGP SIGNATURE----- --Apple-Mail=_4575D0CA-404E-4DEE-AC76-3081977CC10D-- From nobody Tue Oct 21 19:13:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A621A8A20 for ; Tue, 21 Oct 2014 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDUCVyF799Yd for ; Tue, 21 Oct 2014 19:12:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867E21A8A0F for ; Tue, 21 Oct 2014 19:12:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNX18916; Wed, 22 Oct 2014 02:12:54 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 03:12:54 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 10:12:49 +0800 From: "Liubing (Leo)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w4xUoAgAEA2GCAAJBxgIABAp1A Date: Wed, 22 Oct 2014 02:12:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589DAC73@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589D977B@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/je194fb1YsEgbm0nBHitb0YjDJE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:12:59 -0000 SGkgSmlubWVpLA0KDQo+IFRoZXJlIGFyZSBtYW55IGFtYmlndW91cyB0aGluZ3MgKGFuZCBwb3Nz aWJsZSBiZWhhdmlvciBkaXZlcmdlbmNlIGFzIGENCj4gcmVzdWx0KSBpbiB0aGlzIHdvcmxkIGlu IGdlbmVyYWwuICBKdXN0IGJlY2F1c2Ugd2UgaGF2ZSBzb21ldGhpbmcgYW1iaWd1b3VzDQo+IGlz IG5vdCBjcml0aWNhbCBlbm91Z2ggdG8gbWUgZm9yIHRoZSBjb3N0IG9mIHB1Ymxpc2hpbmcgc29t ZXRoaW5nIGZvcm1hbCBzdWNoDQo+IGFzIGFuIFJGQzsgSU1PIHdlIHNob3VsZCBoYXZlIHNwZWNp ZmljIHByb2JsZW1zIHRoYXQgdGhlIGFtYmlndWl0eSBhbmQNCj4gZGl2ZXJnZW5jZSBjYW4gY2F1 c2UsIGFuZCB0aGUgcHJvYmxlbXMgc2hvdWxkIGJlIGNyaXRpY2FsIGVub3VnaC4NCg0KW0Jpbmdd IEkgYWxzbyBhZ3JlZSBub3QgYW55IGFtYmlndW91cyB0aGluZ3MgYXJlIHdvcnRoIHRvIGJlIGRv Y3VtZW50ZWQuDQpCdXQgdGhlIERIQ1B2Ni9TTEFBQyBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gaXNz dWUgaXMgcXVpdGUgZnVuZGFtZW50YWwgYW5kIGNyaXRpY2FsIGluIG15IHBvaW50IG9mIHZpZXcu DQoNCj4gSW4gaXRzIGN1cnJlbnQgZm9ybSwgdGhlIGRlc2NyaWJlZCBwcm9ibGVtcyBzZWVtIHRv IGJlIHRvbyBhcnRpZmljaWFsLCBoeXBvdGhldGljYWwgb3IgbWlub3IgdG8gYmUgaW1wb3J0YW50 IHRvIG1lLiAgDQo+IEFuZCB0aGF0J3Mgd2h5IEkgZGlkbid0IHJlZ2FyZCB0aGlzIGRyYWZ0IGFz IHRoYXQgaW1wb3J0YW50LiAgDQo+IE92ZXJhbGwsIHlvdXIgcmVzcG9uc2UgdG8gdGhpcyBwb2lu dCBkb2Vzbid0IGNoYW5nZSBteSBpbXByZXNzaW9uLg0KPiBJIHVuZGVyc3RhbmQgZGlmZmVyZW50 IHBlb3BsZSBjYW4gaGF2ZSBkaWZmZXJlbnQgdmlld3Mgb24gdGhlIGltcG9ydGFuY2UsIHNvDQo+ IEkgZGlkbid0IGludGVuZCB0byBpbnNpc3QgbWluZSBpcyB0aGUgb25seSBjb3JyZWN0IHZpZXcu ICBJIGV4cHJlc3NlZCBpdCBhcyB0aGUNCj4gY2hhaXJzIGV4cGxpY2l0bHkgYXNrZWQgZm9yIGl0 LCBidXQgaWYgbWFueSBvdGhlcnMgdGhpbmsgaXQgaW1wb3J0YW50IGVub3VnaCwNCj4gdGhhdCdz IGZpbmUgdG8gbWUuDQoNCltCaW5nXSBJIGNhbid0IGFncmVlIHRoZSBwcm9ibGVtcyBhcmUgYXJ0 aWZpY2lhbCBvciBoeXBvdGhldGljYWwuIElmIHlvdSdyZSBpbiB0aGUgY2FzZXMgdGhlIGRvY3Vt ZW50IGRlc2NyaWJlcywgeW91J2xsIGZhY2UgdGhlIHByb2JsZW1zLCBpdCdzIHJlYWwuDQpIb3dl dmVyLCBpZiB5b3UgYXJndWUgeW91J2xsIG5ldmVyIG1lZXQgdGhlIHNpdHVhdGlvbnMgb3IgaXQn cyBub3QgYSBiaWcgZGVhbCBldmVuIGlmIHlvdSBtZWV0IHRoZSBzaXR1YXRpb25zLCB0aGF0J3Mg YW5vdGhlciB0aGluZy4gT3BpbmlvbnMgbWF5IHZhcnkuDQoNCkFueXdheSwgdGhhbmtzIGZvciBl eHByZXNzaW5nIHlvdXIgb3BpbmlvbnMgb24gaXQuIEkgYWxzbyBob3BlIHRoZXJlIGNvdWxkIGJl IG1vcmUgZmVlZGJhY2tzIGZyb20gdGhlIFdHLiANCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQo+ IC0tDQo+IEpJTk1FSSwgVGF0dXlhDQo= From nobody Tue Oct 21 19:34:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5981A8A48 for ; Tue, 21 Oct 2014 19:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNmOM_8uWUyb for ; Tue, 21 Oct 2014 19:34:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD5E1A8A3E for ; Tue, 21 Oct 2014 19:34:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU47360; Wed, 22 Oct 2014 02:34:04 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 03:34:03 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 10:33:59 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w4xUoAgAElIACAAXlugA== Date: Wed, 22 Oct 2014 02:33:58 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589DACA2@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45589DACA2nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4-XpzPDrIH5j6tDY6q0ShsioVFY Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 02:34:07 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45589DACA2nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIHJlcGxp ZXMgaW5saW5lLg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBMb3JlbnpvIENvbGl0dGkNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjEs IDIwMTQgNzo0MiBQTQ0KVG86IOelnuaYjumBlOWTiQ0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtIFdH TEMNCg0KT24gdGhlIG90aGVyIGhhbmQsIHRoZSBhcHBlbmRpeCwgd2hpY2ggZG9jdW1lbnRzIHRo ZSBiZWhhdmlvdXIgb2YgdmFyaW91cyBPU2VzIHVuZGVyIGRpZmZlcmVudCBjb25kaXRpb25zLCBp cyB1c2VmdWwuDQoNCkdpdmVuIHRoYXQsIGl0IHdvdWxkIHNlZW0gdG8gbWFrZSBtb3JlIHNlbnNl IGZvciB0aGlzIGRvY3VtZW50IHRvIGZvY3VzIG9ubHkgb24gdGhlIHJlc3VsdHMgb2YgdGhlIGlu dmVzdGlnYXRpb24gKGkuZS4sIG9ubHkgdGhlIGFwcGVuZGl4KSwgYW5kIGEgY29uY2x1ZGluZyBz dGF0ZW1lbnQgdGhhdCBub3RlcyB0aGF0IGltcGxlbWVudGF0aW9ucyBkaWZmZXIgaW4gdGhlaXIg YmVoYXZpb3VyLCBhbmQgdGhhdCByZW51bWJlcmluZyBiZWhhdmlvdXIgaXMgc3Vic3RhbnRpYWxs eSBkaWZmZXJlbnQuDQoNCltCaW5nXSBJ4oCZbGwgY29uc2lkZXIgdGhpcyBzdWdnZXN0aW9uLiBC dXQgaWYgdGhpcyBkb2N1bWVudCBmb2xsb3dzIHRoZSBhcHByb2FjaCwgaXQgbmVlZHMgYW5vdGhl ciBzaWduaWZpY2FudCByZXZpc2lvbi4gSeKAmWQgbGlrZSB0byBoZWFyIG90aGVyc+KAmSBvcGlu aW9ucyBhbmQgZGlzY3Vzc2lvbiBpbiB0aGUgdXBjb21pbmcgbWVldGluZy4NCg0KQmVzdCByZWdh cmRzLA0KQmluZw0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45589DACA2nkgeml506mbxchi_ 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 bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBMb3Jl bnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIg Y29tbWVudHMuIFBsZWFzZSBzZWUgcmVwbGllcyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+TG9yZW56byBDb2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9i ZXIgMjEsIDIwMTQgNzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7npZ7mmI7pgZTlk4k8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFj LXByb2JsZW0gV0dMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5PbiB0aGUgb3RoZXIgaGFuZCwgdGhlIGFwcGVuZGl4LCB3aGlj aCBkb2N1bWVudHMgdGhlIGJlaGF2aW91ciBvZiB2YXJpb3VzIE9TZXMgdW5kZXIgZGlmZmVyZW50 IGNvbmRpdGlvbnMsIGlzIHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkdpdmVuIHRoYXQsIGl0IHdvdWxkIHNlZW0gdG8gbWFrZSBtb3JlIHNl bnNlIGZvciB0aGlzIGRvY3VtZW50IHRvIGZvY3VzIG9ubHkgb24gdGhlIHJlc3VsdHMgb2YgdGhl IGludmVzdGlnYXRpb24gKGkuZS4sIG9ubHkgdGhlIGFwcGVuZGl4KSwgYW5kIGEgY29uY2x1ZGlu ZyBzdGF0ZW1lbnQgdGhhdCBub3RlcyB0aGF0IGltcGxlbWVudGF0aW9ucyBkaWZmZXIgaW4gdGhl aXIgYmVoYXZpb3VyLA0KIGFuZCB0aGF0IHJlbnVtYmVyaW5nIGJlaGF2aW91ciBpcyBzdWJzdGFu dGlhbGx5IGRpZmZlcmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0Jp bmddIEnigJlsbCBjb25zaWRlciB0aGlzIHN1Z2dlc3Rpb24uIEJ1dCBpZiB0aGlzIGRvY3VtZW50 IGZvbGxvd3MgdGhlIGFwcHJvYWNoLCBpdCBuZWVkcyBhbm90aGVyIHNpZ25pZmljYW50IHJldmlz aW9uLiBJ4oCZZCBsaWtlIHRvIGhlYXIgb3RoZXJz4oCZDQogb3BpbmlvbnMgYW5kIGRpc2N1c3Np b24gaW4gdGhlIHVwY29taW5nIG1lZXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkJpbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45589DACA2nkgeml506mbxchi_-- From nobody Wed Oct 22 06:23:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969AE1A913D for ; Wed, 22 Oct 2014 06:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsstKJCNGzyC for ; Wed, 22 Oct 2014 06:23:45 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262E11A9109 for ; Wed, 22 Oct 2014 06:23:45 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 1efa7445.2ae48be52940.4355744.00-2460.12258949.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 22 Oct 2014 13:23:45 +0000 (UTC) X-MXL-Hash: 5447afe163194bf0-31fba64976d6ac723ff528491ba44280ccc5830e Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 7bfa7445.0.4355322.00-1865.12257728.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 22 Oct 2014 13:23:07 +0000 (UTC) X-MXL-Hash: 5447afbb3906dc91-c4dac05dd7ea088c797b251449295bcd451684bb Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9MDN3TT015016; Wed, 22 Oct 2014 09:23:03 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9MDMvkf014964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Oct 2014 09:22:57 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 22 Oct 2014 13:22:49 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 09:22:49 -0400 From: "STARK, BARBARA H" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , "Liubing (Leo)" Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aTCbHURKcuREOkuS1Hct2VS5w5jnUAgACaXICAAPbsgIAA/j9Q Date: Wed, 22 Oct 2014 13:22:48 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA5F40@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589D977B@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.234] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=XYGasLcb5nsA:10 a=BLceEmwcHowA:10 a=ZPS] X-AnalysisOut: [k82zQDygA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Xb9D4kqwO] X-AnalysisOut: [Y2_vG3uzQoA:9 a=UAVRJdkkkM0A:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9PfdqwTTqNzpGgADA040clO99FE Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:23:47 -0000 > > > > We are looking specifically for comments on the importance of the > > > > document as well as its content. If you have read the document and > > > > believe it to be of operational utility, that is also an important > > > > comment to make. > > > > > > I have a mixed feeling about the importance of the document. I > > > personally don't think it worth publishing in its current form, > > > although I wouldn't be opposed to it if the wg thinks it's useful. > > > > > > Vagueness and ambiguity regarding M, O, and A flags (especially the > > > first two) are well known, and it's not surprising that different > > > implementations behave differently. Since such a divergence can > > > cause a critical operational issue, I see a value in documenting thes= e. > > [Bing] I believe it is well known among standard developers, participan= ts > and implementers who had paid attention on it. However, since the > ambiguity problem is not so explicit in current standard, the vast > administrators/operators out IETF might not quite familiar with it. I onc= e > talked with some operator people, they were quite confused about the > situation when they met the problem in their IPv6 testbed networks. > > So, if there is an RFC explicitly stating the problems, I think it woul= d be good > for administrators/operators to learn the fact before they actually deplo= ying > the networks. Also, the document could be a formal reference for potentia= l > standard work in the future to clear the ambiguity in current standards. > There are many ambiguous things (and possible behavior divergence as a > result) in this world in general. Just because we have something ambiguo= us > is not critical enough to me for the cost of publishing something formal = such > as an RFC; IMO we should have specific problems that the ambiguity and > divergence can cause, and the problems should be critical enough. >=20 > In its current form, the described problems seem to be too artificial, > hypothetical, or minor to be important to me. And that's why I didn't re= gard > this draft as that important. Overall, your response to this point doesn= 't > change my impression. +1 I agree with what Jinmei said. Barbara From nobody Wed Oct 22 06:56:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03931AC3AB for ; Wed, 22 Oct 2014 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPY_mAU4kBNj for ; Wed, 22 Oct 2014 06:56:32 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF701AC3A8 for ; Wed, 22 Oct 2014 06:56:32 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id rl12so3482347iec.17 for ; Wed, 22 Oct 2014 06:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MA4gXq7Lo1u6DeFVLUp7znvx6wz0fBXVRth+Nm66Ra0=; b=n287uHuBI+BL7p9dC9jgib4BwNvveoWoE6vJuDs3fI5+xoqFxfgx4YSrmaOZMbdWfu MRp3nRgWgJrJEfx3hv1ptb16xI+D/bKjwnGNTsqXeemI27D8rcp5AF3j09STL9zNLgGO 5wf5ClUtR8UyU1w1rL7m/WZU+Fr5Gz/mtA50lK7U3Vtbi4g1ibGQtSM0+FrDvkcjgNsZ XWKTScAVch5S2xm18erYTy2+cV0cPvgtlxJVcxwb/8/rY9RaFXQRXVv3hy+jErPsaj2q e/wzGswuqjOWiWYT2GjGJl1sGpCjSrXq2XZZmemQVCNiw/eUuNkFAFJtvXtCRY+oyWl7 n31A== MIME-Version: 1.0 X-Received: by 10.107.133.170 with SMTP id p42mr44106597ioi.7.1413986192050; Wed, 22 Oct 2014 06:56:32 -0700 (PDT) Received: by 10.107.137.231 with HTTP; Wed, 22 Oct 2014 06:56:31 -0700 (PDT) In-Reply-To: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> Date: Wed, 22 Oct 2014 15:56:31 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: fred@cisco.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/35P46fcn1NnPZez8hIWFh3RPXSE Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:56:35 -0000 Below goes my review of this document. General impressions: The information about the differences in the behavior of the OSes is operationally useful and is worth publishing. Some of the questions that this document raises do look like valid concerns to me, and should be brought further (i.e. the DHCPv6 address behavior on flag change), some of them (A=3D0,O=3D1,M=3D0), in the absence of supporting reasons "why", look more like a curiosity - interesting to point out in case this corner case happens as a transient, but not worth spending the cycles trying to agree what the implementations should be doing in that case. More specific comments: 2.1. M (Managed) Flag "The M flag indicates that addresses are available from IPv6." s/IPv6/DHCPv6/ ? "the O flag is redundant and can be ignored" Could be good to have an explicit reference to section "4.2.Router Advertisement Message Format" of RFC4861 where this text is coming from. 2.3. A (Autonomous) Flag "The A flag indicates that the prefix that is also carried by the PI option can be used for SLAAC. A flag semantics are independent of M and O flag semantics. The A flag indicates that the prefix can be used by SLAAC, regardless of the M and O flag settings." What about rephrasing this as: "The A flag, carried within the Prefix Information option, indicates that the prefix in this option can be used for stateless autoconfiguration. Flag semantics are independent of M and O flags, and their values do not affect whether this prefix can be used or not." "3.2.1. Inappropriate Sources" interesting finding. Why is it a problem worth solving ? "3.2.2. Renumbering" The three steps described read as a sequence, whereas they are alternative renumbering strategies. This should be rephrased to make it clearer. Also, the renumbering discusses flash renumbering process. Should it also make a reference to rfc4192 which is aiming to perform a renumbering without a flag day, and look at the issues accordingly ? Appendix A: A.1: "Host 1: Window 7 / Window 8.1 Virtual Host" - Windows should be in plural. "Host 2: Ubuntu 14.04" - is it Ubuntu Desktop in default configuration ? I presume so, but it should be mentioned explicitly. A.3: "reveiving A transitiong" =3D> needs spellcheck and potentially rephrase for the sentence. Appendix B: "More specifically, is RA (with M=3D1) required to trigger DHCPv6? If there are no RAs at all, should hosts initiate DHCPv6 by themselves?" RFC4862, 5.5.2. Absence of Router Advertisements mentions: Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [RFC4861]. Note that it is possible that there is no router on the link in this sense, but there is a node that has the ability to forward packets. In this case, the forwarding node's address must be manually configured in hosts to be able to send packets off-link, since the only mechanism to configure the default router's address automatically is the one using Router Advertisements. Does this wording answer the question ? "it is not clear whether the host should start DHCPv6 or not; or vise versa, the host is already both SLAAC/DHCPv6 configured, then M flag change from TRUE to FALSE, it is also not clear whether the host should turn DHCPv6 off or not." What is desired from the operational standpoint and why ? (Also, taking into the account the effects on the DHCPv6 server caused by a crowd of hosts receiving an RA and simultaneously (re)starting up the DHCPv6 process). "For example, when both M and O flags are TRUE, it is not clear whether the host should initiate one stateful DHCPv6 session to get both address and info- configuration or initiate two independent sessions of which one is dedicated for address provisioning and the other is for information provision. " The end result of doing either of the two behaviors should be the same, shouldn=E2=80=99t it ? If so - then why going through the effort of specifying one or another behavior ? " When A and M flags are FALSE and O flag is TRUE, it is not clear whether the host should initiate a stand- alone stateless DHCPv6 session." Again, same question as in 3.2.1: what is the practical use case scenario for this ? i.e. is this problem worth solving and why ? --a On 10/19/14, fred@cisco.com wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Oct 22 09:59:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7321ACE48; Wed, 22 Oct 2014 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZn8DGZC2LjR; Wed, 22 Oct 2014 09:59:48 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA531ACE22; Wed, 22 Oct 2014 09:59:47 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 50BAC2AA0F; Wed, 22 Oct 2014 16:59:44 +0000 (GMT) Date: Wed, 22 Oct 2014 10:00:38 -0700 From: Marc Binderberger To: Robert Raszuk , Iljitsch van Beijnum Message-ID: <20141022100038252323.69536a03@sniff.de> In-Reply-To: References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <20141017021132122119.6274d1f2@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vysDDdYViKTFluyXJRghT7i5eH4 Cc: V6 Ops List , "grow@ietf.org" , Pedro Andres Aranda Gutierrez Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 16:59:50 -0000 Hello Robert et al., > You can't *mandate* anything in BGP until you have a way to > effectively enforce it regardless if this is v4 or v6 or v9. no need to mandate anything. If a best-practice is used by enough people then it is de- facto enforced. And it's actually better than a formal rule as (local) exceptions may be needed. Not to mention that agreements between ISP-ISP or ISP-customer should be possible that are not following BCPs (and are no matter of others unless they are negatively impacted). > [...] but as Randy said those in suits who care about their > respective businesses. The beauty of BCP (IMHO) is it's not you who is "a problem" for the suits, it's this anonymous "Internet" that e.g. stubbornly refuses to accept the customer's /27 (IPv4). Announce it, take you pay check and filter it out once the suites realize it does not work and they cannot blame anyone. > Today at most we can have Geoff very nicely illustrating the picture > at next RIPE or NANOG. But he does not have a way to issue fine > tickets to offenders :) Which is "fine", this is how it works until today: reactive. If problems show up and stay, new recommendations can be brought up. Worked so far (although there is no guarantee it will continue to work) . The original email from Iljitsch was about some best practice. Reading through the email thread I start to wonder if de-aggregation should be actually "encouraged" instead of being restricted - in the sense that it might be better to allow de-aggregation than having enterprise LIRs with multiple AS and PA allocations. Reason: the de-aggregation can be filtered in regions that are "remote" (unless the de-aggregator spans all regions). Iljitsch mentioned Note that filtering according to geographic communities could be done within an AS, removing the need for inter-AS coordination (beyond propagating the communities). and I wonder if there is even a need for an agreement on communities; can't this be done per AS itself? Then use the information to e.g. calculate prefix filter off-router and updated every N hours the routers. The result would be de-aggregation of a customer PA or PI network in it's own region and using the aggregate in other regions (what I named "remote") where the details don't matter. This would require that the aggregate network is announced. It would also require to assign larger address blocks instead of multiple smaller to allow de-aggregation. Making de-aggregation painful will result in Enterprises requesting multiple AS, as Enno pointed out. Regards, Marc On Sat, 18 Oct 2014 11:06:09 +0200, Robert Raszuk wrote: >> IPv6 BPs could mandate best aggregates only. > > You can't *mandate* anything in BGP until you have a way to > effectively enforce it regardless if this is v4 or v6 or v9. > > It is not the problem of folks in shorts and sandals who type in BGP > policies, but as Randy said those in suits who care about their > respective businesses. > > Today at most we can have Geoff very nicely illustrating the picture > at next RIPE or NANOG. But he does not have a way to issue fine > tickets to offenders :) > > Best, > r. > From nobody Wed Oct 22 12:21:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBD61A0242; Fri, 17 Oct 2014 21:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plxQKK8qrGDF; Fri, 17 Oct 2014 21:15:29 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6D91A0204; Fri, 17 Oct 2014 21:15:29 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id w7so1566530qcr.18 for ; Fri, 17 Oct 2014 21:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YUHE8vZ7XRbZ9kvSv9MFLvKKAx0vQqcD2gBUETcj1GE=; b=bCXfNOOShzUpFrfznqPn57ba/2AelPRmdkv6ttWneNzPO2YNwNAiPmCK1OfZI8Oht0 vzMX0wHc8SBQi+a+gdemQIX18F6ktq0t4RvYh8oGFpLCOYB60YxJiGRWejdJNs7kVNpJ zOU/R+GVnltZgDEVcRF9k3dYQW+6LxcqEMU7qQiJvykxfyhjg49SIqrA7glBIE2lmadp CKVpEJrUn/R0SlyWAzGnT+7CCD22YNRw0qhun5ujw9nlyLBMSpKqAvixIqBmPuidLbF5 tn8yRYgfVkxyD5dKLXGxzlbB5PsxXiPnpU5GaiZB4A2vwl7471SHpBS8y5nmBgNx6CAV pzhg== MIME-Version: 1.0 X-Received: by 10.224.113.197 with SMTP id b5mr11270514qaq.5.1413605728696; Fri, 17 Oct 2014 21:15:28 -0700 (PDT) Received: by 10.96.228.107 with HTTP; Fri, 17 Oct 2014 21:15:28 -0700 (PDT) Received: by 10.96.228.107 with HTTP; Fri, 17 Oct 2014 21:15:28 -0700 (PDT) In-Reply-To: <20141017021132122119.6274d1f2@sniff.de> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <543FA152.4080907@foobar.org> <9C220463-4D0E-465B-ADF5-390518F180C7@muada.com> <54403599.6040205@foobar.org> <20141017021132122119.6274d1f2@sniff.de> Date: Sat, 18 Oct 2014 06:15:28 +0200 Message-ID: From: Pedro Andres Aranda Gutierrez To: Marc Binderberger Content-Type: multipart/alternative; boundary=047d7bd7580a4fbd7b0505aabb3c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r-HDA49xEW4gjaiIDEhGc6R5A64 X-Mailman-Approved-At: Wed, 22 Oct 2014 12:21:22 -0700 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation data (was: Deaggregation by large organizations) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 04:15:32 -0000 --047d7bd7580a4fbd7b0505aabb3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just my .002. Maybe it could help in the discussion to make a distinction between subnets of an AS and different ASes. Clearly there is no solution for the latter. And for the first, there will be lots of controversy ;-) IPv6 BPs could mandate best aggregates only. /PA El 17/10/2014 15:47, "Marc Binderberger" escribi=C3=B3: > Hello Nick and Iljitsch, > > fairly stable baseline of 20-30%, which may be acceptable if it stays > there. > Although peaks of 70% (is the 100% a graph problem?) seem to be a reason > _for_ filtering. > > Now what I'm wondering > > (1) is there a need to carry all the deaggregates? Because if you are far > enough away they may "look the same as the aggregate". To use Iljitsch' > example ... > > > I know this is controversial. "Topology ain't geography". Actually, mos= t > of > > the time there is a significant correlation. If all German cities injec= t > a > > more specific, do you really need to hear those in Tokyo or Seattle? Ju= st > > send the traffic to Europe as per the aggregate and let them figure it > out > > there. > > ... it's likely that for an US ISP X, peering with European ISPs Y and Z > who > carry the various deaggregate plus aggregate from Germany, all the Europe= an > prefixes have this peering router as next hop (let's say we have > next-hop-self). > > What about BGP on this peering router doing some auto-aggregation in such= a > case? Has this been discussed? It would avoid geographic communities an= d > would simply follow the BGP topology: if the deaggregates result in the > same > forwarding information than the aggregate just keep the aggregate. Your > routing table would have deaggregates for your own region but only > aggregates > for the other, more distant regions. > > > (2) the problem of ever-growing routing tables and de-aggregation is not > new. > After so many years I'm wondering if the answer is that this cannot be > solved > with BGP/routing alone (?) Otherwise you would have found a solution > meanwhile :-) > And we have the - understandable and growing - needs of Enterprises, who > de-aggregate their PA addresses when they are LIR, or request PI addresse= s > per location. > > Combining this, should the de-aggregation step not be done with a differe= nt > technology? LISP comes to my mind (biased, as I'm working on it) or in > general a "de-aggregation overlay". The overlay would need gateways to th= e > BGP world and would announce one aggregate prefix only while the > de-aggregate > prefixes would be limited to the particular Enterprise overlay network an= d > would not show up in BGP. > > > > Regards, Marc > > > > > On Thu, 16 Oct 2014 22:16:09 +0100, Nick Hilliard wrote: > > On 16/10/2014 16:47, Iljitsch van Beijnum wrote: > >> Growth in IPv6 more specifics was 57% last year... > > > > Here's a graph which shows the percentage of more-specifics between 200= 3 > > and today from Geoff Huston's web site: > > > > http://goo.gl/QA0xud > > > > Eyeballing the graph, it's not clear where the figure of 57% came from. > In > > terms of trajectories, there doesn't seem to be a major problem either. > > > > Nick > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --047d7bd7580a4fbd7b0505aabb3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just my .002.
Maybe it could help in the discussion to make a distinction between subnets= of an AS and different ASes.
Clearly there is no solution for the latter. And for the first, there will = be lots of controversy ;-)
IPv6 BPs could mandate best aggregates only.

/PA

El 17/10/2014 15:47, "Marc Binderberger&quo= t; <marc@sniff.de> escribi=C3=B3= :
Hello Nick and Ilj= itsch,

fairly stable baseline of 20-30%, which may be acceptable if it stays there= .
Although peaks of 70% (is the 100% a graph problem?) seem to be a reason _for_ filtering.

Now what I'm wondering

(1) is there a need to carry all the deaggregates? Because if you are far enough away they may "look the same as the aggregate". To use Ilj= itsch'
example ...

> I know this is controversial. "Topology ain't geography"= . Actually, most of
> the time there is a significant correlation. If all German cities inje= ct a
> more specific, do you really need to hear those in Tokyo or Seattle? J= ust
> send the traffic to Europe as per the aggregate and let them figure it= out
> there.

... it's likely that for an US ISP X, peering with European ISPs Y and = Z who
carry the various deaggregate plus aggregate from Germany, all the European=
prefixes have this peering router as next hop (let's say we have
next-hop-self).

What about BGP on this peering router doing some auto-aggregation in such a=
case?=C2=A0 Has this been discussed?=C2=A0 It would avoid geographic commun= ities and
would simply follow the BGP topology: if the deaggregates result in the sam= e
forwarding information than the aggregate just keep the aggregate. Your
routing table would have deaggregates for your own region but only aggregat= es
for the other, more distant regions.


(2) the problem of ever-growing routing tables and de-aggregation is not ne= w.
After so many years I'm wondering if the answer is that this cannot be = solved
with BGP/routing alone (?)=C2=A0 Otherwise you would have found a solution<= br> meanwhile :-)
And we have the - understandable and growing - needs of Enterprises, who de-aggregate their PA addresses when they are LIR, or request PI addresses<= br> per location.

Combining this, should the de-aggregation step not be done with a different=
technology? LISP comes to my mind (biased, as I'm working on it) or in<= br> general a "de-aggregation overlay". The overlay would need gatewa= ys to the
BGP world and would announce one aggregate prefix only while the de-aggrega= te
prefixes would be limited to the particular Enterprise overlay network and<= br> would not show up in BGP.



Regards, Marc




On Thu, 16 Oct 2014 22:16:09 +0100, Nick Hilliard wrote:
> On 16/10/2014 16:47, Iljitsch van Beijnum wrote:
>> Growth in IPv6 more specifics was 57% last year...
>
> Here's a graph which shows the percentage of more-specifics betwee= n 2003
> and today from Geoff Huston's web site:
>
> http://goo.gl/QA0xu= d
>
> Eyeballing the graph, it's not clear where the figure of 57% came = from.=C2=A0 In
> terms of trajectories, there doesn't seem to be a major problem ei= ther.
>
> Nick
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
GROW mailing list
GROW@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/grow
--047d7bd7580a4fbd7b0505aabb3c-- From nobody Wed Oct 22 13:39:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C62F1A1A84; Wed, 22 Oct 2014 13:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb6wd3w7aEQs; Wed, 22 Oct 2014 13:39:37 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69D71A0264; Wed, 22 Oct 2014 13:39:36 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5155:1185:301b:2db] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9MKdQxH076466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 22:39:26 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Oct 2014 22:39:27 +0200 References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> To: "grow@ietf.org grow@ietf.org" , IPv6 Operations Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MTvWe_8VwPZn857Bn7nlt-gK7LA Subject: [v6ops] Fwd: I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 20:39:39 -0000 I've written down my ideas for controlled deaggregation of enterprise = LIR prefixes. I'm sure everyone is going to love the second half where I talk about = encoding GPS coordinates into BGP communities. :-) Please send me all your feedback. I'd be happy to do a short presentation about this in v6ops and/or grow = next month. Iljitsch > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > Title : Controlled IPv6 deaggregation by large = organizations > Author : Iljitsch van Beijnum > Filename : draft-van-beijnum-grow-controlled-deagg-00.txt > Pages : 8 > Date : 2014-10-22 > Abstract: > The use of IPv6 addresses by large organizations doesn't fit the > commonly used PA/PI dichotomy. Such organizations may hold a large > address block which is deaggregated into subprefixes that are > advertised by subunits of the organization. This document proposes = a > set of best practices to allow this deaggregation to be controlled > through filtering so that on the one hand, the size of the IPv6 > global routing table isn't unduly inflated, while on the other hand > organizations that seek to deaggregate a large IPv6 address block > don't see their reachability limited by remote filters. > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-van-beijnum-grow-controlled-deagg/ > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-van-beijnum-grow-controlled-deagg-00 From nobody Thu Oct 23 01:41:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924071A892C for ; Thu, 23 Oct 2014 01:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmixT3Bsqnrp for ; Thu, 23 Oct 2014 01:41:35 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DEC1A8924 for ; Thu, 23 Oct 2014 01:41:34 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B1E8360798 for ; Thu, 23 Oct 2014 10:41:32 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7D97660140 for ; Thu, 23 Oct 2014 10:41:32 +0200 (CEST) Received: (qmail 10150 invoked by uid 1007); 23 Oct 2014 10:41:32 +0200 Date: Thu, 23 Oct 2014 10:41:32 +0200 From: Gert Doering To: Matthew Petach Message-ID: <20141023084132.GE31092@Space.Net> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> <20141017010552.9682921A4D54@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2mmb8Oz7Vd2jfl0bAbHsmwUPM7w Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:41:37 -0000 Hi, On Thu, Oct 16, 2014 at 06:18:34PM -0700, Matthew Petach wrote: > The probability of us figuring out how to scale > the routing table to handle 40 billion prefixes > is orders of magnitude more likely than solving > the headaches associated with dynamic host > renumbering. That ship has done gone and > sailed, hit the proverbial iceberg, and is gathering > barnacles at the bottom of the ocean. What I find scary in this statement is the underlying "one solution must fit all users" mentality. I can fully see and understand Owen's point that in an *enterprise* environment, renumbering is truly hard, because you need to get lots of other people that have no real interest to renumber stuff in their config files - and yes, vendors of that could handle DNS lookups and combinations of "get prefix from DNS, attach , put result into usage" would be truly nice, but indeed, that should have been specced 15 years ago to be available now (maybe). OTOH, there's the large mass of SOHO style users, where "dynamic host renumbering" *really* is a non-issue. I've gone there and tested it in a homenet testbed with two IPv6 uplinks, so multi-homing and src-based routing thrown in - it works. It needs polishing and some IETF work here and there (SAS failover comes to mind, and labels-to- prefixes) but it works better than "IPv4 with two providers" today, for that particular class of users. PI(-ish) "for everybody" is just not the right solution for non-technical- savy users that would just not know that these funny numbers they received from one of their providers are relevant, and lose them - thus, when changing providers, would get new ones anyway. And what do they need static addresses for, anyway, as long as some sort of "register and lookup" mechanism exist (mDNS, DNS, SIP, ...) to find the address when needed? No, Owen's home does not qualify for a typical "SOHO" network, and most likely, none of the other readers. Ask yourself, what is needed to make the network on your parent's home work (assuming those are not network engineers). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Oct 23 04:51:49 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D9B1A9034 for ; Thu, 23 Oct 2014 04:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyPm88TAVgvZ for ; Thu, 23 Oct 2014 04:51:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3C31A8F3D for ; Thu, 23 Oct 2014 04:51:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNY78305; Thu, 23 Oct 2014 11:51:28 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Oct 2014 12:51:27 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 23 Oct 2014 19:51:24 +0800 From: "Liubing (Leo)" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , "fred@cisco.com" Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w7ok2AgAHqGMA= Date: Thu, 23 Oct 2014 11:51:24 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sB4ajgD-4z89D22tStruV6vJQk8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 11:51:34 -0000 SGkgQW5kcmV3LA0KDQpSZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIGNhcmVmdWwgcmV2aWV3IGFuZCB0 aGUgY29tbWVudHMuDQpQbGVhc2UgZmluZCByZXBsaWVzIGlubGluZS4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgPz8NCj4gWW91cnRjaGVua28NCj4gU2VudDogV2Vk bmVzZGF5LCBPY3RvYmVyIDIyLCAyMDE0IDk6NTcgUE0NCj4gVG86IGZyZWRAY2lzY28uY29tDQo+ IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2 b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtIFdHTEMNCj4gDQo+IEJlbG93IGdvZXMgbXkgcmV2aWV3 IG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBHZW5lcmFsIGltcHJlc3Npb25zOg0KPiANCj4gVGhl IGluZm9ybWF0aW9uIGFib3V0IHRoZSBkaWZmZXJlbmNlcyBpbiB0aGUgYmVoYXZpb3Igb2YgdGhl IE9TZXMgaXMNCj4gb3BlcmF0aW9uYWxseSB1c2VmdWwgYW5kIGlzIHdvcnRoIHB1Ymxpc2hpbmcu ICBTb21lIG9mIHRoZSBxdWVzdGlvbnMgdGhhdA0KPiB0aGlzIGRvY3VtZW50IHJhaXNlcyBkbyBs b29rIGxpa2UgdmFsaWQgY29uY2VybnMgdG8gbWUsIGFuZCBzaG91bGQgYmUNCj4gYnJvdWdodCBm dXJ0aGVyIChpLmUuIHRoZSBESENQdjYgYWRkcmVzcyBiZWhhdmlvciBvbiBmbGFnIGNoYW5nZSks IHNvbWUgb2YNCj4gdGhlbSAoQT0wLE89MSxNPTApLCBpbiB0aGUgYWJzZW5jZSBvZiBzdXBwb3J0 aW5nIHJlYXNvbnMgIndoeSIsIGxvb2sNCj4gbW9yZSBsaWtlIGEgY3VyaW9zaXR5IC0gaW50ZXJl c3RpbmcgdG8gcG9pbnQgb3V0IGluIGNhc2UgdGhpcyBjb3JuZXIgY2FzZQ0KPiBoYXBwZW5zIGFz IGEgdHJhbnNpZW50LCBidXQgbm90IHdvcnRoIHNwZW5kaW5nIHRoZSBjeWNsZXMgdHJ5aW5nIHRv IGFncmVlDQo+IHdoYXQgdGhlIGltcGxlbWVudGF0aW9ucyBzaG91bGQgYmUgZG9pbmcgaW4gdGhh dCBjYXNlLg0KDQpbQmluZ10gSSdsbCBjb25zaWRlciB0aGlzIHRvZ2V0aGVyIHdpdGggTG9yZW56 bydzIGNvbW1lbnQuIE1heWJlIGFub3RoZXIgYmlnIHJldmlzaW9uIGlzIG5lZWRlZC4gDQoNCg0K PiBNb3JlIHNwZWNpZmljIGNvbW1lbnRzOg0KPiANCj4gMi4xLiAgTSAoTWFuYWdlZCkgRmxhZw0K PiANCj4gIlRoZSBNIGZsYWcgaW5kaWNhdGVzIHRoYXQgYWRkcmVzc2VzIGFyZSBhdmFpbGFibGUg ZnJvbSBJUHY2LiINCj4gDQo+IHMvSVB2Ni9ESENQdjYvID8NCltCaW5nXSBNeSBmYXVsdC4gU29y cnkuDQogDQo+ICJ0aGUgTyBmbGFnIGlzIHJlZHVuZGFudCBhbmQgY2FuIGJlIGlnbm9yZWQiDQo+ IA0KPiBDb3VsZCBiZSBnb29kIHRvIGhhdmUgYW4gZXhwbGljaXQgcmVmZXJlbmNlIHRvIHNlY3Rp b24NCj4gDQo+ICI0LjIuUm91dGVyIEFkdmVydGlzZW1lbnQgTWVzc2FnZSBGb3JtYXQiIG9mIFJG QzQ4NjEgd2hlcmUgdGhpcyB0ZXh0IGlzDQo+IGNvbWluZyBmcm9tLg0KW0JpbmddIE9rLCB3aWxs IGRvLg0KDQogDQo+IDIuMy4gIEEgKEF1dG9ub21vdXMpIEZsYWcNCj4gDQo+ICJUaGUgQSBmbGFn IGluZGljYXRlcyB0aGF0IHRoZSBwcmVmaXggdGhhdCBpcyBhbHNvIGNhcnJpZWQgYnkgdGhlIFBJ DQo+ICAgIG9wdGlvbiBjYW4gYmUgdXNlZCBmb3IgU0xBQUMuICBBIGZsYWcgc2VtYW50aWNzIGFy ZSBpbmRlcGVuZGVudCBvZiBNDQo+ICAgIGFuZCBPIGZsYWcgc2VtYW50aWNzLiAgVGhlIEEgZmxh ZyBpbmRpY2F0ZXMgdGhhdCB0aGUgcHJlZml4IGNhbiBiZQ0KPiAgICB1c2VkIGJ5IFNMQUFDLCBy ZWdhcmRsZXNzIG9mIHRoZSBNIGFuZCBPIGZsYWcgc2V0dGluZ3MuIg0KPiANCj4gV2hhdCBhYm91 dCByZXBocmFzaW5nIHRoaXMgYXM6DQo+IA0KPiAiVGhlIEEgZmxhZywgY2FycmllZCB3aXRoaW4g dGhlIFByZWZpeCBJbmZvcm1hdGlvbiBvcHRpb24sIGluZGljYXRlcyB0aGF0IHRoZQ0KPiBwcmVm aXggaW4gdGhpcyBvcHRpb24gY2FuIGJlIHVzZWQgZm9yIHN0YXRlbGVzcyBhdXRvY29uZmlndXJh dGlvbi4gRmxhZw0KPiBzZW1hbnRpY3MgYXJlIGluZGVwZW5kZW50IG9mIE0gYW5kIE8gZmxhZ3Ms IGFuZCB0aGVpciB2YWx1ZXMgZG8gbm90IGFmZmVjdA0KPiB3aGV0aGVyIHRoaXMgcHJlZml4IGNh biBiZSB1c2VkIG9yIG5vdC4iDQpbQmluZ10gSXQncyBiZXR0ZXIsIHRoYW5rIHlvdS4NCg0KPiAi My4yLjEuICBJbmFwcHJvcHJpYXRlIFNvdXJjZXMiDQo+IA0KPiBpbnRlcmVzdGluZyBmaW5kaW5n LiBXaHkgaXMgaXQgYSBwcm9ibGVtIHdvcnRoIHNvbHZpbmcgPw0KW0JpbmddIEEgaG9zdCB3aG8g c2VsZi1jb25maWd1cmluZyB0aGUgSVAgYWRkcmVzcyB3aWxsIG5vdCBiZSBhYmxlIHRvIGRvIGEg c3RhdGVsZXNzIGNvbmZpZ3VyYXRpb24uIA0KU2F5LCBhIHNlbnNvciBzZWxmLWNvbmZpZ3VyZXMg VUxBIGFkZHJlc3MgYW5kIG5lZWRzIHRvIGdldCBvdGhlciBpbmZvcm1hdGlvbiBmcm9tIERIQ1B2 NiBzZXJ2ZXIuIEluIHRoaXMgc2NlbmFyaW8sIHN0YXRlZnVsIERIQ1B2NiBtaWdodCBiZSB0b28g aGVhdnkgZm9yIHRoZSBzeXN0ZW0uDQoNCj4gIjMuMi4yLiAgUmVudW1iZXJpbmciDQo+IA0KPiBU aGUgdGhyZWUgc3RlcHMgZGVzY3JpYmVkIHJlYWQgYXMgYSBzZXF1ZW5jZSwgd2hlcmVhcyB0aGV5 IGFyZSBhbHRlcm5hdGl2ZQ0KPiByZW51bWJlcmluZyBzdHJhdGVnaWVzLiBUaGlzIHNob3VsZCBi ZSByZXBocmFzZWQgdG8gbWFrZSBpdCBjbGVhcmVyLg0KPiANCj4gQWxzbywgdGhlIHJlbnVtYmVy aW5nIGRpc2N1c3NlcyBmbGFzaCByZW51bWJlcmluZyBwcm9jZXNzLiBTaG91bGQgaXQgYWxzbw0K PiBtYWtlIGEgcmVmZXJlbmNlIHRvIHJmYzQxOTIgd2hpY2ggaXMgYWltaW5nIHRvIHBlcmZvcm0g YSByZW51bWJlcmluZw0KPiB3aXRob3V0IGEgZmxhZyBkYXksIGFuZCBsb29rIGF0IHRoZSBpc3N1 ZXMgYWNjb3JkaW5nbHkgPw0KW0JpbmddIFRoZSBpbnRlbmRlZCBtZWFuaW5nIGlzIGFjdHVhbGx5 IHRvIGNhdXRpb24gdGhhdCBhIGZsYXNoIHJlbnVtYmVyaW5nIG1pZ2h0IGhhcHBlbiBvbiBzb21l IG9wZXJhdGluZyBzeXN0ZW1zIHdoZW4gdGhlIE0gZmxhZyBpcyB0dXJuZWQgb2ZmLiANClRoZSB3 b3JkaW5nIG5lZWRzIHRvIGJlIHJldmlzZWQuDQoNCj4gQXBwZW5kaXggQToNCj4gDQo+IEEuMToN Cj4gDQo+ICJIb3N0IDE6IFdpbmRvdyA3IC8gV2luZG93IDguMSBWaXJ0dWFsIEhvc3QiIC0gV2lu ZG93cyBzaG91bGQgYmUgaW4gcGx1cmFsLg0KPiAiSG9zdCAyOiBVYnVudHUgMTQuMDQiIC0gaXMg aXQgVWJ1bnR1IERlc2t0b3AgaW4gZGVmYXVsdCBjb25maWd1cmF0aW9uID8gSQ0KPiBwcmVzdW1l IHNvLCBidXQgaXQgc2hvdWxkIGJlIG1lbnRpb25lZCBleHBsaWNpdGx5Lg0KW0JpbmddIFllcywg dGhleSdyZSBhbGwgaW4gZGVmYXVsdCBjb25maWd1cmF0aW9uLiBXaWxsIHJldmlzZSBhY2NvcmRp bmdseS4NCiANCj4gQS4zOg0KPiANCj4gInJldmVpdmluZyBBIHRyYW5zaXRpb25nIiA9PiBuZWVk cyBzcGVsbGNoZWNrIGFuZCBwb3RlbnRpYWxseSByZXBocmFzZSBmb3IgdGhlDQo+IHNlbnRlbmNl Lg0KW0JpbmddIFdpbGwgZG8uDQoNCj4gQXBwZW5kaXggQjoNCltCaW5nXSBUaGlzIGFwcGVuZGl4 IGlzIGFuIGFuYWx5c2lzIGluIHRoZW9yeSB0aGF0IHdoYXQgYW1iaWd1aXRpZXMgYXJlIGV4aXN0 aW5nIGluIGN1cnJlbnQgc3RhbmRhcmRzLiBJdCBpcyBhIGhpbnQsIG1pZ2h0IG5vdCBuZWNlc3Nh cmlseSBtZWFucyBvcGVyYXRpb25hbCBwcm9ibGVtcy4NCkkgdGhpbmsgeW91ciBmb2xsb3dpbmcg cXVlc3Rpb25zIGFyZSB1c2VmdWwgZm9yIHRoZSBESENQdjYvU0xBQUMgSW50ZXJhY3Rpb24gR3Vp ZGFuY2UgZHJhZnQuIEknbGwgY29uc2lkZXIgdGhlbSBpbiB0aGF0IGRyYWZ0Lg0KDQpNYW55IHRo YW5rcy4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQo+ICJNb3JlIHNwZWNpZmljYWxseSwgaXMg UkEgKHdpdGggTT0xKSByZXF1aXJlZCB0byB0cmlnZ2VyIERIQ1B2Nj8gIElmIHRoZXJlDQo+IGFy ZSBubyBSQXMgYXQgYWxsLCBzaG91bGQgaG9zdHMgaW5pdGlhdGUgREhDUHY2IGJ5IHRoZW1zZWx2 ZXM/Ig0KPiANCj4gUkZDNDg2MiwgNS41LjIuICBBYnNlbmNlIG9mIFJvdXRlciBBZHZlcnRpc2Vt ZW50cyBtZW50aW9uczoNCj4gICAgRXZlbiBpZiBhIGxpbmsgaGFzIG5vIHJvdXRlcnMsIHRoZSBE SENQdjYgc2VydmljZSB0byBvYnRhaW4gYWRkcmVzc2VzDQo+ICAgIG1heSBzdGlsbCBiZSBhdmFp bGFibGUsIGFuZCBob3N0cyBtYXkgd2FudCB0byB1c2UgdGhlIHNlcnZpY2UuICBGcm9tDQo+ICAg IHRoZSBwZXJzcGVjdGl2ZSBvZiBhdXRvY29uZmlndXJhdGlvbiwgYSBsaW5rIGhhcyBubyByb3V0 ZXJzIGlmIG5vDQo+ICAgIFJvdXRlciBBZHZlcnRpc2VtZW50cyBhcmUgcmVjZWl2ZWQgYWZ0ZXIg aGF2aW5nIHNlbnQgYSBzbWFsbCBudW1iZXINCj4gICAgb2YgUm91dGVyIFNvbGljaXRhdGlvbnMg YXMgZGVzY3JpYmVkIGluIFtSRkM0ODYxXS4NCj4gDQo+ICAgIE5vdGUgdGhhdCBpdCBpcyBwb3Nz aWJsZSB0aGF0IHRoZXJlIGlzIG5vIHJvdXRlciBvbiB0aGUgbGluayBpbiB0aGlzDQo+ICAgIHNl bnNlLCBidXQgdGhlcmUgaXMgYSBub2RlIHRoYXQgaGFzIHRoZSBhYmlsaXR5IHRvIGZvcndhcmQg cGFja2V0cy4NCj4gICAgSW4gdGhpcyBjYXNlLCB0aGUgZm9yd2FyZGluZyBub2RlJ3MgYWRkcmVz cyBtdXN0IGJlIG1hbnVhbGx5DQo+ICAgIGNvbmZpZ3VyZWQgaW4gaG9zdHMgdG8gYmUgYWJsZSB0 byBzZW5kIHBhY2tldHMgb2ZmLWxpbmssIHNpbmNlIHRoZQ0KPiAgICBvbmx5IG1lY2hhbmlzbSB0 byBjb25maWd1cmUgdGhlIGRlZmF1bHQgcm91dGVyJ3MgYWRkcmVzcw0KPiAgICBhdXRvbWF0aWNh bGx5IGlzIHRoZSBvbmUgdXNpbmcgUm91dGVyIEFkdmVydGlzZW1lbnRzLg0KPiANCj4gRG9lcyB0 aGlzIHdvcmRpbmcgYW5zd2VyIHRoZSBxdWVzdGlvbiA/DQo+ICJpdCBpcyBub3QNCj4gICAgICAg Y2xlYXIgd2hldGhlciB0aGUgaG9zdCBzaG91bGQgc3RhcnQgREhDUHY2IG9yIG5vdDsgb3Igdmlz ZSB2ZXJzYSwNCj4gICAgICAgdGhlIGhvc3QgaXMgYWxyZWFkeSBib3RoIFNMQUFDL0RIQ1B2NiBj b25maWd1cmVkLCB0aGVuIE0gZmxhZw0KPiAgICAgICBjaGFuZ2UgZnJvbSBUUlVFIHRvIEZBTFNF LCBpdCBpcyBhbHNvIG5vdCBjbGVhciB3aGV0aGVyIHRoZSBob3N0DQo+ICAgICAgIHNob3VsZCB0 dXJuIERIQ1B2NiBvZmYgb3Igbm90LiINCj4gDQo+IFdoYXQgaXMgZGVzaXJlZCBmcm9tIHRoZSBv cGVyYXRpb25hbCBzdGFuZHBvaW50IGFuZCB3aHkgPyAoQWxzbywgdGFraW5nIGludG8NCj4gdGhl IGFjY291bnQgdGhlIGVmZmVjdHMgb24gdGhlIERIQ1B2NiBzZXJ2ZXIgY2F1c2VkIGJ5IGEgY3Jv d2Qgb2YgaG9zdHMNCj4gcmVjZWl2aW5nIGFuIFJBIGFuZCBzaW11bHRhbmVvdXNseSAocmUpc3Rh cnRpbmcgdXAgdGhlDQo+IERIQ1B2NiBwcm9jZXNzKS4NCj4gDQo+ICJGb3IgZXhhbXBsZSwgd2hl biBib3RoIE0gYW5kDQo+ICAgICAgIE8gZmxhZ3MgYXJlIFRSVUUsIGl0IGlzIG5vdCBjbGVhciB3 aGV0aGVyIHRoZSBob3N0IHNob3VsZCBpbml0aWF0ZQ0KPiAgICAgICBvbmUgc3RhdGVmdWwgREhD UHY2IHNlc3Npb24gdG8gZ2V0IGJvdGggYWRkcmVzcyBhbmQgaW5mby0NCj4gICAgICAgY29uZmln dXJhdGlvbiBvciBpbml0aWF0ZSB0d28gaW5kZXBlbmRlbnQgc2Vzc2lvbnMgb2Ygd2hpY2ggb25l IGlzDQo+ICAgICAgIGRlZGljYXRlZCBmb3IgYWRkcmVzcyBwcm92aXNpb25pbmcgYW5kIHRoZSBv dGhlciBpcyBmb3INCj4gICAgICAgaW5mb3JtYXRpb24gcHJvdmlzaW9uLiAiDQo+IA0KPiBUaGUg ZW5kIHJlc3VsdCBvZiBkb2luZyBlaXRoZXIgb2YgdGhlIHR3byBiZWhhdmlvcnMgc2hvdWxkIGJl IHRoZSBzYW1lLA0KPiBzaG91bGRu4oCZdCBpdCA/DQo+IElmIHNvIC0gdGhlbiB3aHkgZ29pbmcg dGhyb3VnaCB0aGUgZWZmb3J0IG9mIHNwZWNpZnlpbmcgb25lIG9yIGFub3RoZXINCj4gYmVoYXZp b3IgPw0KPiANCj4gIiBXaGVuIEEgYW5kIE0gZmxhZ3MgYXJlIEZBTFNFIGFuZCBPIGZsYWcgaXMN Cj4gICAgICAgVFJVRSwgaXQgaXMgbm90IGNsZWFyIHdoZXRoZXIgdGhlIGhvc3Qgc2hvdWxkIGlu aXRpYXRlIGEgc3RhbmQtDQo+ICAgICAgIGFsb25lIHN0YXRlbGVzcyBESENQdjYgc2Vzc2lvbi4i DQo+IA0KPiBBZ2Fpbiwgc2FtZSBxdWVzdGlvbiBhcyBpbiAzLjIuMTogd2hhdCBpcyB0aGUgcHJh Y3RpY2FsIHVzZSBjYXNlIHNjZW5hcmlvIGZvcg0KPiB0aGlzID8gaS5lLiBpcyB0aGlzIHByb2Js ZW0gd29ydGggc29sdmluZyBhbmQgd2h5ID8NCj4gDQo+IC0tYQ0KPiANCj4gT24gMTAvMTkvMTQs IGZyZWRAY2lzY28uY29tIDxmcmVkQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gVGhpcyBpcyB0byBp bml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9mDQo+ID4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxl bS4NCj4gPiBQbGVhc2UgcmVhZCBpdCBub3cuIElmIHlvdSBmaW5kIG5pdHMgKHNwZWxsaW5nIGVy cm9ycywgbWlub3Igc3VnZ2VzdGVkDQo+ID4gd29yZGluZyBjaGFuZ2VzLCBldGMpLCBjb21tZW50 IHRvIHRoZSBhdXRob3JzOyBpZiB5b3UgZmluZCBncmVhdGVyDQo+ID4gaXNzdWVzLCBzdWNoIGFz IGRpc2FncmVlaW5nIHdpdGggYSBzdGF0ZW1lbnQgb3IgZmluZGluZyBhZGRpdGlvbmFsDQo+ID4g aXNzdWVzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQsIHBsZWFzZSBwb3N0IHlvdXIgY29tbWVu dHMgdG8gdGhlDQo+ID4gbGlzdC4NCj4gPg0KPiA+IFdlIGFyZSBsb29raW5nIHNwZWNpZmljYWxs eSBmb3IgY29tbWVudHMgb24gdGhlIGltcG9ydGFuY2Ugb2YgdGhlDQo+ID4gZG9jdW1lbnQgYXMg d2VsbCBhcyBpdHMgY29udGVudC4gSWYgeW91IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kDQo+ ID4gYmVsaWV2ZSBpdCB0byBiZSBvZiBvcGVyYXRpb25hbCB1dGlsaXR5LCB0aGF0IGlzIGFsc28g YW4gaW1wb3J0YW50DQo+ID4gY29tbWVudCB0byBtYWtlLg0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Thu Oct 23 10:17:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9385D1ACE04 for ; Thu, 23 Oct 2014 10:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYwFxAOyo55l for ; Thu, 23 Oct 2014 10:17:08 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAC41ACE09 for ; Thu, 23 Oct 2014 10:17:06 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so856133iec.21 for ; Thu, 23 Oct 2014 10:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+M30kzsxdxDqX9sbaOVLcyfCuo8Oa6E+WGe5smmlmH4=; b=qmuOgHrujOzdONK7b3jYKttvg0eb3T7zJO+1CAuUtyrr4COUHoprwlvRGFtdnRXM3h JtpqIKC0B2XcyeyKkCK8iJprLjaS3R0AWFg93xb55po/m5ozVFzhd5JTZmsRRa7MPx8o TNchA1poJ91jdQlF/R7ocjJvh3jTvvc/YVlDUW/pC69gO3VpLosEGhFzAjl9n6OcP0tF juEqNLljwKq7tMUL3PkuW/UNazOVIs/iYtRqcSZr+4z31RIzb2b4ojZyJ+3ftnc6x5lS lpmOlUvDSMqIRSxk/trX6ORCbPEkdMqSla2BSoCN9B/PlLDFQk3oD8Xu1y3qZg4xp0FT jl3Q== MIME-Version: 1.0 X-Received: by 10.50.164.194 with SMTP id ys2mr42615061igb.35.1414084625876; Thu, 23 Oct 2014 10:17:05 -0700 (PDT) Received: by 10.107.137.194 with HTTP; Thu, 23 Oct 2014 10:17:05 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> Date: Thu, 23 Oct 2014 19:17:05 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/s6q2PhGNYOIFxiSVZpy2LD5-Z5k Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 17:17:10 -0000 Hi Bing, thanks for the comments! my replies inline... On 10/23/14, Liubing (Leo) wrote: > Hi Andrew, > > Really appreciate your careful review and the comments. > Please find replies inline. > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Andrew ?? >> Yourtchenko >> Sent: Wednesday, October 22, 2014 9:57 PM >> To: fred@cisco.com >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC >> >> Below goes my review of this document. >> >> General impressions: >> >> The information about the differences in the behavior of the OSes is >> operationally useful and is worth publishing. Some of the questions tha= t >> this document raises do look like valid concerns to me, and should be >> brought further (i.e. the DHCPv6 address behavior on flag change), some >> of >> them (A=3D0,O=3D1,M=3D0), in the absence of supporting reasons "why", lo= ok >> more like a curiosity - interesting to point out in case this corner cas= e >> happens as a transient, but not worth spending the cycles trying to agre= e >> what the implementations should be doing in that case. > > [Bing] I'll consider this together with Lorenzo's comment. Maybe another = big > revision is needed. This looks like good idea to me. > > >> More specific comments: >> >> 2.1. M (Managed) Flag >> >> "The M flag indicates that addresses are available from IPv6." >> >> s/IPv6/DHCPv6/ ? > [Bing] My fault. Sorry. > >> "the O flag is redundant and can be ignored" >> >> Could be good to have an explicit reference to section >> >> "4.2.Router Advertisement Message Format" of RFC4861 where this text is >> coming from. > [Bing] Ok, will do. > > >> 2.3. A (Autonomous) Flag >> >> "The A flag indicates that the prefix that is also carried by the PI >> option can be used for SLAAC. A flag semantics are independent of M >> and O flag semantics. The A flag indicates that the prefix can be >> used by SLAAC, regardless of the M and O flag settings." >> >> What about rephrasing this as: >> >> "The A flag, carried within the Prefix Information option, indicates tha= t >> the >> prefix in this option can be used for stateless autoconfiguration. Flag >> semantics are independent of M and O flags, and their values do not >> affect >> whether this prefix can be used or not." > [Bing] It's better, thank you. > >> "3.2.1. Inappropriate Sources" >> >> interesting finding. Why is it a problem worth solving ? > [Bing] A host who self-configuring the IP address will not be able to do = a > stateless configuration. > Say, a sensor self-configures ULA address and needs to get other informat= ion > from DHCPv6 server. In this scenario, stateful DHCPv6 might be too heavy = for > the system. To clarify - you mean link-local addresses, rather than ULAs, right ? (since to configure ULAs, the host would somehow need to know the prefix being serviced by the router, which sounds awfully close to autoconf to me) If we speak about a specialized environments like sensors, they probably will try the stateless DHCPv6 regardless of the flags in RA, since that will be their only way to configure themselves, what do you think ? The use-case I was after was something involving the common off the shelf OSes, i.e. the part of the "every day network administration" theme of the document. > >> "3.2.2. Renumbering" >> >> The three steps described read as a sequence, whereas they are >> alternative >> renumbering strategies. This should be rephrased to make it clearer. >> >> Also, the renumbering discusses flash renumbering process. Should it als= o >> make a reference to rfc4192 which is aiming to perform a renumbering >> without a flag day, and look at the issues accordingly ? > [Bing] The intended meaning is actually to caution that a flash renumberi= ng > might happen on some operating systems when the M flag is turned off. > The wording needs to be revised. Ahh, then - while the flash-renumbering-with-M-flag is a very worthy problem to mention, it is not clear that this is the "takeaway" from this part of the document. > >> Appendix A: >> >> A.1: >> >> "Host 1: Window 7 / Window 8.1 Virtual Host" - Windows should be in >> plural. >> "Host 2: Ubuntu 14.04" - is it Ubuntu Desktop in default configuration ? >> I >> presume so, but it should be mentioned explicitly. > [Bing] Yes, they're all in default configuration. Will revise accordingly= . > >> A.3: >> >> "reveiving A transitiong" =3D> needs spellcheck and potentially rephrase= for >> the >> sentence. > [Bing] Will do. > >> Appendix B: > [Bing] This appendix is an analysis in theory that what ambiguities are > existing in current standards. It is a hint, might not necessarily means > operational problems. ah okay, thanks for clarifying! --a > I think your following questions are useful for the DHCPv6/SLAAC Interact= ion > Guidance draft. I'll consider them in that draft. > > Many thanks. > > Best regards, > Bing > >> "More specifically, is RA (with M=3D1) required to trigger DHCPv6? If >> there >> are no RAs at all, should hosts initiate DHCPv6 by themselves?" >> >> RFC4862, 5.5.2. Absence of Router Advertisements mentions: >> Even if a link has no routers, the DHCPv6 service to obtain addresses >> may still be available, and hosts may want to use the service. From >> the perspective of autoconfiguration, a link has no routers if no >> Router Advertisements are received after having sent a small number >> of Router Solicitations as described in [RFC4861]. >> >> Note that it is possible that there is no router on the link in this >> sense, but there is a node that has the ability to forward packets. >> In this case, the forwarding node's address must be manually >> configured in hosts to be able to send packets off-link, since the >> only mechanism to configure the default router's address >> automatically is the one using Router Advertisements. >> >> Does this wording answer the question ? >> "it is not >> clear whether the host should start DHCPv6 or not; or vise versa, >> the host is already both SLAAC/DHCPv6 configured, then M flag >> change from TRUE to FALSE, it is also not clear whether the host >> should turn DHCPv6 off or not." >> >> What is desired from the operational standpoint and why ? (Also, taking >> into >> the account the effects on the DHCPv6 server caused by a crowd of hosts >> receiving an RA and simultaneously (re)starting up the >> DHCPv6 process). >> >> "For example, when both M and >> O flags are TRUE, it is not clear whether the host should initiate >> one stateful DHCPv6 session to get both address and info- >> configuration or initiate two independent sessions of which one is >> dedicated for address provisioning and the other is for >> information provision. " >> >> The end result of doing either of the two behaviors should be the same, >> shouldn=E2=80=99t it ? >> If so - then why going through the effort of specifying one or another >> behavior ? >> >> " When A and M flags are FALSE and O flag is >> TRUE, it is not clear whether the host should initiate a stand- >> alone stateless DHCPv6 session." >> >> Again, same question as in 3.2.1: what is the practical use case scenari= o >> for >> this ? i.e. is this problem worth solving and why ? >> >> --a >> >> On 10/19/14, fred@cisco.com wrote: >> > This is to initiate a two week working group last call of >> > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. >> > Please read it now. If you find nits (spelling errors, minor suggested >> > wording changes, etc), comment to the authors; if you find greater >> > issues, such as disagreeing with a statement or finding additional >> > issues that need to be addressed, please post your comments to the >> > list. >> > >> > We are looking specifically for comments on the importance of the >> > document as well as its content. If you have read the document and >> > believe it to be of operational utility, that is also an important >> > comment to make. >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Oct 23 12:21:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7A1ACE9D; Thu, 23 Oct 2014 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVwpwINEEF8l; Thu, 23 Oct 2014 12:21:21 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E0A1ACE9B; Thu, 23 Oct 2014 12:21:21 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so1634496pab.6 for ; Thu, 23 Oct 2014 12:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hwT25SGSDWM358gLuTKn4x12WjdVuwdJm0HVWfxRmIo=; b=zMiqapqqbMl9X9DLt5c9TClUXW2CzYT5JP61gFAAQjWLstPK4YTmc1GJoJcxzAbR0s 6Wfb1qfwnGkli/3aZQlB8KQJ7BZRqDS5zbiIxHhJNYh0A4l1fvkm5fYtdSit85GncM9X OnFrl+ceeo9HoOwJA8rwy+cUbuTiluZJarxedQlJ1hQaval1Cz61G0hUstyZswc8nUML S3hcB0t2WjwPb4gLs+P52o0c9vWHSXk3wsHcSh6RauaMdG5Ynggy/rM7LVCeu4sJBXjz M/uYF9GGutDTX6YJeGpHkyw4/KJhaPwMiFEkF1KrHr/wRTgHSmmNoXUWfTr46OfUZLUF LZVQ== X-Received: by 10.66.154.111 with SMTP id vn15mr3161668pab.155.1414092080940; Thu, 23 Oct 2014 12:21:20 -0700 (PDT) Received: from [192.168.178.23] (9.200.69.111.dynamic.snap.net.nz. [111.69.200.9]) by mx.google.com with ESMTPSA id h4sm2184230pat.11.2014.10.23.12.21.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 12:21:19 -0700 (PDT) Message-ID: <54495537.1030703@gmail.com> Date: Fri, 24 Oct 2014 08:21:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> <20141017010552.9682921A4D54@rock.dv.isc.org> <20141023084132.GE31092@Space.Net> In-Reply-To: <20141023084132.GE31092@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DFb9ULM_Tp0_FOUMafyP6LhMQl0 Cc: v6ops@ietf.org, grow@ietf.org Subject: [v6ops] renumbering [was Deaggregation by large organizations] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:21:23 -0000 Everybody, Indeed, home networks renumber after every power cycle on the home gateway. Homenet will ensure that also works for more complex networks. We have a gap analysis for enterprise renumbering. Go fix the gaps if you think they matter: http://tools.ietf.org/html/rfc7010 Brian On 23/10/2014 21:41, Gert Doering wrote: > Hi, > > On Thu, Oct 16, 2014 at 06:18:34PM -0700, Matthew Petach wrote: >> The probability of us figuring out how to scale >> the routing table to handle 40 billion prefixes >> is orders of magnitude more likely than solving >> the headaches associated with dynamic host >> renumbering. That ship has done gone and >> sailed, hit the proverbial iceberg, and is gathering >> barnacles at the bottom of the ocean. > > What I find scary in this statement is the underlying "one solution must > fit all users" mentality. > > I can fully see and understand Owen's point that in an *enterprise* > environment, renumbering is truly hard, because you need to get lots of > other people that have no real interest to renumber stuff in their config > files - and yes, vendors of that could handle DNS lookups and > combinations of "get prefix from DNS, attach , put result into > usage" would be truly nice, but indeed, that should have been specced > 15 years ago to be available now (maybe). > > OTOH, there's the large mass of SOHO style users, where "dynamic host > renumbering" *really* is a non-issue. I've gone there and tested it > in a homenet testbed with two IPv6 uplinks, so multi-homing and > src-based routing thrown in - it works. It needs polishing and some > IETF work here and there (SAS failover comes to mind, and labels-to- > prefixes) but it works better than "IPv4 with two providers" today, > for that particular class of users. > > PI(-ish) "for everybody" is just not the right solution for non-technical- > savy users that would just not know that these funny numbers they received > from one of their providers are relevant, and lose them - thus, when changing > providers, would get new ones anyway. And what do they need static addresses > for, anyway, as long as some sort of "register and lookup" mechanism exist > (mDNS, DNS, SIP, ...) to find the address when needed? > > No, Owen's home does not qualify for a typical "SOHO" network, and most > likely, none of the other readers. Ask yourself, what is needed to make > the network on your parent's home work (assuming those are not network > engineers). > > Gert Doering > -- NetMaster From nobody Thu Oct 23 14:39:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE071ACEA2; Thu, 23 Oct 2014 14:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92Cl6HdroIMz; Thu, 23 Oct 2014 14:39:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 169F71ACEAB; Thu, 23 Oct 2014 14:39:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C6644181C6B; Thu, 23 Oct 2014 14:39:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141023213900.C6644181C6B@rfc-editor.org> Date: Thu, 23 Oct 2014 14:39:00 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gljdUlNyDz6V8hNJ1ixLDOb2gtE Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7381 on Enterprise IPv6 Deployment Guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 21:39:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7381 Title: Enterprise IPv6 Deployment Guidelines Author: K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke Status: Informational Stream: IETF Date: October 2014 Mailbox: kk@dropbox.com, tjc@ecs.soton.ac.uk, lee.howard@twcable.com, victor@jvknet.com, yanick.pouffary@hp.com, evyncke@cisco.com Pages: 34 Characters: 90299 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt URL: https://www.rfc-editor.org/rfc/rfc7381.txt Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Oct 25 06:10:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65F41A883E; Sat, 25 Oct 2014 06:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdLrgOuELAQz; Sat, 25 Oct 2014 06:10:19 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 151311A001B; Sat, 25 Oct 2014 06:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id F1D3B871612; Sat, 25 Oct 2014 15:10:17 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPnePT2Iuj9C; Sat, 25 Oct 2014 15:10:17 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id C9687870049; Sat, 25 Oct 2014 15:10:17 +0200 (CEST) Message-ID: <544BA11F.7050102@globis.net> Date: Sat, 25 Oct 2014 15:09:51 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Russ White References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <011101cfe935$d0e8a600$72b9f200$@riw.us> In-Reply-To: <011101cfe935$d0e8a600$72b9f200$@riw.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jrA9cFieOXPgnqAvrxWqWn5d6R4 Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 13:10:21 -0000 Russ White wrote: >> Injecting an aggregate as a point of last resort: >> >> I think this can be done today and probably is done today. But a document >> describing how to do it would probably be helpful. I'm thinking along the >> following lines: >> >> The AoLR (Aggregate of Last Resort) service would entail a service > provider >> announcing the aggregate without necessarily providing connectivity > towards >> all the places announcing more specifics covered by the aggregate. So if > ISP A >> announces the AoLR and ISP B provides connectivity to a more specific, ISP > C >> would send traffic to A as per the aggregate and then A would immediately >> hand it over to B. > > Or perhaps something simpler would work here -- bounding longest match. > > :-) > > Russ > No. Now we've "solved" the address space issue, we focus back on routing table size angst. History repeats. My (tiny) datapoint on multinationals is that they're simply grabbing /32's (or as big as possible space) from multiple registries as soon as possible: remembering how much of a battle it was in IPv4 to get PI space properly routed, and assuming that this same discussion would resurface in IPv6, and that maximum prefix length would once again become a hot topic..... short prefixes are "better". Get 'em now while you can. This is natural behaviour, unless there's a less blunt instrument applied to managing BGP routing table size than simply restricting maximum prefix length per peer. e.g. RIR charge being dependent on the number of global routing slot entries, rather than purely on address space allocation size. And yes, of course, de-aggregation is a potentially serious DOS vector. Meanwhile, renumbering is still hard. -- Regards, RayH From nobody Sat Oct 25 07:07:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911D11A0023; Sat, 25 Oct 2014 07:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kyx0P4dVsiJ; Sat, 25 Oct 2014 07:07:12 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3041A0015; Sat, 25 Oct 2014 07:07:12 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:5c73:24de:d860:bd40] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9PE6vFT001411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Oct 2014 16:06:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <544BA11F.7050102@globis.net> Date: Sat, 25 Oct 2014 16:07:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <011101cfe935$d0e8a600$72b9f200$@riw.us> <544BA11F.7050102@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8IrX-PH0vB11OPmxky6x97CGsjU Cc: Russ White , v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 14:07:15 -0000 On 25 Oct 2014, at 15:09, Ray Hunter wrote: > This is natural behaviour, unless there's a less blunt instrument = applied to managing BGP routing table size than simply restricting = maximum prefix length per peer. Please have a look at my draft. I think that establishing an aggregate = of last resort coupled with BGP communities that allow for selectively = filtering deaggregates covered by an aggregate in the places where they = aren't desired helps both big organizations and network operators. If a big organization hires two tier-1 ISPs, for instance, and then = makes sure that the ISPs that its organizational subunits select for = their connectivity interconnect with the ISPs announcing the AoLR (as = peers or as customers), only networks that get paid need to carry the = deaggregates. Which is good for the ISPs that get paid (obviously), for = the ones that don't get paid (no deaggregates) and for the organization = (they know who to blame for connectivity issues).= From nobody Sat Oct 25 07:44:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BDD1A0016; Sat, 25 Oct 2014 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zus-Bl317sE5; Sat, 25 Oct 2014 07:43:59 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAC81A000B; Sat, 25 Oct 2014 07:43:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D723D871613; Sat, 25 Oct 2014 16:43:57 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuKq8c1LPg6f; Sat, 25 Oct 2014 16:43:57 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id A1F15871612; Sat, 25 Oct 2014 16:43:57 +0200 (CEST) Message-ID: <544BB713.8000803@globis.net> Date: Sat, 25 Oct 2014 16:43:31 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <011101cfe935$d0e8a600$72b9f200$@riw.us> <544BA11F.7050102@globis.net> <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com> In-Reply-To: <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0QieoLzP-wpU2NMegfLRWT5Yjzc Cc: Russ White , v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 14:44:01 -0000 > Iljitsch van Beijnum > 25 October 2014 16:07 > > Please have a look at my draft. I think that establishing an aggregate > of last resort coupled with BGP communities that allow for selectively > filtering deaggregates covered by an aggregate in the places where > they aren't desired helps both big organizations and network operators. > > If a big organization hires two tier-1 ISPs, for instance, and then > makes sure that the ISPs that its organizational subunits select for > their connectivity interconnect with the ISPs announcing the AoLR (as > peers or as customers), only networks that get paid need to carry the > deaggregates. Which is good for the ISPs that get paid (obviously), > for the ones that don't get paid (no deaggregates) and for the > organization (they know who to blame for connectivity issues). > I'm not convinced your draft is in line with my own understanding of how multinationals I know either use, or want to use the Internet, and why the de-aggregation occurs in the first place. I'd thus like to see more data on where/why the de-aggregation is occurring. Particularly my perception does not seem to fit the assumption of Section 2. > For reasons of cost and routing efficiency it's not possible or desired to use an internal network between the subunits or locations to transport traffic to/from the internet from one organizational subunit to another. Internet "offload" is a common requirement for low value traffic, in conjunction with a private high quality internal Intranet for corporate apps like design tools, with both networks active simultaneously. My thinking is that SADR, and running multiple (PA) prefixes within an enterprise will address this requirement. So each sub unit would carry both the multinational/global PI space and one or more local PA space prefixes obtained from the local ISP. Only the local PA space would be advertised out of each break out. That would be and prevent the need for de-aggregate routes to be advertised back into the individual ISPs serving the sub unit satellite sites. Equally GRE tunnels or IPSEC tunnels over Internet are already common-practice to create virtual enterprise networks. > This way, deaggregates only have to be carried by ISPs providing the aggregate of last resort service and the ISPs connecting subunits of the organization. I don't think enterprises want to be tied to ISP's at all. The hope/ dream is that once a prefix enters the global routing table, then it will be globally reachable. I don't know of any small set of ISPs that can economically provide service in 50+ countries in some sort of coordinated aggregate ISP manner. Equally, Section 3 seems to assumes that the customer/enterprise relationship is regional, which IMVHO is not always the case. www.myenterprise.com needs to be world wide reachable, but with local content delivered by CDN or local servers. > In theory, a user in Tokyo could connect to the internet in Madrid. In practice, this is is exceedingly rare. I don't agree with this observation. I know of many cases e.g. where a break in/out for a 3rd party from China is made in Europe. Or where a US based company manages systems remotely in Europe, LATAM, Asia Pacific, and the US and has regional links to the customer (with a break in/out per region). My particular worry with aggregates of last resort would be that with longest prefix match matching, it's becoming increasingly easy for longer prefixes to hijack important enterprise aggregates. So advertising an aggregate of last resort, whilst allowing sub units to advertise longer prefixes to other ISPs, might not be such a great idea for security. -- Regards, RayH From nobody Sat Oct 25 19:02:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6181A1B81; Sat, 25 Oct 2014 19:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REeQtyfL05_5; Sat, 25 Oct 2014 19:02:46 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535851A1B92; Sat, 25 Oct 2014 19:02:46 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id v1so1074797yhn.17 for ; Sat, 25 Oct 2014 19:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VsrcER5c6KJONnYZ3fwRc/bxSunaNl6pFrMDsTMce9Y=; b=Oxq+HmtaQoO1e3q4mFM+iuruiJj9pl6byPgZ4h6sj1pzD6ljgSXNCUE5hisPvO4s/9 RBsP+6aVHZI1QAaVPX2hu6ylzJ9sD4bWRvokmUvlhusxdRx1aA3erBba2FZSCLTiylys NlRX+0ixnMi3dxTCFfmi/lEfis0INovd9G0E2LtcSTNdi4WkoaO/VBb+u3x5/fUsMPIU kmxrgiTncNdi/Uso80amIpYa1fzFvRIluYNNRIfmO4bjg8srnihYFmrWQKMQnEpWcW/C sqcsUn74u7bHQpZMjIIMGjYtoXu2Kg5ezqiRYQuvpXNVUjjRU4M8Zlh9qzqXd9Mk35BZ 63Zg== MIME-Version: 1.0 X-Received: by 10.170.161.10 with SMTP id c10mr16980278ykd.9.1414288965559; Sat, 25 Oct 2014 19:02:45 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.170.126.199 with HTTP; Sat, 25 Oct 2014 19:02:45 -0700 (PDT) In-Reply-To: <20141023084132.GE31092@Space.Net> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <20141016233533.1B73521A106C@rock.dv.isc.org> <20141017010552.9682921A4D54@rock.dv.isc.org> <20141023084132.GE31092@Space.Net> Date: Sat, 25 Oct 2014 19:02:45 -0700 X-Google-Sender-Auth: 9Y_0nb7E3A-Cn1pWStH7hX4USq0 Message-ID: From: Matthew Petach To: Gert Doering Content-Type: multipart/alternative; boundary=001a1139a30466eb77050649cf41 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yX6MHBBGV3WF_-K_wh6-0VV4RVc Cc: v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 02:02:52 -0000 --001a1139a30466eb77050649cf41 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 23, 2014 at 1:41 AM, Gert Doering wrote: > Hi, > > On Thu, Oct 16, 2014 at 06:18:34PM -0700, Matthew Petach wrote: > > The probability of us figuring out how to scale > > the routing table to handle 40 billion prefixes > > is orders of magnitude more likely than solving > > the headaches associated with dynamic host > > renumbering. That ship has done gone and > > sailed, hit the proverbial iceberg, and is gathering > > barnacles at the bottom of the ocean. > > What I find scary in this statement is the underlying "one solution must > fit all users" mentality. > ... > No, Owen's home does not qualify for a typical "SOHO" network, and most > likely, none of the other readers. Ask yourself, what is needed to make > the network on your parent's home work (assuming those are not network > engineers). > Totally fair point, Gert--and you're right, I'm biased in my thinking, as I'm focused on all the use cases I run into, at work and at home. I'm not used to thinking of "web browsing only" type users, for whom prefix changes won't have as much of an impact. But you're right. My home network, Owen's home network...indeed, most likely none of ours would be the anticipated target of such efforts. Thanks for the reminder, that when it comes to networking, we are the 0.1%. :/ Thanks! Matt > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > --001a1139a30466eb77050649cf41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 1:41 AM, Gert Doering <gert@space.net> wrote:
Hi,

On Thu, Oct 16, 2014 at 06:18:34PM -0700, Matthew Petach wrote:
> The probability of us figuring out how to scale
> the routing table to handle 40 billion prefixes
> is orders of magnitude more likely than solving
> the headaches associated with dynamic host
> renumbering.=C2=A0 That ship has done gone and
> sailed, hit the proverbial iceberg, and is gathering
> barnacles at the bottom of the ocean.

What I find scary in this statement is the underlying "one solu= tion must
fit all users" mentality.
...
No, Owen's home does not qualify for a typical "SOHO" network= , and most
likely, none of the other readers.=C2=A0 Ask yourself, what is needed to ma= ke
the network on your parent's home work (assuming those are not network<= br> engineers).


Totally fair point, Ger= t--and you're right, I'm biased
in my thinking, as I'm focus= ed on all the use cases
I run into, at work and at home.=C2=A0 I'm n= ot used to
thinking of "web browsing only" type users, forwhom prefix changes won't have as much of an
impact.

<= div>But you're right.=C2=A0 My home network, Owen's
home network= ...indeed, most likely none of
ours would be the anticipated = target of such
efforts.

Thanks for the reminder, that when it
=
comes to networking, we are the 0.1%.=C2=A0 :/

Thanks!

Matt

=C2=A0

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

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279


--001a1139a30466eb77050649cf41-- From nobody Sun Oct 26 04:05:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333E31A7D82; Sun, 26 Oct 2014 04:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJo7aNlZ_Y7q; Sun, 26 Oct 2014 04:05:36 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D835D1A7D81; Sun, 26 Oct 2014 04:05:35 -0700 (PDT) Received: from [192.168.178.23] (5356888C.cm-6-7c.dynamic.ziggo.nl [83.86.136.140]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9QB5IQi007726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 12:05:19 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <544BB713.8000803@globis.net> Date: Sun, 26 Oct 2014 12:05:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1DDE5D8F-4B17-4D11-9F19-F94C38E7E749@muada.com> References: <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <011101cfe935$d0e8a600$72b9f200$@riw.us> <544BA11F.7050102@globis.net> <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com> <544BB713.8000803@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/myMIn-zR6L0bP4qLanst0Az-nNA Cc: Russ White , v6ops@ietf.org, grow@ietf.org Subject: Re: [v6ops] [GROW] Deaggregation by large organizations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 11:05:38 -0000 On 25 Oct 2014, at 16:43, Ray Hunter wrote: > I'm not convinced your draft is in line with my own understanding of = how multinationals I know either use, or want to use the Internet, and = why the de-aggregation occurs in the first place. > I'd thus like to see more data on where/why the de-aggregation is = occurring. Yes, that would be good to know. I guess when I have some time I'll take = the Fortune 500 and see what they inject in the global routing table. However, it's still early days for IPv6 so what we see today isn't = necessarily a reflection of what's needed in the future. > Internet "offload" is a common requirement for low value traffic, in = conjunction with a private high quality internal Intranet for corporate = apps like design tools, with both networks active simultaneously. > My thinking is that SADR, and running multiple (PA) prefixes within an = enterprise will address this requirement. So each sub unit would carry = both the multinational/global PI space and one or more local PA space = prefixes obtained from the local ISP. Only the local PA space would be = advertised out of each break out. That would be and prevent the need for = de-aggregate routes to be advertised back into the individual ISPs = serving the sub unit satellite sites. Do you have any examples of networks doing this? Using multiple = addresses is not easy. > Equally GRE tunnels or IPSEC tunnels over Internet are already = common-practice to create virtual enterprise networks. But that doesn't mean you want all your employees in Europe browsing the = web through a tunnel to North America. > > This way, deaggregates only have to be carried by ISPs providing the > aggregate of last resort service and the ISPs connecting subunits of > the organization. > I don't think enterprises want to be tied to ISP's at all. What do you mean? That they run their own network? Or that they can = switch ISPs easily? No reason the latter couldn't be accomplished with = the aggregate of last resort service. > I don't know of any small set of ISPs that can economically provide = service in 50+ countries in some sort of coordinated aggregate ISP = manner. Simple. Pay ISPs 1 and 2 to announce the aggregate. Then go look for = ISPs 3 - 50 and tell them if they want your business, they have to = interconnect with 1 and 2 (as customers or peers, you do't care). 1 and = 2 need to be present globally or close to it but not necessarily = locally, while 3+ need to be available locally but not necessarily = globally. > > In theory, a user in Tokyo could connect to the internet in Madrid. = In practice, this is is exceedingly rare. > I don't agree with this observation. I know of many cases e.g. where a = break in/out for a 3rd party from China is made in Europe. Or where a US = based company manages systems remotely in Europe, LATAM, Asia Pacific, = and the US and has regional links to the customer (with a break in/out = per region). Can you provide IP addresses that can be tracerouted? > My particular worry with aggregates of last resort would be that with = longest prefix match matching, it's becoming increasingly easy for = longer prefixes to hijack important enterprise aggregates. So = advertising an aggregate of last resort, whilst allowing sub units to = advertise longer prefixes to other ISPs, might not be such a great idea = for security. I guess the draft adds one issue here: an attacker could inject a longer = prefix but add communities that cause it to be filtered before it = reaches certain places so the hijacking is less obvious. But unless you want the IPv4 table to be 14M /24s and the IPv6 table be = some unholy number of /48s, the real solution to prefix hijacking needs = to be found elsewhere.= From nobody Sun Oct 26 11:00:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8483C1A0282 for ; Sun, 26 Oct 2014 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7W4gOGXCAGm for ; Sun, 26 Oct 2014 11:00:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974761A0276 for ; Sun, 26 Oct 2014 11:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1414346405; x=1415556005; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=D2826Rmzm8z4JZ9+kNUzf5Hd0DFL1PC10sBss4IdHPpmhxCOITlSqGPa WAiYI6ySyekJ0fbwSAXJrrh+zmat+A+Am+60tOEp/o+nol74nCadb/p8p 6Gq0w3D2GvdoEsAVS9drYuo3MyqYKmjvtE/lvEyswoJZncnVv5jwbt3Fd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEHADY2TVStJA2B/2dsb2JhbABcgw69YAGYDYEIFgF9hCZcPDSJIQHHWwEBAQEGAQEBAQEBHJEIHYQ1BYtkky6DSZE0hBiDFwEBAQ X-IronPort-AV: E=Sophos;i="5.04,791,1406592000"; d="scan'208";a="366812102" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP; 26 Oct 2014 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9QI04Xs010322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 18:00:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s9QI03uj026236; Sun, 26 Oct 2014 11:00:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s9QI03Aw026234; Sun, 26 Oct 2014 11:00:03 -0700 Date: Sun, 26 Oct 2014 11:00:03 -0700 From: fred@cisco.com Message-Id: <201410261800.s9QI03Aw026234@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3lqf6bujNXuvA3KdiM74qHZSJGg Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 18:00:06 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Sun Oct 26 12:59:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F6B1A1A6E for ; Sun, 26 Oct 2014 12:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.203 X-Spam-Level: * X-Spam-Status: No, score=1.203 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEmCkysHrdjT for ; Sun, 26 Oct 2014 12:59:56 -0700 (PDT) Received: from nm50-vm6.bullet.mail.ne1.yahoo.com (nm50-vm6.bullet.mail.ne1.yahoo.com [98.138.121.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46A91A1A70 for ; Sun, 26 Oct 2014 12:59:55 -0700 (PDT) Received: from [127.0.0.1] by nm50.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2014 19:59:54 -0000 Received: from [98.138.226.180] by nm50.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2014 19:56:56 -0000 Received: from [98.139.212.149] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2014 19:56:56 -0000 Received: from [98.139.212.239] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 26 Oct 2014 19:56:56 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 26 Oct 2014 19:56:56 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 381792.16131.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 41871 invoked by uid 60001); 26 Oct 2014 19:56:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1414353416; bh=BJdqf6mquuKFrbZpj2Xl3E/SfyPWMYdXqdhDSLWg158=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OjKYHQyJ4ADl+668fpgd5Xe3whA0CLApLjv6FCuewX8CjM+j3q1v4Kf620WtxAveEOhw7DQA3tBuXO6MLYXybK8EImP8Nl8xGoOH3IxHt4rYhHU7dfNmdYJo0VYdKcz2hJesdyrlD1eHwEzDQpUHJshzQdFT+E0Q8BcFoolyAok= X-YMail-OSG: 303Ft50VM1lgd.zuHfly7b8kF7TyI1kePvn1Ov62g_SnOP3 ZrvXITANfyTPWlWhgMbSZAu7RzUgkza8qn_TYM84L0h_KVxRNMJ20s2JMd0J 37L8xpJyxsjpCrvkQkBv2FQO_tx98Xnxkge1yjnQp07REPlKKI7xoSNaKbyS gb1YItKGZaWoJvrLHnZEXoJzFktrpESjVvAs0sOXFH2Vkp5h6_awaQKharWG qh0OIthf7BsnWFO9VdrvVdnb4RKDSKgjf37.6KTIDj5UJpnHC4rPgXFkbf0V LxP9jIp9Z3zs6FdRHUZMWyUXPtRDdSQrpZmcdtCh54yZ28X_ZLpHya_5fVN0 6UJujtkcU4TdUgsaltZ3Pb2uTur7VFEsVoRV.qrmaVGDlngZOYktsAKxxecu Vz4IQKVNKy6Z8UGYZwQpRIjWDWAkWwvVzYFRmmX_m8sD5ovzOgB7hfQRHdEm NKXher_krjtecQxq4hHFHZvO1c6Upk.0DKN26EyMH5r30yQZrm9zZew.1AJr XpBf48JAf0VUZ4FztFJsymuohqX.66Sw8ErLKcyGUNOpxtYkuL4WbVFb0Iwe OJXIsEjZDnUyA Received: from [150.101.221.237] by web162202.mail.bf1.yahoo.com via HTTP; Sun, 26 Oct 2014 12:56:56 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKUmVhZGluZyB0aHJvdWdoIHRoaXMsIHRoZSBvbmUgdGhpbmcgSSB0aGluayB0aGF0IGlzIG1pc3NpbmcsIGluIHBhcnRpY3VsYXIgYXMgaXQgaXMgYSBwcm9ibGVtIHN0YXRlbWVudCwgaXMgYSBjbGVhciBzdGF0ZW1lbnQgb2Ygd2hhdCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIGFjdHVhbGx5IGlzLiBJIHRoaW5rIHRoYXQgd291bGQgY2VydGFpbmx5IG1ha2UgaXQgY2xlYXJlciB3aHkgdGhlIGJlaGF2aW91cnMgZGVzY3JpYmVkIGFyZSB0aGVuIGRpdmVyZ2VudC4KCkFzIGZvciB0aGUgZXhwZWN0ZWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <201410261800.s9QI03Aw026234@irp-lnx1.cisco.com> Message-ID: <1414353416.85710.YahooMailNeo@web162202.mail.bf1.yahoo.com> Date: Sun, 26 Oct 2014 12:56:56 -0700 From: Mark ZZZ Smith To: "v6ops@ietf.org" In-Reply-To: <201410261800.s9QI03Aw026234@irp-lnx1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/m-uem1kIe4pB-zYcR_71pa-j38s Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 19:59:57 -0000 Hi,=0A=0A=0AReading through this, the one thing I think that is missing, in= particular as it is a problem statement, is a clear statement of what the = expected behaviour actually is. I think that would certainly make it cleare= r why the behaviours described are then divergent.=0A=0AAs for the expected= behaviour, I think there are actually 3 separate classes of addressing fun= ctions:=0A=0Ao address generation functions=0A=0AThe methods or algorithms = used to numbers that will be used for the IPv6 address e.g., EUI-64 derived= , privacy addresses, available addresses in a database etc.=0A=0Ao address = configuration functions=0A=0AThe methods used to configure an address on an= interface, currently SLAAC, DHCPv6, or static=0A=0Ao address expiry functi= ons=0A=0AThe functions used to expire an address e.g., address aging/lifeti= mes, manual operator removal (but not SLAAC or DHCPv6)=0A=0A=0AI think it h= as been common for either the specifications to imply, sometimes strongly, = or for people to mentally couple together two or three of them under the na= me of one of the address configuration functions. I think this then explain= s why there are the divergent behaviours described in this draft.=0A=0AFor = example, if the implementer of DHCPv6 mentally couples together all three f= unctions, thinking they're all part of DHCPv6, then it is logical that if D= HCPv6 is switched off on a link via switching off the RA M bit, then it is = logical to remove or expire the DHCPv6 learned addresses. Yet I think DHCPv= 6 is only an address configuration function, and if DHCPv6 is switched off,= the DHCPv6 learned addresses should be left to be (normally) removed by th= e (DHCPv6 unrelated) address aging/lifetimes mechanism.=0A=0AThere are some= constraints on what addressing generation functions can be used with parti= cular address configuration functions, however, in many cases there aren't.= =0A=0AI don't think there is any reason why EUI-64 derived and therefore ge= nerated addresses, commonly used with SLAAC, couldn't instead by configured= using static or DHCPv6 methods. RFC4941 privacy addresses, specified for u= se in SLAAC by RFC4941, are also supported in DHCPv6 via IA_TAs, so the met= hod of generating privacy addresses isn't tightly bound to the address conf= iguration method.=0A=0AWhen thinking about/reviewing Fernando's opaque IDs = a while back, which ended up being RFC7217, I realised that there was no re= ason why that address generation method, although specified in that RFC for= SLAAC, wouldn't be just as useful when using DHCPv6 for address configurat= ion. There is now a draft specifying how to use that address generation met= hod with DHCPv6 (draft-ietf-dhc-stable-privacy-addresses), so it isn't tigh= tly bound to SLAAC address configuration. If you want to implement those ty= pes of IDs before your SLAAC or DHCPv6 implementation supports them, you co= uld generate the addresses and then apply them using the static configurati= on method in the interim. Fernando really just came up with an address gene= ration method (generating Semantically Opaque Interface Identifiers) that c= ould be used with any of the address configuration methods.=0A=0AIf people = agree with above, then I think it would be useful to describe this break do= wn of classes of addressing functions in this draft or perhaps another one.= =0A=0A=0ARegards,=0AMark. From nobody Sun Oct 26 13:20:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241731A1A82 for ; Sun, 26 Oct 2014 13:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.537 X-Spam-Level: * X-Spam-Status: No, score=1.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTkk7pYPU6n7 for ; Sun, 26 Oct 2014 13:20:13 -0700 (PDT) Received: from nm44-vm10.bullet.mail.gq1.yahoo.com (nm44-vm10.bullet.mail.gq1.yahoo.com [67.195.87.215]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CA91A1A7E for ; Sun, 26 Oct 2014 13:20:13 -0700 (PDT) Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2014 20:20:12 -0000 Received: from [98.137.12.57] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2014 20:17:19 -0000 Received: from [98.139.214.32] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 26 Oct 2014 20:17:19 -0000 Received: from [98.139.212.192] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 26 Oct 2014 20:17:19 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 26 Oct 2014 20:17:19 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 270518.54374.bm@omp1001.mail.bf1.yahoo.com Received: (qmail 75904 invoked by uid 60001); 26 Oct 2014 20:17:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1414354639; bh=c0n+W1BkX4oA+SoPfKelofIaiGYw6ljSE1gG9rEguVI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hgA4cr9KZq9Nyj4d5hg9enNJ24C3YahYSmt58ORgznxjHWvK/xDkE0ZPMNiNIz+lmVbPG703woDzxY56KKoxiW9ySetD7EBUKlhC8X0Iro9jphWt146Vew3RzcSiLYPymYuKMS9vWjPehwrydvF98Y9RGLOeP2L4u144Cj2cxcQ= X-YMail-OSG: cd44UJwVM1nZ7Ts0UBk8v0qnBBFUsevlhaqcnfChh8xJF0T 0XjkXv9zdAtKqFBp9AuUefUOgT13l8FRrYzVK.DYeoNt.EjUlYR0P2VKSaRE ksORl2V4_meak.atbl6DEth9XJioNQacFWl0Rm5HTJcQBCxoBjCtRqPAxoFd 9dOXxOrVQVNMcmo2oW4.cGbWCFSBPwx__KNzc1eFuFUD_lQ5vCYzNZmlessk 3rbOunSZfZ5BxJJ0NKV3C3OSojcZfvujp7YvfkC1l.xyIcmUwSUFXH0jfMeO AWXplydVI802CLC02SjJwGmXJjwtKr_J.0jyT5hH20l3zZzv16XKKF0IiatE 45CESQJEQSZheaBYf4hQqiiVENontU_ayC8BzjirWha3lN0q4ss90UQ1lQGG nqVtPj5szbrDZQyQIUbAAu..351WqyMv.WfQ98FxPNsLxIyr7khenxcAAAS7 PeFQ7Ug7RwpQLZSF18KAbC0JspB43xPfkwrVF9uKifLQVqFt17fdYlrBAcHD SAtN2fukf8k6xS.qKsXyNs2vPkqC5c_Lj0bAwQDgcBfhAbcyllHhiyFTml0t vlat0iFHlcP9IUDOmbQZYkYd3CGP_ZFEi40C1_g5NM6E8MQQcX8.UmRH53M0 nw61vILRM.YBqm0uuOq0YRTYWidbzT9I6PZtoNwB6Kv25RjVKHQ-- Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Sun, 26 Oct 2014 13:17:19 PDT X-Rocket-MIMEInfo: 002.001, CgpIaSwgCgoKUmVnYXJkaW5nIGNvbnRyb2xsaW5nIGhvdyBmYXIgYSBtb3JlIHNwZWNpZmljIHRyYXZlbHMsIEkndmUgYXR0YWNoZWQgJ25vLWV4cG9ydCcgdG8gbW9yZSBzcGVjaWZpYyByb3V0ZXMgZm9yIFRFIHB1cnBvc2VzIHdoZW4gYWR2ZXJ0aXNpbmcgdGhlbSB0byBhbiB1cHN0cmVhbSBwcm92aWRlciB0byBsaW1pdCB0aGVpciByZWFjaC4gT2YgY291cnNlIHRoZSB0cm91YmxlIGlzIHRoYXQgJ25vLWV4cG9ydCcgaGFzIGEgdmVyeSBsaW1pdGVkIHNjb3BlLiBUaGlzIGRpc2N1c3Npb24gcmVtaW5kZWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> Message-ID: <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Sun, 26 Oct 2014 13:17:19 -0700 From: Mark ZZZ Smith To: Iljitsch van Beijnum , "grow@ietf.org grow@ietf.org" , IPv6 Operations In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ANOFFr9X8eraOKJclf9KM9TfK-o Subject: Re: [v6ops] Fwd: I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 20:20:14 -0000 =0A=0AHi, =0A=0A=0ARegarding controlling how far a more specific travels, I= 've attached 'no-export' to more specific routes for TE purposes when adver= tising them to an upstream provider to limit their reach. Of course the tro= uble is that 'no-export' has a very limited scope. This discussion reminded= me of this draft, which encodes an AS level hop count that can be used to = limit route propagation, perhaps it or something similar needs to be revive= d:=0A=0A"The AS_HOPCOUNT Path Attribute=0A=0A2. Introduction=0A=0A A pre= fix that is injected into BGP [RFC1771] will propagate=0A throughout the = mesh of all BGP speakers unless it is explicitly=0A blocked by policy con= figuration. This behavior is necessary for the=0A correct operation of B= GP, but has some unfortunate interactions with=0A current operational pro= cedures. Currently, it is beneficial in some=0A cases to inject longer p= refixes into BGP to control the flow of=0A traffic headed towards a parti= cular destination. These longer=0A prefixes may be advertised in additio= n to an aggregate, even when the=0A aggregate advertisement is sufficient= for basic reachability. This=0A particular application is known as "int= er-domain traffic engineering"=0A and is a well-known phenomenon that is = contributing to growth in the=0A size of the global routing table [RFC322= 1]. The mechanism proposed=0A here allows the propagation of those longe= r prefixes to be limited,=0A allowing some traffic engineering problems t= o be solved without such=0A global implications."=0A=0A=0Ahttps://tools.i= etf.org/html/draft-ietf-idr-as-hopcount-00=0A=0A=0ANot covered in that draf= t, one thought would be that upstream operators could police something like= this by only accepting more specifics of your aggregate with an AS_HOPCOUN= T value of <=3D 10.=0A=0A=0ARegards,=0AMark.=0A From nobody Sun Oct 26 14:51:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC831A1AAD; Sun, 26 Oct 2014 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZEMAVgcVfuh; Sun, 26 Oct 2014 14:51:45 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539E11A1AAC; Sun, 26 Oct 2014 14:51:45 -0700 (PDT) Received: from [192.168.178.23] (5356888C.cm-6-7c.dynamic.ziggo.nl [83.86.136.140]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9QLpUKF010186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 22:51:30 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Iljitsch van Beijnum In-Reply-To: <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Sun, 26 Oct 2014 22:51:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zc5qcdYSGu6COF_blkWNefYx41Y Cc: "grow@ietf.org grow@ietf.org" , IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:51:47 -0000 On 26 Oct 2014, at 21:17, Mark ZZZ Smith = wrote: > Regarding controlling how far a more specific travels, I've attached = 'no-export' to more specific routes for TE purposes when advertising = them to an upstream provider to limit their reach. Of course the trouble = is that 'no-export' has a very limited scope. This discussion reminded = me of this draft, which encodes an AS level hop count that can be used = to limit route propagation, perhaps it or something similar needs to be = revived: Setting an AS hop limit makes some sense if you assume the origin AS = wants to limit propagation of the advertisement. However, in many cases = the origin AS would probably like to see a deaggregate propagate as far = as possible, as this allows for the shortest paths and the highest level = of redundancy. Third party ASes, on the other hand, may want to limit how many of those = deaggregates they carry, but an AS hop limit wouldn't really give them = any tools to do that. But if you think that it makes sense to specify a community like this, = perhaps it would be a good idea to combine that one and the ones I'm = proposing here and possibly others into a single document. That would = probably make reviewing the document(s) an implementing those = communities easier. Or maybe not...= From nobody Mon Oct 27 00:38:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16FE1A1AB5; Mon, 27 Oct 2014 00:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws0WXcwCTUBO; Mon, 27 Oct 2014 00:38:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2E1A89C6; Mon, 27 Oct 2014 00:38:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027073843.13643.64057.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 00:38:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N1quxAeXBikQCuUmpMlyFYDmmOU Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 07:38:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Considerations For Using Unique Local Addresses Authors : Bing Liu Sheng Jiang Filename : draft-ietf-v6ops-ula-usage-recommendations-04.txt Pages : 16 Date : 2014-10-27 Abstract: This document provides considerations for using IPv6 Unique Local Addresses (ULAs). It identifies cases where ULA addresses are helpful as well as potential problems that their use could introduce, based on an analysis of different ULA usage scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-recommendations-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 05:07:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B3B1A914C; Mon, 27 Oct 2014 05:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xll61c66LZjG; Mon, 27 Oct 2014 05:07:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 624421A9152; Mon, 27 Oct 2014 05:07:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027120717.2023.67183.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 05:07:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nBIqxJmwaS-TN7zYrBpwG6dTqXc Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 12:07:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : DHCPv6/SLAAC Address Configuration Interaction Problem Statement Authors : Bing Liu Sheng Jiang Ron Bonica Xiangyang Gong Wendong Wang Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-03.txt Pages : 13 Date : 2014-10-27 Abstract: The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating which autoconfiguration mechanisms are available to on- link hosts. These are the M, O and A flags. The M and O flags are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also describes operational problems that divergent behaviors cause. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 09:49:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C811A19E7 for ; Mon, 27 Oct 2014 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -116.511 X-Spam-Level: X-Spam-Status: No, score=-116.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3SfSR6drK0c for ; Mon, 27 Oct 2014 09:49:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1618B1A014C for ; Mon, 27 Oct 2014 09:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2483; q=dns/txt; s=iport; t=1414428569; x=1415638169; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xpv2biUozroDexVRUaHOJ8AaF89oS6oPKMOxHBAsWKo=; b=mfAduWSBLOM35dKLnMjt0Pbbm3tqHxq+f24nNIpc27kzdgCnz3kYyfey RFepINNaWLNjjj9rQ+pt53MO6U77ZS4qrerzDihKaGXJNiyA1JPEIl1Ze w/nF8eaJnGcn0d5fh3FZWhOd6O4/LaVS5s0LKPy3ojPtaYoLeZGLs/Fm8 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJZ2TlStJA2I/2dsb2JhbABcgw5UWATNMQqHTQKBHRYBfYQDAQEDAQEBAWkCGwIBCEYnCyUCBBMJBYgqCQ3LRQEBAQEBAQEBAQEBAQEBAQEBAQEBAReRCgWDLYEeBZIHghCBUGiCQ4RPgTE8gw2KWoZag3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,796,1406592000"; d="asc'?scan'208";a="366892791" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 27 Oct 2014 16:49:28 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9RGnSvN010766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Oct 2014 16:49:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 11:49:28 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: I-D Action: draft-chen-v6ops-nfv-ipv6-00.txt Thread-Index: AQHP8e+eYgS2wx93fEqfDUFNex5PhJxEe+CA Date: Mon, 27 Oct 2014 16:49:27 +0000 Message-ID: References: <20141027140742.23834.22483.idtracker@ietfa.amsl.com> In-Reply-To: <20141027140742.23834.22483.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: multipart/signed; boundary="Apple-Mail=_3E78610A-1F0B-4E05-B7E2-6797FFBF7D9D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mHNNaE1cPcmsXsrn1hj5VVbyCZE Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nfv-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:49:31 -0000 --Apple-Mail=_3E78610A-1F0B-4E05-B7E2-6797FFBF7D9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For whatever reason, I haven=92t seen my bot=92s invitation to comment = on this. I am interested in folks comments on it. On Oct 27, 2014, at 7:07 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : IPv6 Considerations for Network Function = Virtualization (NFV) > Authors : Gang Chen > Hui Deng > Filename : draft-chen-v6ops-nfv-ipv6-00.txt > Pages : 9 > Date : 2014-10-27 >=20 > Abstract: > NFV adoption is gaining significant momentum, driven largely by the > need to improve service agility and reduce operational cost. IPv6 = is > a fundamental feature should be enabled. This memo desribes the > layered NFV components and typical implementations. The IPv6 > considerations have been elaborated to each component in order to > consoliate IPv6 demands across entire NFV system. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-v6ops-nfv-ipv6/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_3E78610A-1F0B-4E05-B7E2-6797FFBF7D9D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUTneVbjEdbHIsm0MRAnPbAJ47xu2rzDNzRBXNpq1XnY4Zs/JYXQCeNgQT Wb0PIgGgCz+s0+1hrd1L6Q0= =ZZIe -----END PGP SIGNATURE----- --Apple-Mail=_3E78610A-1F0B-4E05-B7E2-6797FFBF7D9D-- From nobody Mon Oct 27 13:28:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023A61AD46E for ; Mon, 27 Oct 2014 13:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-T61dszzwbI for ; Mon, 27 Oct 2014 13:27:38 -0700 (PDT) Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [163.221.80.91]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4A1AD46F for ; Mon, 27 Oct 2014 13:27:37 -0700 (PDT) Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id 53C90C7B for ; Tue, 28 Oct 2014 05:27:36 +0900 (JST) Received: from [10.10.4.56] (s70.BMT-w1.vectant.ne.jp [122.103.200.70]) by mailpost22.naist.jp (Postfix) with ESMTPSA id F2DCAC7A for ; Tue, 28 Oct 2014 05:27:35 +0900 (JST) Message-ID: <544EAAB6.6090207@is.naist.jp> Date: Tue, 28 Oct 2014 05:27:34 +0900 From: Hiroaki Hazeyama User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141027125751.28426.88868.idtracker@ietfa.amsl.com> In-Reply-To: <20141027125751.28426.88868.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141027125751.28426.88868.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070807070806030502030309" X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-7.5.0.1018-21058.002 X-TM-AS-Result: No--13.989-5.0-31-10 X-imss-scan-details: No--13.989-5.0-31-10 X-TMASE-MatchedRID: 17RrBt0ChF9CXIGdsOwlUh5+URxv1WlB3AYeF1eBimH2Jzqp3fkNE9Yy y3/zxX0mt7LKm7S9yMxEZM+mdBeKWQiDaxAOYjSWzLnsGkFCJyS49IoBojnioSSPufJfHBYzaVt vYPBkvgPjwIdTpLUhISOxVumXuzfxrPvkNFf532RWjqaf7FeZ1fx3eAlFiEvxWltirZ/iPP6QZg zXiUL8NTAiUY63S0LmXm9sSUte0C8Q7qKF6LOVXrxygpRxo469IZm2INWXDp5k2J2ef3Nd3/TrP 5e8ec7BsBb3Q0HEUXwFnwbZRaSvqRvplmlmbTfswbRQ2BpmliqZEoWHC6Rh/fIFt7oBqvJi9rZ8 tOV7IbgqTzT1pjjbPOKfC1GMnPpUxT64X4H/b/5DmVmiQbM5qhtPDNiPbNC6GVfpvCubUPxi4Hy yL6eYhCTFmUPaoH/RbnM/8VJDhM008llWm5zjSgcbMHjYNxGhhZApJAdFDDabKItl61J/yZUdXE /WGn0FfeZdJ1XsorhDIkY9B3A+LM/8zK5WVP8LS0iSG6xyIZejPxW4TOhT9jAnIcQsnUhcMvDfJ 8KV2TNJon7RNmbOkA+MdArWnAQ2gFsqdj5HfOycnLbps5H2GajmuUGrUmS4hw9fGytof3j4Ad1m nP4a8QfSsimtN8Um Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6XnRxWDwzOEDSPS0zLwoujwETNY Subject: [v6ops] Fwd: I-D Action: draft-osamu-v6ops-ipv4-literal-in-url-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:27:40 -0000 This is a multi-part message in MIME format. --------------070807070806030502030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi v6ops memers, this is HIroaki Hazeyama. Along with comments in ietf 90 and Teeme comments from unicast mails, we updated draft-osamu-v6ops-ipv4-address-literal-in-url-02.txt We would like you to give us your comments or feedback. Regards, ----- hazeyama -------- Original Message -------- Subject: I-D Action: draft-osamu-v6ops-ipv4-literal-in-url-02.txt Date: Mon, 27 Oct 2014 05:57:51 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environments Authors : Osamu Nakamura Hiroaki Hazeyama Yukito Ueno Akira Kato Filename : draft-osamu-v6ops-ipv4-literal-in-url-02.txt Pages : 15 Date : 2014-10-27 Abstract: In an IPv6-only environment with DNS64/NAT64 based translation service, there is no way to get access a URL whose domain name part includes an IPv4 address literal. This memo proposes a special purpose TLD so that the IPv4 address literal is accessible from such a DNS64/NAT64 environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-osamu-v6ops-ipv4-literal-in-url/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-osamu-v6ops-ipv4-literal-in-url-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070807070806030502030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi v6ops memers,
this is HIroaki Hazeyama.

Along with comments in ietf 90 and Teeme comments from unicast mails,
we updated draft-osamu-v6ops-ipv4-address-literal-in-url-02.txt

We would like you to give us your comments or feedback.

Regards,
-----
hazeyama


-------- Original Message --------
Subject: I-D Action: draft-osamu-v6ops-ipv4-literal-in-url-02.txt
Date: Mon, 27 Oct 2014 05:57:51 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : A Special Purpose TLD to resolve IPv4 Address Literal on DNS64/NAT64 environments
        Authors         : Osamu Nakamura
                          Hiroaki Hazeyama
                          Yukito Ueno
                          Akira Kato
	Filename        : draft-osamu-v6ops-ipv4-literal-in-url-02.txt
	Pages           : 15
	Date            : 2014-10-27

Abstract:
   In an IPv6-only environment with DNS64/NAT64 based translation
   service, there is no way to get access a URL whose domain name part
   includes an IPv4 address literal.  This memo proposes a special
   purpose TLD so that the IPv4 address literal is accessible from such
   a DNS64/NAT64 environments.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-osamu-v6ops-ipv4-literal-in-url/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-osamu-v6ops-ipv4-literal-in-url-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--------------070807070806030502030309-- From nobody Mon Oct 27 15:23:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ECD1A1A8D; Mon, 27 Oct 2014 15:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEwPbzpgt3ki; Mon, 27 Oct 2014 15:23:48 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFB1A1A99; Mon, 27 Oct 2014 15:23:48 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9RMKPDP006890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Oct 2014 15:20:25 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9RMKPDP006890 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414448426; bh=NFm0gIcrwSSf251h6PbDPVDioMc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TnHTNNPFootFOB/MSoBYTiGQ3lXL2SFmqMGOX4NxX+PhrhEfZ+u25K31X/9Jeu1YG YH79eQAdX2sB+eeFjD6SQsg5NLA1FE4rRY5JH7g3VwIAHw4vEjrdr8t8qmTRoH4cQZ ecDuxDyR/4kpp6b8AsHNaz4de4Jk7ducmNjufDv8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Mon, 27 Oct 2014 15:20:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 27 Oct 2014 15:20:26 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v36O3fTavJ5P1tixsxdiDFIjdEA Cc: "grow@ietf.org grow@ietf.org" , IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:23:51 -0000 What would be nice would be to have a BGP knob from vendors that could = be set on a per-peer basis (or per peer-group basis) that allowed us to = discard covered specifics with identical attributes on ingress. Owen > On Oct 26, 2014, at 2:51 PM, Iljitsch van Beijnum = wrote: >=20 > On 26 Oct 2014, at 21:17, Mark ZZZ Smith = wrote: >=20 >> Regarding controlling how far a more specific travels, I've attached = 'no-export' to more specific routes for TE purposes when advertising = them to an upstream provider to limit their reach. Of course the trouble = is that 'no-export' has a very limited scope. This discussion reminded = me of this draft, which encodes an AS level hop count that can be used = to limit route propagation, perhaps it or something similar needs to be = revived: >=20 > Setting an AS hop limit makes some sense if you assume the origin AS = wants to limit propagation of the advertisement. However, in many cases = the origin AS would probably like to see a deaggregate propagate as far = as possible, as this allows for the shortest paths and the highest level = of redundancy. >=20 > Third party ASes, on the other hand, may want to limit how many of = those deaggregates they carry, but an AS hop limit wouldn't really give = them any tools to do that. >=20 > But if you think that it makes sense to specify a community like this, = perhaps it would be a good idea to combine that one and the ones I'm = proposing here and possibly others into a single document. That would = probably make reviewing the document(s) an implementing those = communities easier. >=20 > Or maybe not... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Oct 27 15:43:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157C81A1A8D; Mon, 27 Oct 2014 15:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlwwRKwT0OC2; Mon, 27 Oct 2014 15:43:02 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D641A1B47; Mon, 27 Oct 2014 15:42:59 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id h18so4038929igc.13 for ; Mon, 27 Oct 2014 15:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GPR4GzN6DsK8ynbbhsrJyMot4zaCiJnY9lkUP5r0dpE=; b=qk0LykNXytNB+lekiA0rt7Olj90kcxuxpYTOZRwbvc0O2llx4LKxJbFM0hGIZAzaXA /ljf7ppK+YHJ3P3ayHAwrqh/mOyIS/P2N3715QwxWJQOR2jIfTTwAclUvP+YFNmBz0sr mX53eWuV8Wm5mO+q1BfMbQQ8O/nBvAU4I5LEF/XHe9jVeI92NbKqJDcWtPziLhay8HdQ tbReun9Wqr30Q6BKeXkzqRgU+v7iSiSXcPu6uOWvyPkNFq6tDVeeMYeYkuIqTjINdPhL BfR6Yjc/46HvgHpJRFnWrE4h6FrYaEkFtlAGHBQ4uocTHg2IK4s0Z76y39ua5uX7HqPc 8GhQ== MIME-Version: 1.0 X-Received: by 10.50.60.97 with SMTP id g1mr25909690igr.2.1414449778898; Mon, 27 Oct 2014 15:42:58 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Mon, 27 Oct 2014 15:42:58 -0700 (PDT) In-Reply-To: References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> Date: Mon, 27 Oct 2014 23:42:58 +0100 X-Google-Sender-Auth: QVKOTpbuTPeaJWrCBbCheSN6UK4 Message-ID: From: Robert Raszuk To: Owen DeLong Content-Type: multipart/alternative; boundary=047d7b10cea79fdea605066f4002 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HyL69hvtZDZWIM6al3VflBSKleM Cc: "grow@ietf.org grow@ietf.org" , IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:43:05 -0000 --047d7b10cea79fdea605066f4002 Content-Type: text/plain; charset=UTF-8 Considering that it takes on average two years to develop, test and ship a knob (not to mention that you need to write a check with sufficient amount of zeros in it) I think much better option would be just to have a parametrized policy language. Good news is that if I am not mistaken some vendors already support what you are asking today :) It just requires a little bit of in depth scripting ... I am sure your vendor of choice will be happy to support you. Cheers, Robert. On Mon, Oct 27, 2014 at 11:20 PM, Owen DeLong wrote: > What would be nice would be to have a BGP knob from vendors that could be > set on a per-peer basis (or per peer-group basis) that allowed us to > discard covered specifics with identical attributes on ingress. > > Owen > > > On Oct 26, 2014, at 2:51 PM, Iljitsch van Beijnum > wrote: > > > > On 26 Oct 2014, at 21:17, Mark ZZZ Smith > wrote: > > > >> Regarding controlling how far a more specific travels, I've attached > 'no-export' to more specific routes for TE purposes when advertising them > to an upstream provider to limit their reach. Of course the trouble is that > 'no-export' has a very limited scope. This discussion reminded me of this > draft, which encodes an AS level hop count that can be used to limit route > propagation, perhaps it or something similar needs to be revived: > > > > Setting an AS hop limit makes some sense if you assume the origin AS > wants to limit propagation of the advertisement. However, in many cases the > origin AS would probably like to see a deaggregate propagate as far as > possible, as this allows for the shortest paths and the highest level of > redundancy. > > > > Third party ASes, on the other hand, may want to limit how many of those > deaggregates they carry, but an AS hop limit wouldn't really give them any > tools to do that. > > > > But if you think that it makes sense to specify a community like this, > perhaps it would be a good idea to combine that one and the ones I'm > proposing here and possibly others into a single document. That would > probably make reviewing the document(s) an implementing those communities > easier. > > > > Or maybe not... > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b10cea79fdea605066f4002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Considering that it = takes on average two years to develop, test and ship a knob (not to mention= that you need to write a check with sufficient amount of zeros in it) I th= ink much better option would be just to have a parametrized policy language= .=C2=A0

Good news is that if I a= m not mistaken some vendors already support what you are asking today :) It= just requires a little bit of in depth scripting ...=C2=A0

I am sure your vendor of choice will be happy t= o support you.

Cheers,
Robert.


On Mon, Oct 27, 2014 at 11:20 PM, Owen = DeLong <owen@delong.com> wrote:
What would be nice would be to have a BGP knob from vendors that could = be set on a per-peer basis (or per peer-group basis) that allowed us to dis= card covered specifics with identical attributes on ingress.

Owen

> On Oct 26, 2014, at 2:51 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
>
> On 26 Oct 2014, at 21:17, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:
>
>> Regarding controlling how far a more specific travels, I've at= tached 'no-export' to more specific routes for TE purposes when adv= ertising them to an upstream provider to limit their reach. Of course the t= rouble is that 'no-export' has a very limited scope. This discussio= n reminded me of this draft, which encodes an AS level hop count that can b= e used to limit route propagation, perhaps it or something similar needs to= be revived:
>
> Setting an AS hop limit makes some sense if you assume the origin AS w= ants to limit propagation of the advertisement. However, in many cases the = origin AS would probably like to see a deaggregate propagate as far as poss= ible, as this allows for the shortest paths and the highest level of redund= ancy.
>
> Third party ASes, on the other hand, may want to limit how many of tho= se deaggregates they carry, but an AS hop limit wouldn't really give th= em any tools to do that.
>
> But if you think that it makes sense to specify a community like this,= perhaps it would be a good idea to combine that one and the ones I'm p= roposing here and possibly others into a single document. That would probab= ly make reviewing the document(s) an implementing those communities easier.=
>
> Or maybe not...
> _______________________________________________
> v6ops mailing list=
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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

--047d7b10cea79fdea605066f4002-- From nobody Mon Oct 27 18:42:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96F1A01F9 for ; Mon, 27 Oct 2014 18:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUzi43WyMFJV for ; Mon, 27 Oct 2014 18:42:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228E01A0084 for ; Mon, 27 Oct 2014 18:42:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOC59237; Tue, 28 Oct 2014 01:41:59 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 01:41:48 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 09:41:42 +0800 From: "Liubing (Leo)" To: Mark ZZZ Smith , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP8Ua6R5/LPNwiD06nd1k+J2CMjZxCRVMAgAJw11A= Date: Tue, 28 Oct 2014 01:41:41 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589E1BBB@nkgeml506-mbx.china.huawei.com> References: <201410261800.s9QI03Aw026234@irp-lnx1.cisco.com> <1414353416.85710.YahooMailNeo@web162202.mail.bf1.yahoo.com> In-Reply-To: <1414353416.85710.YahooMailNeo@web162202.mail.bf1.yahoo.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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sj2XCUiI2Nx2LKBBdUBFspg7i0U Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 01:42:03 -0000 Hi Mark, Thanks a lot for your comments. Please see replies inline. > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith > Sent: Monday, October 27, 2014 3:57 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC >=20 > Hi, >=20 >=20 > Reading through this, the one thing I think that is missing, in particula= r as it is > a problem statement, is a clear statement of what the expected behaviour > actually is. I think that would certainly make it clearer why the behavio= urs > described are then divergent. [Bing] This is indeed a good point. And I tried to discuss the expected beh= aviors in a dedicated draft (http://tools.ietf.org/html/draft-liu-6man-dhcp= v6-slaac-implementation-guide-00). > As for the expected behaviour, I think there are actually 3 separate clas= ses of > addressing functions: > o address generation functions >=20 > The methods or algorithms used to numbers that will be used for the IPv6 > address e.g., EUI-64 derived, privacy addresses, available addresses in a > database etc. >=20 > o address configuration functions >=20 > The methods used to configure an address on an interface, currently SLAAC= , > DHCPv6, or static >=20 > o address expiry functions >=20 > The functions used to expire an address e.g., address aging/lifetimes, > manual operator removal (but not SLAAC or DHCPv6) >=20 >=20 > I think it has been common for either the specifications to imply, someti= mes > strongly, or for people to mentally couple together two or three of them > under the name of one of the address configuration functions. I think thi= s > then explains why there are the divergent behaviours described in this dr= aft. [Bing] I basically share the same opinion with you. Some implementers seem = to mix these separate things together.=20 If you look at the above mentioned draft, the "address configuration functi= ons" and "address expiry functions" have been covered in the document. But I didn't think about the "address generation functions" aspect. I think= it's a good concern. > For example, if the implementer of DHCPv6 mentally couples together all > three functions, thinking they're all part of DHCPv6, then it is logical = that if > DHCPv6 is switched off on a link via switching off the RA M bit, then it = is > logical to remove or expire the DHCPv6 learned addresses. Yet I think > DHCPv6 is only an address configuration function, and if DHCPv6 is switch= ed > off, the DHCPv6 learned addresses should be left to be (normally) removed > by the (DHCPv6 unrelated) address aging/lifetimes mechanism. [Bing] Exactly. Fully agree. =20 > There are some constraints on what addressing generation functions can be > used with particular address configuration functions, however, in many ca= ses > there aren't. >=20 > I don't think there is any reason why EUI-64 derived and therefore genera= ted > addresses, commonly used with SLAAC, couldn't instead by configured using > static or DHCPv6 methods. RFC4941 privacy addresses, specified for use in > SLAAC by RFC4941, are also supported in DHCPv6 via IA_TAs, so the method > of generating privacy addresses isn't tightly bound to the address > configuration method. >=20 > When thinking about/reviewing Fernando's opaque IDs a while back, which > ended up being RFC7217, I realised that there was no reason why that > address generation method, although specified in that RFC for SLAAC, > wouldn't be just as useful when using DHCPv6 for address configuration. > There is now a draft specifying how to use that address generation method > with DHCPv6 (draft-ietf-dhc-stable-privacy-addresses), so it isn't tightl= y > bound to SLAAC address configuration. If you want to implement those type= s > of IDs before your SLAAC or DHCPv6 implementation supports them, you > could generate the addresses and then apply them using the static > configuration method in the interim. Fernando really just came up with an > address generation method (generating Semantically Opaque Interface > Identifiers) that could be used with any of the address configuration > methods. >=20 > If people agree with above, then I think it would be useful to describe t= his > break down of classes of addressing functions in this draft or perhaps > another one. [Bing] I think these are good concerns to be incorporated into the above me= ntioned implement-guidance draft. For the PS, currently I'm not sure whethe= r they are out of scope, since they are for implementers not operators. I'l= l leave it as an open question to the WG. Best regards, Bing =20 > Regards, > Mark. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Oct 27 21:01:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CCB1A0470 for ; Mon, 27 Oct 2014 21:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzEMAcQ-PBAF for ; Mon, 27 Oct 2014 21:01:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B38C1A039A for ; Mon, 27 Oct 2014 21:01:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOC68306; Tue, 28 Oct 2014 04:01:18 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 04:01:18 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 12:01:14 +0800 From: "Liubing (Leo)" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w7ok2AgAHqGMD//+BHgIAHXHqw Date: Tue, 28 Oct 2014 04:01:13 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JFeh_WG6pCPyFbMHIvqg30LVGIg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 04:01:32 -0000 SGkgQW5kcmV3LA0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQoNCj4gPj4gIjMuMi4xLiAg SW5hcHByb3ByaWF0ZSBTb3VyY2VzIg0KPiA+Pg0KPiA+PiBpbnRlcmVzdGluZyBmaW5kaW5nLiBX aHkgaXMgaXQgYSBwcm9ibGVtIHdvcnRoIHNvbHZpbmcgPw0KPiA+IFtCaW5nXSBBIGhvc3Qgd2hv IHNlbGYtY29uZmlndXJpbmcgdGhlIElQIGFkZHJlc3Mgd2lsbCBub3QgYmUgYWJsZSB0bw0KPiA+ IGRvIGEgc3RhdGVsZXNzIGNvbmZpZ3VyYXRpb24uDQo+ID4gU2F5LCBhIHNlbnNvciBzZWxmLWNv bmZpZ3VyZXMgVUxBIGFkZHJlc3MgYW5kIG5lZWRzIHRvIGdldCBvdGhlcg0KPiA+IGluZm9ybWF0 aW9uIGZyb20gREhDUHY2IHNlcnZlci4gSW4gdGhpcyBzY2VuYXJpbywgc3RhdGVmdWwgREhDUHY2 DQo+ID4gbWlnaHQgYmUgdG9vIGhlYXZ5IGZvciB0aGUgc3lzdGVtLg0KPiANCj4gVG8gY2xhcmlm eSAtIHlvdSBtZWFuIGxpbmstbG9jYWwgYWRkcmVzc2VzLCByYXRoZXIgdGhhbiBVTEFzLCByaWdo dCA/DQo+IChzaW5jZSB0byBjb25maWd1cmUgVUxBcywgdGhlIGhvc3Qgd291bGQgc29tZWhvdyBu ZWVkIHRvIGtub3cgdGhlIHByZWZpeA0KPiBiZWluZyBzZXJ2aWNlZCBieSB0aGUgcm91dGVyLCB3 aGljaCBzb3VuZHMgYXdmdWxseSBjbG9zZSB0byBhdXRvY29uZiB0byBtZSkNCltCaW5nXSBMaW5r LWxvY2FsIGlzIGFsc28gYSB1c2UgY2FzZSwgYnV0IEkgYWxzbyBtZWFudCBVTEEgY2FzZSwgc2lu Y2Ugb2ZmbGluZSBjb21tdW5pY2F0aW9uIG1pZ2h0IGFsc28gbmVlZGVkLg0KQW5kIHRoZSBVTEFz IGNvdWxkIGJlIHNlbGYtZ2VuZXJhdGVkIGluc3RhbnRseSBvciBidXJudCBpbiB0aGUgZGV2aWNl IGluIGFkdmFuY2UuDQoNCj4gSWYgd2Ugc3BlYWsgYWJvdXQgYSBzcGVjaWFsaXplZCBlbnZpcm9u bWVudHMgbGlrZSBzZW5zb3JzLCB0aGV5IHByb2JhYmx5IHdpbGwNCj4gdHJ5IHRoZSBzdGF0ZWxl c3MgREhDUHY2IHJlZ2FyZGxlc3Mgb2YgdGhlIGZsYWdzIGluIFJBLCBzaW5jZSB0aGF0IHdpbGwg YmUgdGhlaXINCj4gb25seSB3YXkgdG8gY29uZmlndXJlIHRoZW1zZWx2ZXMsIHdoYXQgZG8geW91 IHRoaW5rID8NCltCaW5nXSBJJ20gbm90IHN1cmUgd2hldGhlciBhbHdheXMgdHJ5aW5nIHN0YXRl bGVzcyBESENQdjYgaXMgYSBnb29kIGJlaGF2aW9yIG9yIG5vdC4gTWF5YmUgdGhleSBkb24ndCBu ZWVkIGV4dHJhIGluZm9ybWF0aW9uIGZyb20gREhDUHY2LCBvciBtYXliZSBSQXMgYXJlIGVub3Vn aC4NClRoZSBwb2ludCBoZXJlIGlzLCBpZiBJIGdvdCBhbiBhZGRyZXNzIHdpdGhvdXQgU0xBQUMv REhDUHY2LCBjYW4gSSBzdGlsbCBkZWNpZGUgd2hldGhlciB0byBpbml0aWFsIHN0YXRlbGVzcyBE SENQdjYgYWNjb3JkaW5nIHRvIHRoZSBvbmx5IE8gZmxhZz8NCg0KQmVzdCByZWdhcmRzLA0KQmlu Zw0KIA0KPiBUaGUgdXNlLWNhc2UgSSB3YXMgYWZ0ZXIgd2FzIHNvbWV0aGluZyBpbnZvbHZpbmcg dGhlIGNvbW1vbiBvZmYgdGhlIHNoZWxmDQo+IE9TZXMsIGkuZS4gdGhlIHBhcnQgb2YgdGhlICJl dmVyeSBkYXkgbmV0d29yayBhZG1pbmlzdHJhdGlvbiINCj4gdGhlbWUgb2YgdGhlIGRvY3VtZW50 Lg0KPiANCj4gPg0KDQo= From nobody Tue Oct 28 07:30:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0411A8965 for ; Tue, 28 Oct 2014 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdTDz2V2hqBO for ; Tue, 28 Oct 2014 07:30:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCB51A896C for ; Tue, 28 Oct 2014 07:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3181; q=dns/txt; s=iport; t=1414506601; x=1415716201; h=from:to:subject:date:message-id:references:mime-version; bh=9f/foyojXMCoGoCX53/nKYY3Sspmv7LzhXYdcbhvHds=; b=imvSWWG2taJ7CgmTG9bZ55r/8FFrZDLAIVgHOvreIjxbYEhEG9JmUP1C xALoTRapfEqGwT/uLkdaCCq+LDho2wvA+OPH8UDHwudMKM+5A8ufi3Y9D JWXn7Ie6L9hlT4qVaYe1KcWooDl5MP5UPWZZwABzCRtK692IqMytErsbg Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAMmnT1StJA2M/2dsb2JhbABcgw5UWATOMAyHS4EcFgF9hAIBAQEDAQEBAWsQCwIBGQMBAi8nCxQHAggCBBMJBYgqCQ3JWgEBAQEBAQQBAQEBAQEBG5A/OBMLgjBTJIEeBZIHghCBUGiHEoExPIMNilqGWoN4bAGBBkGBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,802,1406592000"; d="asc'?scan'208";a="367151147" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 28 Oct 2014 14:30:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9SEU0vR022546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Oct 2014 14:30:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 09:29:59 -0500 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt Thread-Index: AQHP8iARH2EEXUPMqkm2esltgUSvnQ== Date: Tue, 28 Oct 2014 14:29:59 +0000 Message-ID: <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_9C349D3E-76E4-4005-8EF3-76C1B8748E3E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ohBbLM9SC67VgTUSO_iuQbBpmBQ Subject: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:30:04 -0000 --Apple-Mail=_9C349D3E-76E4-4005-8EF3-76C1B8748E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would be interested in folks=92 view of this. Is this interesting? Begin forwarded message: > From: > Subject: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt > Date: October 27, 2014 at 12:55:22 PM PDT > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Happy Eyeballs Considerations for HTTP State = Management Mechanisms > Author : Eric Vyncke > Filename : = draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt > Pages : 5 > Date : 2014-10-27 >=20 > Abstract: > HTTP servers usually save session states in their persistent storage > indexed by session cookies generated by the HTTP servers. It is up > to the HTTP user-agent to send this session cookie on each HTTP > request. Some HTTP servers check whether the cookie is associated > with the HTTP user-agent by the means of the user-agent IP = address... >=20 > If the Happy Eyeball mechanism is used to select between IPv6 and > IPv4, it may happen that while using the same HTTP server, some HTTP > requests are done over IPv6 and the others over IPv4, which leads to > two different sets of session states in the HTTP server. This has > the consequence of inconsistencies at the HTTP server. >=20 > The only purpose of this document is to document this issue. >=20 > A similar problem arises with the use of non RFC 6888 compliant = Large > Scale NAT (LSN) devices used to access an IPv4-only HTTP server. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-vyncke-v6ops-happy-eyeballs-cookie/= >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_9C349D3E-76E4-4005-8EF3-76C1B8748E3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUT6hgbjEdbHIsm0MRAhtpAJ9jGmxAlPoslnfLeI+qsGIh9bF97ACeL7P3 MwkE5GHK+kDj6P/pzxHIFGg= =jhrf -----END PGP SIGNATURE----- --Apple-Mail=_9C349D3E-76E4-4005-8EF3-76C1B8748E3E-- From nobody Tue Oct 28 07:45:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124CB1A89C4 for ; Tue, 28 Oct 2014 07:45:23 -0700 (PDT) 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=[BAYES_20=-0.001, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUX9KoFbYkwQ for ; Tue, 28 Oct 2014 07:45:20 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6902E1A8A03 for ; Tue, 28 Oct 2014 07:45:20 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0135125D37C3; Tue, 28 Oct 2014 14:45:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 04EE4C7706E; Tue, 28 Oct 2014 14:45:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4U2bUd3leb5D; Tue, 28 Oct 2014 14:45:15 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6E7DEC77042; Tue, 28 Oct 2014 14:45:13 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Bjoern A. Zeeb" In-Reply-To: <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> Date: Tue, 28 Oct 2014 14:45:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8B7E9BED-0032-46BF-9F4A-89008E8FC97D@lists.zabbadoz.net> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vxvJJNqFOa4SFVoVJQa6ZD9YQmo Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:45:23 -0000 On 28 Oct 2014, at 14:29 , Fred Baker (fred) wrote: > I would be interested in folks=92 view of this. Is this interesting? Everything that makes crappy eyeballs more complicated and complex is a = waste of time and trying to optimise for these kinds of client decisions = on a server is a bad idea. Everything that tries to track the user state by IP at upper layers = should have gone away with the boom in 2001 as well. For the sake of Section 5 I like this. /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From nobody Tue Oct 28 07:46:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FFD1A89C4 for ; Tue, 28 Oct 2014 07:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxxFXarMQDm4 for ; Tue, 28 Oct 2014 07:46:08 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B761A89FB for ; Tue, 28 Oct 2014 07:46:08 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id gf13so762470lab.17 for ; Tue, 28 Oct 2014 07:46:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XZPaUR2Wtw0e3IDzTwHW2EyqBCX54CbH4n2tC7lFePQ=; b=Uu5+7B7uMQnaBEG8esgHUS9y+cjt7j0yI6T6fuUTKBnHAnXxqI7JA9t2+mbZ/Wyq/I jhzm1R8jSBW35RVA/Ptfi5DWbws3/aH6Hm29XjFm/ZOBHJh8OCP3RzHbAlrLVSCpSXgH XMLBkGVJWAMySO4P+5H9MOXzq1f2phoa5nh4fm0gn5woylBjXwsPYpHdbZe4XilEx0CX ELeDPsIQh9LmZPhu8B0G/zRcBmBUHvKXtl8YwhMyH14hB7ajyVoSXEeHJHNa5pxiDl+R /pf07tcBz//WgIcJzAfcKCt6SAFbVyedaKmH1ftWiNVMSR8o89YpgUKJyWfxz+Qj45aj 2ABw== X-Gm-Message-State: ALoCoQlRYpNo9IkH1t8EHGT6WpdX3HUX9mtUfVROJNyGLzynSRpO8SQFk0xYBbim/Px+mHQ3GQBG MIME-Version: 1.0 X-Received: by 10.152.9.201 with SMTP id c9mr4542499lab.38.1414507566355; Tue, 28 Oct 2014 07:46:06 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Tue, 28 Oct 2014 07:46:06 -0700 (PDT) In-Reply-To: <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> Date: Tue, 28 Oct 2014 10:46:06 -0400 Message-ID: From: Simon Perreault To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a1132f75e066dbf05067cb51d Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KN4pCI-fxOypBVZADgIcnvprYpY Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 14:46:12 -0000 --001a1132f75e066dbf05067cb51d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) wrote: > I would be interested in folks=E2=80=99 view of this. Is this interesting= ? Kind of. There are a lot of web apps that tie session cookies to IP addresses. In my day-to-day life the top offender is Bugzilla. You can still see the infamous checkbox here: https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=3D1 "[X] Restrict this session to this IP address (*using this option improves security*)" (emphasis mine) Many open source projects use Bugzilla. If this draft's only accomplishment is making this checkbox disappear, then IMHO it will have been a huge success. ;) One improvement to the draft could be to justify why what it suggests (i.e., not tying sessions to IP addresses) does not lower security. You have to convince technical people to remove a feature that was up to now advertised as "improving security". This can be a hard sell. Simon --001a1132f75e066dbf05067cb51d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) <<= a href=3D"mailto:fred@cisco.com" target=3D"_blank">fred@cisco.com> wrote:
I would be interested in folks=E2=80=99 vi= ew of this. Is this interesting?

Kind of.

There are a lot o= f web apps that tie session cookies to IP addresses. In my day-to-day life = the top offender is Bugzilla. You can still see the infamous checkbox here:=

https://b= ugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=3D1

"[X] Restrict th= is session to this IP address (using this option improves security)&= quot; (emphasis mine)

Many open source projects use Bugzilla. If this draft'= s only accomplishment is making this checkbox disappear, then IMHO it will = have been a huge success. ;)

One improvement to the draft could be to justify why= what it suggests (i.e., not tying sessions to IP addresses) does not lower= security. You have to convince technical people to remove a feature that w= as up to now advertised as "improving security". This can be a ha= rd sell.

Simon
--001a1132f75e066dbf05067cb51d-- From nobody Tue Oct 28 13:19:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8291ACEE5 for ; Tue, 28 Oct 2014 13:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkSePoipZsQP for ; Tue, 28 Oct 2014 13:19:33 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542C51ACE62 for ; Tue, 28 Oct 2014 13:15:00 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9SKEtxr006816; Tue, 28 Oct 2014 20:14:56 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s9SKEtxr006816 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1414527296; bh=Qhq298pGov37QH12G3JuSCmLXqw=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=al4hCKVvapiY3Isz8mmMO0PBzRFgV9CBG8XJokghVOurNbUzzO6QFz+9Ft3/7m5NS kIZdI9gmFF3CmKS4ZCxK0pDFqwEBX3MTDjtgndjH7Tcy4kXfm7KgGV53NjmtArE3bD RWJ3ptse0Llxe7lw6wEvg3jMekr3ClfKaJkW1aAU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q9RKEy0763112083I5 ret-id none; Tue, 28 Oct 2014 20:14:56 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9SKE3mY030423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Oct 2014 20:14:05 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_FFD8C081-990C-4215-A36C-E80D894D3978" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: Date: Tue, 28 Oct 2014 20:14:03 +0000 Message-ID: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> To: Simon Perreault X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q9RKEs076311208300; tid=q9RKEy0763112083I5; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s9SKEtxr006816 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/h2_40IxSv9CtE_jG5m14Ddze9Qs Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:19:35 -0000 --Apple-Mail=_FFD8C081-990C-4215-A36C-E80D894D3978 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28 Oct 2014, at 14:46, Simon Perreault wrote: >=20 > On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) = wrote: > I would be interested in folks=92 view of this. Is this interesting? >=20 > Kind of. >=20 > There are a lot of web apps that tie session cookies to IP addresses. = In my day-to-day life the top offender is Bugzilla. You can still see = the infamous checkbox here: >=20 > https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=3D1 >=20 > "[X] Restrict this session to this IP address (using this option = improves security)" (emphasis mine) >=20 > Many open source projects use Bugzilla. If this draft's only = accomplishment is making this checkbox disappear, then IMHO it will have = been a huge success. ;) >=20 > One improvement to the draft could be to justify why what it suggests = (i.e., not tying sessions to IP addresses) does not lower security. You = have to convince technical people to remove a feature that was up to now = advertised as "improving security". This can be a hard sell. This would be a good outcome of this draft. There can be not dissimilar issues between visits to the same site when = the OS picks a different IP version per visit (as OSX is prone to do). Tim --Apple-Mail=_FFD8C081-990C-4215-A36C-E80D894D3978 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 28 = Oct 2014, at 14:46, Simon Perreault <sperreault@jive.com> = wrote:


On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker = (fred) <fred@cisco.com> wrote:
I would be interested in folks=92 view of = this. Is this interesting?

Kind of.

There are a = lot of web apps that tie session cookies to IP addresses. In my = day-to-day life the top offender is Bugzilla. You can still see the = infamous checkbox here:

https:= //bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=3D1

"[X] Restrict = this session to this IP address (using this option improves = security)" (emphasis mine)

Many open = source projects use Bugzilla. If this draft's only accomplishment is = making this checkbox disappear, then IMHO it will have been a huge = success. ;)

One improvement to the draft could be to justify = why what it suggests (i.e., not tying sessions to IP addresses) does not = lower security. You have to convince technical people to remove a = feature that was up to now advertised as "improving security". This can = be a hard sell.

This would be a = good outcome of this draft.

There can be not = dissimilar issues between visits to the same site when the OS picks a = different IP version per visit (as OSX is prone to = do).

Tim

= --Apple-Mail=_FFD8C081-990C-4215-A36C-E80D894D3978-- From nobody Tue Oct 28 13:48:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11EA1A8F4A; Tue, 28 Oct 2014 13:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CnM_0mkkvnA; Tue, 28 Oct 2014 13:47:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3FD1A8AE7; Tue, 28 Oct 2014 13:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=362; q=dns/txt; s=iport; t=1414529269; x=1415738869; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a5sguN7RrYNErVgLva73QrlidOcoSPlnFuSW6WB7lgs=; b=JIx7ER0E9rjRN0eTXB3/epoCKl9n8zkkY20FvH9TE3VxNcl7/KRG1Vlm 5qcV3AZeSDmxwIjFIiC5KjkTVHQ73hmwxRXyyOL2BqzoE1BpjAG10Hw64 9X3aSFjLCOeljvjqUAohep3VOQRniXgeTSh5xx2/OTQNauwJeWkqueyhf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAB0AUFStJV2T/2dsb2JhbABcgw5UWATOQYdNAoEhFgEBAQEBfYQDAQEEOj8QAgEINhAyJQIEAQ0FiEENxw4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBJEJB4RLAQSPbYIehEqHE5Y2g3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,804,1406592000"; d="scan'208";a="367224062" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP; 28 Oct 2014 20:47:48 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9SKlmCH001164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 20:47:48 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.162]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 15:47:48 -0500 From: "Alvaro Retana (aretana)" To: Owen DeLong , Iljitsch van Beijnum Thread-Topic: [v6ops] I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt Thread-Index: AQHP8vBu3ZdQMvNUnkC4PgcWIAV3bg== Date: Tue, 28 Oct 2014 20:47:47 +0000 Message-ID: References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.209.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <10E658C88BA7014FA66A90FD1D7FDB03@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tEgBBsxfiKWU9VFM1TgpkscBx8g Cc: "grow@ietf.org grow@ietf.org" , IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:47:51 -0000 On 10/27/14, 7:20 PM, "Owen DeLong" wrote: >What would be nice would be to have a BGP knob from vendors that could be >set on a per-peer basis (or per peer-group basis) that allowed us to >discard covered specifics with identical attributes on ingress. https://tools.ietf.org/html/draft-white-grow-overlapping-routes :-) Alvaro. From nobody Tue Oct 28 14:07:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BAF1ACF98 for ; Tue, 28 Oct 2014 14:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym7UyLLAdBkQ for ; Tue, 28 Oct 2014 14:07:24 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211221ACFA3 for ; Tue, 28 Oct 2014 14:07:19 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hy10so853378vcb.26 for ; Tue, 28 Oct 2014 14:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c4TjLvJq3S8xtOtc/utE6TE0JyMBASS5Vmhbm1JTBxc=; b=NEra2T5saYwGMefnCvX93UyfREzlMXq9qldbJSG8j5AllpLprMXtImuM3KSx5FDjSQ jyJ269X8OxftS9kjevpnZmj1LDGKVnIR6Y7Hn8fKLusIzBc9SctNwtfX9NMZE001BUk3 uA6SchPqGdv0tUmby8U+0Wn2a0lA+UkHufRl50kOrU7Dd4yTGLsgHfEBdYa0rKXwmECb QtZ8BvG0MEmUDPph/8kVecqKttHZM0Vn+AVjA/r6nlifL12ZQFik031NpiF/e2xyyiaq W1Trjqs7cZWeBbgoPH9CCLYBbDLngmeJStsK5C6wEgwqK8e859Or5d9gTanuZPVnYb/1 3P9g== MIME-Version: 1.0 X-Received: by 10.52.127.130 with SMTP id ng2mr3116003vdb.29.1414530438204; Tue, 28 Oct 2014 14:07:18 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.190.71 with HTTP; Tue, 28 Oct 2014 14:07:18 -0700 (PDT) In-Reply-To: <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> Date: Tue, 28 Oct 2014 17:07:18 -0400 X-Google-Sender-Auth: JNGuaPj6pGEyAgFD-nGIf_OoYbs Message-ID: From: Erik Nygren To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=bcaec52bee614b176005068208c8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ighevURc8Qe2PARQX4RRyb8Omak Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:07:25 -0000 --bcaec52bee614b176005068208c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) wrote: > I would be interested in folks=E2=80=99 view of this. Is this interesting= ? > This is mentioned in section 8.2 of rfc6883 but keeps coming up over and over again so may be worth calling out more clearly. I'd title it in some way that didn't make it seem like a happy eyeball specific issue. It's not just a happy eyeballs issue. It also happens with dual-stack environments where cookies or session or authentication tokens span origins where some servers are dual-stack and some are IPv4-only. (For example, an auth granting service grants bearer tokens locked to the client IP address and then the client connects to some other service on a different hostname and passes along the tokens. Even absent Happy Eyeballs these can be on different IP versions.) The large-scale NAT/CGN issue does make this not just an IPv6 issue. At least some systems I've seen then check the IP in the cookie to make sure it's in the same /24 rather than the exact same IP, but that doesn't help in the dual-stack world. Another issue beyond Happy Eyeballs is that privacy addressing bites you here as well for cookies that are used across different TCP connections spanning a privacy address rotation. Having some more clear "don't do this" to point people to would be good, but I suspect we'll have many years of cleaning up applications doing this. --bcaec52bee614b176005068208c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) <fred@cisco.com> wrote:
I would be in= terested in folks=E2=80=99 view of this. Is this interesting?

This is mentioned in section 8.2 of rfc6883 but keep= s coming up over and over again
so may be worth calling out m= ore clearly.=C2=A0 I'd title it in some way that didn't make it see= m like
a happy eyeball specific issue.

It's not just a happy = eyeballs issue.=C2=A0 It also happens with dual-stack environments where co= okies or session or authentication tokens span origins where some servers a= re dual-stack and some are IPv4-only.=C2=A0=C2=A0 (For example, an auth gra= nting service grants bearer tokens locked to the client IP address and then= the client connects to some other service on a different hostname and pass= es along the tokens.=C2=A0 Even absent Happy Eyeballs these can be on diffe= rent IP versions.)

The large-scale NAT/CGN issue does make this not = just an IPv6 issue.=C2=A0 At least some systems I've seen then check th= e IP in the cookie to make sure it's in the same /24 rather than the ex= act same IP, but that doesn't help in the dual-stack world.

Another issue beyond Happy Eyeballs is that privacy addressing bites you = here as well for cookies that are used across different TCP connections spa= nning a privacy address rotation.

<= div>Having some more clear "don't do this" to point people to= would be good, but I suspect we'll have many years of cleaning up appl= ications doing this.
--bcaec52bee614b176005068208c8-- From nobody Tue Oct 28 14:19:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C28B1ACF66 for ; Tue, 28 Oct 2014 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTco_jpYq6uc for ; Tue, 28 Oct 2014 14:19:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3711A19EC for ; Tue, 28 Oct 2014 14:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6349; q=dns/txt; s=iport; t=1414531152; x=1415740752; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8XfDGaPC1kGEP1Vy0Jb1HhFKetqOBi9kaSIifvpffYc=; b=BbU3Ir9knOw5od1k+Z75Sf0ARQfSdKhBL4a68vDag9cV1Ria7f0SZJA0 +oLouwPM4fFyDTYftBNRrKuqtMl+Pk7NjUA2nsqfZBZtIsHsN+P0LqKxr ywrvVUFP7bR1ur+mZHYqBVPZwJuVMEPLg4/dM/SeJtE6/gqwGpvAGZQF/ Y=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFsHUFStJA2L/2dsb2JhbABUCIMOgSwE1g8CgSIWAQEBAQF9hAIBAQEDAXkFCwIBCAQULjIlAgQOBQ6IKgnGbAEBAQEBAQEBAQEBAQEBAQEBAQEBAReQM1YHgy2BHgWSC4ISgVCHe5Y2g3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,805,1406592000"; d="asc'?scan'208,217";a="364160340" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP; 28 Oct 2014 21:19:11 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9SLJBZM009537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 21:19:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 16:19:11 -0500 From: "Fred Baker (fred)" To: Erik Nygren Thread-Topic: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt Thread-Index: AQHP8iARH2EEXUPMqkm2esltgUSvnQ== Date: Tue, 28 Oct 2014 21:19:10 +0000 Message-ID: <71D94EF2-2740-4BC8-BA1D-40A667A9BD8E@cisco.com> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_D5C14AA1-5161-4256-B4DF-9E42FEBEE87A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9pSEVn4-UO2WJJv2BLQY_m0POns Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:19:15 -0000 --Apple-Mail=_D5C14AA1-5161-4256-B4DF-9E42FEBEE87A Content-Type: multipart/alternative; boundary="Apple-Mail=_0A0D0506-06C8-465E-88C4-1C325852FF35" --Apple-Mail=_0A0D0506-06C8-465E-88C4-1C325852FF35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 28, 2014, at 2:07 PM, Erik Nygren wrote: > On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) = wrote: > I would be interested in folks=92 view of this. Is this interesting? >=20 > This is mentioned in section 8.2 of rfc6883 but keeps coming up over = and over again > so may be worth calling out more clearly. I'd title it in some way = that didn't make it seem like > a happy eyeball specific issue. >=20 > It's not just a happy eyeballs issue. It also happens with dual-stack = environments where cookies or session or authentication tokens span = origins where some servers are dual-stack and some are IPv4-only. (For = example, an auth granting service grants bearer tokens locked to the = client IP address and then the client connects to some other service on = a different hostname and passes along the tokens. Even absent Happy = Eyeballs these can be on different IP versions.) An important thing, in my mind, is that Happy Eyeballs isn=92t = fundamentally about IPv4 and IPv6, it=92s about multihoming, which is to = say that I have more than one address and more than one route, and it is = conceivable that one or more of my addresses or routes doesn=92t work. = If I am multihomed in the sense of having multiple IPv4 paths, I can = have the same problems, and I can have the same problems if I am = IPv6-only but have multiple upstreams. > The large-scale NAT/CGN issue does make this not just an IPv6 issue. = At least some systems I've seen then check the IP in the cookie to make = sure it's in the same /24 rather than the exact same IP, but that = doesn't help in the dual-stack world. >=20 > Another issue beyond Happy Eyeballs is that privacy addressing bites = you here as well for cookies that are used across different TCP = connections spanning a privacy address rotation. >=20 > Having some more clear "don't do this" to point people to would be = good, but I suspect we'll have many years of cleaning up applications = doing this. --Apple-Mail=_0A0D0506-06C8-465E-88C4-1C325852FF35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 28, 2014, at 2:07 PM, Erik = Nygren <erik+ietf@nygren.org> = wrote:

On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker = (fred) <fred@cisco.com> wrote:
I would be interested in folks=92= view of this. Is this = interesting?

This is mentioned in = section 8.2 of rfc6883 but keeps coming up over and over = again
so may be worth calling out more clearly.  I'd = title it in some way that didn't make it seem like
a happy eyeball = specific issue.

It's not just a happy eyeballs issue.  It = also happens with dual-stack environments where cookies or session or = authentication tokens span origins where some servers are dual-stack and = some are IPv4-only.   (For example, an auth granting service = grants bearer tokens locked to the client IP address and then the client = connects to some other service on a different hostname and passes along = the tokens.  Even absent Happy Eyeballs these can be on different = IP versions.)

An important thing, in my = mind, is that Happy Eyeballs isn=92t fundamentally about IPv4 and IPv6, = it=92s about multihoming, which is to say that I have more than one = address and more than one route, and it is conceivable that one or more = of my addresses or routes doesn=92t work. If I am multihomed in the = sense of having multiple IPv4 paths, I can have the same problems, and I = can have the same problems if I am IPv6-only but have multiple = upstreams.

The large-scale NAT/CGN issue does make this = not just an IPv6 issue.  At least some systems I've seen then check = the IP in the cookie to make sure it's in the same /24 rather than the = exact same IP, but that doesn't help in the dual-stack = world.

Another issue beyond Happy Eyeballs is that privacy = addressing bites you here as well for cookies that are used across = different TCP connections spanning a privacy address = rotation.

Having some more clear = "don't do this" to point people to would be good, but I suspect we'll = have many years of cleaning up applications doing = this.

= --Apple-Mail=_0A0D0506-06C8-465E-88C4-1C325852FF35-- --Apple-Mail=_D5C14AA1-5161-4256-B4DF-9E42FEBEE87A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD4DBQFUUAhKbjEdbHIsm0MRAi8BAKDSGWhR9Ktwd7Z243bZk7jGHnmulQCWJ4Cg 86TjN4Ex48bVDamP4xwviw== =bWzB -----END PGP SIGNATURE----- --Apple-Mail=_D5C14AA1-5161-4256-B4DF-9E42FEBEE87A-- From nobody Tue Oct 28 17:29:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA91A1AA4; Tue, 28 Oct 2014 17:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq-jAUmYqUBr; Tue, 28 Oct 2014 17:29:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57201A1A29; Tue, 28 Oct 2014 17:29:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1XjH8U-0007SB-Fw; Wed, 29 Oct 2014 00:29:14 +0000 Date: Wed, 29 Oct 2014 09:29:13 +0900 Message-ID: From: Randy Bush To: Alvaro Retana In-Reply-To: References: <20141022203344.29294.49897.idtracker@ietfa.amsl.com> <1414354639.42283.YahooMailNeo@web162201.mail.bf1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/p-G8oK-kAnQvTJ9OAFzInUkhxbA Cc: GROW List , IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-van-beijnum-grow-controlled-deagg-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 00:29:18 -0000 >> What would be nice would be to have a BGP knob from vendors that could be >> set on a per-peer basis (or per peer-group basis) that allowed us to >> discard covered specifics with identical attributes on ingress. >=20 > https://tools.ietf.org/html/draft-white-grow-overlapping-routes >=20 > :-) DRAGON: Distributed Route Aggregation on the Global Network. Jo=E3o Lu=EDs Sobrinho, Laurent Vanbever, Franck Le, Jennifer Rexford.=09 ACM CoNEXT 2014. Sydney, Australia (December 2014). http://vanbever.eu/pdfs/vanbever_dragon_conext_2014.pdf :) randy From nobody Tue Oct 28 19:29:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B361A6EDC for ; Tue, 28 Oct 2014 19:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kBy35cEweKR for ; Tue, 28 Oct 2014 19:29:30 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9654E1A1BF0 for ; Tue, 28 Oct 2014 19:29:30 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 121B620835 for ; Tue, 28 Oct 2014 22:29:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 28 Oct 2014 22:29:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=UAue/rmO6ci6EGVzchBtOt wdJGY=; b=a8sTsN8QXpUH+kEX6O1OntI/G9RvaRipB5XQl7uFjZkFwZQF0oAeZF Dwl8OQvmaMXyeRos8mcCjyD6ovEoDwyQsyg0WuYRiZA5br6KDJyeJ9B1LKe4NrNh iBlWckgrpOoliKEnrEScBBxUvZ1nVgUTS4+rzRg22/w1e+0bxMvBA= X-Sasl-enc: ndexn8qb/59QTpa94jWXqRCwjboIivP3pBX759QapjCo 1414549769 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id A4B46C00008; Tue, 28 Oct 2014 22:29:29 -0400 (EDT) Message-ID: <545050FE.8020807@network-heretics.com> Date: Tue, 28 Oct 2014 22:29:18 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> In-Reply-To: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xF1JpBz7LsquXMK76Zdm2wdrlDs Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 02:29:32 -0000 I must continue to object to this document and protocol action as long as native v6 support is not widely available. The other problem that I have with this document is that it (still) blames 6to4 for failures caused by widespread poor practice in router configuration. If an IP network fails to forward protocol 41 packets, it's the network that's broken, not the use of protocol 41. I do not see the need for this document or protocol action, as the recommended behavior of disabling 6to4 by default is already sufficient to keep users from being accidentally burned by hosts or applications using 6to4 paths in preference to IPv4 paths. Keith On 10/21/2014 02:38 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4) > Authors : Ole Troan > Brian Carpenter > Filename : draft-ietf-v6ops-6to4-to-historic-06.txt > Pages : 7 > Date : 2014-10-20 > > Abstract: > Experience with the "Connection of IPv6 Domains via IPv4 Clouds > (6to4)" IPv6 transition mechanism has shown that the mechanism is > unsuitable for widespread deployment and use in the Internet. This > document requests that RFC3056 and the companion document "An Anycast > Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved to > historic status. It also recommends that future products should not > support 6to4 and that existing deployments should be reviewed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 28 19:36:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2548D1A6EFC for ; Tue, 28 Oct 2014 19:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Euy4DmKSqf2 for ; Tue, 28 Oct 2014 19:36:17 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389C61A3BA7 for ; Tue, 28 Oct 2014 19:36:17 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id a13so450382igq.17 for ; Tue, 28 Oct 2014 19:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/aAXw+h2pBzpzITtihhslneASxGZXVX2O90LTxlr+IA=; b=n9MxJMYeM1W79q19g6RIFge+P2UxHH/Olf0rpFD6qa+EP376qr3vXr18FoK8tUPmdN iwojp/WuGnKO7xuRMNy2Km6ghSjuiCirMy5yImvhATNOS+lsJYCzAXi9ttd5MiVkV04G J13WPLR+y8xD3KFY+7qgLjA2gTc3YGTyAKvyL3WW724ZKHLWkkNWY/d/O2/L/MXd/tZ2 IS5iK4vAw0tHMqq/rTfIrWw0tk1xEOYY0/OSgMFmtbpC+rk2oGq9/fH9eaD/CN884EBR v7HpMNHsnD8VJEGOyuBY+t4Cu65U0WTeFCu3U4cZPf0CEyG0rVAvx60gowRJcN6UnzBz V2oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/aAXw+h2pBzpzITtihhslneASxGZXVX2O90LTxlr+IA=; b=L3oxwGz7NvwyLmHV3AMleQBoNVhaRHF1My/8gtmKzwDFGNTNZcUrObhcAUzoxuwHjb g1eBi5GoXjjN5zGAlyl+DATX3MCoUvYdbZ03jceiGL7SH4WUoM88WMmnWJ6a1wzhWz/5 /BqsiqCvRfNoHaqaW7eSqvho1BNy76crp6Zc9eXPKMNSvieegI0XS/R6Vms4sDGTSIfe iRoTYp2MJcUmecU04wOzFj2GUqmt5rZPy3CDdPm89/ERQwyiCaz7p2EENK1TaIcfO0aA q73dB87by5EXkiRjLokMtNe5jIV/O7/uIeU9LtG7Kw1fujqyaWL8aYBXWBxJTPCkeAXG 4eCQ== X-Gm-Message-State: ALoCoQkzXB2GFdDSNEFdUdgOYy9lnoZNnC0vK2IVeIRcZ8ts9RC11WLqoh6Bz30Lmrpe9Hyb+8p+ X-Received: by 10.42.37.15 with SMTP id w15mr7103115icd.20.1414550176413; Tue, 28 Oct 2014 19:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.176.203 with HTTP; Tue, 28 Oct 2014 19:35:56 -0700 (PDT) In-Reply-To: <545050FE.8020807@network-heretics.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> From: Lorenzo Colitti Date: Wed, 29 Oct 2014 11:35:56 +0900 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=90e6ba613938c86e43050686a037 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/guBDmReS3hHP0wOHNkYLOPkKzbQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 02:36:19 -0000 --90e6ba613938c86e43050686a037 Content-Type: text/plain; charset=UTF-8 Keith, would you still object if this document were amended so it only declares RFC 3068 (the 6to4 relay router) historic? The way I see it, RFC 3068 proposes a model which operational experience has shown to be slow and unreliable, because it relies on the "kindness of whatever stranger BGP has selected" to route packets between 6to4 addresses and native addresses. Cheers, Lorenzo On Wed, Oct 29, 2014 at 11:29 AM, Keith Moore wrote: > I must continue to object to this document and protocol action as long as > native v6 support is not widely available. > > The other problem that I have with this document is that it (still) blames > 6to4 for failures caused by widespread poor practice in router > configuration. > > If an IP network fails to forward protocol 41 packets, it's the network > that's broken, not the use of protocol 41. > > I do not see the need for this document or protocol action, as the > recommended behavior of disabling 6to4 by default is already sufficient to > keep users from being accidentally burned by hosts or applications using > 6to4 paths in preference to IPv4 paths. > > Keith > > > On 10/21/2014 02:38 AM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >> >> Title : Deprecating Connection of IPv6 Domains via >> IPv4 Clouds (6to4) >> Authors : Ole Troan >> Brian Carpenter >> Filename : draft-ietf-v6ops-6to4-to-historic-06.txt >> Pages : 7 >> Date : 2014-10-20 >> >> Abstract: >> Experience with the "Connection of IPv6 Domains via IPv4 Clouds >> (6to4)" IPv6 transition mechanism has shown that the mechanism is >> unsuitable for widespread deployment and use in the Internet. This >> document requests that RFC3056 and the companion document "An Anycast >> Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved to >> historic status. It also recommends that future products should not >> support 6to4 and that existing deployments should be reviewed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-06 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --90e6ba613938c86e43050686a037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Keith,

would you still object if this d= ocument were amended so it only declares RFC 3068 (the 6to4 relay router) h= istoric?

The way I see it, RFC 3068 proposes a mod= el which operational experience has shown to be slow and unreliable, becaus= e it relies on the "kindness of whatever stranger BGP has selected&quo= t; to route packets between 6to4 addresses and native addresses.
=
Cheers,
Lorenzo

On Wed, Oct 29, 2014 at 11:29 AM, Keith = Moore <moore@network-heretics.com> wrote:
I must continue to object to this document and pro= tocol action as long as native v6 support is not widely available.

The other problem that I have with this document is that it (still) blames = 6to4 for failures caused by widespread poor practice in router configuratio= n.

If an IP network fails to forward protocol 41 packets, it's the network= that's broken, not the use of protocol 41.

I do not see the need for this document or protocol action, as the recommen= ded behavior of disabling 6to4 by default is already sufficient to keep use= rs from being accidentally burned by hosts or applications using 6to4 paths= in preference to IPv4 paths.

Keith


On 10/21/2014 02:38 AM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0 This draft is a work item of the IPv6 Operations Working Group of th= e IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Ole Troan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Brian Carpenter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-6to4-to-historic-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-20

Abstract:
=C2=A0 =C2=A0 Experience with the "Connection of IPv6 Domains via IPv4= Clouds
=C2=A0 =C2=A0 (6to4)" IPv6 transition mechanism has shown that the mec= hanism is
=C2=A0 =C2=A0 unsuitable for widespread deployment and use in the Internet.= =C2=A0 This
=C2=A0 =C2=A0 document requests that RFC3056 and the companion document &qu= ot;An Anycast
=C2=A0 =C2=A0 Prefix for 6to4 Relay Routers" RFC3068 are made obsolete= and moved to
=C2=A0 =C2=A0 historic status.=C2=A0 It also recommends that future product= s should not
=C2=A0 =C2=A0 support 6to4 and that existing deployments should be reviewed= .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v= 6ops-6to4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-= to-historic-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-v6ops-6to4-to-historic-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

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

--90e6ba613938c86e43050686a037-- From nobody Tue Oct 28 19:46:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C401A1B00 for ; Tue, 28 Oct 2014 19:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdSKkccoN31f for ; Tue, 28 Oct 2014 19:46:01 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC7F1A0373 for ; Tue, 28 Oct 2014 19:46:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6E25E20BCF for ; Tue, 28 Oct 2014 22:46:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 28 Oct 2014 22:46:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=3iuels9xpbmqRfZSbG4wL1 qmrKk=; b=dolnGJ2smBnt+KIlBpaHu7RZClCCo+1X9mNKJEg0cUdDa0nOHBABZM j1M1gS9YIZOGnXtuULqv+nAv+eWOtf0XZpVL/Re6pgTvXiRo6OTHsYwSVT84jfYn jNH4fOLn8rkodQrK/LsoM+biKDXN4r/ikmJtPWIybeImD5IGfHnLs= X-Sasl-enc: kDTRte6htLlYeOY10EQMqLcPrC7GI6zpuTAZxg6CDgJd 1414550760 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id F1C78680125; Tue, 28 Oct 2014 22:45:59 -0400 (EDT) Message-ID: <545054DD.9020406@network-heretics.com> Date: Tue, 28 Oct 2014 22:45:49 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pS3zdBz-8vB5JeBHvrorW5r-21M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 02:46:02 -0000 On 10/28/2014 10:35 PM, Lorenzo Colitti wrote: > would you still object if this document were amended so it only > declares RFC 3068 (the 6to4 relay router) historic? I would certainly find that position more reasonable than the one taken by the current document. > The way I see it, RFC 3068 proposes a model which operational > experience has shown to be slow and unreliable, because it relies on > the "kindness of whatever stranger BGP has selected" to route packets > between 6to4 addresses and native addresses. I don't disagree with that characterization. Though as far as I've been able to tell the bigger problem is that a great many border routers are (mis?)configured to deny incoming protocol 41 traffic even if there's been outgoing protocol 41 traffic to the same IPv4 destination. (the increased difficulty of filtering 6to4 traffic based on actual source/destination addresses might also be part of the reason for that) Keith p.s. Aside from the potential of this proposal to break things for people who are currently successfully using 6to4 and who do not yet have a native v6 alternative available, other things that bug me rather strongly about this document are its implicit position(s) that (a) IP-in-IP tunneling is something you shouldn't expect to work and therefore shouldn't be doing and (b) you shouldn't be using tunneling to bypass your ISPs routing. I am emphatically opposed to both of those positions and feel that this document takes a really carrier-centric (and customer-hostile) view that is not appropriate for IETF to be taking. From nobody Tue Oct 28 20:30:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B884D1A6F17 for ; Tue, 28 Oct 2014 20:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3jdGhAf6FQw for ; Tue, 28 Oct 2014 20:30:11 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D961A6EE0 for ; Tue, 28 Oct 2014 20:30:11 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id r10so2110249pdi.3 for ; Tue, 28 Oct 2014 20:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6mSDtKMYJKlumd26AFl6ldRQfrws2SXbq3LBi2eWRRs=; b=ZXc7RP4p6saN6OlXfhBTcoKFVP+/AYNbNinIuEEoKqIeEINjIAM2A/T0TwP54PgD7z VlLhez+DY7fjlrUQPpqM2AlVvV3XcFkg3oP19QZ/XSAGTv1T02wQDw18fnEzF6wLgPrd lk7TpM4+1TVdR9Vmd/ZYBSVF1ePlzDIECKx+qn2Dmp6WRgt1oFmKL7j1tGvr4lw23oPG RoQ4ubvotvVFEVKym25XShEVAiaUHpTzfzi57j2BLPTKge42zCW41OFkKYyycb0gdpFl cAE6ifpZAzOgAjIOJBU/jbqAtutwsiVxkvIJld+d6CIcWk/Gx6UlqzObFwiFbPxJ+tnf j5NQ== X-Received: by 10.68.108.36 with SMTP id hh4mr7776048pbb.108.1414553411570; Tue, 28 Oct 2014 20:30:11 -0700 (PDT) Received: from [192.168.178.23] (162.194.69.111.dynamic.snap.net.nz. [111.69.194.162]) by mx.google.com with ESMTPSA id rg6sm2917731pdb.20.2014.10.28.20.30.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 20:30:10 -0700 (PDT) Message-ID: <54505F43.5020203@gmail.com> Date: Wed, 29 Oct 2014 16:30:11 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> In-Reply-To: <545054DD.9020406@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UO2RzCypRPrVUOxNIV3bmq2Y4NA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 03:30:13 -0000 On 29/10/2014 15:45, Keith Moore wrote: > On 10/28/2014 10:35 PM, Lorenzo Colitti wrote: >> would you still object if this document were amended so it only >> declares RFC 3068 (the 6to4 relay router) historic? > > I would certainly find that position more reasonable than the one taken > by the current document. >> The way I see it, RFC 3068 proposes a model which operational >> experience has shown to be slow and unreliable, because it relies on >> the "kindness of whatever stranger BGP has selected" to route packets >> between 6to4 addresses and native addresses. > > I don't disagree with that characterization. Though as far as I've been > able to tell the bigger problem is that a great many border routers are > (mis?)configured to deny incoming protocol 41 traffic even if there's > been outgoing protocol 41 traffic to the same IPv4 destination. As far as we know anything, we know that the guidance in RFC 6343 hasn't been widely applied (and it is quite complex). Border routers and firewalls are really out of anybody's control except site IT managers, and apparently they haven't read the RFC. Or maybe they have, and they want to block automatic tunnels. We also know (I just checked the numbers today) that anycast-based 6to4 traffic from Google's users is down to 0.2% of total IPv6 traffic (having been about 10% in 2011). Personally I have changed my mind. The progress on ISP-provided IPv6 has been significant, Teredo has basically vanished, and I don't see a case for paying the operational and trouble-shooting costs of 6to4 any more. The draft is constructed so that it doesn't affect current peer to peer usage; declaring an RFC historic doesn't change running code. The crucial point that *isn't* covered in the draft yet is recommendations about filtering the IPv4 and IPv6 prefixes, and I hope we'll be discussing that in HNL. (Keith, will you be there? For me it's only one island over so it turns out to be a convenient flight with only one hour's time change.) Brian > > (the increased difficulty of filtering 6to4 traffic based on actual > source/destination addresses might also be part of the reason for that) > > Keith > > p.s. Aside from the potential of this proposal to break things for > people who are currently successfully using 6to4 and who do not yet have > a native v6 alternative available, other things that bug me rather > strongly about this document are its implicit position(s) that (a) > IP-in-IP tunneling is something you shouldn't expect to work and > therefore shouldn't be doing and (b) you shouldn't be using tunneling to > bypass your ISPs routing. I am emphatically opposed to both of those > positions and feel that this document takes a really carrier-centric > (and customer-hostile) view that is not appropriate for IETF to be taking. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Oct 29 02:04:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8F1A6FF1 for ; Wed, 29 Oct 2014 02:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHSQtWWTvn_e for ; Wed, 29 Oct 2014 02:04:12 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4E81A0A6A for ; Wed, 29 Oct 2014 02:04:12 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 3C9F23D0B3; Wed, 29 Oct 2014 10:04:10 +0100 (CET) Date: Wed, 29 Oct 2014 10:04:10 +0100 (CET) Message-Id: <20141029.100410.96162224.he@uninett.no> To: moore@network-heretics.com From: Havard Eidnes In-Reply-To: <545050FE.8020807@network-heretics.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> X-Mailer: Mew version 6.5 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/F53a8oq5CfYdZg-BTyBKXakFYCM Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:04:15 -0000 > The other problem that I have with this document is that it (still) > blames 6to4 for failures caused by widespread poor practice in router= > configuration. > > If an IP network fails to forward protocol 41 packets, it's the > network that's broken, not the use of protocol 41. Well, like it or not, some people like to organization-centrally manage firewalls or packet filters as a first line of defense against malware spreading uncontrollably, or to protect the soft underbelly of internal hosts. I don't know any devices which are in widespread use and which allows such a filtering device to unwrap the outer encapsulation payload to be able to filter on the layer-3 or layer-4 information in the encapsulated packet. This leaves such managers with the choice of "pass IP protocol 41 unfiltered" or "don't allow IP protocol 41 to pass through". Given the risk of the former to expose internal systems to unfiltered access from the vast Internet, where not everyone's intentions are benign, it is quite understandable the choice most people make in this situation. Calling this out as "widespread poor practice" is IMHO a mis-characterization. I would perhaps rather call it a lack of attention to deployment considerations in the protocol design. So ... count my voice in support of this document and protocol action. Best regards, - H=E5vard From nobody Wed Oct 29 02:32:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F791A7004 for ; Wed, 29 Oct 2014 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qj8RWjLN_ek for ; Wed, 29 Oct 2014 02:32:24 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C7F1A6FFE for ; Wed, 29 Oct 2014 02:32:23 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6428C20968 for ; Wed, 29 Oct 2014 05:32:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 29 Oct 2014 05:32:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=2oHIBmzIjAXTsoctD/2WwW 1lx+4=; b=lIebD5TWWFYoJwFYpkHa2Uv9z0/Mr6qv4oOZZa9I6Auytq6ygAb5mt Tg8XZWo/wDxQRMu8F8XvDS3TZw/HT7mUFIhXelnIC7sKY/D5qZXw5vHisMjCa5Ch MVelnIqNXsG221fMVOjqQRaSgrOAyJT6BFKGJofAlrwjaAzuuW7GE= X-Sasl-enc: GiFWzZ9+xIq4SD9MWRoSapBNXbH6QstjHESY/ooXvVHu 1414575143 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id EFAAC6800A8; Wed, 29 Oct 2014 05:32:22 -0400 (EDT) Message-ID: <5450B41C.8090001@network-heretics.com> Date: Wed, 29 Oct 2014 05:32:12 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Havard Eidnes References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <20141029.100410.96162224.he@uninett.no> In-Reply-To: <20141029.100410.96162224.he@uninett.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1oC1g6i28LIgB3oU2UqWRYBvgVc Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:32:29 -0000 On 10/29/2014 05:04 AM, Havard Eidnes wrote: > Well, like it or not, some people like to organization-centrally > manage firewalls or packet filters as a first line of defense against > malware spreading uncontrollably, or to protect the soft underbelly of > internal hosts. I don't know any devices which are in widespread use > and which allows such a filtering device to unwrap the outer > encapsulation payload to be able to filter on the layer-3 or layer-4 > information in the encapsulated packet. This leaves such managers > with the choice of "pass IP protocol 41 unfiltered" or "don't allow IP > protocol 41 to pass through". Given the risk of the former to expose > internal systems to unfiltered access from the vast Internet, where > not everyone's intentions are benign, it is quite understandable the > choice most people make in this situation. Calling this out as > "widespread poor practice" is IMHO a mis-characterization. The fix, of course, would have been to either provide native v6 access if were available, or to set up a 6to4 router at the border and filter on the unencapsulated IPv6 traffic. In either of those cases host-to-host 6to4 would have been no longer needed or useful, and there would have been few problems with blocking 6to4 traffic between internal and external hosts. (And how many enterprise networks were still using public v4 addresses internally anyway?) So if you prefer, the "widespread poor practice" was ignoring the impending exhaustion of v4 address space, failing to make any plans to accommodate v6, and pretending that by simply blocking protocol 41 the need to transition to IPv6 would go away. Keith From nobody Wed Oct 29 05:24:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629941A00A9 for ; Wed, 29 Oct 2014 05:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9ZcWVffHWbM for ; Wed, 29 Oct 2014 05:24:56 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D011A00A6 for ; Wed, 29 Oct 2014 05:24:56 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tp5so2855247ieb.15 for ; Wed, 29 Oct 2014 05:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UMemd3c0wfjhtaMR5XQksfJAFuZ5BNAnOuruZpNOqZs=; b=wlLMS/d9P8QvMc9FvQGC/2pFMazuP3dtPolrxLtfzho3sEkBhVQjF2jpSPa1Y8dee5 Bnpl701x8PtMo77KLf1Cns+x9lK0bpJV7Ipxh0Nlpun1P/KhuDbwk7TlMHoMZlDqixJO 7nj6X/I4cbFp6HLBvF6opGZs2c+yfcCuf2VSaXSTLQD5F+wmvxSuc0LBMtbYZCBMdeJW 3YlUSoiBCDse3dsGYLBMo2inttt8xXefFscxc3opiIYWBrMqD5xSqQrQEC3UuxoZGIug Dt/Gb2qvxZOxLH1AY66tTV2LnrkzAgz9cQmAaGq6rVwaAsI/40CRU7HznNhARwm01CZO HnmA== MIME-Version: 1.0 X-Received: by 10.50.83.66 with SMTP id o2mr37283805igy.30.1414585495826; Wed, 29 Oct 2014 05:24:55 -0700 (PDT) Received: by 10.107.137.194 with HTTP; Wed, 29 Oct 2014 05:24:55 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> Date: Wed, 29 Oct 2014 13:24:55 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XP9HC4qBghZi4uVauyg0UcBgiBs Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 12:24:57 -0000 Hi Bing, On 10/28/14, Liubing (Leo) wrote: > Hi Andrew, > > Sorry for the late reply. > >> >> "3.2.1. Inappropriate Sources" >> >> >> >> interesting finding. Why is it a problem worth solving ? >> > [Bing] A host who self-configuring the IP address will not be able to >> > do a stateless configuration. >> > Say, a sensor self-configures ULA address and needs to get other >> > information from DHCPv6 server. In this scenario, stateful DHCPv6 >> > might be too heavy for the system. >> >> To clarify - you mean link-local addresses, rather than ULAs, right ? >> (since to configure ULAs, the host would somehow need to know the prefix >> being serviced by the router, which sounds awfully close to autoconf to >> me) > [Bing] Link-local is also a use case, but I also meant ULA case, since > offline communication might also needed. > And the ULAs could be self-generated instantly or burnt in the device in > advance. Sure, a self-generated ULA implies that there is only that host on that prefix. Who is it communicating with and how ? How does the router know it has to service those ULA prefixes ? How does the host that a peer's ULA prefix is on-link so it could talk directly without a router ? What am I misunderstanding in the above ? > >> If we speak about a specialized environments like sensors, they probably >> will >> try the stateless DHCPv6 regardless of the flags in RA, since that will be >> their >> only way to configure themselves, what do you think ? > [Bing] I'm not sure whether always trying stateless DHCPv6 is a good > behavior or not. Maybe they don't need extra information from DHCPv6, or > maybe RAs are enough. > The point here is, if I got an address without SLAAC/DHCPv6, can I still > decide whether to initial stateless DHCPv6 according to the only O flag? Yeah, from the completeness standpoint, sure. By the way, this triggers a suggestion for one more general comment: RFC6106 interaction is completely out of coverage in the draft, but would be very useful from the practical standpoint, also to see what happens if the information in RDNSS and DHCPv6 is in conflict. --a > > Best regards, > Bing > >> The use-case I was after was something involving the common off the shelf >> OSes, i.e. the part of the "every day network administration" >> theme of the document. >> >> > > > From nobody Wed Oct 29 08:08:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436831A01EC for ; Wed, 29 Oct 2014 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJDXe_r_2BS0 for ; Wed, 29 Oct 2014 08:08:21 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06E51A01D5 for ; Wed, 29 Oct 2014 08:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1414595301; x=1415804901; h=date:from:message-id:to:subject:cc; bh=HgjdZK9MGBX/RE+oMsIFjBP4zR4IBvqoqAN4GkOHuNo=; b=OGf+Tkesom1RGLMaKmTD4hOkzIZbGttoa6ZaDsmfixXQY8Whn1c7xJ/O Ok1z6iny7h2ZUtKbQ0q03xeAGXAxkZOHqrtF7SaeI3sMWwl05VkaL7wQ8 fh9pfakKw0iaT1WabCVXoSKUACqHwU6JJgftKEI67rtR4pLtwgZT9kaZ0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQIAK0BUVStJA2G/2dsb2JhbABcgw5UWb1XAZBEh0QJgR0WAQEBAQF9hQI8NIkhAQ3HJgEBCAIBH5EJHYQ1BYtoim2IRDyDDZE+hBiDFwEBAQ X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="91417544" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 29 Oct 2014 15:08:21 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9TF8KH8023128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 15:08:20 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s9TF8KhB018635; Wed, 29 Oct 2014 08:08:20 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s9TF8Ki1018634; Wed, 29 Oct 2014 08:08:20 -0700 Date: Wed, 29 Oct 2014 08:08:20 -0700 From: fred@cisco.com Message-Id: <201410291508.s9TF8Ki1018634@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/62cOB6goage8S_bc22-tQk2Kb6Q Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:08:23 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. From nobody Wed Oct 29 08:14:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1485A1A0282 for ; Wed, 29 Oct 2014 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr8D5iZ4UZe0 for ; Wed, 29 Oct 2014 08:14:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153291A01D5 for ; Wed, 29 Oct 2014 08:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1414595662; x=1415805262; h=date:from:message-id:to:subject:cc; bh=HgjdZK9MGBX/RE+oMsIFjBP4zR4IBvqoqAN4GkOHuNo=; b=hnAiyKSM1QRuXLuTQyyanGl+o1AxifIjVk/FDHgQkBGwG5jVzr9btvZA JkS7fO4RiBM1UIPZCSNTwZxWa1blKftigkohm+muGru5zjuOqDJ23pXpV Yu3CBXg7BWlwVY7MPfCJHueL0SWwegu9N8ADk5dcFLElsorGqUy8Q7wSa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQIAAQEUVStJA2G/2dsb2JhbABcgw5UWb1XAZBEh0QJgR0WAQEBAQF9hQI8NIkhAQ3HOAEBCAIBH5EJHYQ1BYtoim2IRDyDDZE+hBiDFwEBAQ X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="91408158" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 29 Oct 2014 15:14:21 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9TFEKHg027024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 15:14:21 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s9TFEKI0025068; Wed, 29 Oct 2014 08:14:20 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s9TFEKBW025067; Wed, 29 Oct 2014 08:14:20 -0700 Date: Wed, 29 Oct 2014 08:14:20 -0700 From: fred@cisco.com Message-Id: <201410291514.s9TFEKBW025067@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FtHGELfRAtpmRcXZQzAd0fJMX_Y Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:14:29 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. From nobody Wed Oct 29 08:27:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E541A035F for ; Wed, 29 Oct 2014 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9FftqRrUT84 for ; Wed, 29 Oct 2014 08:26:50 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5F71A0386 for ; Wed, 29 Oct 2014 08:26:50 -0700 (PDT) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id BCE891009F37D; Wed, 29 Oct 2014 15:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414596407; bh=VPjyEj3x5rVnhKcg8spryD1vatQnIYWo+mt0XlYCOMw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=k/vkVEYy3TVLI0AsRGiGV40dZlYAzfLSETMFSpzq13wD5wJiXPKKrWFgHi9nEByiH IuaXpR5Z5HQ1hMoXeWmZDX2L4bWblFNNRfSiaFA5d/GnSugbjmnJrwYTbLjiDqkPum zJNjB+CwSJI0z8WaIXpUwkaSpKqfe0lQuaPBoE1EaxQtVz+5aYWBaGxszU+zN5ZoLK qBLHsVUOzYNTd5GBwWmq3XE/9zK9Y8QjUSn940l+ecrROyG1tN47hYIw38jFk2MaLU JFKKl6blSDZel4jlPkJ6ou4kEktpiNWujroILshtQe+Mg4h4P+zaSqm3bRFsFk5YpO iqLjIDYYWjy/g== Message-ID: <54510734.2050701@massar.ch> Date: Wed, 29 Oct 2014 16:26:44 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201410291514.s9TFEKBW025067@irp-lnx1.cisco.com> In-Reply-To: <201410291514.s9TFEKBW025067@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/alfUVonDVE5wTJX8a0sCaFRXnFk Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:26:57 -0000 On 2014-10-29 16:14, fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. Any site which restricts the cookie by IP will have been broken by one of: - NAT - Multiple IPs for outbound HTTP proxies - mobile devices that move around etc etc etc.. - CGN/AFTR/etc Hence, how is this Happy Eyeball specific? It is common sense to not lock a cookie down to the IP. The IP can be shared, because of above, thus it won't help to lock it down that way. Of course, from a security perspective that is bad, but that is how the world works. HTTPS should solve the problem of any cookie stealing; if people get in to the site or browser/client, the IP lockdown does not help. If anything, this should just be an errata/addon for: http://tools.ietf.org/html/rfc6265 Greets, Jeroen From nobody Wed Oct 29 09:11:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04321A1B28 for ; Wed, 29 Oct 2014 09:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_1p2z1pC2fI for ; Wed, 29 Oct 2014 09:10:54 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EBC01A1B29 for ; Wed, 29 Oct 2014 09:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=125; q=dns/txt; s=iport; t=1414599047; x=1415808647; h=date:from:message-id:to:subject:cc; bh=A5VVlA5BupNbaE6LYjd36XkygK0RYVuBcXYJ89y6vCA=; b=KQJH20dizBgU0d/8Q7LM8pqxPVGdFLZ5nJon3DyI6MYe3TKPQevRF4tV 9frrWbfcxrO1vXmYegwkLMxmr9hepO0n4ugluVFe5a5gOWg+gay62ZWBl D2ubGC8VbMWWKmxy3vRMY7h2q30fN8XBrhbFaafAccyYRaB9+nnGZOGci Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcHAHIQUVRIo8UY/2dsb2JhbABcg2JZvVcBkEyHRAmBMwEBAQEBfYUCPDSJIQENx2UBAQgCAR+REB2ENQWLaYpuiEQ8gw6RRYQYgxcBAQE X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="46788211" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 29 Oct 2014 16:10:44 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9TGAgk5003809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 16:10:44 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id s9TGAfIK012884; Wed, 29 Oct 2014 09:10:41 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id s9TGAfBl012874; Wed, 29 Oct 2014 09:10:41 -0700 Date: Wed, 29 Oct 2014 09:10:41 -0700 From: fred@cisco.com Message-Id: <201410291610.s9TGAfBl012874@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iVaOzO8G6v8dYb-CS5JJXoBb4bY Cc: draft-chen-v6ops-nfv-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-nfv-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:11:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6. Please take a look at it and comment. From nobody Wed Oct 29 12:29:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BE81A897E for ; Wed, 29 Oct 2014 12:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4ejAs7BlnyU for ; Wed, 29 Oct 2014 12:29:22 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EAF1A897A for ; Wed, 29 Oct 2014 12:29:22 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id eu11so3811559pac.2 for ; Wed, 29 Oct 2014 12:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9Y2JWeS92uhW6l1iUnButdql7O1jX2EJVqvBgPA7sgc=; b=CUnSXIhiZQNeWu/qJKeZVuKxxYFiIxhFK2RwCQACL4+uU0kkr5syWQhjGiwjWA7Af3 aKAHKj6laKodwHp6OGFlCXoxWs6dHsilHK0ggZMxthi73KMOFrguzvFX40te0UVUyjLg +1HdHQqE9YD/A0OTu0PWH6oYO8UShTSRAa47EH1q95JRJ2U14ZKI8ge4M5f7mgwaDOuc UtjhSD+0W3qEjV0X9LLVM6JTrCrxMJvxRibowk+B82OuDMI/nQ35NzfMACpCtVePovuY R7y1APnjE9EQIU/RI+Hzja7fpycbjh5HLnfA4ZmlXqOxy6cEvamkzme5XpJ9JnjUpC2i JsDA== X-Received: by 10.70.88.201 with SMTP id bi9mr12171398pdb.73.1414610962484; Wed, 29 Oct 2014 12:29:22 -0700 (PDT) Received: from [192.168.178.23] (25.200.69.111.dynamic.snap.net.nz. [111.69.200.25]) by mx.google.com with ESMTPSA id kk7sm5068292pab.31.2014.10.29.12.29.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 12:29:21 -0700 (PDT) Message-ID: <54514014.40604@gmail.com> Date: Thu, 30 Oct 2014 08:29:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?QW5kcmV3IPCfkb0gWW91cnRjaGVua28=?= References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tGKtoevgUx22PEfHFoMVk6zO06Q Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 19:29:23 -0000 On 30/10/2014 01:24, Andrew =F0=9F=91=BD Yourtchenko wrote: =2E.. > How does the host [know] > that a peer's ULA prefix is on-link so it could talk directly without > a router ? Why is this different from the question: How does the host know that a peer's GUA prefix is on-link so it could talk directly without a router ? Brian From nobody Wed Oct 29 14:16:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C5B1A88F2 for ; Wed, 29 Oct 2014 14:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJPtoHcjoGH7 for ; Wed, 29 Oct 2014 14:16:08 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00671A6F15 for ; Wed, 29 Oct 2014 14:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9010; q=dns/txt; s=iport; t=1414617368; x=1415826968; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aqCAcnbxkKabvzk1rF992jEgPDDMyfa+OiX/9HvUgjg=; b=WkQmISV59NFSsMiqdkcHQX8kl4QTK2kCVYgiSS0DT989LkKMANIyBQ3k uNqeBHqfdPhp+UuUwwsZNecHjrqez/QOOJJZsiY1HSsdbkZSIG0PjNhWs 5h6tzMCBwVonWtH+L7PettTUh0zZiUMt+pX07FkmmI9tEAve77KCNiNJ/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikGAHBYUVStJA2J/2dsb2JhbABUCIJIIyOBLATVbwIbgQMWAQEBAQF9hAIBAQEEI1YQAgEIEQMBAigDAgICMBQJCAIEAQ0FiEEBsxyVCwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQOAJFEQeCd4FUBZINi12BMZEGhAmDeGyBBkKBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,280,1413244800"; d="scan'208,217"; a="91530275" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 29 Oct 2014 21:16:07 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9TLG7VH029149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 21:16:07 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 16:16:07 -0500 From: "Eric Vyncke (evyncke)" To: Erik Nygren , "Fred Baker (fred)" Thread-Topic: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt Thread-Index: AQHP872NMfRLh4sCb0G72nWTYOgdiQ== Date: Wed, 29 Oct 2014 21:16:07 +0000 Message-ID: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.55.185.72] Content-Type: multipart/alternative; boundary="_000_D077164330804evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ktuPiD5i5BuqRn9B1YAue_z6Grs Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:16:14 -0000 --_000_D077164330804evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpaywgQmpvZXJuIGFuZCBTaW1vbiwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29t bWVudHMuDQoNClRoZSBvcmlnaW5hbCBpbnRlbmQgd2FzIHRvIGRvY3VtZW50IGFuIGlzc3VlIGZh Y2VkIGJ5IHNvbWUgY29udGVudCBwcm92aWRlcnMsIGJ1dCwgRXJpaywgeW91IGFyZSByaWdodCBS RkMgNjg4MyBzZWN0aW9uIDguMiBjbGVhcmx5IHNwZWxscyBvdXQgdGhlIHByb2JsZW0gcmFpc2Vk IGluIG15IEktRCwgc28sIEkgZ3Vlc3MgbXkgSS1EIGlzIGNsZWFybHkgdXNlbGVzcyBhbmQgYnJp bmdzIG5vdGhpbmcuDQoNCj09PiBsZXQncyBsZXQgaGltIGRpZSBieSBleHBpcmF0aW9uIDstKQ0K DQpFbHNlLCBJIGFncmVlIHdpdGggRnJlZCdzLCBKZXJvZW4ncyBhbmQgb3RoZXJzIGNvbW1lbnQg dGhhdCB0aGUgdGl0bGUgd2FzIG5vdCB3ZWxsLWNob3NlbiBhcyBpdCBpcyBub3QgbGltaXRlZCBv bmx5IHRvIGhhcHB5IGV5ZWJhbGwgKHRoZSBMU04gY2FzZSB3YXMgYWxzbyBkb2N1bWVudCBpbiB0 aGUgSS1EIHRob3VnaCkNCg0KLcOpcmljDQoNCkZyb206IEVyaWsgTnlncmVuIDxlcmlrK2lldGZA bnlncmVuLm9yZzxtYWlsdG86ZXJpaytpZXRmQG55Z3Jlbi5vcmc+Pg0KRGF0ZTogbWFyZGkgMjgg b2N0b2JyZSAyMDE0IDIyOjA3DQpUbzogRnJlZCBCYWtlciA8ZnJlZEBjaXNjby5jb208bWFpbHRv OmZyZWRAY2lzY28uY29tPj4NCkNjOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPG1h aWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rp b246IGRyYWZ0LXZ5bmNrZS12Nm9wcy1oYXBweS1leWViYWxscy1jb29raWUtMDAudHh0DQoNCk9u IFR1ZSwgT2N0IDI4LCAyMDE0IGF0IDEwOjI5IEFNLCBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBj aXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29tPj4gd3JvdGU6DQpJIHdvdWxkIGJlIGludGVy ZXN0ZWQgaW4gZm9sa3PigJkgdmlldyBvZiB0aGlzLiBJcyB0aGlzIGludGVyZXN0aW5nPw0KDQpU aGlzIGlzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDguMiBvZiByZmM2ODgzIGJ1dCBrZWVwcyBjb21p bmcgdXAgb3ZlciBhbmQgb3ZlciBhZ2Fpbg0Kc28gbWF5IGJlIHdvcnRoIGNhbGxpbmcgb3V0IG1v cmUgY2xlYXJseS4gIEknZCB0aXRsZSBpdCBpbiBzb21lIHdheSB0aGF0IGRpZG4ndCBtYWtlIGl0 IHNlZW0gbGlrZQ0KYSBoYXBweSBleWViYWxsIHNwZWNpZmljIGlzc3VlLg0KDQpJdCdzIG5vdCBq dXN0IGEgaGFwcHkgZXllYmFsbHMgaXNzdWUuICBJdCBhbHNvIGhhcHBlbnMgd2l0aCBkdWFsLXN0 YWNrIGVudmlyb25tZW50cyB3aGVyZSBjb29raWVzIG9yIHNlc3Npb24gb3IgYXV0aGVudGljYXRp b24gdG9rZW5zIHNwYW4gb3JpZ2lucyB3aGVyZSBzb21lIHNlcnZlcnMgYXJlIGR1YWwtc3RhY2sg YW5kIHNvbWUgYXJlIElQdjQtb25seS4gICAoRm9yIGV4YW1wbGUsIGFuIGF1dGggZ3JhbnRpbmcg c2VydmljZSBncmFudHMgYmVhcmVyIHRva2VucyBsb2NrZWQgdG8gdGhlIGNsaWVudCBJUCBhZGRy ZXNzIGFuZCB0aGVuIHRoZSBjbGllbnQgY29ubmVjdHMgdG8gc29tZSBvdGhlciBzZXJ2aWNlIG9u IGEgZGlmZmVyZW50IGhvc3RuYW1lIGFuZCBwYXNzZXMgYWxvbmcgdGhlIHRva2Vucy4gIEV2ZW4g YWJzZW50IEhhcHB5IEV5ZWJhbGxzIHRoZXNlIGNhbiBiZSBvbiBkaWZmZXJlbnQgSVAgdmVyc2lv bnMuKQ0KDQpUaGUgbGFyZ2Utc2NhbGUgTkFUL0NHTiBpc3N1ZSBkb2VzIG1ha2UgdGhpcyBub3Qg anVzdCBhbiBJUHY2IGlzc3VlLiAgQXQgbGVhc3Qgc29tZSBzeXN0ZW1zIEkndmUgc2VlbiB0aGVu IGNoZWNrIHRoZSBJUCBpbiB0aGUgY29va2llIHRvIG1ha2Ugc3VyZSBpdCdzIGluIHRoZSBzYW1l IC8yNCByYXRoZXIgdGhhbiB0aGUgZXhhY3Qgc2FtZSBJUCwgYnV0IHRoYXQgZG9lc24ndCBoZWxw IGluIHRoZSBkdWFsLXN0YWNrIHdvcmxkLg0KDQpBbm90aGVyIGlzc3VlIGJleW9uZCBIYXBweSBF eWViYWxscyBpcyB0aGF0IHByaXZhY3kgYWRkcmVzc2luZyBiaXRlcyB5b3UgaGVyZSBhcyB3ZWxs IGZvciBjb29raWVzIHRoYXQgYXJlIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBUQ1AgY29ubmVjdGlv bnMgc3Bhbm5pbmcgYSBwcml2YWN5IGFkZHJlc3Mgcm90YXRpb24uDQoNCkhhdmluZyBzb21lIG1v cmUgY2xlYXIgImRvbid0IGRvIHRoaXMiIHRvIHBvaW50IHBlb3BsZSB0byB3b3VsZCBiZSBnb29k LCBidXQgSSBzdXNwZWN0IHdlJ2xsIGhhdmUgbWFueSB5ZWFycyBvZiBjbGVhbmluZyB1cCBhcHBs aWNhdGlvbnMgZG9pbmcgdGhpcy4NCg== --_000_D077164330804evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2029AB1E2B5BAC4EAAAB0D5F163B5C78@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+RXJpaywgQmpv ZXJuIGFuZCBTaW1vbiw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3Ig eW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhlIG9yaWdpbmFsIGludGVuZCB3YXMgdG8gZG9jdW1lbnQgYW4gaXNzdWUgZmFjZWQgYnkgc29t ZSBjb250ZW50IHByb3ZpZGVycywgYnV0LCBFcmlrLCB5b3UgYXJlIHJpZ2h0IFJGQyA2ODgzIHNl Y3Rpb24gOC4yIGNsZWFybHkgc3BlbGxzIG91dCB0aGUgcHJvYmxlbSByYWlzZWQgaW4gbXkgSS1E LCBzbywgSSBndWVzcyBteSBJLUQgaXMgY2xlYXJseSB1c2VsZXNzIGFuZCBicmluZ3Mgbm90aGlu Zy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pj09Jmd0OyBsZXQncyBsZXQg aGltIGRpZSBieSBleHBpcmF0aW9uIDstKTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ RWxzZSwgSSBhZ3JlZSB3aXRoIEZyZWQncywgSmVyb2VuJ3MgYW5kIG90aGVycyBjb21tZW50IHRo YXQgdGhlIHRpdGxlIHdhcyBub3Qgd2VsbC1jaG9zZW4gYXMgaXQgaXMgbm90IGxpbWl0ZWQgb25s eSB0byBoYXBweSBleWViYWxsICh0aGUgTFNOIGNhc2Ugd2FzIGFsc28gZG9jdW1lbnQgaW4gdGhl IEktRCB0aG91Z2gpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tw6lyaWM8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246 bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVG VDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQ QURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RXJpayBOeWdyZW4gJmx0OzxhIGhyZWY9Im1haWx0 bzplcmlrJiM0MztpZXRmQG55Z3Jlbi5vcmciPmVyaWsmIzQzO2lldGZAbnlncmVuLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5tYXJk aSAyOCBvY3RvYnJlIDIwMTQgMjI6MDc8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj5GcmVkIEJha2VyICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNjby5j b20iPmZyZWRAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj5JUHY2IE9wZXJhdGlvbnMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt2Nm9wc10gRndkOiBJLUQgQWN0aW9u OiBkcmFmdC12eW5ja2UtdjZvcHMtaGFwcHktZXllYmFsbHMtY29va2llLTAwLnR4dDxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsg UEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCAxMDoyOSBBTSwgRnJlZCBCYWtlciAoZnJlZCkg PHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmZyZWRAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4NCkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBmb2xrc+KAmSB2aWV3IG9mIHRoaXMuIElz IHRoaXMgaW50ZXJlc3Rpbmc/PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhpcyBpcyBtZW50aW9uZWQgaW4gc2VjdGlvbiA4LjIgb2YgcmZjNjg4MyBidXQga2Vl cHMgY29taW5nIHVwIG92ZXIgYW5kIG92ZXIgYWdhaW48YnI+DQo8L2Rpdj4NCjxkaXY+c28gbWF5 IGJlIHdvcnRoIGNhbGxpbmcgb3V0IG1vcmUgY2xlYXJseS4mbmJzcDsgSSdkIHRpdGxlIGl0IGlu IHNvbWUgd2F5IHRoYXQgZGlkbid0IG1ha2UgaXQgc2VlbSBsaWtlPGJyPg0KYSBoYXBweSBleWVi YWxsIHNwZWNpZmljIGlzc3VlLjxicj4NCjxicj4NCkl0J3Mgbm90IGp1c3QgYSBoYXBweSBleWVi YWxscyBpc3N1ZS4mbmJzcDsgSXQgYWxzbyBoYXBwZW5zIHdpdGggZHVhbC1zdGFjayBlbnZpcm9u bWVudHMgd2hlcmUgY29va2llcyBvciBzZXNzaW9uIG9yIGF1dGhlbnRpY2F0aW9uIHRva2VucyBz cGFuIG9yaWdpbnMgd2hlcmUgc29tZSBzZXJ2ZXJzIGFyZSBkdWFsLXN0YWNrIGFuZCBzb21lIGFy ZSBJUHY0LW9ubHkuJm5ic3A7Jm5ic3A7IChGb3IgZXhhbXBsZSwgYW4gYXV0aCBncmFudGluZyBz ZXJ2aWNlIGdyYW50cyBiZWFyZXINCiB0b2tlbnMgbG9ja2VkIHRvIHRoZSBjbGllbnQgSVAgYWRk cmVzcyBhbmQgdGhlbiB0aGUgY2xpZW50IGNvbm5lY3RzIHRvIHNvbWUgb3RoZXIgc2VydmljZSBv biBhIGRpZmZlcmVudCBob3N0bmFtZSBhbmQgcGFzc2VzIGFsb25nIHRoZSB0b2tlbnMuJm5ic3A7 IEV2ZW4gYWJzZW50IEhhcHB5IEV5ZWJhbGxzIHRoZXNlIGNhbiBiZSBvbiBkaWZmZXJlbnQgSVAg dmVyc2lvbnMuKTxicj4NCjxicj4NClRoZSBsYXJnZS1zY2FsZSBOQVQvQ0dOIGlzc3VlIGRvZXMg bWFrZSB0aGlzIG5vdCBqdXN0IGFuIElQdjYgaXNzdWUuJm5ic3A7IEF0IGxlYXN0IHNvbWUgc3lz dGVtcyBJJ3ZlIHNlZW4gdGhlbiBjaGVjayB0aGUgSVAgaW4gdGhlIGNvb2tpZSB0byBtYWtlIHN1 cmUgaXQncyBpbiB0aGUgc2FtZSAvMjQgcmF0aGVyIHRoYW4gdGhlIGV4YWN0IHNhbWUgSVAsIGJ1 dCB0aGF0IGRvZXNuJ3QgaGVscCBpbiB0aGUgZHVhbC1zdGFjayB3b3JsZC48YnI+DQo8YnI+DQo8 L2Rpdj4NCkFub3RoZXIgaXNzdWUgYmV5b25kIEhhcHB5IEV5ZWJhbGxzIGlzIHRoYXQgcHJpdmFj eSBhZGRyZXNzaW5nIGJpdGVzIHlvdSBoZXJlIGFzIHdlbGwgZm9yIGNvb2tpZXMgdGhhdCBhcmUg dXNlZCBhY3Jvc3MgZGlmZmVyZW50IFRDUCBjb25uZWN0aW9ucyBzcGFubmluZyBhIHByaXZhY3kg YWRkcmVzcyByb3RhdGlvbi48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxkaXY+SGF2aW5nIHNvbWUgbW9yZSBjbGVhciAmcXVvdDtkb24ndCBkbyB0aGlzJnF1 b3Q7IHRvIHBvaW50IHBlb3BsZSB0byB3b3VsZCBiZSBnb29kLCBidXQgSSBzdXNwZWN0IHdlJ2xs IGhhdmUgbWFueSB5ZWFycyBvZiBjbGVhbmluZyB1cCBhcHBsaWNhdGlvbnMgZG9pbmcgdGhpcy48 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D077164330804evynckeciscocom_-- From nobody Wed Oct 29 14:25:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC61A9046 for ; Wed, 29 Oct 2014 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qny7I6EiHi5 for ; Wed, 29 Oct 2014 14:25:10 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3651A902A for ; Wed, 29 Oct 2014 14:25:10 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so2029307vcb.21 for ; Wed, 29 Oct 2014 14:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WZ8uDNAxW0brrj8jXh2xcTBWnUN3rFvwRM85QlF+JWs=; b=RFXxPvMfm5MWieJAsV0mzKfGTQc2DPrXOEsx7dzXajP3g73lZjcuZIr/Gn1gnjgNvW d+nZ80tohoZZHvF13e8Kdb16siObSGIL0ehGk16owXI45h0Knm7nJJ6KpkuwKUkTxTTB v51H/T5JJuH1nvOfleWHo4bXp4hC7SJCU3pcyPAf+46HC7lb0udpm+pWq3sR/5MlrtlV Hsszwjs5gbw+Sc+1482Xw1Nz9HJumidB2YIWlqcJJBMyImiSj2Nti9yEHJfp5bb57pB8 HO/n78MhHi1IDAZ+R4rqyMOWOPm5J3jCU+kGeJDzOiiIGF9DjsYn1J28/pcwlkG2lPkG R3cQ== MIME-Version: 1.0 X-Received: by 10.220.118.74 with SMTP id u10mr8529618vcq.35.1414617909284; Wed, 29 Oct 2014 14:25:09 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.190.71 with HTTP; Wed, 29 Oct 2014 14:25:09 -0700 (PDT) In-Reply-To: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> Date: Wed, 29 Oct 2014 17:25:09 -0400 X-Google-Sender-Auth: ESnJBxbT6ALHsxLVPtyHbiowbCE Message-ID: From: Erik Nygren To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=001a11369940f9e39f05069665e8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T8yZIQqKhGzv18KBvYwCM-xh80U Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:25:12 -0000 --001a11369940f9e39f05069665e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I guess the question is whether it is worth having an Informational covering this class of problem explicitly with a very clear "don't do this!" focus? In particular, there are two dimensions: 1) the classes of things people lock by IP address today (session cookies, auth tokens, bearer tokens, etc) 2) the classes of multi-homing that cause problems here and how all of them are increasing (happy eyeballs for dual-stack, privacy addressing, multi-link multi-homing, load balanced proxies, load balanced NATs, ...) With the summary that because of the increases in #2, it is strongly advised not to do #1 anymore. Questions sometimes come up on whether there are good technical solutions, such as ways clients can force outbound connections across each link to build up some sort of "association record" that glues the various IP addresses together, but that is more of an apps-area topic, and also don't work with some of the above. Erik On Wed, Oct 29, 2014 at 5:16 PM, Eric Vyncke (evyncke) wrote: > Erik, Bjoern and Simon, > > Thanks for your review and comments. > > The original intend was to document an issue faced by some content > providers, but, Erik, you are right RFC 6883 section 8.2 clearly spells o= ut > the problem raised in my I-D, so, I guess my I-D is clearly useless and > brings nothing. > > =3D=3D> let's let him die by expiration ;-) > > Else, I agree with Fred's, Jeroen's and others comment that the title > was not well-chosen as it is not limited only to happy eyeball (the LSN > case was also document in the I-D though) > > -=C3=A9ric > > From: Erik Nygren > Date: mardi 28 octobre 2014 22:07 > To: Fred Baker > Cc: IPv6 Operations > Subject: Re: [v6ops] Fwd: I-D Action: > draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt > > On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) > wrote: > >> I would be interested in folks=E2=80=99 view of this. Is this interestin= g? >> > > This is mentioned in section 8.2 of rfc6883 but keeps coming up over and > over again > so may be worth calling out more clearly. I'd title it in some way that > didn't make it seem like > a happy eyeball specific issue. > > It's not just a happy eyeballs issue. It also happens with dual-stack > environments where cookies or session or authentication tokens span origi= ns > where some servers are dual-stack and some are IPv4-only. (For example, > an auth granting service grants bearer tokens locked to the client IP > address and then the client connects to some other service on a different > hostname and passes along the tokens. Even absent Happy Eyeballs these c= an > be on different IP versions.) > > The large-scale NAT/CGN issue does make this not just an IPv6 issue. At > least some systems I've seen then check the IP in the cookie to make sure > it's in the same /24 rather than the exact same IP, but that doesn't help > in the dual-stack world. > > Another issue beyond Happy Eyeballs is that privacy addressing bites you > here as well for cookies that are used across different TCP connections > spanning a privacy address rotation. > > Having some more clear "don't do this" to point people to would be good, > but I suspect we'll have many years of cleaning up applications doing thi= s. > > --001a11369940f9e39f05069665e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess the question is whether it is worth having an= Informational covering this class of problem explicitly with a very clear = "don't do this!" focus?

In particular, ther= e are two dimensions:

1) the classes of things people loc= k by IP address today (session cookies, auth tokens, bearer tokens, etc)
2) the classes of multi-homing that cause problems here and= how all of them are increasing (happy eyeballs for dual-stack, privacy add= ressing, multi-link multi-homing, load balanced proxies, load balanced NATs= , ...)

With the summary that because of the increases in = #2, it is strongly advised not to do #1 anymore.

Question= s sometimes come up on whether there are good technical solutions, such as = ways clients can force outbound connections across each link to build up so= me sort of "association record" that glues the various IP address= es together, but that is more of an apps-area topic, and also don't wor= k with some of the above.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Erik


On Wed, Oct 29, 2014 at 5:16 PM, Eric Vyncke (= evyncke) <evyncke@cisco.com> wrote:
Erik, Bjoern and Simon,

Thanks for your review and comments.

The original intend was to document an issue faced by some content pro= viders, but, Erik, you are right RFC 6883 section 8.2 clearly spells out th= e problem raised in my I-D, so, I guess my I-D is clearly useless and bring= s nothing.=C2=A0

=3D=3D> let's let him die by expiration ;-)

Else, I agree with Fred's, Jeroen's and others comment that th= e title was not well-chosen as it is not limited only to happy eyeball (the= LSN case was also document in the I-D though)

-=C3=A9ric

From: Erik Nygren <erik+ietf@nygren.org> Date: mardi 28 octobre 2014 22:07 To: Fred Baker <fred@cisco.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: I-D Actio= n: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt

On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fr= ed) <fred@cisco.com&= gt; wrote:
I would be interested in folks=E2=80=99 view of this. Is this interesting?<= br>

This is mentioned in section 8.2 of rfc6883 but keeps coming up over a= nd over again
so may be worth calling out more clearly.=C2=A0 I'd title it in so= me way that didn't make it seem like
a happy eyeball specific issue.

It's not just a happy eyeballs issue.=C2=A0 It also happens with dual-s= tack environments where cookies or session or authentication tokens span or= igins where some servers are dual-stack and some are IPv4-only.=C2=A0=C2=A0= (For example, an auth granting service grants bearer tokens locked to the client IP address and then the client connects to som= e other service on a different hostname and passes along the tokens.=C2=A0 = Even absent Happy Eyeballs these can be on different IP versions.)

The large-scale NAT/CGN issue does make this not just an IPv6 issue.=C2=A0 = At least some systems I've seen then check the IP in the cookie to make= sure it's in the same /24 rather than the exact same IP, but that does= n't help in the dual-stack world.

Another issue beyond Happy Eyeballs is that privacy addressing bites you he= re as well for cookies that are used across different TCP connections spann= ing a privacy address rotation.

Having some more clear "don't do this" to point people t= o would be good, but I suspect we'll have many years of cleaning up app= lications doing this.

--001a11369940f9e39f05069665e8-- From nobody Wed Oct 29 14:29:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176E41A907C for ; Wed, 29 Oct 2014 14:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSw9Ii40pHhi for ; Wed, 29 Oct 2014 14:28:58 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667421A8750 for ; Wed, 29 Oct 2014 14:28:58 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3188A25D3A91; Wed, 29 Oct 2014 21:28:55 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 07707C77057; Wed, 29 Oct 2014 21:28:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id JoDeuG9_y1f8; Wed, 29 Oct 2014 21:28:53 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2A73CC77042; Wed, 29 Oct 2014 21:28:51 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 29 Oct 2014 21:28:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> To: Erik Nygren X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Q7_qHg6zGuHasnsK9BMcJcIWb64 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:29:00 -0000 On 29 Oct 2014, at 21:25 , Erik Nygren wrote: > 2) the classes of multi-homing that cause problems here and how all of = them are increasing (happy eyeballs for dual-stack, privacy addressing, = multi-link multi-homing, load balanced proxies, load balanced NATs, ...) >=20 > With the summary that because of the increases in #2, it is strongly = advised not to do #1 anymore. >=20 > Questions sometimes come up on whether there are good technical = solutions, such as ways clients can force outbound connections across = each link to build up some sort of "association record" that glues the = various IP addresses together, but that is more of an apps-area topic, = and also don't work with some of the above. I would phrase that differently as =93I want predictable, deterministic = behaviour and not magic=94. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From nobody Wed Oct 29 14:39:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7081A90CF for ; Wed, 29 Oct 2014 14:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWnzTozbh3Pc for ; Wed, 29 Oct 2014 14:39:06 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512CD1A90BA for ; Wed, 29 Oct 2014 14:38:53 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C8336DA0215 for ; Wed, 29 Oct 2014 21:42:07 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3665353E084; Wed, 29 Oct 2014 14:38:23 -0700 (PDT) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 14:38:22 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> Date: Wed, 29 Oct 2014 17:38:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/A5fFllgTY_ZpUTtbzh6XLn4HmeQ Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:39:07 -0000 On Oct 29, 2014, at 5:28 PM, Bjoern A. Zeeb = wrote: > I would phrase that differently as =93I want predictable, = deterministic behaviour and not magic=94. Then you want POTS, not a global packet-switched network. :) From nobody Wed Oct 29 17:04:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6151ACDA0 for ; Wed, 29 Oct 2014 17:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkWbDblR6esM for ; Wed, 29 Oct 2014 17:04:27 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780301ACD9E for ; Wed, 29 Oct 2014 17:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1048; q=dns/txt; s=iport; t=1414627467; x=1415837067; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NUK1BdwpEJD+xFYpKoTZlSawIyqJrNRMiAfxep7Ptao=; b=eOPfkrsFZTKNLLKw2hdRuNJoVv/AMecFi8wpVYyWA0G3VqUL/e0ajSpo 3xp/5zDbRtGcjYvlevvpl0GIX0pst78yYq+JQkOQBu4kaZjjaN6BmNEU1 h3aa1IyygChCTrE3ha+Da8hbN/N+sio4bNKtlnzF7B6HpqXLXQKxPVnvE w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAE5/UVStJA2I/2dsb2JhbABcgw6BLATOHIdXAoEWFgEBAQEBfYQCAQEBAwEBAnYFCwIBCBguKAolAgQOBQ6IKgnICQEBAQEBAQEBAQEBAQEBAQEBAQEBAReREAeDLYEeAQSSDYISgVCEd4MElkCDeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,281,1413244800"; d="asc'?scan'208";a="91571148" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 30 Oct 2014 00:04:26 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9U04QGj002902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 00:04:26 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 19:04:26 -0500 From: "Fred Baker (fred)" To: Ted Lemon Thread-Topic: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt Thread-Index: AQHP8iARH2EEXUPMqkm2esltgUSvnQ== Date: Thu, 30 Oct 2014 00:04:26 +0000 Message-ID: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> In-Reply-To: <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_3C743593-5FA5-430B-945A-B8F1234D3AE7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dQ2hde8f7DGaFaZrY39KgeqOGIo Cc: "Bjoern A. Zeeb" , IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 00:04:29 -0000 --Apple-Mail=_3C743593-5FA5-430B-945A-B8F1234D3AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 29, 2014, at 2:38 PM, Ted Lemon wrote: > On Oct 29, 2014, at 5:28 PM, Bjoern A. Zeeb = wrote: >> I would phrase that differently as =93I want predictable, = deterministic behaviour and not magic=94. >=20 > Then you want POTS, not a global packet-switched network. Go to the detnet BOF... --Apple-Mail=_3C743593-5FA5-430B-945A-B8F1234D3AE7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUUYB/bjEdbHIsm0MRAgwNAKCzVjPARNzyyE0CMUHbSrbee9fNkACg0fCM S3A5m3cItESpmOSl3bWlnx8= =IWzG -----END PGP SIGNATURE----- --Apple-Mail=_3C743593-5FA5-430B-945A-B8F1234D3AE7-- From nobody Thu Oct 30 02:11:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2790E1ACFE1 for ; Thu, 30 Oct 2014 02:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbGpIN4lZnmg for ; Thu, 30 Oct 2014 02:11:27 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB4C1A6FC6 for ; Thu, 30 Oct 2014 02:11:27 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tp5so4847217ieb.15 for ; Thu, 30 Oct 2014 02:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KGF0gkEsJEkTLwbC5Tco9XB+v5sgbietCmKfzkI8EUE=; b=oykJRcUh8LFGM8dLcnbtqcTu4RxjcbvoBPt2rcSoEi6XhUFkM5d90fPLUx2QZrCuH2 KxJZ3Xwz8sGzTjU3kvhFPgIYpRAE6qJY7lLKRnyiFVNAOIjucwAWvM1R+s0kzejsAoff KPHIfmhgGy24o1qy8NYMcI8I8j1YayGpTJOZheDm8y678lWip2cC/Y0gbEyh5TWwwWGr b22ZuF3Eu/i+3qLrTaA+aBx/4Lk2Q4/b4J5DvcVtpAwvsvINPxq5WxBdIOvBgwdSXWtl KifJui3sRjZv1SjwUUstGjbVbHzMY5l+3UeU0M9yXOUJjSzDNjvlEVYMdgJOp47XNSJC 9AAQ== MIME-Version: 1.0 X-Received: by 10.107.133.234 with SMTP id p103mr17788592ioi.7.1414660286453; Thu, 30 Oct 2014 02:11:26 -0700 (PDT) Received: by 10.107.137.194 with HTTP; Thu, 30 Oct 2014 02:11:26 -0700 (PDT) In-Reply-To: <54514014.40604@gmail.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> <54514014.40604@gmail.com> Date: Thu, 30 Oct 2014 10:11:26 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YNyO-EgnJZTfGshvCOWngeHRtXk Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 09:11:28 -0000 On 10/29/14, Brian E Carpenter wrote: > On 30/10/2014 01:24, Andrew =F0=9F=91=BD Yourtchenko wrote: > ... >> How does the host [know] >> that a peer's ULA prefix is on-link so it could talk directly without >> a router ? > > Why is this different from the question: > > How does the host know that a peer's GUA prefix is on-link so it > could talk directly without a router ? It's not. And my "without a router" wording was clumsy - it was supposed to emphasize the way two on-link hosts communicate (directly, without the involvement of the router), not the absence of the router altogether. I am sorry for confusing the language. In both ULA and GUA cases there would need to be a router would need to have the prefix(es) in the RA, wouldn't it ? But, on the origin of the "ULA" and this sub-thread: > In the case described in Section 3.2.1, the host would only have link-loc= al > addresses. [Bing] Or maybe self-generated ULAs. (But of course, it is not the point of this document.) I was trying to understand how that straw man was supposed to work. A possibility of statically assigned GUAs in the first place somehow escaped me - while, in fact, a server admin that manages the addresses but does not control where is the today's DNS server is a much more plausible case. Thus that comment to which Bing replied with "ULA" straw man should not have been there in the first place. Thanks for triggering me to realize that. Bing, please disregard the part of my previous mail related to ULAs. Would be still interesting to hear your opinion about rfc6106. --a > > Brian > > From nobody Thu Oct 30 05:16:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756B61A0024 for ; Thu, 30 Oct 2014 05:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBQmrcCW1uLv for ; Thu, 30 Oct 2014 05:16:39 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820FA1A0037 for ; Thu, 30 Oct 2014 05:16:34 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8DA0E25D3A91 for ; Thu, 30 Oct 2014 12:16:32 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 817A6C7709C for ; Thu, 30 Oct 2014 12:16:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id LADMVjqwqrKb for ; Thu, 30 Oct 2014 12:16:30 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DD377C7709B for ; Thu, 30 Oct 2014 12:16:29 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Bjoern A. Zeeb" In-Reply-To: <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> Date: Thu, 30 Oct 2014 12:16:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/zXoCSUfY6pEZO9D97O977ELPLJs Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:16:41 -0000 On 29 Oct 2014, at 21:38 , Ted Lemon wrote: > On Oct 29, 2014, at 5:28 PM, Bjoern A. Zeeb = wrote: >> I would phrase that differently as =93I want predictable, = deterministic behaviour and not magic=94. >=20 > Then you want POTS, not a global packet-switched network. >=20 > :) Damn that thing still works after so many decades and is so reliable = indeed; now SIP is taking over. I was more thinking in terms of applications (or more general end-node = behaviour), but I wouldn=92t mind more simple, deterministic protocol = behaviour either; less can be more; feature-itis is a disease of its = own. And, personally I guess, if we had more working (deployed) code = before we=92d have RFCs published on specifications, we=92d have a lot = less OPs (or ooops) things to write down and deal with and a lot less = crap and a lot less drafts making it to RFCs;-) /bz =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From nobody Thu Oct 30 06:21:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28621AD0D0 for ; Thu, 30 Oct 2014 06:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXZlNpWP7sKF for ; Thu, 30 Oct 2014 06:21:49 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B873E1AD190 for ; Thu, 30 Oct 2014 06:21:48 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id gf13so4432570lab.3 for ; Thu, 30 Oct 2014 06:21:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pBcPpiSsjLfw87xCNY2wvfRD3xPgpKThLNPbSBS/3wE=; b=crON6NIQS4j50zSFNlrVV+aG7IiN/htWAviMkSvV/OVY3P2J72DZpjigFJJYrkOPxr DRp9R5O6lqo+ebuTht0HkXH4sqTAfJDs3WF5E98kMhJ9gIsNkZVyhPtjsvdcBMQr9pEw BlmRo0Wa7GuhM1bnUs2hiikK00D9xDEbExeywsG/KLPQPUGoBcKkLRuLHh/Yzol3jCZ5 CPCzONLy+ISwiD6Ek7Ti6vZfGe/yaYqTr1gD5ZFh2cNDN/4pjtTCw4ii5sx+u8sSzu5p KgCdhLbHHerKupaqjYYFrTxcqKlRS9M8faeFLpcenuaVV02Uas3QOwzJFXQucbxKHBfi rVdw== X-Gm-Message-State: ALoCoQk1GfQFnDSIEem3P/ki/IEdbWUdop/hX3UCThhYIzVw2XZCn4aGIOFx/GoVxGCvN60mMKU8 MIME-Version: 1.0 X-Received: by 10.112.87.162 with SMTP id az2mr18652905lbb.15.1414675306589; Thu, 30 Oct 2014 06:21:46 -0700 (PDT) Received: by 10.25.167.20 with HTTP; Thu, 30 Oct 2014 06:21:46 -0700 (PDT) In-Reply-To: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> Date: Thu, 30 Oct 2014 09:21:46 -0400 Message-ID: From: Simon Perreault To: "Bjoern A. Zeeb" Content-Type: multipart/alternative; boundary=001a11347e0a1f4a750506a3c315 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wkO57cXJuzEn0ET8ba6_0sx0ybw Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:21:53 -0000 --001a11347e0a1f4a750506a3c315 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2014 at 8:16 AM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > On Oct 29, 2014, at 5:28 PM, Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> I would phrase that differently as =E2=80=9CI want predictable, determ= inistic > behaviour and not magic=E2=80=9D. > > > > Then you want POTS, not a global packet-switched network. > > > > :) > > Damn that thing still works after so many decades and is so reliable > indeed; now SIP is taking over. > > I was more thinking in terms of applications (or more general end-node > behaviour), but I wouldn=E2=80=99t mind more simple, deterministic protoc= ol > behaviour either; less can be more; feature-itis is a disease of its > own. And, personally I guess, if we had more working (deployed) code > before we=E2=80=99d have RFCs published on specifications, we=E2=80=99d h= ave a lot less OPs > (or ooops) things to write down and deal with and a lot less crap and a l= ot > less drafts making it to RFCs;-) Come on Bjoern, you're too young for change resistance syndrome! ;) We need more and more to think of source IP addresses as ephemeral things. Just like you don't care which ephemeral source port gets picked by the OS when you call connect(), you shouldn't care about which source address is picked when calling connect_by_name() or whatever other HE-like API out there. Simon --001a11347e0a1f4a750506a3c315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 30, 2014 at 8:16 AM, Bjoern A. Zeeb <bzeeb-lists@= lists.zabbadoz.net> wrote:
= > On Oct 29, 2014, at 5:28 PM, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net= > wrote:
>> I would phrase that differently as =E2=80=9CI want predictable, de= terministic behaviour and not magic=E2=80=9D.
>
> Then you want POTS, not a global packet-switched network.
>
> :)

Damn that thing still works after so many decades and is so reliable= indeed;=C2=A0 now SIP is taking over.

I was more thinking in terms of applications (or more general end-node beha= viour), but I wouldn=E2=80=99t mind more simple, deterministic protocol beh= aviour either;=C2=A0 less can be more;=C2=A0 feature-itis is a disease of i= ts own.=C2=A0 And, personally I guess, if we had more working (deployed) co= de before we=E2=80=99d have RFCs published on specifications, we=E2=80=99d = have a lot less OPs (or ooops) things to write down and deal with and a lot= less crap and a lot less drafts making it to RFCs;-)
Come on Bjoern, you're too young for change resistance syndrome! ;)

We need = more and more to think of source IP addresses as ephemeral things. Just lik= e you don't care which ephemeral source port gets picked by the OS when= you call connect(), you shouldn't care about which source address is p= icked when calling connect_by_name() or whatever other HE-like API out ther= e.

Sim= on
--001a11347e0a1f4a750506a3c315-- From nobody Thu Oct 30 06:31:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F5E1AD213 for ; Thu, 30 Oct 2014 06:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tVx1i4eRL_2 for ; Thu, 30 Oct 2014 06:31:54 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5081A005E for ; Thu, 30 Oct 2014 06:31:53 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 77CAA1009FC6E; Thu, 30 Oct 2014 13:31:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414675911; bh=XjOQUuhzbbV5BO17YHJnhOGtcf2/dHNOE5DGSpNncPs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ROdAcXmbF0YHsdoQyMXCqT3wDbqkOGEbPpXnZv0araQ/iMltQoO1BJQUms/APy3un HbmkPkOhCV+WGiJA512/JRnOzZhIV3dKmAv1nxsCPWHibO8mCKjHP5bK3uY/HhDQ12 LJh2dctEv88pAPQ57NXkOa1usfAbOArSY+/1cW6L4lxDSpxHxoazxPYkqrUdpMrIJT zykASzZ5noS4v/QNapJ4zxUGHPy9wkGZJ+pQfXCt2w3sJ9ZhJOu3WruJKX5mop50DF Z67CoUPd4zUG0xj94Ao1Isj3sc1K9EIuT3PdOm3uSNQz5v+eYUBNHECYl4QG7+5qe9 F6J0u5Bdldeig== Message-ID: <54523DC4.2090303@massar.ch> Date: Thu, 30 Oct 2014 14:31:48 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Simon Perreault , "Bjoern A. Zeeb" References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WQL2D5-po-YQADwrexfTBA6Jb1A Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:31:57 -0000 On 2014-10-30 14:21, Simon Perreault wrote: [..] > you shouldn't care about which source > address is picked when calling connect_by_name() or whatever other > HE-like API out there. While in the general case you should not care, it would be really useful if there is a knob that makes it deterministic, so that you are not swapping between source/dest pairs all the time. Sometimes you actually want to debug the problem, to fix the issue instead of the world breaking behind your back. On OSX that means SSHing into another box (eg Linux) which does not muck around with randomness based on the position of the moon. Well, latency + throughput, *apparently*, nobody really knows the parameters they use for picking what the destination will be or how th results of getaddrinfo() get sorted. Greets, Jeroen From nobody Thu Oct 30 10:12:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5B01A1A60 for ; Thu, 30 Oct 2014 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YCgz-E-FxWu for ; Thu, 30 Oct 2014 10:12:27 -0700 (PDT) Received: from slimemold.creativedynamo.com (slimemold.creativedynamo.com [IPv6:2605:b00:0:2:218:51ff:fea6:15c0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B920F1A1A8F for ; Thu, 30 Oct 2014 10:06:47 -0700 (PDT) Received: from [2001:470:d:ffe:230:1bff:fe3f:6050] (unknown [IPv6:2001:470:d:ffe:230:1bff:fe3f:6050]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by slimemold.creativedynamo.com (Postfix) with ESMTPS id D2593A0040; Thu, 30 Oct 2014 07:06:44 -1000 (HST) Date: Thu, 30 Oct 2014 07:06:40 -1000 (HST) From: Antonio Querubin X-X-Sender: tony@sol To: Brian E Carpenter In-Reply-To: <54505F43.5020203@gmail.com> Message-ID: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BB5RwO2lKRcL7gSSiDvbQTvLBXY Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:12:29 -0000 On Wed, 29 Oct 2014, Brian E Carpenter wrote: > Personally I have changed my mind. The progress on ISP-provided IPv6 has > been significant, Teredo has basically vanished, and I don't see a case for > paying the operational and trouble-shooting costs of 6to4 any more. The draft Progress? Perhaps. Significant? Depends on whether any of your ISPs provide IPv6. In my pond the average joe consumer still doesn't have easy access to native IPv6 from the local ISPs. I know because I worked for the last local ISP that did. It was bought out by someone who didn't care for IPv6 and promptly shut it all off - no I didn't stick around. Since then I don't know of any local ISP that offers native IPv6 to non-business customers. I suspect there are many other places where this would be true. If the response is 'go get a tunnel' I would ask how easily/quickly could you set that up for a new residential DSL or cable modem user using a single computer? For that matter how many typical off-the-shelf consumer grade routers provide 6in4 tunnelling capability? I've looked at the box advertising on many of these units and check the websites of the vendors. It's near impossible to tell which models can do tunnelling. While the goal of this proposal is commendable I think it's a bit premature - not until native IPv6 has significant penetration and/or 6in4 tunnelling is more commonplace in consumer grade routers. Progress is good but availability is what counts operationally. Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com From nobody Thu Oct 30 10:17:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFFE1A00F1 for ; Thu, 30 Oct 2014 10:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zBIghFB4UF4 for ; Thu, 30 Oct 2014 10:17:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EDB1A0155 for ; Thu, 30 Oct 2014 10:17:42 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B43A421BDD for ; Thu, 30 Oct 2014 13:17:41 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 30 Oct 2014 13:17:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=Ml65qNqluzw5idVK3i/itySrY1U=; b=mCgG5g0+sVFC5PWNF EpAzH/RdhcLAaVIIs8BdPKWL/DX4v4Z7kOl56MIMi+qiMRmeD63nPCFWdd4kekdS NicAUeh2lR4DlJ/SeRWwCdtXBtZwlA09evjsVc6g6ucnTMQRnU6OapUdWd0aRPpu kUp85et7BWoKGb2EEu+67yuP2s= X-Sasl-enc: h2/9yGjcaZ5uM5hJXBFb3FZo2EOuD/6+aFvfx06hM/va 1414689461 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D77568010D; Thu, 30 Oct 2014 13:17:41 -0400 (EDT) Message-ID: <545272B4.3030500@network-heretics.com> Date: Thu, 30 Oct 2014 13:17:40 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Antonio Querubin , Brian E Carpenter References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080906040406060707030505" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pKm84xuXB5rn8kVLFuoO-qmuYhg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:17:45 -0000 This is a multi-part message in MIME format. --------------080906040406060707030505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/30/2014 01:06 PM, Antonio Querubin wrote: > Progress? Perhaps. Significant? Depends on whether any of your ISPs > provide IPv6. I would say it depends on whether *most* of your ISPs provide native IPv6. If only one of your ISPs provides IPv6, being forced into choosing that provider is not a good situation. And more and more ISPs are being accused of blocking tunnels for consumer-grade accounts. This isn't something that IETF should be endorsing in any way. Internet service is supposed to be about making a best effort to faithfully forward IP packets to their destinations. Outside of very narrow circumstances, carriers that intercept, alter, block, or pessimize certain kinds of IP traffic on a routine basis are a threat to the utility of the Internet. Keith --------------080906040406060707030505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/30/2014 01:06 PM, Antonio Querubin wrote:
Progress? Perhaps. Significant? Depends on whether any of your ISPs provide IPv6.

I would say it depends on whether most of your ISPs provide native IPv6. If only one of your ISPs provides IPv6, being forced into choosing that provider is not a good situation.

And more and more ISPs are being accused of blocking tunnels for consumer-grade accounts. This isn't something that IETF should be endorsing in any way. Internet service is supposed to be about making a best effort to faithfully forward IP packets to their destinations. Outside of very narrow circumstances, carriers that intercept, alter, block, or pessimize certain kinds of IP traffic on a routine basis are a threat to the utility of the Internet.

Keith


--------------080906040406060707030505-- From nobody Thu Oct 30 11:14:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17161A1A40 for ; Thu, 30 Oct 2014 11:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkV12jsnRmxE for ; Thu, 30 Oct 2014 11:14:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AC1FC1A038E for ; Thu, 30 Oct 2014 11:14:18 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9UIArXr006465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 11:11:06 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9UIArXr006465 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414692666; bh=RR8tpKBda3phSRwJmmhiCEWBtr4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d6LfdUI1oPwo/v5+FeYbnN79lOYJGF0M1uVhGbZnnGPdPKcri182jlztRi0+JC3WS HVsMMpUXQvLPhvlOPTBGWf7+k2bZYvNKewplcfOarvWrsuSkM4R1Rdjk3u/Nq0MY7k OeBlRsPcWuI0CtpDbOG4XI31SUSm/C00O4Dj+lNE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <545054DD.9020406@network-heretics.com> Date: Thu, 30 Oct 2014 11:10:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 30 Oct 2014 11:11:06 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/39jG_gnG8IOBq5ZsDzYrmfclMTE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 18:14:20 -0000 >=20 > p.s. Aside from the potential of this proposal to break things for = people who are currently successfully using 6to4 and who do not yet have = a native v6 alternative available, other things that bug me rather = strongly about this document are its implicit position(s) that (a) = IP-in-IP tunneling is something you shouldn't expect to work and = therefore shouldn't be doing and (b) you shouldn't be using tunneling to = bypass your ISPs routing. I am emphatically opposed to both of those = positions and feel that this document takes a really carrier-centric = (and customer-hostile) view that is not appropriate for IETF to be = taking. I agree with both of these objections. Owen From nobody Thu Oct 30 11:52:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466041A01AE for ; Thu, 30 Oct 2014 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pdym5MSYKQn for ; Thu, 30 Oct 2014 11:52:41 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB3C1A0199 for ; Thu, 30 Oct 2014 11:52:40 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EA1DB60785 for ; Thu, 30 Oct 2014 19:52:37 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id AEF366010D for ; Thu, 30 Oct 2014 19:52:37 +0100 (CET) Received: (qmail 91786 invoked by uid 1007); 30 Oct 2014 19:52:37 +0100 Date: Thu, 30 Oct 2014 19:52:37 +0100 From: Gert Doering To: Antonio Querubin Message-ID: <20141030185237.GR31092@Space.Net> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FlMSagEr9C7SQrV2YWCEFGr3014 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 18:52:43 -0000 Hi, On Thu, Oct 30, 2014 at 07:06:40AM -1000, Antonio Querubin wrote: > While the goal of this proposal is commendable I think it's a bit > premature - not until native IPv6 has significant penetration and/or 6in4 > tunnelling is more commonplace in consumer grade routers. Progress is > good but availability is what counts operationally. Before you get a 6to4 tunnel, stick to IPv4-only. 6to4 tunneled IPv6 to the "wild Internet" (unlike "to your friend who also uses 6to4, no gateway involved") will be SO much worse than "just use native IPv4" that you're doing nobody a favour doing this. 6to4 is not "get a tunnel from he.net" - which actually works quite well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Oct 30 11:54:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6811A1AA6 for ; Thu, 30 Oct 2014 11:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTqAX8u5bit0 for ; Thu, 30 Oct 2014 11:54:53 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C029B1A1A52 for ; Thu, 30 Oct 2014 11:54:20 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 57F0460614 for ; Thu, 30 Oct 2014 19:54:19 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1E3F26032F for ; Thu, 30 Oct 2014 19:54:19 +0100 (CET) Received: (qmail 91844 invoked by uid 1007); 30 Oct 2014 19:54:19 +0100 Date: Thu, 30 Oct 2014 19:54:19 +0100 From: Gert Doering To: Owen DeLong Message-ID: <20141030185419.GS31092@Space.Net> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sj7v8i5INKd4kVSd3V3TiJK0RIE Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 18:54:55 -0000 Hi, On Thu, Oct 30, 2014 at 11:10:51AM -0700, Owen DeLong wrote: > > p.s. Aside from the potential of this proposal to break things for people who are currently successfully using 6to4 and who do not yet have a native v6 alternative available, other things that bug me rather strongly about this document are its implicit position(s) that (a) IP-in-IP tunneling is something you shouldn't expect to work and therefore shouldn't be doing and (b) you shouldn't be using tunneling to bypass your ISPs routing. I am emphatically opposed to both of those positions and feel that this document takes a really carrier-centric (and customer-hostile) view that is not appropriate for IETF to be taking. > > I agree with both of these objections. Neither is expressed in this draft. "IPv6 in IPv4 tunneling using some 3rd party relay which is not maintained well enough and since you do not know who's relay you are using, you can not even tell them that it's broken" - this is what you should avoid. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Oct 30 12:21:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB751A1B73 for ; Thu, 30 Oct 2014 12:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIEqbZt8t4EG for ; Thu, 30 Oct 2014 12:21:20 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0891A1B70 for ; Thu, 30 Oct 2014 12:21:20 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 79E6E21EE7 for ; Thu, 30 Oct 2014 15:21:19 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Oct 2014 15:21:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=YV3sQfw9841xoFGjaLVs7j gFGAI=; b=WAKmymvwzB9KyEVLGS8wEAEHKwMNPRjFe1Pq7+sCjyjrZsN+R8apOz EzIXcU+sS4RBlpRRiEoIYgUarERPQtK36Ewht2ftKXMFjS+J7YFcJ0Q+P9KDEOLI 4968wtnCyGsJyO2Z84+xLUAUBVmPfaEJceyT3a9zO8grYC7IUiYMg= X-Sasl-enc: ODATUF3EdNem2PdRGBOKZOG1QXHOJtysZ/bulaTaG/jW 1414696879 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E36B2C00008; Thu, 30 Oct 2014 15:21:18 -0400 (EDT) Message-ID: <54528FAE.3050907@network-heretics.com> Date: Thu, 30 Oct 2014 15:21:18 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering , Antonio Querubin References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> In-Reply-To: <20141030185237.GR31092@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oBsvcHy5n8Gg9x_tavN7tCR5P3E Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:21:22 -0000 On 10/30/2014 02:52 PM, Gert Doering wrote: >> While the goal of this proposal is commendable I think it's a bit >> >premature - not until native IPv6 has significant penetration and/or 6in4 >> >tunnelling is more commonplace in consumer grade routers. Progress is >> >good but availability is what counts operationally. > Before you get a 6to4 tunnel, stick to IPv4-only. 6to4 tunneled IPv6 > to the "wild Internet" (unlike "to your friend who also uses 6to4, no > gateway involved") will be SO much worse than "just use native IPv4" > that you're doing nobody a favour doing this. It's a mistake to assume that the reason for using IPv6 is to talk to the "wild Internet" (especially if you define "wild Internet" as the set of hosts that talk IPv4 and might also happen to talk IPv6). The motivation to use IPv6 is driven by different applications than IPv4 was. Keith From nobody Thu Oct 30 12:22:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227B51A1B3A for ; Thu, 30 Oct 2014 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOz7h4vtCAmT for ; Thu, 30 Oct 2014 12:22:22 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAB21A1B1A for ; Thu, 30 Oct 2014 12:22:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8BD3521E75 for ; Thu, 30 Oct 2014 15:22:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 30 Oct 2014 15:22:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=uX+67HyXPV4d5DIhZiR9Jl gaOO4=; b=gWQ7/w5zvEqVPNvIXPwNQklNevra3h0AzV+CWqdBL1bWsXB4FO/W6o 2GIu5k10aO3XIKNRsERRQ5U8nX1mLa1ttCrWwSK/Lxh3hGyT02qMSS2L6XQj1QAl ydpLvrIb1+uHaMmhg5ZT6tyUD42p50n1Nr4A6XCs4pamkbesnEkdo= X-Sasl-enc: /u9rTRPqlCJrnW4ksEKpgJyCkG1EPrMY7ARswrffHer6 1414696941 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 1912FC00008; Thu, 30 Oct 2014 15:22:21 -0400 (EDT) Message-ID: <54528FEC.9060601@network-heretics.com> Date: Thu, 30 Oct 2014 15:22:20 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering , Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <20141030185419.GS31092@Space.Net> In-Reply-To: <20141030185419.GS31092@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PvvFkoFLjUNJhfUdxnDKzHYdJYY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:22:25 -0000 On 10/30/2014 02:54 PM, Gert Doering wrote: > "IPv6 in IPv4 tunneling using some 3rd party relay which is not maintained > well enough and since you do not know who's relay you are using, you can > not even tell them that it's broken" - this is what you should avoid. Mostly agree. But the current document isn't just about deprecating RFC 3068. Keith From nobody Thu Oct 30 13:41:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF21A702D for ; Thu, 30 Oct 2014 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykcm0c6yy42L for ; Thu, 30 Oct 2014 13:41:17 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B531A1B67 for ; Thu, 30 Oct 2014 13:41:17 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id ED8B2608D0 for ; Thu, 30 Oct 2014 21:41:15 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A900C60274 for ; Thu, 30 Oct 2014 21:41:15 +0100 (CET) Received: (qmail 9313 invoked by uid 1007); 30 Oct 2014 21:41:15 +0100 Date: Thu, 30 Oct 2014 21:41:15 +0100 From: Gert Doering To: Keith Moore Message-ID: <20141030204115.GT31092@Space.Net> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bGRa+VvXQ1yiQLn9" Content-Disposition: inline In-Reply-To: <54528FAE.3050907@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LfipdmnJ2oZjYk1ZdkKkpngAxKc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:41:19 -0000 --bGRa+VvXQ1yiQLn9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Oct 30, 2014 at 03:21:18PM -0400, Keith Moore wrote: > > Before you get a 6to4 tunnel, stick to IPv4-only. 6to4 tunneled IPv6 > > to the "wild Internet" (unlike "to your friend who also uses 6to4, no > > gateway involved") will be SO much worse than "just use native IPv4" > > that you're doing nobody a favour doing this. > It's a mistake to assume that the reason for using IPv6 is to talk to=20 > the "wild Internet" (especially if you define "wild Internet" as the set= =20 > of hosts that talk IPv4 and might also happen to talk IPv6). The=20 > motivation to use IPv6 is driven by different applications than IPv4 was. So in which way does this draft impact your ability to talk IPv6 between your nodes? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --bGRa+VvXQ1yiQLn9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVFKia99WwGXkzn/FAQKODw/+KyDWi1F5DW7ExcvNxf5PX7Bdf3L8RpRe z+xBFi/9ca+tbajIHjeVtZT26kgjZoThBvdAXzpi9c/Ld0YGSiL3yfE3c0vR88Ve Yez4R37+d8h3jq4KMpj+Y/LdA90c1bpVqrVcExiZKsxb/ArVz/OWKHavNzbd3Sy0 o4K+fmcytZdrW/TOtifXRyCJWt8idsjQDGv+iN18gLLPV7Ya+F1rNfxY3+GRpXzr Ws+YSRS5eVqhY3s2CRy/O2Bi3yAl7ZSmk5uF8ynIGSaAqhlMYP6anq+YYzsj8gpa 7oyyPlt5zF/00KgQPvJv+vtq98EwpwO79IvYmAAU+py+W9okagZHU1q3/HJlC+zz B7CqyTsNqBxx8ZW6UQ7XuZO9Hgajj16ucbpe9MCeKUJJIxo3zJ81N2XGCGquC5Y9 A198SGvMYWcOhrFGuqP6QJIFDssWVZssHpzhqpJDeX09ZOc0X22zgsjBl+CdIDKv YADrq86oYC/WSjMpFRhOsVyfJLjlt/XHSE4wB/rhqaeMBZw5h7WIrXMEKK4VdLgw hjBcnZTWsq9Qv3KPSLPJsi0WoH+HzTbiWkoLsGZy1jBLYoF//g1P3RvAu8rCCgUL JHZzc0Zm2tK8L5TWGUlIyeLhva6kBwr9v+BhAZzK5oRaSTzD+LIstVoTEc2i85tR IvjRO8L2jHk= =0ZNX -----END PGP SIGNATURE----- --bGRa+VvXQ1yiQLn9-- From nobody Thu Oct 30 13:44:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9741A8764 for ; Thu, 30 Oct 2014 13:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lj84kWe1t7g for ; Thu, 30 Oct 2014 13:44:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFA31A8765 for ; Thu, 30 Oct 2014 13:44:46 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4D49B2065C for ; Thu, 30 Oct 2014 16:44:46 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Oct 2014 16:44:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=x7WIVu+vEQlmLSpRkPmgiy 4m1+s=; b=lTUPVpQBtm3BZ5sQ83/GLSrh3mrUbnEEP5PjUg/7Wg1Qqryf9ofRzn X5eP4tjENzIe8tKneemYSLDJaCcu/7l05Hdsf4tuDlcylOvLZ9RU94xGKF6SOkiR gGpfH14lupCCAE9yIinF08ReZA0/jo+Sc4fQMj9Sv0GsSrT8UxK70= X-Sasl-enc: Fwv2iwzkILe8gCydgjOgQ/ZKFSA1GczNQPwe9jV16TvE 1414701886 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id BEB9EC00011; Thu, 30 Oct 2014 16:44:45 -0400 (EDT) Message-ID: <5452A333.7060300@network-heretics.com> Date: Thu, 30 Oct 2014 16:44:35 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> In-Reply-To: <20141030204115.GT31092@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aLagTIUp4HZ5Cpl4n0P7GIyRP-E Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 20:44:51 -0000 On 10/30/2014 04:41 PM, Gert Doering wrote: >>> Before you get a 6to4 tunnel, stick to IPv4-only. 6to4 tunneled IPv6 >>> > >to the "wild Internet" (unlike "to your friend who also uses 6to4, no >>> > >gateway involved") will be SO much worse than "just use native IPv4" >>> > >that you're doing nobody a favour doing this. >> >It's a mistake to assume that the reason for using IPv6 is to talk to >> >the "wild Internet" (especially if you define "wild Internet" as the set >> >of hosts that talk IPv4 and might also happen to talk IPv6). The >> >motivation to use IPv6 is driven by different applications than IPv4 was. > So in which way does this draft impact your ability to talk IPv6 between > your nodes? It impacts my ability to talk IPv6 with any other nodes for which 6to4 currently works, which are not necessarily "my" nodes, nor nodes that also support IPv4. To give one example, I've found that video conferencing over 6to4 can work in situations in which STUN-based NAT traversal fails. Keith From nobody Thu Oct 30 15:14:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220A31A876B for ; Thu, 30 Oct 2014 15:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSjO6dc1ueDT for ; Thu, 30 Oct 2014 15:14:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2199A1A038F for ; Thu, 30 Oct 2014 15:14:42 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9UMERVf022268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Oct 2014 15:14:27 -0700 (PDT) Message-ID: <5452B843.10209@isi.edu> Date: Thu, 30 Oct 2014 15:14:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201410291508.s9TF8Ki1018634@irp-lnx1.cisco.com> In-Reply-To: <201410291508.s9TF8Ki1018634@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AOca-UYmbefPKyDmJ1xAK8BfFAQ Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 22:14:44 -0000 On 10/29/2014 8:08 AM, fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment. Under potential mitigations, is there a reason not to refer to the use of alternate (non-IP address) host IDs? E.g., as noted in RFC 6967 and draft-boucadair-intarea-host-identifier-scenarios. Joe From nobody Thu Oct 30 15:22:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617C51A8863 for ; Thu, 30 Oct 2014 15:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abL0Lf-9UO_0 for ; Thu, 30 Oct 2014 15:22:08 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F6C1A8862 for ; Thu, 30 Oct 2014 15:22:06 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so3255203vcb.35 for ; Thu, 30 Oct 2014 15:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ggEomdXubA2l7V5PXMFTLrYVZyVADuKFEbhtoklOCFI=; b=d3jKMbUn2gFhiGwAr2eHJZTn5aMlikI/UcH87JoALhuZ9JMxpZH2xuPc2HzHBki/YA snAsmGAQJc9LK1L/SXP4eH3lHbwVDHa9e8p7hZfL75MI+6rW59dl+F+U7VD26FlMjdKV 7vOfMMT2RtRjelHI7n2h0NEMKtlc5efB/ZlIsX6CgFAlth6xxFEreSyuCyXGfwDxKZ9c mKirnrLAkLPDdGknIZF7y7OHDQSfxm1aWvieeMo1IW2iKaMhb49XQWo0u5QR72zUwxX8 0+njTnoJsNU55K6p1eUTtw0vTJ+7E/FyJY+v/FKuT3558Kh4pfWjlBbXwI5xhYxY4DVs 2YSw== MIME-Version: 1.0 X-Received: by 10.52.120.50 with SMTP id kz18mr12351233vdb.20.1414707725922; Thu, 30 Oct 2014 15:22:05 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.220.190.71 with HTTP; Thu, 30 Oct 2014 15:22:05 -0700 (PDT) In-Reply-To: <5452B843.10209@isi.edu> References: <201410291508.s9TF8Ki1018634@irp-lnx1.cisco.com> <5452B843.10209@isi.edu> Date: Thu, 30 Oct 2014 18:22:05 -0400 X-Google-Sender-Auth: KiULUoKI6MMqluaPUP27UckRoyQ Message-ID: From: Erik Nygren To: Joe Touch Content-Type: multipart/alternative; boundary=089e013a0e127734d40506ab4fbd Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fHvKMZJkHiD9ck6qz9BwNHfbAM4 Cc: "v6ops@ietf.org" , draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 22:22:10 -0000 --089e013a0e127734d40506ab4fbd Content-Type: text/plain; charset=UTF-8 It's unclear if the solution space here is the same as for host IDs? In particular, that draft talks about "remote servers are not able to distinguish between hosts sharing the same IP address" whereas here the case is "remote servers are not able to distinguish that a single host uses multiple IP addresses, some of which may be shared with other hosts". In particular, the multiple IP addresses in the multi-homing context may not even be in the same administrative domain. Erik On Thu, Oct 30, 2014 at 6:14 PM, Joe Touch wrote: > > > On 10/29/2014 8:08 AM, fred@cisco.com wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. > Please take a look at it and comment. > > Under potential mitigations, is there a reason not to refer to the use > of alternate (non-IP address) host IDs? > > E.g., as noted in RFC 6967 and > draft-boucadair-intarea-host-identifier-scenarios. > > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e013a0e127734d40506ab4fbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's unclear if the solution space here is the sa= me as for host IDs?=C2=A0 In particular, that draft talks about "remot= e servers are not able to distinguish between hosts sharing the same IP address" whereas here the case is= "remote servers are not able to distinguish that a single host uses m= ultiple IP addresses, some of which may be shared with other hosts".= =C2=A0 In particular, the multiple IP addresses in the multi-homing context= may not even be in the same administrative domain.

=C2=A0=C2= =A0 Erik


On Thu, Oct 30, 2014 at 6:14 PM, Joe Touch <touch@isi.edu> = wrote:


On 10/29/2014 8:08 AM, fred@cisco.com= wrote:
> A new draft has been posted, at http://tools.ie= tf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a loo= k at it and comment.

Under potential mitigations, is there a reason not to refer to the u= se
of alternate (non-IP address) host IDs?

E.g., as noted in RFC 6967 and
draft-boucadair-intarea-host-identifier-scenarios.

Joe

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

--089e013a0e127734d40506ab4fbd-- From nobody Thu Oct 30 15:43:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08F1A887C for ; Thu, 30 Oct 2014 15:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRPUHYG1pc6c for ; Thu, 30 Oct 2014 15:43:23 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991D81A887B for ; Thu, 30 Oct 2014 15:43:23 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9UMgqOu028209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Oct 2014 15:42:52 -0700 (PDT) Message-ID: <5452BEEC.7000708@isi.edu> Date: Thu, 30 Oct 2014 15:42:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Erik Nygren References: <201410291508.s9TF8Ki1018634@irp-lnx1.cisco.com> <5452B843.10209@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qslsEZWaQbQEnYpK1DamMd-a10I Cc: "v6ops@ietf.org" , draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 22:43:25 -0000 On 10/30/2014 3:22 PM, Erik Nygren wrote: > It's unclear if the solution space here is the same as for host IDs? In > particular, that draft talks about "remote servers are not able to > distinguish between hosts sharing the same IP address" whereas here the > case is "remote servers are not able to distinguish that a single host > uses multiple IP addresses, some of which may be shared with other > hosts". Yes, the role of client and server is reversed, but in both cases the issue is the same: a single host using multiple IP addresses The key issue for this doc is that the addresses are IPv4 and IPv6, but the potential solutions remain relevant, AFAICT. > In particular, the multiple IP addresses in the multi-homing > context may not even be in the same administrative domain. That affects *some* of the solutions, but not all. Joe > > Erik > > > On Thu, Oct 30, 2014 at 6:14 PM, Joe Touch > wrote: > > > > On 10/29/2014 8:08 AM, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. > Please take a look at it and comment. > > Under potential mitigations, is there a reason not to refer to the use > of alternate (non-IP address) host IDs? > > E.g., as noted in RFC 6967 and > draft-boucadair-intarea-host-identifier-scenarios. > > Joe > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Oct 30 15:48:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863FF1A8884 for ; Thu, 30 Oct 2014 15:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDMG0634TZYo for ; Thu, 30 Oct 2014 15:48:20 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AA21A8883 for ; Thu, 30 Oct 2014 15:48:20 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id ft15so6020813pdb.21 for ; Thu, 30 Oct 2014 15:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3Y33sof8K1fmsWreTcr+ffNZfnFqxtJ+QuREnrCNFkA=; b=b/aWwIYafF19vHLm73UrrjVq6KDbR04ZQ2B8BzbKbWUFIsCz8kxDZlio6n8F5m3T16 DVw89pasQAZI7E3i+1nopxRtGzuxovc53sPZo+yUi6NpanqDLOx8M6q9BRnAS8z/CBHy QA05dU+jOXOUtJk5PsXg5xJo3XCgJsnzCA23cir94hIGemMTM8w0n3V4NK2KURkNlwCp THCFBuvt338aIUtqKXcPKqYXf+lRdybpzavuMoMAPpxfc44qShmbrrCpg+lt3qF44w/M 6vgyVM3JPoY8Bm6f41Y+UCT0JMaarV8Fb5O33FR6XSW05ZNUnaUWM7RGd11RsZIKM6AW GgCQ== X-Received: by 10.66.118.136 with SMTP id km8mr21009874pab.100.1414709300477; Thu, 30 Oct 2014 15:48:20 -0700 (PDT) Received: from [192.168.178.23] (18.200.69.111.dynamic.snap.net.nz. [111.69.200.18]) by mx.google.com with ESMTPSA id ns3sm8061860pbb.75.2014.10.30.15.48.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 15:48:19 -0700 (PDT) Message-ID: <5452C039.6080208@gmail.com> Date: Fri, 31 Oct 2014 11:48:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Antonio Querubin References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I38AT1ChtjzqUpmmnpTL1rSs9Yk Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 22:48:23 -0000 On 31/10/2014 06:06, Antonio Querubin wrote: > On Wed, 29 Oct 2014, Brian E Carpenter wrote: > >> Personally I have changed my mind. The progress on ISP-provided IPv6 has >> been significant, Teredo has basically vanished, and I don't see a >> case for >> paying the operational and trouble-shooting costs of 6to4 any more. >> The draft > > Progress? Perhaps. Significant? Depends on whether any of your ISPs > provide IPv6. In my pond the average joe consumer still doesn't have > easy access to native IPv6 from the local ISPs. I know because I worked > for the last local ISP that did. It was bought out by someone who > didn't care for IPv6 and promptly shut it all off - no I didn't stick > around. Since then I don't know of any local ISP that offers native > IPv6 to non-business customers. > > I suspect there are many other places where this would be true. If the > response is 'go get a tunnel' I would ask how easily/quickly could you > set that up for a new residential DSL or cable modem user using a single > computer? No, the response is actually "You're better off with IPv4 for now", sadly. The Google data convince me that 6to4 is simply not useful any more. A few years ago it was 10% of Google's IPv6 traffic; now it's 0.2%. It was designed as a subversive technology to get around IPv4-only operators, but because of NAT44 it has simply failed except for a tiny minority. > For that matter how many typical off-the-shelf consumer grade routers > provide 6in4 tunnelling capability? I've looked at the box advertising > on many of these units and check the websites of the vendors. It's near > impossible to tell which models can do tunnelling. Those boxes are all NAT44 (to a very close approximation) and NAT44 breaks host-based anycast 6to4 completely. The tiny amount of 6to4 traffic that Google sees must come from either non-NATted IPv4 hosts or 6to4-capable CPE routers. > While the goal of this proposal is commendable I think it's a bit > premature - not until native IPv6 has significant penetration Google is seeing ~4.5% of clients via IPv6, compared to ~0.5% in 2011. Of course it's a matter of opinion whether that is "significant" or not. > and/or > 6in4 tunnelling is more commonplace in consumer grade routers. I predict that this will not change, but we might see pressure for 464xlat in CPEs. Brian Progress > is good but availability is what counts operationally. > > Antonio Querubin > e-mail: tony@lavanauts.org > xmpp: antonioquerubin@gmail.com > . > From nobody Thu Oct 30 15:57:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298C61A8892 for ; Thu, 30 Oct 2014 15:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a3gon0Bpa6l for ; Thu, 30 Oct 2014 15:57:07 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EF81A8891 for ; Thu, 30 Oct 2014 15:57:06 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9UMv4Ys006793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2014 22:57:04 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <5452C240.2080202@foobar.org> Date: Thu, 30 Oct 2014 22:57:04 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> In-Reply-To: <5452A333.7060300@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZI6E7VqlEJCpqlvJn9aA76ip5Qc Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 22:57:09 -0000 On 30/10/2014 20:44, Keith Moore wrote: > It impacts my ability to talk IPv6 with any other nodes for which 6to4 > currently works, which are not necessarily "my" nodes, nor nodes that also > support IPv4. To give one example, I've found that video conferencing > over 6to4 can work in situations in which STUN-based NAT traversal fails. No, it doesn't. 6to4 will continue to work for the foreseeable future and this draft will change exactly nothing in this regard. If it stops working in the distant future, it's going to be because operators have stopped caring about it to the point that their relays will either decay to the point that they no longer work, as happened in IE earlier this year (no-one noticed, btw). If this happens, get yourself a free ipv6 tunnel from a tunnel broker - there are several of the around, including SixXS and HE. They work very nicely and are actively cared for by their operators. Nick From nobody Thu Oct 30 16:11:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CDF1A88A3 for ; Thu, 30 Oct 2014 16:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r6B1-qSP0p6 for ; Thu, 30 Oct 2014 16:10:58 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3591A88C5 for ; Thu, 30 Oct 2014 16:08:41 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9UN6Kal005491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 16:06:20 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9UN6Kal005491 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414710381; bh=N7TdXA+Nx6HWqmdzW21bF+4ve+0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=gn2tti6GfVVPsHrtf+0l4VtXxv2ZeyFwvqPg64eDo4CiO/DQ2t5cIlaUXwTRNWA6m cpdth5R6X8o0k1wk++LnTBWLaZbokAGbR8FScJsC68A9Ju7ECE7eHx4Hzv+Rvw5VAo OXUTXykkIRws6wcMrcnfovqCvDYPY+dLHwi9EiO4= Content-Type: multipart/alternative; boundary="Apple-Mail=_2B376297-08F2-4C2F-A8D9-186FAA5CAD29" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <5452C039.6080208@gmail.com> Date: Thu, 30 Oct 2014 16:06:14 -0700 Message-Id: <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 30 Oct 2014 16:06:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EaFFDSKjUPJ-OVWRLYgW9BWXnlU Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:11:00 -0000 --Apple-Mail=_2B376297-08F2-4C2F-A8D9-186FAA5CAD29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 30, 2014, at 3:48 PM, Brian E Carpenter = wrote: >=20 > On 31/10/2014 06:06, Antonio Querubin wrote: >> On Wed, 29 Oct 2014, Brian E Carpenter wrote: >>=20 >>> Personally I have changed my mind. The progress on ISP-provided IPv6 = has >>> been significant, Teredo has basically vanished, and I don't see a >>> case for >>> paying the operational and trouble-shooting costs of 6to4 any more. >>> The draft >>=20 >> Progress? Perhaps. Significant? Depends on whether any of your = ISPs >> provide IPv6. In my pond the average joe consumer still doesn't have >> easy access to native IPv6 from the local ISPs. I know because I = worked >> for the last local ISP that did. It was bought out by someone who >> didn't care for IPv6 and promptly shut it all off - no I didn't stick >> around. Since then I don't know of any local ISP that offers native >> IPv6 to non-business customers. >>=20 >> I suspect there are many other places where this would be true. If = the >> response is 'go get a tunnel' I would ask how easily/quickly could = you >> set that up for a new residential DSL or cable modem user using a = single >> computer? I could set it up very quickly and easily. I could probably do it in = under 15 minutes, but let=E2=80=99s say 1/2 hour to be overly cautious. http://tunnelbroker.net There=E2=80=99s even help for exactly how to configure a variety of = systems and routers. >> While the goal of this proposal is commendable I think it's a bit >> premature - not until native IPv6 has significant penetration=20 >=20 > Google is seeing ~4.5% of clients via IPv6, compared to ~0.5% > in 2011. Of course it's a matter of opinion whether that is > "significant" or not. I think more significant is that 100% of Comcast Residential customers = now have the ability to go IPv6 if they have capable equipment. I expect as modems/routers get replaced over the next 1-2 years, = that=E2=80=99s going to make for a much bigger increase than the last 3 years. >> and/or >> 6in4 tunnelling is more commonplace in consumer grade routers. It=E2=80=99s not that uncommon today. DDWRT generally supports it. = Almost all of the IPv6 capable consumer grade routers from D-Link, = Netgear, Apple, et al support it. > I predict that this will not change, but we might see pressure for > 464xlat in CPEs. 464xlat isn=E2=80=99t currently there. 6in4 is pretty common in my = experience. YMMV. Owen --Apple-Mail=_2B376297-08F2-4C2F-A8D9-186FAA5CAD29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 30, 2014, at 3:48 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 31/10/2014 06:06, = Antonio Querubin wrote:
On Wed, 29 Oct 2014, Brian E Carpenter wrote:
Personally I have = changed my mind. The progress on ISP-provided IPv6 has
been = significant, Teredo has basically vanished, and I don't see a
case for
paying the operational and = trouble-shooting costs of 6to4 any more.
The draft

Progress?  Perhaps. =  Significant?  Depends on whether any of your ISPs
provide IPv6.  In my pond the average joe consumer still = doesn't have
easy access to native IPv6 from the local = ISPs.  I know because I worked
for the last local ISP = that did.  It was bought out by someone who
didn't = care for IPv6 and promptly shut it all off - no I didn't stick
around.  Since then I don't know of any local ISP that = offers native
IPv6 to non-business customers.

I suspect there are many other places where = this would be true.  If the
response is 'go get a = tunnel' I would ask how easily/quickly could you
set that = up for a new residential DSL or cable modem user using a single
computer?

I = could set it up very quickly and easily. I could probably do it in under = 15 minutes,
but let=E2=80=99s say 1/2 hour to be overly = cautious.


There=E2=80=99s even help for exactly how to = configure a variety of systems and routers.

While the goal of this = proposal is commendable I think it's a bit
premature - not = until native IPv6 has significant penetration

Google is seeing ~4.5% of clients = via IPv6, compared to ~0.5%
in 2011. Of course it's a = matter of opinion whether that is
"significant" or not.

I think more = significant is that 100% of Comcast Residential customers now = have
the ability to go IPv6 if they have capable = equipment.

I expect as = modems/routers get replaced over the next 1-2 years, that=E2=80=99s = going to make for
a much bigger increase than the last 3 = years.

and/or
6in4 = tunnelling is more commonplace in consumer grade routers.

It=E2=80=99s not that uncommon today. DDWRT generally = supports it. Almost all of the IPv6 capable consumer grade routers from = D-Link, Netgear, Apple, et al support it.

I = predict that this will not change, but we might see pressure for
464xlat in CPEs.

464xlat isn=E2=80=99t currently there. 6in4 is pretty = common in my experience.

YMMV.

Owen


= --Apple-Mail=_2B376297-08F2-4C2F-A8D9-186FAA5CAD29-- From nobody Thu Oct 30 16:11:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790EE1A8903 for ; Thu, 30 Oct 2014 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW_nT1csSZ0k for ; Thu, 30 Oct 2014 16:11:02 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCE31A890D for ; Thu, 30 Oct 2014 16:09:22 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9UN9IbH006863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 23:09:18 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <5452C51E.1000407@foobar.org> Date: Thu, 30 Oct 2014 23:09:18 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> In-Reply-To: <545054DD.9020406@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VS9WbfaUu_56vzwLcZsQtaDERMw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:11:09 -0000 X-List-Received-Date: Thu, 30 Oct 2014 23:11:09 -0000 Keith, On 29/10/2014 02:45, Keith Moore wrote: > other things that bug me rather strongly about > this document are its implicit position(s) that (a) IP-in-IP tunneling is > something you shouldn't expect to work and therefore shouldn't be doing and > (b) you shouldn't be using tunneling to bypass your ISPs routing. I am > emphatically opposed to both of those positions These are straw men arguments. This is not helpful. Regarding your objection (b), this is not stated or implied anywhere in the document. Regarding (a), we aren't talking about generic IP-in-IP tunnelling; instead we're talking specifically about inter-domain anycast 6to4, which is a very specific application of IPoIP. You've also misunderstood something more important: the data on 6to4 tunnelling suggests that instead of it being something you shouldn't expect to work, it's something that you should explicitly expect not to work in many situations. It is an actively harmful technology where there is undeniable data to show that it continues to cause high levels of measurable problems in many cases. Given the terminal level of breakage, it beggars belief how and why anyone would think that this was an appropriate technology for providing reliable ipv6 connectivity in the general case. These problems will never go away because they depend on everyone running bug-free networks. Expecting otherwise is unrealistic beyond bound. If it works for you, then good for you. This document will not stop it working in future. Nick From nobody Thu Oct 30 16:14:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AFB1A8948 for ; Thu, 30 Oct 2014 16:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szglUZLqI3ib for ; Thu, 30 Oct 2014 16:14:35 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D36C1A88E5 for ; Thu, 30 Oct 2014 16:13:34 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9UNDWCH006903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 23:13:32 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host xe-0-0-2.transit07.phb1.foobar.org [87.192.56.84] claimed to be cupcake.foobar.org Message-ID: <5452C61C.20207@foobar.org> Date: Thu, 30 Oct 2014 23:13:32 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Keith Moore References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <545272B4.3030500@network-heretics.com> In-Reply-To: <545272B4.3030500@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bIE83hL7K7dKe9M9_MUDsvxSCaQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:14:37 -0000 On 30/10/2014 17:17, Keith Moore wrote: > And more and more ISPs are being accused of blocking tunnels for > consumer-grade accounts. This isn't something that IETF should be > endorsing in any way. This is another straw man argument - the IETF is endorsing nothing of the sort. Nick From nobody Thu Oct 30 16:27:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E741A895D for ; Thu, 30 Oct 2014 16:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9zSxoXCzjli for ; Thu, 30 Oct 2014 16:27:25 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA571A88E0 for ; Thu, 30 Oct 2014 16:27:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E084D20E83 for ; Thu, 30 Oct 2014 19:27:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 30 Oct 2014 19:27:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=v77EgEh7j6qQ8Jd3/jytM7idBY0=; b=h8MtwuPyDk8wKaA5U QSelzI/PyouAp8RrzDM7SiDd20hf1Pm4Y/htn9ZLN6h1xMsnriTdCd0XRtoBrM2j Jppc8w3M11qAJ2zGxCcmQSLoGIfAZny04JNwRYIO4yXRoCHMnmIPohwKORAavh1b 001t2a1VfVRqf+2LnDXj65++QY= X-Sasl-enc: 4flfbuJmwrzZqiPfg5YbdNaqFxMzk7CmIXgVGhsViNx7 1414711644 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D35AC0000A; Thu, 30 Oct 2014 19:27:24 -0400 (EDT) Message-ID: <5452C951.5030002@network-heretics.com> Date: Thu, 30 Oct 2014 19:27:13 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian E Carpenter , Antonio Querubin References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> In-Reply-To: <5452C039.6080208@gmail.com> Content-Type: multipart/alternative; boundary="------------050502050004060903030404" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5DoN7IN_-IVKeYIEXoew1uqosts Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 23:27:28 -0000 This is a multi-part message in MIME format. --------------050502050004060903030404 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/30/2014 06:48 PM, Brian E Carpenter wrote: > On 31/10/2014 06:06, Antonio Querubin wrote: >> On Wed, 29 Oct 2014, Brian E Carpenter wrote: >> >>> Personally I have changed my mind. The progress on ISP-provided IPv6 has >>> been significant, Teredo has basically vanished, and I don't see a >>> case for >>> paying the operational and trouble-shooting costs of 6to4 any more. >>> The draft >> Progress? Perhaps. Significant? Depends on whether any of your ISPs >> provide IPv6. In my pond the average joe consumer still doesn't have >> easy access to native IPv6 from the local ISPs. I know because I worked >> for the last local ISP that did. It was bought out by someone who >> didn't care for IPv6 and promptly shut it all off - no I didn't stick >> around. Since then I don't know of any local ISP that offers native >> IPv6 to non-business customers. >> >> I suspect there are many other places where this would be true. If the >> response is 'go get a tunnel' I would ask how easily/quickly could you >> set that up for a new residential DSL or cable modem user using a single >> computer? > No, the response is actually "You're better off with IPv4 for now", sadly. > The Google data convince me that 6to4 is simply not useful any more. > A few years ago it was 10% of Google's IPv6 traffic; now it's 0.2%. Google's data is no indication of the utility of 6to4. The trend reflects a number of things not related to 6to4's utility, including increased native v6 connectivity among Google's users, the increased deployment of better address prefix selection algorithms and happy eyeballs, the recent recommendations to disable 6to4 by default. ANd of course it only measures people trying to reach Google, which while a popular use of the Internet, is in no way representative of the vast variety of Internet applications. And the whole point of 6to4 (outside of experimental use) isn't to reach hosts that are reachable via IPv4; it's to reach hosts that /aren't/ reachable by IPv4. Obviously for any scenario in which IPv4 works to reach a destination, 6to4 will never work better, at least not for two-party applications. Similarly, the point of 6to4 isn't to communicate between hosts that both already have native IPv6 access. > It was designed as a subversive technology to get around IPv4-only > operators, but because of NAT44 it has simply failed except for > a tiny minority. NAT44, hostile operators, and clueless or hostile network admins. >> For that matter how many typical off-the-shelf consumer grade routers >> provide 6in4 tunnelling capability? I've looked at the box advertising >> on many of these units and check the websites of the vendors. It's near >> impossible to tell which models can do tunnelling. > Those boxes are all NAT44 (to a very close approximation) and NAT44 > breaks host-based anycast 6to4 completely. The tiny amount of 6to4 > traffic that Google sees must come from either non-NATted IPv4 hosts or > 6to4-capable CPE routers. I have a router that does NAT44 but also supports 6to4. It acts as a v4 NAT and a v6 router. I don't know about current product offerings, but there used to be several consumer-grade products that did this. The one I have worked fine for me for many years, until my ISP started blocking protocol it for no good reason. (I do have a static IPv4 address.) >> While the goal of this proposal is commendable I think it's a bit >> premature - not until native IPv6 has significant penetration > Google is seeing ~4.5% of clients via IPv6, compared to ~0.5% > in 2011. Of course it's a matter of opinion whether that is > "significant" or not. It's not enough penetration to justify a conclusion that most people using 6to4 have a viable alternative. Keith --------------050502050004060903030404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/30/2014 06:48 PM, Brian E Carpenter wrote:
On 31/10/2014 06:06, Antonio Querubin wrote:

On Wed, 29 Oct 2014, Brian E Carpenter wrote:


Personally I have changed my mind. The progress on ISP-provided IPv6 has
been significant, Teredo has basically vanished, and I don't see a
case for
paying the operational and trouble-shooting costs of 6to4 any more.
The draft

Progress?  Perhaps.  Significant?  Depends on whether any of your ISPs
provide IPv6.  In my pond the average joe consumer still doesn't have
easy access to native IPv6 from the local ISPs.  I know because I worked
for the last local ISP that did.  It was bought out by someone who
didn't care for IPv6 and promptly shut it all off - no I didn't stick
around.  Since then I don't know of any local ISP that offers native
IPv6 to non-business customers.

I suspect there are many other places where this would be true.  If the
response is 'go get a tunnel' I would ask how easily/quickly could you
set that up for a new residential DSL or cable modem user using a single
computer?

No, the response is actually "You're better off with IPv4 for now", sadly.
The Google data convince me that 6to4 is simply not useful any more.
A few years ago it was 10% of Google's IPv6 traffic; now it's 0.2%.

Google's data is no indication of the utility of 6to4.   The trend reflects a number of things not related to 6to4's utility, including increased native v6 connectivity among Google's users,  the increased deployment of better address prefix selection algorithms and happy eyeballs, the recent recommendations to disable 6to4 by default.   ANd of course it only measures people trying to reach Google, which while a popular use of the Internet, is in no way representative of the vast variety of Internet applications.

And the whole point of 6to4 (outside of experimental use) isn't to reach hosts that are reachable via IPv4; it's to reach hosts that aren't reachable by IPv4.  Obviously for any scenario in which IPv4 works to reach a destination, 6to4 will never work better, at least not for two-party applications. 

Similarly, the point of 6to4 isn't to communicate between hosts that both already have native IPv6 access.

It was designed as a subversive technology to get around IPv4-only
operators, but because of NAT44 it has simply failed except for
a tiny minority.

NAT44, hostile operators, and clueless or hostile network admins.
For that matter how many typical off-the-shelf consumer grade routers
provide 6in4 tunnelling capability?  I've looked at the box advertising
on many of these units and check the websites of the vendors.  It's near
impossible to tell which models can do tunnelling.

Those boxes are all NAT44 (to a very close approximation) and NAT44
breaks host-based anycast 6to4 completely. The tiny amount of 6to4
traffic that Google sees must come from either non-NATted IPv4 hosts or
6to4-capable CPE routers.

I have a router that does NAT44 but also supports 6to4.  It acts as a v4 NAT and a v6 router.  I don't know about current product offerings, but there used to be several consumer-grade products that did this.   The one I have worked fine for me for many years, until my ISP started blocking protocol it for no good reason.   (I do have a static IPv4 address.)

While the goal of this proposal is commendable I think it's a bit
premature - not until native IPv6 has significant penetration 

Google is seeing ~4.5% of clients via IPv6, compared to ~0.5%
in 2011. Of course it's a matter of opinion whether that is
"significant" or not.

It's not enough penetration to justify a conclusion that most people using 6to4 have a viable alternative.

Keith

--------------050502050004060903030404-- From nobody Thu Oct 30 17:12:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7299F1A8981 for ; Thu, 30 Oct 2014 17:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7uLzpjUCVtZ for ; Thu, 30 Oct 2014 17:12:30 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252551A897B for ; Thu, 30 Oct 2014 17:12:30 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id g10so6158793pdj.10 for ; Thu, 30 Oct 2014 17:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RrquvB62Vn6qfSO9S8isnrA1PYvq2Fm5MJju2tVOy3s=; b=Z/cRdDy4kAhvt2ohZJEE9SzEa6cNz+gQOkydZk+alzJuOR0vgW94etRHxczcdOBrUA De25FiNOKRG5f/BL2xllVjeOI2leMxmfnxKqrtNVVsB7GKuHko7oFCcmlAEtoL/N1i1/ zcOr3WG2pd4QK+vp30Zrr1wk6E3nrLoC11cBQFscQCtUjfkm9jgXqjQg12jLyjiRfcqU A63/B98QX/b4HlKTn+IsnP1tU5/RTUHZ+H6Y9yd9JsN+SfYR/mmClg85tXF008h9srwl ufjoBpvBCCpz/ebeNRJ5/MRqEBWoPrJESG4ArmSZf1YJgIjKvSlNstEW0RhxAq/mnXEH eA7Q== X-Received: by 10.70.49.232 with SMTP id x8mr21155981pdn.4.1414714349785; Thu, 30 Oct 2014 17:12:29 -0700 (PDT) Received: from [192.168.178.23] (18.200.69.111.dynamic.snap.net.nz. [111.69.200.18]) by mx.google.com with ESMTPSA id fv4sm8174384pbd.47.2014.10.30.17.12.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 17:12:28 -0700 (PDT) Message-ID: <5452D3F3.50304@gmail.com> Date: Fri, 31 Oct 2014 13:12:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> In-Reply-To: <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/thmKTMNLmYUXAYvSZRT7UhNUUBA Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:12:32 -0000 On 31/10/2014 07:10, Owen DeLong wrote: >> p.s. Aside from the potential of this proposal to break things for people who are currently successfully using 6to4 and who do not yet have a native v6 alternative available, other things that bug me rather strongly about this document are its implicit position(s) that (a) IP-in-IP tunneling is something you shouldn't expect to work and therefore shouldn't be doing and (b) you shouldn't be using tunneling to bypass your ISPs routing. I am emphatically opposed to both of those positions and feel that this document takes a really carrier-centric (and customer-hostile) view that is not appropriate for IETF to be taking. I really don't see that in the document. The problems with anycast 6to4 are not generic problems of protocol 41, and afaik the blocking of protocol 41, when it occurs, is mainly done by corporate firewalls. Enterprises would often like to block any kind of non-encrypted IP-in-IP tunnel because they view them as security bypasses. Anyway, please suggest text changes. Brian > I agree with both of these objections. > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Oct 30 17:26:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FE01A88B1 for ; Thu, 30 Oct 2014 17:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SkrVVMS_626 for ; Thu, 30 Oct 2014 17:26:34 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948621A87AC for ; Thu, 30 Oct 2014 17:26:34 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so6151234pdj.14 for ; Thu, 30 Oct 2014 17:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4IvG2XcLp/yrdZGd5qhkZToe5ymvduKf0bqrbaGSHnk=; b=Vg++zDTIh0rxB7pdychS8eqTS1DAQdUjI4vI+3hxEyPExPNeOKTPENtXQKmHLYosDb qDuMiX01/wdnr89LDoY5O2b7usIoC9LVEpwXgBjP8jwyFzpH97H9f+UZafsqkYC951jg w/Lpgv2R2alg9ejCgLo/8k/p9Za1jT0XBgofXzsrnk7bn4/XijQv21drQ+n99dCNAaa0 8lYYQ+sPp6EpIzc1je+nioZJQ3pPPiHIoqSxvUBC0RFHfRO4ZVtZAlpRxNFgwTa54Vxj edcU7HTF2ce4wWVOQoIdf0+hnh59eimSY+pSUP5/5plWYOLWQ79xR9EcJiC9oJ/qo9uQ saKg== X-Received: by 10.66.129.142 with SMTP id nw14mr20841343pab.119.1414715194217; Thu, 30 Oct 2014 17:26:34 -0700 (PDT) Received: from [192.168.178.23] (18.200.69.111.dynamic.snap.net.nz. [111.69.200.18]) by mx.google.com with ESMTPSA id i10sm8233240pdr.21.2014.10.30.17.26.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 17:26:33 -0700 (PDT) Message-ID: <5452D73F.9000504@gmail.com> Date: Fri, 31 Oct 2014 13:26:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> In-Reply-To: <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MP1k1aUBDr2BsT3SPXBMD09TS4E Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:26:36 -0000 On 31/10/2014 12:06, Owen DeLong wrote: >> On Oct 30, 2014, at 3:48 PM, Brian E Carpenter wrote: >> >> On 31/10/2014 06:06, Antonio Querubin wrote: >>> On Wed, 29 Oct 2014, Brian E Carpenter wrote: >>> >>>> Personally I have changed my mind. The progress on ISP-provided IPv6= has >>>> been significant, Teredo has basically vanished, and I don't see a >>>> case for >>>> paying the operational and trouble-shooting costs of 6to4 any more. >>>> The draft >>> Progress? Perhaps. Significant? Depends on whether any of your ISP= s >>> provide IPv6. In my pond the average joe consumer still doesn't have= >>> easy access to native IPv6 from the local ISPs. I know because I wor= ked >>> for the last local ISP that did. It was bought out by someone who >>> didn't care for IPv6 and promptly shut it all off - no I didn't stick= >>> around. Since then I don't know of any local ISP that offers native >>> IPv6 to non-business customers. >>> >>> I suspect there are many other places where this would be true. If t= he >>> response is 'go get a tunnel' I would ask how easily/quickly could yo= u >>> set that up for a new residential DSL or cable modem user using a sin= gle >>> computer? >=20 > I could set it up very quickly and easily. I could probably do it in un= der 15 minutes, > but let=E2=80=99s say 1/2 hour to be overly cautious. >=20 > http://tunnelbroker.net >=20 > There=E2=80=99s even help for exactly how to configure a variety of sys= tems and routers. >=20 >>> While the goal of this proposal is commendable I think it's a bit >>> premature - not until native IPv6 has significant penetration=20 >> Google is seeing ~4.5% of clients via IPv6, compared to ~0.5% >> in 2011. Of course it's a matter of opinion whether that is >> "significant" or not. >=20 > I think more significant is that 100% of Comcast Residential customers = now have > the ability to go IPv6 if they have capable equipment. >=20 > I expect as modems/routers get replaced over the next 1-2 years, that=E2= =80=99s going to make for > a much bigger increase than the last 3 years. >=20 >>> and/or >>> 6in4 tunnelling is more commonplace in consumer grade routers. >=20 > It=E2=80=99s not that uncommon today. DDWRT generally supports it. Almo= st all of the IPv6 capable consumer grade routers from D-Link, Netgear, A= pple, et al support it. You mean support for manually configured tunnels per RFC 4213, or what? (My FritzBox has great native IPv6 support but no tunnel support that I can find, and my D-Link box is old.) Brian >> I predict that this will not change, but we might see pressure for >> 464xlat in CPEs. >=20 > 464xlat isn=E2=80=99t currently there. 6in4 is pretty common in my expe= rience. >=20 > YMMV. >=20 > Owen >=20 >=20 >=20 From nobody Thu Oct 30 20:56:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4D1A8A96 for ; Thu, 30 Oct 2014 20:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldK2JMtySohV for ; Thu, 30 Oct 2014 20:56:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305151A8A83 for ; Thu, 30 Oct 2014 20:56:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD06044; Fri, 31 Oct 2014 03:56:14 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 03:56:14 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.162]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 11:56:10 +0800 From: "Liubing (Leo)" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= Thread-Topic: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC Thread-Index: AQHP68aUMVG3aJmxgku+68Zh3hvzF5w7ok2AgAHqGMD//+BHgIAHXHqwgAG/4YCAAHaaAIAA5awAgAG3aFA= Date: Fri, 31 Oct 2014 03:56:08 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45589E2D44@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> <54514014.40604@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PLPi5OJX4WKao2iW79XyAhD8YAc Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 03:56:18 -0000 SGkgQW5kcmV3LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcg8J+RvSBZb3VydGNoZW5rbyBbbWFpbHRvOmF5b3VydGNo QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMzAsIDIwMTQgNToxMSBQTQ0K PiBUbzogQnJpYW4gRSBDYXJwZW50ZXINCj4gQ2M6IExpdWJpbmcgKExlbyk7IHY2b3BzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtZGhjcHY2LXNsYWFj LXByb2JsZW0gV0dMQw0KPiANCj4gT24gMTAvMjkvMTQsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiA+IE9uIDMwLzEwLzIwMTQgMDE6MjQs IEFuZHJldyDwn5G9IFlvdXJ0Y2hlbmtvIHdyb3RlOg0KPiA+IC4uLg0KPiA+PiBIb3cgZG9lcyB0 aGUgaG9zdCBba25vd10NCj4gPj4gdGhhdCBhIHBlZXIncyBVTEEgcHJlZml4IGlzIG9uLWxpbmsg c28gaXQgY291bGQgdGFsayBkaXJlY3RseSB3aXRob3V0DQo+ID4+IGEgcm91dGVyID8NCj4gPg0K PiA+IFdoeSBpcyB0aGlzIGRpZmZlcmVudCBmcm9tIHRoZSBxdWVzdGlvbjoNCj4gPg0KPiA+IEhv dyBkb2VzIHRoZSBob3N0IGtub3cgdGhhdCBhIHBlZXIncyBHVUEgcHJlZml4IGlzIG9uLWxpbmsg c28gaXQgY291bGQNCj4gPiB0YWxrIGRpcmVjdGx5IHdpdGhvdXQgYSByb3V0ZXIgPw0KPiANCj4g SXQncyBub3QuIEFuZCBteSAid2l0aG91dCBhIHJvdXRlciIgd29yZGluZyB3YXMgY2x1bXN5IC0g aXQgd2FzIHN1cHBvc2VkIHRvDQo+IGVtcGhhc2l6ZSB0aGUgd2F5IHR3byAgb24tbGluayBob3N0 cyBjb21tdW5pY2F0ZSAoZGlyZWN0bHksIHdpdGhvdXQgdGhlDQo+IGludm9sdmVtZW50IG9mIHRo ZSByb3V0ZXIpLCBub3QgdGhlIGFic2VuY2Ugb2YgdGhlIHJvdXRlciBhbHRvZ2V0aGVyLiBJIGFt DQo+IHNvcnJ5IGZvciBjb25mdXNpbmcgdGhlIGxhbmd1YWdlLg0KPiANCj4gSW4gYm90aCBVTEEg YW5kIEdVQSBjYXNlcyB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIGEgcm91dGVyIHdvdWxkIG5lZWQg dG8NCj4gaGF2ZSB0aGUgcHJlZml4KGVzKSBpbiB0aGUgUkEsIHdvdWxkbid0IGl0ID8NCj4gDQo+ IEJ1dCwgb24gdGhlIG9yaWdpbiBvZiB0aGUgIlVMQSIgYW5kIHRoaXMgc3ViLXRocmVhZDoNCj4g DQo+IDxxdW90ZT4NCj4gPiBJbiB0aGUgY2FzZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuMSwg dGhlIGhvc3Qgd291bGQgb25seSBoYXZlDQo+ID4gbGluay1sb2NhbCBhZGRyZXNzZXMuDQo+IFtC aW5nXSBPciBtYXliZSBzZWxmLWdlbmVyYXRlZCBVTEFzLiAoQnV0IG9mIGNvdXJzZSwgaXQgaXMg bm90IHRoZSBwb2ludCBvZg0KPiB0aGlzIGRvY3VtZW50LikgPC9xdW90ZT4NCj4gDQo+IEkgd2Fz IHRyeWluZyB0byB1bmRlcnN0YW5kIGhvdyB0aGF0IHN0cmF3IG1hbiB3YXMgc3VwcG9zZWQgdG8g d29yay4NCj4gDQo+IEEgcG9zc2liaWxpdHkgb2Ygc3RhdGljYWxseSBhc3NpZ25lZCBHVUFzIGlu IHRoZSBmaXJzdCBwbGFjZSBzb21laG93IGVzY2FwZWQNCj4gbWUgLSB3aGlsZSwgaW4gZmFjdCwg YSBzZXJ2ZXIgYWRtaW4gdGhhdCBtYW5hZ2VzIHRoZSBhZGRyZXNzZXMgYnV0IGRvZXMgbm90DQo+ IGNvbnRyb2wgd2hlcmUgaXMgdGhlIHRvZGF5J3MgRE5TIHNlcnZlciBpcyBhIG11Y2ggbW9yZSBw bGF1c2libGUgY2FzZS4gVGh1cw0KPiB0aGF0IGNvbW1lbnQgdG8gd2hpY2ggQmluZyByZXBsaWVk IHdpdGggIlVMQSINCj4gc3RyYXcgbWFuIHNob3VsZCBub3QgaGF2ZSBiZWVuIHRoZXJlIGluIHRo ZSBmaXJzdCBwbGFjZS4gVGhhbmtzIGZvcg0KPiB0cmlnZ2VyaW5nIG1lIHRvIHJlYWxpemUgdGhh dC4NCj4gDQo+IEJpbmcsDQo+IA0KPiBwbGVhc2UgZGlzcmVnYXJkIHRoZSBwYXJ0IG9mIG15IHBy ZXZpb3VzIG1haWwgcmVsYXRlZCB0byBVTEFzLg0KW0JpbmddIFRoYW5rcyBmb3IgdGhlIGRpc2N1 c3Npb24gYW5kIGNsYXJpZmljYXRpb24uDQoNCj4gV291bGQgYmUgc3RpbGwgaW50ZXJlc3Rpbmcg dG8gaGVhciB5b3VyIG9waW5pb24gYWJvdXQgcmZjNjEwNi4NCltCaW5nXSBUaGlzIGlzIGluZGVl ZCBhbiBpc3N1ZS4gVGhlcmUgd2VyZSBzb21lIHBlb3BsZSBhbHNvIHJhaXNlZCB0aGlzIHByb2Js ZW0gYmVmb3JlLiBXZSd2ZSBjYXB0dXJlZCB0aGUgcHJvYmxlbSBpbiB0aGUgR3VpZGFuY2UgZHJh ZnQgKHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LXY2b3BzLWRoY3B2 Ni1zbGFhYy1ndWlkYW5jZS0wMyNzZWN0aW9uLTIuMi4zLCB0aGUgbGFzdCBidWxsZXQpLg0KRm9y IHRoZSBQUyBkcmFmdCwgaXQgaXMgbW9zdGx5IHJlZ2FyZGluZyB0byB0aGUgaW50ZXJhY3Rpb24g YmV0d2VlbiB0d28gcHJvdG9jb2xzIChESENQdjYvU0xBQUMpLiBBbHRob3VnaCB0aGUgdHdvIHBy b3RvY29scyBib3RoIGhhdmUgdGhlIEROUyBvcHRpb24sIHRoZXkgYXJlIHNlcGFyYXRlIGluIHBy b3RvY29sIGxldmVsLiBTbyB3ZSBvbmx5IGluY2x1ZGUgdGhpcyBpc3N1ZSBpbiB0aGUgR3VpZGFu Y2UgZHJhZnQuIA0KVGhhdCdzIG15IGNvbnNpZGVyYXRpb24sIGJ1dCBJJ2QgbGlrZSB0byBoZWFy IHlvdXJzLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCj4gLS1hDQo+IA0KPiA+DQo+ID4gICBC cmlhbg0KPiA+DQo+ID4NCg== From nobody Thu Oct 30 21:29:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284301A8A9F for ; Thu, 30 Oct 2014 21:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.203 X-Spam-Level: * X-Spam-Status: No, score=1.203 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nEHxBoVKbcb for ; Thu, 30 Oct 2014 21:29:33 -0700 (PDT) Received: from nm33-vm3.bullet.mail.gq1.yahoo.com (nm33-vm3.bullet.mail.gq1.yahoo.com [98.136.216.242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DD91A8A83 for ; Thu, 30 Oct 2014 21:29:33 -0700 (PDT) Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 31 Oct 2014 04:29:33 -0000 Received: from [216.39.60.180] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 31 Oct 2014 04:26:33 -0000 Received: from [66.196.81.174] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 31 Oct 2014 04:26:33 -0000 Received: from [98.139.212.219] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 04:26:32 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 31 Oct 2014 04:26:32 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 900746.79405.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 77879 invoked by uid 60001); 31 Oct 2014 04:26:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1414729592; bh=zoKKJxIgP3M5SaIRgJ+XbAEFD+Ub9nd1VgfgWFi/V/E=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EKdasRj329IAK0+34ENspI9Gp7Vmf+KMCZUBQkDrSiSlvz4YvtNAkFAZIQ2jZRg+GHAxMzdayr0QdKUY8JB4Y/z64hLO5cZaHVKwvq0ugKWmDdrXWkC0ZQ+ljtNQLv7N0+qPVzanyR9LSafaOpwrjjtTVnrsZCJvFbhjWj97rAo= X-YMail-OSG: FNesC7YVM1nq5DwBILhDBSoJmkIFUKODpdMCfK3mEaqSIwF a3WraUtU9PzFNrLmXi8_iUPFhNVKCWITBFpivTYRFNinuvvQUrUUunXVXDP_ _NuAUoGBB5AWq5SZEdakgzG0HtwaoGV2jvMwMmNjT8f6Ofh8h6OYivGeYHLO Jj3TabJATxRwhWn6mfGe7nMmbaslYNAuZfdbcXPggb21AbgTIPMUTbFqZDMV udQmpd3it0oZKmu9sbSgQklWKXsegUp5ubpP.KYUTydOyBwo_odR2npEPXnA 3f4AMzbxTrGR2s0AZ0l3uiy7Q.I8leM3r7MVhlw6KVVaEO5X_LrhRevEyPJk m.LdoYsDCBGUu.n09WYLFazMa08zpRq7Ug7Z0deFJMIdOscwbydDUdB1RGnx BR0WuhG9LzyzxgxYyPPjtE6UHukNXppyatVh3_Ajy9_vDT__Qflyr0xdwFeO 79l5q0Cjcleim2q.1_.7pMMv3g6HQotNNbjXiwehsI_SDEXm0.lwvadWuOxf MwQRNGye4rexHeG_O6QKfVa_TdgzYcPqhfKs527LXsiamOXK4IcVO8xPvokW wFY8- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Thu, 30 Oct 2014 21:26:32 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBGcmVkIEJha2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20.Cj5UbzogRXJpayBOeWdyZW4gPGVyaWsraWV0ZkBueWdyZW4ub3JnPiAKPkNjOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPiAKPlNlbnQ6IFdlZG5lc2RheSwgMjkgT2N0b2JlciAyMDE0LCA4OjE5Cj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXZ5bmNrZS12Nm9wcy1oYXBweS1leWViYWxscy1jb29raWUtMDAudHh0Cj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <71D94EF2-2740-4BC8-BA1D-40A667A9BD8E@cisco.com> Message-ID: <1414729592.66054.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Thu, 30 Oct 2014 21:26:32 -0700 From: Mark ZZZ Smith To: "Fred Baker \(fred\)" , Erik Nygren In-Reply-To: <71D94EF2-2740-4BC8-BA1D-40A667A9BD8E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HBbW5SutCp4apD1-mZkdSmTDw6A Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 04:29:35 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Fred Baker (fred= ) =0A>To: Erik Nygren =0A>Cc: IPv6 O= perations =0A>Sent: Wednesday, 29 October 2014, 8:19=0A>Su= bject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cooki= e-00.txt=0A> =0A>=0A>=0A>=0A>=0A>On Oct 28, 2014, at 2:07 PM, Erik Nygren <= erik+ietf@nygren.org> wrote:=0A>=0A>On Tue, Oct 28, 2014 at 10:29 AM, Fred = Baker (fred) wrote:=0A>=0A>I would be interested in folks= =E2=80=99 view of this. Is this interesting?=0A>>=0A>=0A>=0A>This is mentio= ned in section 8.2 of rfc6883 but keeps coming up over and over again=0A>= =0A>so may be worth calling out more clearly. I'd title it in some way tha= t didn't make it seem like=0A>a happy eyeball specific issue.=0A>=0A>It's n= ot just a happy eyeballs issue. It also happens with dual-stack environmen= ts where cookies or session or authentication tokens span origins where som= e servers are dual-stack and some are IPv4-only. (For example, an auth gr= anting service grants bearer tokens locked to the client IP address and the= n the client connects to some other service on a different hostname and pas= ses along the tokens. Even absent Happy Eyeballs these can be on different= IP versions.)=0A=0AI'd think Multipath TCP could also cause these issues, = as the MPTCP subflows are not limited to the IP protocol that application '= thinks' it is talking. Even MPTCP subflows of the same IP version to the sa= me destination across session might end up with this issue if the subflows = come up in different order.=0A=0A=0A>=0A>=0A>=0A>An important thing, in my = mind, is that Happy Eyeballs isn=E2=80=99t fundamentally about IPv4 and IPv= 6, it=E2=80=99s about multihoming, which is to say that I have more than on= e address and more than one route, and it is conceivable that one or more o= f my addresses or routes doesn=E2=80=99t work. If I am multihomed in the se= nse of having multiple IPv4 paths, I can have the same problems, and I can = have the same problems if I am IPv6-only but have multiple upstreams.=0A>= =0A>=0A>=0A>=0A>=0A>The large-scale NAT/CGN issue does make this not just a= n IPv6 issue. At least some systems I've seen then check the IP in the coo= kie to make sure it's in the same /24 rather than the exact same IP, but th= at doesn't help in the dual-stack world.=0A>>=0A>>Another issue beyond Happ= y Eyeballs is that privacy addressing bites you here as well for cookies th= at are used across different TCP connections spanning a privacy address rot= ation.=0A>>=0A>>=0A>>Having some more clear "don't do this" to point people= to would be good, but I suspect we'll have many years of cleaning up appli= cations doing this.=0A>>=0A>=0A>=0A>_______________________________________= ________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/ma= ilman/listinfo/v6ops=0A>=0A>=0A> From nobody Fri Oct 31 00:28:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8141A8AE7 for ; Fri, 31 Oct 2014 00:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4DIZI421bF8 for ; Fri, 31 Oct 2014 00:28:22 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F70C1A8AEB for ; Fri, 31 Oct 2014 00:28:21 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 700631009F362; Fri, 31 Oct 2014 07:28:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414740498; bh=nf6f0f87fJCqSEyyhDaMuk/CRI2KrK9GifVrtAmF5OM=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Ji44viKjEbQYpElDT4ngAZ2dFhtBX2S0XLhBVQeWCJ65xRxRTGNf8GdE/h5eRowR6 HbW6YMC3fBovZgOcFP7L6Q0Rymw8VltmguHZCuKTglTXr9X9I1RsNY/Y+PwTBTyU0N 5pMNh2kc9j7teS3bXP1wZp0R2+LcozcGLkYURW3gJBvbXfQy9s8QOFWpfGaHTGdYw8 Wg+3hyoVadvOVcX+5W0SMDdTAQeMeJiShkgPv37GVRXECIbgXi0PMr1PcEK0CwPTaD m0LZQze7lOw/K9pJZiTTDO4IXR/Wwyumo8T3SJphFh0NhFO3iatC/CFeITVUiY/kYs 2pRddb95YK0Ng== Message-ID: <54533A0F.1050502@massar.ch> Date: Fri, 31 Oct 2014 08:28:15 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore , Gert Doering References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> In-Reply-To: <5452A333.7060300@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CzHpIf0vQSQbHfOLnLAYCEh6cs0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 07:28:24 -0000 On 2014-10-30 21:44, Keith Moore wrote: > On 10/30/2014 04:41 PM, Gert Doering wrote: >>>> Before you get a 6to4 tunnel, stick to IPv4-only. 6to4 tunneled IPv6 >>>> > >to the "wild Internet" (unlike "to your friend who also uses >>>> 6to4, no >>>> > >gateway involved") will be SO much worse than "just use native IPv4" >>>> > >that you're doing nobody a favour doing this. >>> >It's a mistake to assume that the reason for using IPv6 is to talk to >>> >the "wild Internet" (especially if you define "wild Internet" as the >>> set >>> >of hosts that talk IPv4 and might also happen to talk IPv6). The >>> >motivation to use IPv6 is driven by different applications than IPv4 >>> was. >> So in which way does this draft impact your ability to talk IPv6 between >> your nodes? > It impacts my ability to talk IPv6 with any other nodes for which 6to4 > currently works, which are not necessarily "my" nodes, nor nodes that > also support IPv4. To give one example, I've found that video > conferencing over 6to4 can work in situations in which STUN-based NAT > traversal fails. You are saying you can transport proto-41 packets through a NAT setup, that while STUN does not work? I would really love to see the details. As NATs that know about proto-41 or are able to stick it to a specific endpoint are rare. In most cases to get proto-41 working behind NAT you will have to force the NAT box into "DMZ mode" (or whatever the flavor of the name is). And even then, typically they do not do proto-41. The DMZ trick will fail anyway, as you cannot teach your local host to use the local IP address (eg 192.0.2.1) and configure it to listen to a 6to4 address of 2002:::: Thus I am *really* wondering how that is supposed to work. Unless you mean you let the NAT box do the 6to4, as then, indeed things get better. That requires also the other host to do 6to4. But in that situation you will have an up-to-date enough host that will properly handle STUN, uPNP or NAT-PMP and should thus not have any issues with NAT. You will have a much better chance using Teredo in this situation (which is what Xbox One does btw :) Or much better: just use TSP or AYIYA, then you have determinism on your side. Greets, Jeroen From nobody Fri Oct 31 00:32:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B7C1A8AE6 for ; Fri, 31 Oct 2014 00:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVg-SFIGMaWi for ; Fri, 31 Oct 2014 00:32:03 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FF41A8ADE for ; Fri, 31 Oct 2014 00:32:03 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 8C56410039BEA; Fri, 31 Oct 2014 07:31:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414740720; bh=w8kTR919rZ84Kgqk85ptBaTM6G3NZ9iAQ5cexqPmYtI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=D47S4XDhlpj4502PSGAcHqr6BlwS8dCYxiNjmg55UbZwCbHGx3LG9NccLT+n/rRXl O4pWcMngR8f8tQyRAqzOJUHUNIVgelje8JZnPMbaCjeBzjGRu9rUzZhA4KFQ+liuWB xpIvOlMCdr6b+MwpiXz2uHSH9jUePox2NyPEdSTN349hkc/657Lr+3AoJ1ZYd8RRng s9vHxVxDQJTUv9853XO8cSholQMUtKFFcTACac/H+7dduST/EBdZpiB/rJt3arNbij wr33Kw+IseHf6k4GwBisZ/Q+bxBahXHJCdTmGnu/HE/LzYLEyMF46oEIYYKvc/Rpip JPQJsl/l1ZMoQ== Message-ID: <54533AED.3010506@massar.ch> Date: Fri, 31 Oct 2014 08:31:57 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Gert Doering , Antonio Querubin References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> In-Reply-To: <20141030185237.GR31092@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QjY068oi0-pNX3XlFddCPBRnju8 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 07:32:05 -0000 On Thu, Oct 30, 2014 at 07:06:40AM -1000, Antonio Querubin wrote: > While the goal of this proposal is commendable I think it's a bit > premature - not until native IPv6 has significant penetration > and/or 6in4 tunnelling is more commonplace in consumer grade > routers. If a device can do 6to4 then it is also doing 6in4. Same for those devices doing 6rd. Though with 6rd you can trick them to be configured as a 6in4 tunnel in a /32bit space, and thus a single endpoint. For 6to4 that is not possible. But in the end that is just a GUI issue. > Progress is good but availability is what counts operationally. With the large amount of failure scenarios of 6to4, I can only assume you want 6to4 gone as well ;) Greets, Jeroen From nobody Fri Oct 31 03:38:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15941A0AF7 for ; Fri, 31 Oct 2014 03:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTzZ8jO59Wbe for ; Fri, 31 Oct 2014 03:38:12 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB651A00AB for ; Fri, 31 Oct 2014 03:38:12 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id a13so647085igq.17 for ; Fri, 31 Oct 2014 03:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6u+VShHSvilczQ9hGE3QeaZlf8xvcPzxakQSDG0Za50=; b=ByGB4pSJcKRP9JpHVfZyCEFwnnqvaQnhdu4fK+VPyPbKu4PWHaeNz6PxMrB2VjXlGI U914ZrqSbDSC6oDgwCBIbXsE3MjAMZvWX7dXehda64l+d96U+TZqPTR4lDu4y8gYPmAU IEr/tKH8PtippJQYC3+XWA8fo1kgAyfaGFkKad9Ka41z8NJNIzbBltirZM1SuYmDWr2/ XJ18xUz8PvOQMbE0Da9Cy89PQeIunh9GyCKLa3IJVcTG/2jP8+ZYxTV39Y/SnuR/8rmD StJZcMFgONHwcOLMmDQh6kM1GTIiUyuK6h+BrWkF0mDDeS6lXq9EuYg8vZuzZ6JmgVjQ j3IA== MIME-Version: 1.0 X-Received: by 10.42.86.142 with SMTP id u14mr1217974icl.77.1414751891586; Fri, 31 Oct 2014 03:38:11 -0700 (PDT) Received: by 10.107.137.194 with HTTP; Fri, 31 Oct 2014 03:38:11 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45589E2D44@nkgeml506-mbx.china.huawei.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> <54514014.40604@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E2D44@nkgeml506-mbx.china.huawei.com> Date: Fri, 31 Oct 2014 11:38:11 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sSQbZXuPdFrCqb2_wdtJR5MHs9w Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 10:38:13 -0000 Hi Bing, On 10/31/14, Liubing (Leo) wrote: [snip] >> Would be still interesting to hear your opinion about rfc6106. > [Bing] This is indeed an issue. There were some people also raised this > problem before. We've captured the problem in the Guidance draft (see > https://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-03#section-2.2.3, > the last bullet). ok, thanks for the link! on that one, might be useful to add an explicit reference to RFC6106 as a normative reference. > For the PS draft, it is mostly regarding to the interaction between two > protocols (DHCPv6/SLAAC). Although the two protocols both have the DNS > option, they are separate in protocol level. So we only include this issue > in the Guidance draft. > That's my consideration, but I'd like to hear yours. The draft highlights the less common scenarios with various values of flags in the RA and their transitions - and the behavior of hosts during these scenarios. To me, the RFC6106/DHCPv6 interaction would fall into the same bucket, from the practical administration perspective. The questions that pop up are like: What do the hosts do if RDNSS is within the RA but the "O" flag is set ? Do the hosts keep their DNS information if we switch the stateless DHCPv6 off, use only the RDNSS ? If I want to maximize the chances of devices working, do I use RDNSS, or stateless DHCPv6, or both ? The mention in SLAAC guidance document just says that the host would get confused if different information gets sent, is that the only scenario ? (I did not test extensively myself, so asking if you have more info). There is draft-gont-6man-slaac-dns-config-issues that talks about the RDNSS specific issues, and I do not know whether RDNSS+DHCPv6 interaction has just not been tested or does not have any issues. Now, of course it is a lot of additional testing work, so adding anything like that into the document would be contingent on more participants of WG saying it is a useful idea vs. shipping the document as is. --a > > Best regards, > Bing > >> --a >> >> > >> > Brian >> > >> > > From nobody Fri Oct 31 04:03:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3571A19E5 for ; Fri, 31 Oct 2014 04:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ECMqpjXHCed for ; Fri, 31 Oct 2014 04:03:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A751A03A8 for ; Fri, 31 Oct 2014 04:03:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s9VB3V1c020667; Fri, 31 Oct 2014 12:03:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D3C720A705; Fri, 31 Oct 2014 12:03:31 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5BDA62059B0; Fri, 31 Oct 2014 12:03:31 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s9VB3QYS004386; Fri, 31 Oct 2014 12:03:30 +0100 Message-ID: <54536C7D.20301@gmail.com> Date: Fri, 31 Oct 2014 12:03:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian E Carpenter , Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> In-Reply-To: <5452D3F3.50304@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZUp5qtbYQzqgUrOQBTwppn9b0ec Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 11:03:54 -0000 Hi Brian, I take advantage of your invitation to suggest text changes although I am not sure it covers topics unrelated to the one discussed in that email. I think the document should mention what are the recommended alternatives. Until now we see recommendations of particular tunnel brokers such as Hurricane Electric's (is it really that company behind it or just a reuse from a distant past?) and SixXs or AYIYA, and also recommendations to move to native IPv6. There should be balance between these recommendations, because: - tunnel broker should be considered as intermediate solution to native IPv6 and as such may incur additional renumbering efforts. - tunnel broker offers some advantages over 6to4, e.g. IPsec security is possible because it's not an anycast address. - tunnel broker creates new inconvenients, e.g. a new 'focal point' or single point of failure. - tunnel brokers seem well used and maintained. Alex Le 31/10/2014 01:12, Brian E Carpenter a crit : > On 31/10/2014 07:10, Owen DeLong wrote: >>> p.s. Aside from the potential of this proposal to break things for people who are currently successfully using 6to4 and who do not yet have a native v6 alternative available, other things that bug me rather strongly about this document are its implicit position(s) that (a) IP-in-IP tunneling is something you shouldn't expect to work and therefore shouldn't be doing and (b) you shouldn't be using tunneling to bypass your ISPs routing. I am emphatically opposed to both of those positions and feel that this document takes a really carrier-centric (and customer-hostile) view that is not appropriate for IETF to be taking. > > I really don't see that in the document. The problems with anycast 6to4 > are not generic problems of protocol 41, and afaik the blocking of > protocol 41, when it occurs, is mainly done by corporate firewalls. > Enterprises would often like to block any kind of non-encrypted > IP-in-IP tunnel because they view them as security bypasses. Anyway, > please suggest text changes. > > Brian > >> I agree with both of these objections. >> >> Owen >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Oct 31 05:58:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817D91A8ADF for ; Fri, 31 Oct 2014 05:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlQe3qHXWCLr for ; Fri, 31 Oct 2014 05:58:04 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC46E1A8A89 for ; Fri, 31 Oct 2014 05:58:04 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id a13so870062igq.5 for ; Fri, 31 Oct 2014 05:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zFZIsnXNE+uyVjmv6pO3KRCrPZeQz5vxBxTxQT2Rjmo=; b=AM4YyfHy0OMFpGwqhhgXAHhia1fJ76l6SOzayMv1N2/ZbrNj15lPb5I8vx6EzyP6wT gRrdhlizXb1T5XpY3Fr3vZ600jBFPstBMmTXZhnr5AhywGyBnUdl/Jo9qBj4C3k/uJvo VlvEnT7ph30Ej9UBE3447FTOS4MhF9OARpouwFnkqUCNpW/6UpUgeuxshNcjOH54iV7y tv+/KABLenrCXdj5xFas97z6t0cAwXZUHPJUpx1Ih/TUgEB3u+8XDgsTv+yGgtdHxliI BhTYB7yIynEWUvF5NLG7Sdv4Hf1XGWgqZuUi9OFa2S/lmzToP4szFojkahQyTDWUj9Yu YMrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zFZIsnXNE+uyVjmv6pO3KRCrPZeQz5vxBxTxQT2Rjmo=; b=mqcJISSabVVzY68NPx/iB7J0btzl8gNCzu9BtFBBUeiQovYehnN6ebe8zizWDitE89 9sNr7zn/kqTQJk8LGuX8uellQQuQsFdHkqfdaDkM/r6WJlpZLnlfEN8idNi2Yp2C32wj VKiBpGWMYDRKEmi7tyiOUFIIZyGxQXH5FDLtAspmbbIIvbpAjCQXfc9fMQ5nX+y6GJL7 s4ffAsA6SoG94hd/gBrW2BB+fwWxvQ9MMj/GsRy15C/JT3c4qyciAxcHTVeDq9z6DMM8 NkFn+9CkG6tBpCVbKwIkLLP3UTlwr63TK6g8Kec9Vn+m4wKcTEbbL7rf6+8KGgDekD32 rGWw== X-Gm-Message-State: ALoCoQnHrKDgUs3Gkx20bM2vDUYVUTzFCq2oJtFlkjIe8y4GDvt0P3xmKdVyg3vHMTQjvZ4lfDFH X-Received: by 10.50.85.101 with SMTP id g5mr4037368igz.40.1414760276078; Fri, 31 Oct 2014 05:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.176.203 with HTTP; Fri, 31 Oct 2014 05:57:35 -0700 (PDT) In-Reply-To: References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> <54514014.40604@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E2D44@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Fri, 31 Oct 2014 21:57:35 +0900 Message-ID: To: =?UTF-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= Content-Type: multipart/alternative; boundary=089e0149c248b2f3bb0506b78b73 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/bPDhcM51iUY3RFKiqmHKNFipsCg Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 12:58:06 -0000 --089e0149c248b2f3bb0506b78b73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2014 at 7:38 PM, Andrew =F0=9F=91=BD Yourtchenko wrote: > Now, of course it is a lot of additional testing work, so adding > anything like that into the document would be contingent on more > participants of WG saying it is a useful idea vs. shipping the > document as is. > The way I see it, the value of the document is in the testing, not in the operational guidance (of which there is very little). Thus, more testing would increase the value of the document. --089e0149c248b2f3bb0506b78b73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 7:38 PM, Andrew =F0=9F=91=BD Yourtchenko <ayourtch@g= mail.com> wrote:
Now, of = course it is a lot of additional testing work, so adding
anything like that into the document would be contingent on more
participants of WG saying it is a useful idea vs. shipping the
document as is.

The way I see it, the v= alue of the document is in the testing, not in the operational guidance (of= which there is very little). Thus, more testing would increase the value o= f the document.
--089e0149c248b2f3bb0506b78b73-- From nobody Fri Oct 31 06:21:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AF21A8868 for ; Fri, 31 Oct 2014 06:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7eg8KO9IebG for ; Fri, 31 Oct 2014 06:21:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800DA1A8967 for ; Fri, 31 Oct 2014 06:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4586; q=dns/txt; s=iport; t=1414761666; x=1415971266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zw1hmDJ9KJgVUxCBmGUZsTjqw129WJCkHu7yScpvUK4=; b=RBB3R7Rk4fpA0SKbJCQLyzxyzbZhxFdl8lz0fMwrwVXprwP0p4k+Xyok bNQrKn//V9LPz3CJ95bXtAiIUCxWLAA8mw4XdjK41AVCUqEp3T+zFl/Un f8nzhhM+8a9601s3fYVhkT1Oq8gFkgl2u+NhGw3GQBp+XFzDiBMbVBqsB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4FAEuMU1StJV2b/2dsb2JhbABUCIJrI1RYBIMCyhYKh00CHHsWAQEBAQF9hAIBAQEEAQEBIBE6CxACAQgRBAEBAQICJgICAiULFQgIAgQBDQWILAMSAQy1A5RwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBLY0pgWICIxgbB4J3gVQFhRkFjHeHEIJIgguPW4Ztg3hsgQZCgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,294,1413244800"; d="scan'208";a="368188333" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2014 13:21:05 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9VDL5mJ001432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 13:21:05 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 08:21:05 -0500 From: "Eric Vyncke (evyncke)" To: Mark ZZZ Smith , "Fred Baker (fred)" , Erik Nygren Thread-Topic: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt Thread-Index: AQHP9MNQKJIumVyT6ES71v1qwzlW3ZxKlhWA Date: Fri, 31 Oct 2014 13:21:05 +0000 Message-ID: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <71D94EF2-2740-4BC8-BA1D-40A667A9BD8E@cisco.com> <1414729592.66054.YahooMailNeo@web162204.mail.bf1.yahoo.com> In-Reply-To: <1414729592.66054.YahooMailNeo@web162204.mail.bf1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.55.185.73] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TlvVSKCeSPc-QkL6GUlRj2bQiX0 Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 13:21:09 -0000 TWFyaywNCg0KTXkgdW5kZXJzdGFuZGluZyBvZiBNVENQIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9u IGxheWVyIGFsd2F5cyBzZWVzIHRoZQ0Kc2FtZSAodGhlIGZpcnN0IG9uZSBJIGd1ZXNzKSBJUCBh ZGRyZXNzIGFuZCBkb2VzIG5vdCBzZWUgYWxsIHRoZSBkaWZmZXJlbnQNCm9uZXMgaW52b2x2ZXMg aW4gdGhlIHN1YiBmbG93cy4NCg0KLcOpcmljDQoNCk9uIDMxLzEwLzE0IDA1OjI2LCAiTWFyayBa WlogU21pdGgiIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiB3cm90ZToNCg0KPg0KPg0KPg0K Pg0KPg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRnJvbTogRnJlZCBC YWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPg0KPj5UbzogRXJpayBOeWdyZW4gPGVyaWsraWV0 ZkBueWdyZW4ub3JnPg0KPj5DYzogSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZz4NCj4+ U2VudDogV2VkbmVzZGF5LCAyOSBPY3RvYmVyIDIwMTQsIDg6MTkNCj4+U3ViamVjdDogUmU6IFt2 Nm9wc10gRndkOiBJLUQgQWN0aW9uOg0KPj5kcmFmdC12eW5ja2UtdjZvcHMtaGFwcHktZXllYmFs bHMtY29va2llLTAwLnR4dA0KPj4gDQo+Pg0KPj4NCj4+DQo+Pg0KPj5PbiBPY3QgMjgsIDIwMTQs IGF0IDI6MDcgUE0sIEVyaWsgTnlncmVuIDxlcmlrK2lldGZAbnlncmVuLm9yZz4gd3JvdGU6DQo+ Pg0KPj5PbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCAxMDoyOSBBTSwgRnJlZCBCYWtlciAoZnJlZCkg PGZyZWRAY2lzY28uY29tPg0KPj53cm90ZToNCj4+DQo+Pkkgd291bGQgYmUgaW50ZXJlc3RlZCBp biBmb2xrc+KAmSB2aWV3IG9mIHRoaXMuIElzIHRoaXMgaW50ZXJlc3Rpbmc/DQo+Pj4NCj4+DQo+ Pg0KPj5UaGlzIGlzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDguMiBvZiByZmM2ODgzIGJ1dCBrZWVw cyBjb21pbmcgdXAgb3ZlciBhbmQNCj4+b3ZlciBhZ2Fpbg0KPj4NCj4+c28gbWF5IGJlIHdvcnRo IGNhbGxpbmcgb3V0IG1vcmUgY2xlYXJseS4gIEknZCB0aXRsZSBpdCBpbiBzb21lIHdheSB0aGF0 DQo+PmRpZG4ndCBtYWtlIGl0IHNlZW0gbGlrZQ0KPj5hIGhhcHB5IGV5ZWJhbGwgc3BlY2lmaWMg aXNzdWUuDQo+Pg0KPj5JdCdzIG5vdCBqdXN0IGEgaGFwcHkgZXllYmFsbHMgaXNzdWUuICBJdCBh bHNvIGhhcHBlbnMgd2l0aCBkdWFsLXN0YWNrDQo+PmVudmlyb25tZW50cyB3aGVyZSBjb29raWVz IG9yIHNlc3Npb24gb3IgYXV0aGVudGljYXRpb24gdG9rZW5zIHNwYW4NCj4+b3JpZ2lucyB3aGVy ZSBzb21lIHNlcnZlcnMgYXJlIGR1YWwtc3RhY2sgYW5kIHNvbWUgYXJlIElQdjQtb25seS4gICAo Rm9yDQo+PmV4YW1wbGUsIGFuIGF1dGggZ3JhbnRpbmcgc2VydmljZSBncmFudHMgYmVhcmVyIHRv a2VucyBsb2NrZWQgdG8gdGhlDQo+PmNsaWVudCBJUCBhZGRyZXNzIGFuZCB0aGVuIHRoZSBjbGll bnQgY29ubmVjdHMgdG8gc29tZSBvdGhlciBzZXJ2aWNlIG9uDQo+PmEgZGlmZmVyZW50IGhvc3Ru YW1lIGFuZCBwYXNzZXMgYWxvbmcgdGhlIHRva2Vucy4gIEV2ZW4gYWJzZW50IEhhcHB5DQo+PkV5 ZWJhbGxzIHRoZXNlIGNhbiBiZSBvbiBkaWZmZXJlbnQgSVAgdmVyc2lvbnMuKQ0KPg0KPkknZCB0 aGluayBNdWx0aXBhdGggVENQIGNvdWxkIGFsc28gY2F1c2UgdGhlc2UgaXNzdWVzLCBhcyB0aGUg TVBUQ1ANCj5zdWJmbG93cyBhcmUgbm90IGxpbWl0ZWQgdG8gdGhlIElQIHByb3RvY29sIHRoYXQg YXBwbGljYXRpb24gJ3RoaW5rcycgaXQNCj5pcyB0YWxraW5nLiBFdmVuIE1QVENQIHN1YmZsb3dz IG9mIHRoZSBzYW1lIElQIHZlcnNpb24gdG8gdGhlIHNhbWUNCj5kZXN0aW5hdGlvbiBhY3Jvc3Mg c2Vzc2lvbiBtaWdodCBlbmQgdXAgd2l0aCB0aGlzIGlzc3VlIGlmIHRoZSBzdWJmbG93cw0KPmNv bWUgdXAgaW4gZGlmZmVyZW50IG9yZGVyLg0KPg0KPg0KPj4NCj4+DQo+Pg0KPj5BbiBpbXBvcnRh bnQgdGhpbmcsIGluIG15IG1pbmQsIGlzIHRoYXQgSGFwcHkgRXllYmFsbHMgaXNu4oCZdA0KPj5m dW5kYW1lbnRhbGx5IGFib3V0IElQdjQgYW5kIElQdjYsIGl04oCZcyBhYm91dCBtdWx0aWhvbWlu Zywgd2hpY2ggaXMgdG8NCj4+c2F5IHRoYXQgSSBoYXZlIG1vcmUgdGhhbiBvbmUgYWRkcmVzcyBh bmQgbW9yZSB0aGFuIG9uZSByb3V0ZSwgYW5kIGl0IGlzDQo+PmNvbmNlaXZhYmxlIHRoYXQgb25l IG9yIG1vcmUgb2YgbXkgYWRkcmVzc2VzIG9yIHJvdXRlcyBkb2VzbuKAmXQgd29yay4gSWYNCj4+ SSBhbSBtdWx0aWhvbWVkIGluIHRoZSBzZW5zZSBvZiBoYXZpbmcgbXVsdGlwbGUgSVB2NCBwYXRo cywgSSBjYW4gaGF2ZQ0KPj50aGUgc2FtZSBwcm9ibGVtcywgYW5kIEkgY2FuIGhhdmUgdGhlIHNh bWUgcHJvYmxlbXMgaWYgSSBhbSBJUHY2LW9ubHkNCj4+YnV0IGhhdmUgbXVsdGlwbGUgdXBzdHJl YW1zLg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PlRoZSBsYXJnZS1zY2FsZSBOQVQvQ0dOIGlzc3Vl IGRvZXMgbWFrZSB0aGlzIG5vdCBqdXN0IGFuIElQdjYgaXNzdWUuICBBdA0KPj5sZWFzdCBzb21l IHN5c3RlbXMgSSd2ZSBzZWVuIHRoZW4gY2hlY2sgdGhlIElQIGluIHRoZSBjb29raWUgdG8gbWFr ZQ0KPj5zdXJlIGl0J3MgaW4gdGhlIHNhbWUgLzI0IHJhdGhlciB0aGFuIHRoZSBleGFjdCBzYW1l IElQLCBidXQgdGhhdA0KPj5kb2Vzbid0IGhlbHAgaW4gdGhlIGR1YWwtc3RhY2sgd29ybGQuDQo+ Pj4NCj4+PkFub3RoZXIgaXNzdWUgYmV5b25kIEhhcHB5IEV5ZWJhbGxzIGlzIHRoYXQgcHJpdmFj eSBhZGRyZXNzaW5nIGJpdGVzDQo+Pj55b3UgaGVyZSBhcyB3ZWxsIGZvciBjb29raWVzIHRoYXQg YXJlIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBUQ1ANCj4+PmNvbm5lY3Rpb25zIHNwYW5uaW5nIGEg cHJpdmFjeSBhZGRyZXNzIHJvdGF0aW9uLg0KPj4+DQo+Pj4NCj4+PkhhdmluZyBzb21lIG1vcmUg Y2xlYXIgImRvbid0IGRvIHRoaXMiIHRvIHBvaW50IHBlb3BsZSB0byB3b3VsZCBiZQ0KPj4+Z29v ZCwgYnV0IEkgc3VzcGVjdCB3ZSdsbCBoYXZlIG1hbnkgeWVhcnMgb2YgY2xlYW5pbmcgdXAgYXBw bGljYXRpb25zDQo+Pj5kb2luZyB0aGlzLg0KPj4+DQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+djZvcHMgbWFpbGluZyBsaXN0DQo+ PnY2b3BzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMNCj4+DQo+Pg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Fri Oct 31 06:24:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D61A8AA9 for ; Fri, 31 Oct 2014 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5sN1GMZnjYp for ; Fri, 31 Oct 2014 06:23:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D3B1A8A15 for ; Fri, 31 Oct 2014 06:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3258; q=dns/txt; s=iport; t=1414761838; x=1415971438; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Hpog+tobXZTgb9oRBYyzSttvIDrrfkkl28Z8FQ4iPcs=; b=kh5JjYdpv7+hvwKH+HdQvlPpeztYWq4viLdpxWoTfmjEbk4B86GvauDw FWjYfU5SLulmgUhAdr0P+AdH/LTjzAxopu+QgIpRwRax6Ua0iPbu/kXOo qXqX2537IQSGVl+ml4tKMDZpSi9cIPHLw5wRS52u6km7ZEipogm2l20lW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoFAA+MU1StJA2D/2dsb2JhbABcgkgjI4EsBIMC0W0CHHsWAQEBAQF9hAMBAQQjVhACAQgECgcqAwICAjAUEQIEAQ0FiEEBtQ+UcAEBAQEBAQEBAQEBAQEBAQEBAQEBAReREAeCd4FUBZIVi2OWSIN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,294,1413244800"; d="scan'208,217";a="368155795" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2014 13:23:57 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9VDNutP003603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 13:23:57 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 08:23:56 -0500 From: "Eric Vyncke (evyncke)" To: Simon Perreault , "Bjoern A. Zeeb" Thread-Topic: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt Thread-Index: AQHP9Dtne7ZnWB55ZUGTqpP/g6Nm6ZxI9EMAgAGjsoA= Date: Fri, 31 Oct 2014 13:23:56 +0000 Message-ID: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.55.185.73] Content-Type: multipart/alternative; boundary="_000_D0794BD030ED8evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9i0PN96I87q0M-UfF-NEgpyzdAA Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 13:24:00 -0000 --_000_D0794BD030ED8evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFNpbW9uIFBlcnJlYXVsdCA8c3BlcnJlYXVsdEBqaXZlLmNvbTxtYWlsdG86c3Bl cnJlYXVsdEBqaXZlLmNvbT4+DQpXZSBuZWVkIG1vcmUgYW5kIG1vcmUgdG8gdGhpbmsgb2Ygc291 cmNlIElQIGFkZHJlc3NlcyBhcyBlcGhlbWVyYWwgdGhpbmdzLiBKdXN0IGxpa2UgeW91IGRvbid0 IGNhcmUgd2hpY2ggZXBoZW1lcmFsIHNvdXJjZSBwb3J0IGdldHMgcGlja2VkIGJ5IHRoZSBPUyB3 aGVuIHlvdSBjYWxsIGNvbm5lY3QoKSwgeW91IHNob3VsZG4ndCBjYXJlIGFib3V0IHdoaWNoIHNv dXJjZSBhZGRyZXNzIGlzIHBpY2tlZCB3aGVuIGNhbGxpbmcgY29ubmVjdF9ieV9uYW1lKCkgb3Ig d2hhdGV2ZXIgb3RoZXIgSEUtbGlrZSBBUEkgb3V0IHRoZXJlLg0KDQoNCkVwaGVtZXJhbCBhbmQg cHJvYmFibHkgbGVzcyBhbmQgbGVzcyBtZWFuaW5nZnVsDQoNCg0KDQo= --_000_D0794BD030ED8evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFs aWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBp bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPlNpbW9uIFBlcnJlYXVsdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb20iPnNwZXJyZWF1bHRAaml2ZS5jb208L2E+Jmd0 Ozxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JM T0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAg MCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9Imdt YWlsX2V4dHJhIj5XZSBuZWVkIG1vcmUgYW5kIG1vcmUgdG8gdGhpbmsgb2Ygc291cmNlIElQIGFk ZHJlc3NlcyBhcyBlcGhlbWVyYWwgdGhpbmdzLiBKdXN0IGxpa2UgeW91IGRvbid0IGNhcmUgd2hp Y2ggZXBoZW1lcmFsIHNvdXJjZSBwb3J0IGdldHMgcGlja2VkIGJ5IHRoZSBPUyB3aGVuIHlvdSBj YWxsIGNvbm5lY3QoKSwgeW91IHNob3VsZG4ndCBjYXJlIGFib3V0IHdoaWNoIHNvdXJjZSBhZGRy ZXNzIGlzIHBpY2tlZCB3aGVuDQogY2FsbGluZyBjb25uZWN0X2J5X25hbWUoKSBvciB3aGF0ZXZl ciBvdGhlciBIRS1saWtlIEFQSSBvdXQgdGhlcmUuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkVwaGVtZXJhbCBhbmQgcHJvYmFibHkgbGVzcyBhbmQgbGVzcyBt ZWFuaW5nZnVsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgZGlyPSJsdHIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D0794BD030ED8evynckeciscocom_-- From nobody Fri Oct 31 06:44:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151E11A0062 for ; Fri, 31 Oct 2014 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw1cJmPiSxe9 for ; Fri, 31 Oct 2014 06:43:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678951A003B for ; Fri, 31 Oct 2014 06:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3234; q=dns/txt; s=iport; t=1414763039; x=1415972639; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HdMAR/ajW+/EZwekeiz13d318XeHKiz+Ai8DPXA0jeE=; b=YFaaLoHl9tINyFAqGhC+u61e3zOFCTGEbQgA+5ZDOdEZ3kCP7XBWvK9C kqvgW2D7n4o5gOeaewZIZyi+ovSu9S9aDIwZnZ85jGZvq2ONrCbMrBK7N wAlcUWbr9ng0jbzsWwV2iaTJVL8DG/WyBTRHXTrZzuz5EBwHzcfl6JGVW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoFAMGQU1StJV2T/2dsb2JhbABcDoI6IyOBLASDAtFvAhx6FgEBAQEBfYQDAQEEI1YQAgEIBBABKgMCAgIwFBECBAENBYhBAbUmlHEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkHUKEQeCd4FUBYUZAox6i2OWSIM4QGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208,217";a="368194258" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2014 13:43:58 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9VDhw8n027054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 13:43:58 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 08:43:58 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti , Tim Chown Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP7PnOqETYxJBI7UuSbmapWyxTwpw6rceAgABDQwCAAAEmAIAPudWA Date: Fri, 31 Oct 2014 13:43:57 +0000 Message-ID: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.55.185.73] Content-Type: multipart/alternative; boundary="_000_D0794EEC30EDFevynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AvMpwK7LB23HbYmXG8oMt8LuS94 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 13:44:01 -0000 --_000_D0794EEC30EDFevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHN1cHBvcnQgdGhlIHN1Z2dlc3Rpb24gdG8gb25seSBpbXBhY3QgUkZDIDMwNjggYW5k IGxlYXZlIHNvbWUgZGlyZWN0IDZ0bzQgY29ubmVjdGl2aXR5ICdjdXJyZW50Jy4NCg0KQlRXLCBh ZGRpbmcgMTkyLjg4Ljk5LjAvMjQgdG8gdGhlIGJvZ29ucyB3aWxsIG5vdCByZWFsbHkgaGVscCBp biBhbnl3YXkgYXMgdGhlIGNsaWVudCAodGhlIGVudHJ5IHBvaW50IGluIHRoZSA2dG80IHR1bm5l bCkgd2lsbCBub3QgYmUgYWJsZSB0byBzaWduYWwgdGhlIElQdjYgbm9kZSBvZiBsYWNrIG9mIElQ djYgY29ubmVjdGl2aXR5IGluIG1vc3QgaW1wbGVtZW50YXRpb25zLg0KDQotw6lyaWMNCg0KRnJv bTogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbT4+DQpEYXRlOiBtYXJkaSAyMSBvY3RvYnJlIDIwMTQgMTU6MzQNCldvdWxkIGl0IG1h a2Ugc2Vuc2UgdG8gbW92ZSBvbmx5IDMwNjggdG8gaGlzdG9yaWMsIGFuZCBub3QgMzA1Nj8NCg== --_000_D0794EEC30EDFevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SSBhbHNvIHN1 cHBvcnQgdGhlIHN1Z2dlc3Rpb24gdG8gb25seSBpbXBhY3QgUkZDIDMwNjggYW5kIGxlYXZlIHNv bWUgZGlyZWN0IDZ0bzQgY29ubmVjdGl2aXR5ICdjdXJyZW50Jy48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkJUVywgYWRkaW5nIDE5Mi44OC45OS4wLzI0IHRvIHRoZSBib2dvbnMgd2ls bCBub3QgcmVhbGx5IGhlbHAgaW4gYW55d2F5IGFzIHRoZSBjbGllbnQgKHRoZSBlbnRyeSBwb2lu dCBpbiB0aGUgNnRvNCB0dW5uZWwpIHdpbGwgbm90IGJlIGFibGUgdG8gc2lnbmFsIHRoZSBJUHY2 IG5vZGUgb2YgbGFjayBvZiBJUHY2IGNvbm5lY3Rpdml0eSBpbiBtb3N0IGltcGxlbWVudGF0aW9u cy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi3DqXJpYzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0 OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJ TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdI VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Mb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0 bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5tYXJkaSAyMSBvY3RvYnJl IDIwMTQgMTU6MzQ8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsg UEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxkaXY+V291bGQgaXQgbWFrZSBzZW5zZSB0byBtb3ZlIG9ubHkgMzA2OCB0byBoaXN0 b3JpYywgYW5kIG5vdCAzMDU2PyZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D0794EEC30EDFevynckeciscocom_-- From nobody Fri Oct 31 06:55:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89111A8AD6 for ; Fri, 31 Oct 2014 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QicwJ-o6kk0B for ; Fri, 31 Oct 2014 06:55:10 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 975441A005C for ; Fri, 31 Oct 2014 06:55:10 -0700 (PDT) Received: from h118.viagenie.ca (h118.viagenie.ca [206.123.31.118]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E0F89403B0 for ; Fri, 31 Oct 2014 09:55:09 -0400 (EDT) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_7CFE5D22-12D2-45C2-8ADF-F506356F371C" Date: Fri, 31 Oct 2014 09:55:10 -0400 References: To: v6ops@ietf.org Message-Id: <2E38DB4E-0CF2-49B1-B2A7-ED3C97841B85@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/b_9QSRwOo_IkZPGA3I53n6_Z1Xs Subject: [v6ops] Fwd: [sunset4] New Version Notification for draft-song-sunset4-ipv6only-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 13:55:17 -0000 --Apple-Mail=_7CFE5D22-12D2-45C2-8ADF-F506356F371C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, this draft has been posted to sunset4, but has some v6 operational = perspective, which is why I=E2=80=99m forwarding to this mailing list.=20= Marc (co-chair sunset4) > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > Date: 27 octobre 2014 22:00:52 UTC=E2=88=924 > De: Davey Song > =C3=80: "sunset4@ietf.org" > Objet: [sunset4] Fwd: New Version Notification for = draft-song-sunset4-ipv6only-dns-00.txt >=20 > Hi folks, I have just post a new draft on IPv6-only DNS development. = Comments are welcome!!=20 >=20 > A new version of I-D, draft-song-sunset4-ipv6only-dns-00.txt > has been successfully submitted by Linjian Song and posted to the > IETF repository. >=20 > Name: draft-song-sunset4-ipv6only-dns > Revision: 00 > Title: Considerations on IPv6-only DNS Development > Document date: 2014-10-27 > Group: Individual Submission > Pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-song-sunset4-ipv6only-dns-00.txt= = > Status: = https://datatracker.ietf.org/doc/draft-song-sunset4-ipv6only-dns/ = > Htmlized: = http://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns-00 = >=20 >=20 > Abstract: > Deployment of IPv6-only networks are impacted by assumptions of > IPv4-only or dual-stack transition scenarios. For example, these > assumptions are in the operations of DNS. This memo is problem > statement and hopes to eventually propose a mitigation technique. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 --Apple-Mail=_7CFE5D22-12D2-45C2-8ADF-F506356F371C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,
 this draft has = been posted to sunset4, but has some v6 operational perspective, which = is why I=E2=80=99m forwarding to this mailing list. 

Marc (co-chair = sunset4)

D=C3=A9but du message = r=C3=A9exp=C3=A9di=C3=A9 :

Date: = 27 octobre 2014 22:00:52 = UTC=E2=88=924
De: = Davey Song <songlinjian@gmail.com>
=C3=80: = "sunset4@ietf.org" <sunset4@ietf.org>
Objet: = [sunset4] Fwd: = New Version Notification for = draft-song-sunset4-ipv6only-dns-00.txt

Hi folks, I have = just post a new draft on IPv6-only DNS development. Comments are = welcome!! 

A new version of I-D, = draft-song-sunset4-ipv6only-dns-00.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:          =  draft-song-sunset4-ipv6only-dns
Revision:       00
Title:          Considerations on IPv6-only DNS = Development
Document date:  2014-10-27
Group:          Individual Submission
Pages:          8
URL:            http://www.ietf.org/internet-drafts/draft-song-sunset4-ipv6only= -dns-00.txt
Status:         https://datatracker.ietf.org/doc/draft-song-sunset4-ipv6only-dn= s/
Htmlized:       http://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns-00


Abstract:
   Deployment of IPv6-only networks are impacted by = assumptions of
   IPv4-only or dual-stack transition scenarios.  For = example, these
   assumptions are in the operations of DNS.  This memo = is problem
   statement and hopes to eventually propose a mitigation = technique.




Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

= --Apple-Mail=_7CFE5D22-12D2-45C2-8ADF-F506356F371C-- From nobody Fri Oct 31 07:03:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080091A902E for ; Fri, 31 Oct 2014 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxU2bUJ_CQR0 for ; Fri, 31 Oct 2014 07:03:25 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170C41A8AE9 for ; Fri, 31 Oct 2014 07:03:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6E216204EB for ; Fri, 31 Oct 2014 10:03:06 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 31 Oct 2014 10:03:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=4nuJksJrhQ6S+Lp0SYvBMi RFUFc=; b=od9kVSpqDoqsnNHIZIFr6UwWi5eENegEfy8Rpv9mfrJ/ECXS8+hteZ FULGNN1xFi3ySAyNF9EUiBMvsQQnGLdnhRmct2/YY5mdjzhb3DL+Neo2QTkyCP6f z+uk9MDYhlKu9FyHbFCJwCe6c0FmPlHbuUeuv/rWIzUzVonlt/EXk= X-Sasl-enc: p67cil7ARSaANiu+6kQikY7doY2riKnxf5ZdjONxKocL 1414764186 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E91826800FF; Fri, 31 Oct 2014 10:03:05 -0400 (EDT) Message-ID: <5453968F.6070103@network-heretics.com> Date: Fri, 31 Oct 2014 10:02:55 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , Gert Doering References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> In-Reply-To: <54533A0F.1050502@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pRE6Pp7sG9eFxF9hugb3UtMEpVc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:03:29 -0000 On 10/31/2014 03:28 AM, Jeroen Massar wrote: >>> So in which way does this draft impact your ability to talk IPv6 between >>> >>your nodes? >> >It impacts my ability to talk IPv6 with any other nodes for which 6to4 >> >currently works, which are not necessarily "my" nodes, nor nodes that >> >also support IPv4. To give one example, I've found that video >> >conferencing over 6to4 can work in situations in which STUN-based NAT >> >traversal fails. > You are saying you can transport proto-41 packets through a NAT setup, > that while STUN does not work? > > I would really love to see the details. As NATs that know about proto-41 > or are able to stick it to a specific endpoint are rare. In this case I'm using such a NAT that implements a IPv6 router with 6to4 as its external interface and "normal" v6 (unencapsulated, with SLAAC, RD, etc.) on the internal one. (In some cases it's also possible to build a 6to4 router that operates outside of the NAT, processes protocol 41 packets itself, and sends protocol 1, 6 and 17 packets to the NAT. The 6to4 router and the NAT have separate connections to the LAN.) Keith From nobody Fri Oct 31 07:05:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B73C1A9036 for ; Fri, 31 Oct 2014 07:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWFWqwxL8F-x for ; Fri, 31 Oct 2014 07:05:48 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D0B1A9033 for ; Fri, 31 Oct 2014 07:05:48 -0700 (PDT) Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7B90F62CE; Fri, 31 Oct 2014 07:05:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ole Troan In-Reply-To: Date: Fri, 31 Oct 2014 15:05:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rfIQuN0FNKDIOTAD8CG6wjhXeoA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:05:50 -0000 Eric, > I also support the suggestion to only impact RFC 3068 and leave some = direct 6to4 connectivity 'current'. for my education, any idea what use cases there are / could be for = direct 6to4 connectivity?=20 given that: - you shouldn't put 6to4 addresses in DNS - 6to4 likely breaks if address sharing is in place just speculating here; is it because tunnelling bypasses filters / = throttling? if so doesn't e.g. peer applications bypass that by other = means? > BTW, adding 192.88.99.0/24 to the bogons will not really help in = anyway as the client (the entry point in the 6to4 tunnel) will not be = able to signal the IPv6 node of lack of IPv6 connectivity in most = implementations.=20 cheers, Ole= From nobody Fri Oct 31 07:06:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242001A9025 for ; Fri, 31 Oct 2014 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7QfjK5VmnVX for ; Fri, 31 Oct 2014 07:06:00 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7961A9042 for ; Fri, 31 Oct 2014 07:05:58 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A64F620751 for ; Fri, 31 Oct 2014 10:05:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 31 Oct 2014 10:05:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=3XhkmqSMBdsrPpMywdkdFP LomC8=; b=ENRywcgZpjzZrEOwCQWOuGO7A2kNzhtbKSao79pP2NBCm8iVwAzbgh +viAdfbTp9fxfwG25teNuYcnWGHhfSGYr5H0snNEJhhZYGrPffXWhDZBp1xZqs47 /434uEGCvoopaBL3BKP5/4DyybTa2IaE5ykkg4O1aafg6bbB9mrcU= X-Sasl-enc: gQrvVR3NULveTpLPRe8DuJcicGcn5GQApVWQ8KefUSuS 1414764357 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 09E3E6800FF; Fri, 31 Oct 2014 10:05:56 -0400 (EDT) Message-ID: <5453973A.6030503@network-heretics.com> Date: Fri, 31 Oct 2014 10:05:46 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeroen Massar , Gert Doering , Antonio Querubin References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54533AED.3010506@massar.ch> In-Reply-To: <54533AED.3010506@massar.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kulHqlC0ij4z0p3Pl54d1wlR7tU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:06:02 -0000 On 10/31/2014 03:31 AM, Jeroen Massar wrote: > If a device can do 6to4 then it is also doing 6in4. Actually, no. I've seen several devices that only support one v6 mechanism (6to4) and claim to support v6 (lame, I admit). Keith From nobody Fri Oct 31 07:06:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A579F1A9037 for ; Fri, 31 Oct 2014 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln6M47Afsish for ; Fri, 31 Oct 2014 07:06:39 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53E81A9025 for ; Fri, 31 Oct 2014 07:06:37 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tp5so1359609ieb.1 for ; Fri, 31 Oct 2014 07:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RTw46fp5cZKL0QO/DJCIr4U23lwRKMpohTIWJvfYDOU=; b=eQlxtetj4VHaEVLDrqg3ZEO23N/XKelL9ikku/ZY4h+WDB6Onu8C8BkhjQ4FCDPM99 D99b8v4ZJ/gJsTgTxsteiPee/wbQC4/zenuJEKlRExlyqxnkAvKCacx2m5F+u0cI/a8+ eAfIrRHlM892rJzS7R8lyfdzCvTW68CYEBrtsJJuWb6dBd4q/+5xTpoipiFaDnii6QqO QR7m5HJM3GC3IkYuMUjkXr7+RwffAeuVj1Kl7jTqAGDg9T90c6VURwQMeEun35bHcaGr LICM+YzMozl1CxGJMs/vSMNgFy79LFdXuNKDseLmVC+tGAbzQIhB0sfKmS7hD/NVQXuB O+dw== MIME-Version: 1.0 X-Received: by 10.50.79.193 with SMTP id l1mr4444577igx.30.1414764397261; Fri, 31 Oct 2014 07:06:37 -0700 (PDT) Received: by 10.107.137.194 with HTTP; Fri, 31 Oct 2014 07:06:37 -0700 (PDT) In-Reply-To: References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> Date: Fri, 31 Oct 2014 15:06:37 +0100 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/N7RjNMHC9PWg9iXSUsR7KLGU2uc Cc: IPv6 Operations , "Bjoern A. Zeeb" Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:06:40 -0000 On 10/31/14, Eric Vyncke (evyncke) wrote: > > > From: Simon Perreault > > We need more and more to think of source IP addresses as ephemeral things. > Just like you don't care which ephemeral source port gets picked by the OS > when you call connect(), you shouldn't care about which source address is > picked when calling connect_by_name() or whatever other HE-like API out > there. > > > Ephemeral and probably less and less meaningful It loses its meaning of an "identity", and keeps the one as a full (IPv6) or partial (IPv4+NAT) "current locator in the network". --a From nobody Fri Oct 31 07:08:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457DC1A903F for ; Fri, 31 Oct 2014 07:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytac55JqUSL3 for ; Fri, 31 Oct 2014 07:08:20 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899231A9028 for ; Fri, 31 Oct 2014 07:08:03 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 75D7B606F4 for ; Fri, 31 Oct 2014 15:08:01 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 0FE9660135 for ; Fri, 31 Oct 2014 15:08:01 +0100 (CET) Received: (qmail 88212 invoked by uid 1007); 31 Oct 2014 15:08:01 +0100 Date: Fri, 31 Oct 2014 15:08:01 +0100 From: Gert Doering To: Keith Moore Message-ID: <20141031140800.GH31092@Space.Net> References: <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C+imGKfifomKvLP2" Content-Disposition: inline In-Reply-To: <5453968F.6070103@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hf1fJKuATre9YcI3jzrA64lPLdk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:08:24 -0000 --C+imGKfifomKvLP2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Oct 31, 2014 at 10:02:55AM -0400, Keith Moore wrote: > In this case I'm using such a NAT that implements a IPv6 router with=20 > 6to4 as its external interface and "normal" v6 (unencapsulated, with=20 > SLAAC, RD, etc.) on the internal one. (In some cases it's also=20 > possible to build a 6to4 router that operates outside of the NAT,=20 > processes protocol 41 packets itself, and sends protocol 1, 6 and 17=20 > packets to the NAT. The 6to4 router and the NAT have separate=20 > connections to the LAN.) Which is, pretty much, "peer to peer 6to4", just implemented in a router for "users in its /48", and not just in a host for itself. Doesn't make a big difference in the grand scheme - peer to peer 6to4 is known to work, no matter how implemented, while 6to4-to-native is=20 known to not-work except in controlled environments (which "the Internet" isn't - inside our DCs it works surprisingly well, but it's still a=20 nuisance if boxes start tunneling just because they can) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --C+imGKfifomKvLP2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVFOXwN9WwGXkzn/FAQJJdw/+Pc4sstYP72IuhWeDgcE3x4UbeRQ0p6oR AunCoFAVeT2lpTZElYCEROGK3LP6RyruFYXdtWmMOKKzSWlR31iQcoSLaBMU4LvL 9WUdGUIrPALxaph/oIpIaDTMF1MkWLfnAwTNYlVFXvdPXnwx+GZOwJ2m9QALgW1a gOrfD6aBfvS2wPIMtBJ3zklbQ1MhxzNFu1EJRcDWEWDxrQCOKcLsgBDEO8/5uIvF EMelGGmYgqcavNMxVajp6lIzSm2W8hzzIFx876tgqzMgMddC3QQtTX+b9NRGqydQ 9by0Yhr7W7i36/PfCuar0VyHDrSuIjyYk8p3n0WvQYIoCqB/DDu2TPREeW1J3SxL GQa6jAHoWpmOvkaLOCvWsjzwhBjIJ4OfQjCCzggnQPaDy9JaOdBcziBrCuIGX1Qp +SYzpq6t4B1JRd/UUQgu83QhqBJpkU2ygiXaWr+nllXOGZQkp8zofrf8z5NqOjGy jjTPgoyg4OipMLxSllmHsB7DPcOgFJgtYvZBZPyecCM5QJcsRCUfRfl2pNcjuu/i 6GOKfo9nfEWT8HJhjIEt2cJ8K7c98mf0w1Ou+gmzTnmPSdcr/y1cN8lQgsp5C9MS rIB+2oCRP/hzUvrhr5hs/YMmezSQnGR8+NAY1zprjKX1D2fXrrrh7biaONMN+a1V m07b6DyklpA= =5aGE -----END PGP SIGNATURE----- --C+imGKfifomKvLP2-- From nobody Fri Oct 31 07:14:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E49A1A007D for ; Fri, 31 Oct 2014 07:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68xR0LxA07SW for ; Fri, 31 Oct 2014 07:14:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5C91A0013 for ; Fri, 31 Oct 2014 07:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1622; q=dns/txt; s=iport; t=1414764843; x=1415974443; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ovPUMrF66SIcF6xD2/VjUhTfTxiJ0Af4VxWogC0nVws=; b=gbI5rxNyYeCQduvAoF/xC4A+IIfXtlhG36hVU8K0JS3xZc/5pdkipWtg fPF7WR6CymFt7qkSd+KMghND515cbJzmgoI+bz4ftFLzMyzt1LU6lYugM Q0PMNWVfhoJWFmc03xkUWNeaFY3HEQf/RgguSZNYUm95SJWtzW/HR1lbl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkFAHyYU1StJV2U/2dsb2JhbABcgmsjgSwEgwLRbwIceRYBAQEBAX2EAwEBBCMRRRACAQgODAImAgICMBUQAgQOBRaIKwG1OpR1AQEBAQEBAQEBAQEBAQEBAQEBARmBLY8wGBsHgneBVAEEkhWLY5ZIg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="92135216" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 31 Oct 2014 14:14:02 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9VEE2qU005465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 14:14:02 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 09:14:02 -0500 From: "Eric Vyncke (evyncke)" To: Ole Troan Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP7PnOqETYxJBI7UuSbmapWyxTwpw6rceAgABDQwCAAAEmAIAPudWA///1XgCAABMSgA== Date: Fri, 31 Oct 2014 14:14:02 +0000 Message-ID: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.55.185.73] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UIZHVMIttGviDtCzqR3-5_-A8zQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:14:08 -0000 SSBrbm93IHRoYXQgdGhlcmUgaGF2ZSBiZWVuIGRlc2lnbnMgdXNpbmcgNnRvNCB0byBwcm92aWRl IHByaXZhdGUgSVB2Ng0KY29ubmVjdGl2aXR5IGFtb25nIGR1YWwtc3RhY2sgaXNsYW5kcyB3aGVy ZSB0aGUgQ0Ugcm91dGVyIGhhcyBhIHB1YmxpYw0KSVB2NCBhZGRyZXNzIG9ubHkgYW5kIHVzZXMg c29tZSA2dG80IGNvbWJpbmVkIHdpdGggSVB2Ni1CR1AgYWxsb3cgcm91dGluZw0KYW1vbmcgdGhv c2UgcHJpdmF0ZSBpc2xhbmRzLiBTbywgbm90IGEgc2luZ2xlIElQdjYgcGFja2V0cyB3aXRoIDIw MDI6Oi8xNg0KcHJlZml4Lg0KDQpOb3Qgc3VyZSB0aG91Z2ggd2hldGhlciB0aG9zZSBkZXNpZ25z IGFyZSBzdGlsbCBpbiB1c2UuDQoNCi3DqXJpYw0KDQpPbiAzMS8xMC8xNCAxNTowNSwgIk9sZSBU cm9hbiIgPG90cm9hbkBlbXBsb3llZXMub3JnPiB3cm90ZToNCg0KPkVyaWMsDQo+DQo+PiBJIGFs c28gc3VwcG9ydCB0aGUgc3VnZ2VzdGlvbiB0byBvbmx5IGltcGFjdCBSRkMgMzA2OCBhbmQgbGVh dmUgc29tZQ0KPj5kaXJlY3QgNnRvNCBjb25uZWN0aXZpdHkgJ2N1cnJlbnQnLg0KPg0KPmZvciBt eSBlZHVjYXRpb24sIGFueSBpZGVhIHdoYXQgdXNlIGNhc2VzIHRoZXJlIGFyZSAvIGNvdWxkIGJl IGZvciBkaXJlY3QNCj42dG80IGNvbm5lY3Rpdml0eT8NCj5naXZlbiB0aGF0Og0KPiAtIHlvdSBz aG91bGRuJ3QgcHV0IDZ0bzQgYWRkcmVzc2VzIGluIEROUw0KPiAtIDZ0bzQgbGlrZWx5IGJyZWFr cyBpZiBhZGRyZXNzIHNoYXJpbmcgaXMgaW4gcGxhY2UNCj4NCj5qdXN0IHNwZWN1bGF0aW5nIGhl cmU7IGlzIGl0IGJlY2F1c2UgdHVubmVsbGluZyBieXBhc3NlcyBmaWx0ZXJzIC8NCj50aHJvdHRs aW5nPyBpZiBzbyBkb2Vzbid0IGUuZy4gcGVlciBhcHBsaWNhdGlvbnMgYnlwYXNzIHRoYXQgYnkg b3RoZXINCj5tZWFucz8NCj4NCj4+IEJUVywgYWRkaW5nIDE5Mi44OC45OS4wLzI0IHRvIHRoZSBi b2dvbnMgd2lsbCBub3QgcmVhbGx5IGhlbHAgaW4gYW55d2F5DQo+PmFzIHRoZSBjbGllbnQgKHRo ZSBlbnRyeSBwb2ludCBpbiB0aGUgNnRvNCB0dW5uZWwpIHdpbGwgbm90IGJlIGFibGUgdG8NCj4+ c2lnbmFsIHRoZSBJUHY2IG5vZGUgb2YgbGFjayBvZiBJUHY2IGNvbm5lY3Rpdml0eSBpbiBtb3N0 DQo+PmltcGxlbWVudGF0aW9ucy4gDQo+DQo+Y2hlZXJzLA0KPk9sZQ0KDQo= From nobody Fri Oct 31 07:15:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBA81A8B84 for ; Fri, 31 Oct 2014 07:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wig7RmGO8vo for ; Fri, 31 Oct 2014 07:15:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB201A8AA9 for ; Fri, 31 Oct 2014 07:15:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0B5932097C for ; Fri, 31 Oct 2014 10:15:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 31 Oct 2014 10:15:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=/uex44bv0bTFl4iFK4AIJZ pIzsw=; b=jgHmjR7wihWV7Updc0ngkKvTNnrZXS3wzfd8bJtX0490KWmidPAn7d R0bWPzbNKO5jtPtb+80uZPUfbtPJoSyN29DcGhmLke8/+nhyvkUeuu1VZek/5BNi aotfmdJPsfwfxpZ7gmxR2uxussH1SlIQ3+PPgN+dOlnO9g9sG0AtY= X-Sasl-enc: FDHZ0CKkZv8z+vuzYAnMnUCxIgpseM60VuSOb842/3xo 1414764947 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id AFCD968011A; Fri, 31 Oct 2014 10:15:47 -0400 (EDT) Message-ID: <54539989.9030901@network-heretics.com> Date: Fri, 31 Oct 2014 10:15:37 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ca5vu79zRAZ7W0Fg9d0p3lh9Pg4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:15:50 -0000 On 10/31/2014 10:05 AM, Ole Troan wrote: > for my education, any idea what use cases there are / could be for direct 6to4 connectivity? Any application that uses IPv6 and involves some hosts that don't have native (non-NATted) IPv4 access. > given that: > - you shouldn't put 6to4 addresses in DNS There's nothing wrong with putting 6to4 addresses in DNS, just like there's nothing wrong with putting ULIAs in DNS. > - 6to4 likely breaks if address sharing is in place What do you mean by "address sharing"? (If you mean the same v4 address is associated with multiple end sites using carrier-side NAT, I agree.) > > just speculating here; is it because tunnelling bypasses filters / throttling? if so doesn't e.g. peer applications bypass that by other means? No, it's because global v4 addresses are scarce and 6to4 provides a way around that. Keith From nobody Fri Oct 31 07:17:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EC91A8B84 for ; Fri, 31 Oct 2014 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwOEXvFA_RvM for ; Fri, 31 Oct 2014 07:17:41 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368E71A005E for ; Fri, 31 Oct 2014 07:17:39 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id A1783100A037D; Fri, 31 Oct 2014 14:17:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414765055; bh=LCPjIPaRLdjWv4Yz2kqBKEzrmBD/KRmJXUEBw34UFOY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=CENQJYIJD1Z8ptdyljo0r/R43aN0fTD+QYZPk3sThkw+nllv2jHgcBT5bRGmDz0st 4nORua1pyoz5eyPwDVekZeR9jzRITV+94Vn5CB2dQ454ZaFj9/Fos2mJMpFodAKBge hLgAceQ89+9XNHlndXcGKGQu2wx/XBUztUL7nrVJhKCQycOyDSa6bRVQ7TfN9UONTa 54lNk+mwM5svfEbZE4m+imDg9GxpmbC4dtRvvtRfY0z/Ije2B+4Jw1xR+M+WV01AuX Xu794lqYdC5AQaFjCMEpqOa/2/jSy5pVDYDhMZX6AKviQTChfoeL/QDfxVXDPkG7aL U4yV886nEpksA== Message-ID: <545399FC.1040407@massar.ch> Date: Fri, 31 Oct 2014 15:17:32 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Keith Moore , Gert Doering References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> In-Reply-To: <5453968F.6070103@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BruF8lulPFCJgXX0g9ARgmyTKrc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:17:44 -0000 On 2014-10-31 15:02, Keith Moore wrote: > On 10/31/2014 03:28 AM, Jeroen Massar wrote: >>>> So in which way does this draft impact your ability to talk IPv6 >>>> between >>>> >>your nodes? >>> >It impacts my ability to talk IPv6 with any other nodes for which 6to4 >>> >currently works, which are not necessarily "my" nodes, nor nodes that >>> >also support IPv4. To give one example, I've found that video >>> >conferencing over 6to4 can work in situations in which STUN-based NAT >>> >traversal fails. >> You are saying you can transport proto-41 packets through a NAT setup, >> that while STUN does not work? >> >> I would really love to see the details. As NATs that know about proto-41 >> or are able to stick it to a specific endpoint are rare. > > In this case I'm using such a NAT that implements a IPv6 router with > 6to4 as its external interface and "normal" v6 (unencapsulated, with > SLAAC, RD, etc.) on the internal one. (In some cases it's also > possible to build a 6to4 router that operates outside of the NAT, > processes protocol 41 packets itself, and sends protocol 1, 6 and 17 > packets to the NAT. The 6to4 router and the NAT have separate > connections to the LAN.) No need to have separate connections for that. Apple Airports don't for instance. As it is 6to4 and use of it is very limited due to Happy Eyeballs I can only recommend to find a firmware upgrade or schedule the device for replacement. You still have time before this draft becomes a standard... On 2014-10-31 15:05, Keith Moore wrote: > On 10/31/2014 03:31 AM, Jeroen Massar wrote: >> If a device can do 6to4 then it is also doing 6in4. > Actually, no. I've seen several devices that only support one v6 > mechanism (6to4) and claim to support v6 (lame, I admit). Read the next sentence in my message: it is a UI thing. You need to implement proto-41 before you can do 6to4 on top of that. As for "support IPv6", does the device have a "IPv6 Ready" logo on it? (https://www.ipv6ready.org/) If yes, then we need to kick those folks hard to stop giving out numbers for it. Device, make/model details would be great. 99% probability it has a Linux variant inside anyways. Greets, Jeroen From nobody Fri Oct 31 07:17:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C491A9030 for ; Fri, 31 Oct 2014 07:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL0CbsQsHBUO for ; Fri, 31 Oct 2014 07:17:45 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24D91A007C for ; Fri, 31 Oct 2014 07:17:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3006A2063A for ; Fri, 31 Oct 2014 10:17:45 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 31 Oct 2014 10:17:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=gbMMq0ybgC+GA4wfN/XRP+ sv9E4=; b=kHSDvKpGvwYEUBa4/kWRSd+q8JNt5jkgKvhVJkAYI1m3fN586zZo63 tVWR4ypMPikuM+wM4tkj2D69X75SWDYiq7NBdFTEYfZLbQNIGjfGidcPDlM2KQ48 0KwTwDPyRENWb6UshFyqHmtii/Stbrq8xvKhO563laPg2O5pQWqjI= X-Sasl-enc: iCR6maOcXpEvrXgsokXsBnzh8CfKiPu+soxiVQ3WdIwT 1414765064 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id CEB8468011A; Fri, 31 Oct 2014 10:17:44 -0400 (EDT) Message-ID: <54539A08.5090707@network-heretics.com> Date: Fri, 31 Oct 2014 10:17:44 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> In-Reply-To: <20141031140800.GH31092@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/pRE0sYZ2_1AxiQMJk-qu1E3bKfI Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:17:47 -0000 On 10/31/2014 10:08 AM, Gert Doering wrote: > Hi, > > On Fri, Oct 31, 2014 at 10:02:55AM -0400, Keith Moore wrote: >> In this case I'm using such a NAT that implements a IPv6 router with >> 6to4 as its external interface and "normal" v6 (unencapsulated, with >> SLAAC, RD, etc.) on the internal one. (In some cases it's also >> possible to build a 6to4 router that operates outside of the NAT, >> processes protocol 41 packets itself, and sends protocol 1, 6 and 17 >> packets to the NAT. The 6to4 router and the NAT have separate >> connections to the LAN.) > Which is, pretty much, "peer to peer 6to4", just implemented in a router > for "users in its /48", and not just in a host for itself. Actually it supports both "peer to peer 6to4" and connectivity to native v6 via a relay router. I believe the relay router is configurable but defaults to the anycast address. > > Doesn't make a big difference in the grand scheme - peer to peer 6to4 > is known to work, no matter how implemented, while 6to4-to-native is > known to not-work except in controlled environments The latter statement is simply false. Keith From nobody Fri Oct 31 07:21:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EEC1A9034 for ; Fri, 31 Oct 2014 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BwF0GMaIFXO for ; Fri, 31 Oct 2014 07:21:28 -0700 (PDT) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EC31A000E for ; Fri, 31 Oct 2014 07:21:28 -0700 (PDT) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 09:21:27 -0500 From: "Metzler, Dan J" To: Alexandru Petrescu , Brian E Carpenter , Owen DeLong , Keith Moore Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsew Date: Fri, 31 Oct 2014 14:21:26 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> In-Reply-To: <54536C7D.20301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mkxaANAhw5lszQHJgkeF26OsG5Y Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:21:37 -0000 I agree with the statement regarding mentioning alternatives in the documen= t, (perhaps in the introduction?), but I'd point out the tunneling protocol= (s) that could be used as an alternative, and then if desired, optionally l= ist some tunnel brokers along with that information. Hurricane Electric is= 6in4 or straight tunneling in protocol 41, which is not affected by this d= ocument. I wonder if perhaps some of the confusion from the discussion on this list = is from a faulty assumption that this document might be getting rid of the = protocols used by the tunnel brokers. For example, if a Hurricane Electric tunnel relied on 6to4, that may lead o= ne to the impression that one should no longer use a tunnel broker like Hur= ricane Electric because of the statement that 6to4 is deprecated.=20 The reason to focus on the protocols is because when you're buying a router= or looking at specs of an existing router, it is the protocol supported th= at determines the set of viable options. Or perhaps a reference to RFC 3053 ma= y be of use, though it may be somewhat dated, to distinguish between what t= his document is talking about and just a configured tunnel to a broker. I saw 6rd was mentioned pretty well, but that's more of a temporary transit= ional solution for an organization like an ISP, should they decide to imple= ment IPv6, which is what differentiates from configured tunnel brokers that= let you bypass the slow to adopt ISPs. (I realize 6rd was explained more = from the context of differentiating from 6to4.) Aside from adding some of this additional wording I would be supportive of = the intent of this document. Thanks, - Dan Metzler=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru > Petrescu > Sent: Friday, October 31, 2014 6:03 AM > To: Brian E Carpenter; Owen DeLong > Cc: v6ops@ietf.org WG; Keith Moore > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt= - > alternatives to 6to4 >=20 > Hi Brian, >=20 > I take advantage of your invitation to suggest text changes although I am= not > sure it covers topics unrelated to the one discussed in that email. >=20 > I think the document should mention what are the recommended > alternatives. Until now we see recommendations of particular tunnel > brokers such as Hurricane Electric's (is it really that company behind it= or just > a reuse from a distant past?) and SixXs or AYIYA, and also recommendation= s > to move to native IPv6. >=20 > There should be balance between these recommendations, because: >=20 > - tunnel broker should be considered as intermediate solution to native > IPv6 and as such may incur additional renumbering efforts. > - tunnel broker offers some advantages over 6to4, e.g. IPsec security is > possible because it's not an anycast address. > - tunnel broker creates new inconvenients, e.g. a new 'focal point' or si= ngle > point of failure. > - tunnel brokers seem well used and maintained. >=20 > Alex >=20 > Le 31/10/2014 01:12, Brian E Carpenter a =E9crit : > > On 31/10/2014 07:10, Owen DeLong wrote: > >>> p.s. Aside from the potential of this proposal to break things for pe= ople > who are currently successfully using 6to4 and who do not yet have a nativ= e > v6 alternative available, other things that bug me rather strongly about = this > document are its implicit position(s) that (a) IP-in-IP tunneling is some= thing > you shouldn't expect to work and therefore shouldn't be doing and (b) you > shouldn't be using tunneling to bypass your ISPs routing. I am emphatic= ally > opposed to both of those positions and feel that this document takes a > really carrier-centric (and customer-hostile) view that is not appropriat= e for > IETF to be taking. > > > > I really don't see that in the document. The problems with anycast > > 6to4 are not generic problems of protocol 41, and afaik the blocking > > of protocol 41, when it occurs, is mainly done by corporate firewalls. > > Enterprises would often like to block any kind of non-encrypted > > IP-in-IP tunnel because they view them as security bypasses. Anyway, > > please suggest text changes. > > > > Brian > > > >> I agree with both of these objections. > >> > >> Owen > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Oct 31 07:30:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325E1A9033 for ; Fri, 31 Oct 2014 07:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfMjTCWwLtlr for ; Fri, 31 Oct 2014 07:30:20 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580011A8B84 for ; Fri, 31 Oct 2014 07:30:20 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 74EFB6032F for ; Fri, 31 Oct 2014 15:30:18 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3384C60135 for ; Fri, 31 Oct 2014 15:30:18 +0100 (CET) Received: (qmail 92085 invoked by uid 1007); 31 Oct 2014 15:30:18 +0100 Date: Fri, 31 Oct 2014 15:30:18 +0100 From: Gert Doering To: Keith Moore Message-ID: <20141031143018.GI31092@Space.Net> References: <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54539A08.5090707@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V1ANN_Yf77RSG_a7iP0UN0nJFbY Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:30:22 -0000 Hi, On Fri, Oct 31, 2014 at 10:17:44AM -0400, Keith Moore wrote: > > Doesn't make a big difference in the grand scheme - peer to peer 6to4 > > is known to work, no matter how implemented, while 6to4-to-native is > > known to not-work except in controlled environments > > The latter statement is simply false. So, you know better than the people who actually *measure* and come to that conclusion based on observable reality? Call me impressed. Ever occurred to you that you might have just been lucky that 6to4-to-native worked from your personal vantage points (due to topological closeness to well-maintained relays in the forward and back direction), but that the Internet is slightly bigger than what you can see *and* nobody will guarantee you that this relay will still be there tomorrow? (Could someone just find out which relay Keith is using and break it, like, introduce 30% packet loss? Might be more convincing than just measurements and results) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Oct 31 07:30:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A5E1A9035 for ; Fri, 31 Oct 2014 07:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIQ-TAglT-kl for ; Fri, 31 Oct 2014 07:30:54 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FA11A9036 for ; Fri, 31 Oct 2014 07:30:54 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id l13so1107717iga.8 for ; Fri, 31 Oct 2014 07:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WA675+jknd/lk4rHeyj+7Xh/IEy83lg3t+m7Jprk/Y4=; b=SgsiDM0puFVdDgSrTUDDtCOeIhvbUfFG2M82L9xiygL1SGcuci9nGnzWXm340UnyKf XD+ygeeizRvzMlryAG4PRbUtg+K5e1sDqVsy7q2w3hf2oE6ViX/NBCc5CNICxm4vt8Za o7wQugwLU0hmPCgOtVnwAUumF9s9N8KLmMgSfoRFBO93nJf5M/x3UvE+qf55FAPSrJmF jQX7fOYYNB3+dqt/SJEFAFWb3aXze3m/ABd5r6nk96wfupG6SkJfjmMAG0+SLj/5+C80 UXWkOs8pLYMp+gk5xFBOQ+Y5Y4T0t/nInm5uLUOiWa0PaRVpUCeOgB/H3fPlDyIG0e4u i2bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WA675+jknd/lk4rHeyj+7Xh/IEy83lg3t+m7Jprk/Y4=; b=ApCsI5erRoLnVWzCxzOSb+aVwpKTnovi9hs5RL1RQheRlswsdVdG996CvutHVc4bUV /rUJLHMk5LyhMnrx7G8NSuaCksXJh0vD6wEfO8+SSnTXWoTyyL37uzy0ZiTLNkIJtNu/ SHZt1KzJpvk8Eq2NuMpJL8VE/xvA2NFP9ve9Cp1dBzDeTfYPgiIFb5Ph5mfH3qQFGwHX zrcqFIYpMpRud4kq8nKujGN0BT++W1c34MakAecFibEERqLv8RQDplkF7Cu6ea4zyHW0 Z5vA9e9vPG6NyvdFPS800l7Cc6S6YlCY8duWrcHot4uHCi/81L1MtQRl2RRXX1flyYzj tszw== X-Gm-Message-State: ALoCoQmY85LjlwWifmF4Epmzu3t2bNxDToaLPO+roJ/ESfJ4cumIgCajRKgO+YCBJfG0DwVLaZtS X-Received: by 10.42.49.8 with SMTP id u8mr24120838icf.39.1414765853604; Fri, 31 Oct 2014 07:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.176.203 with HTTP; Fri, 31 Oct 2014 07:30:33 -0700 (PDT) In-Reply-To: References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> From: Lorenzo Colitti Date: Fri, 31 Oct 2014 23:30:33 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=90e6ba1efb46252b940506b8d80a Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-uyXqgV6BvvOBhE8dFgEIf0lseA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:30:55 -0000 --90e6ba1efb46252b940506b8d80a Content-Type: text/plain; charset=UTF-8 On Fri, Oct 31, 2014 at 11:05 PM, Ole Troan wrote: > for my education, any idea what use cases there are / could be for direct > 6to4 connectivity? > given that: > - you shouldn't put 6to4 addresses in DNS > - 6to4 likely breaks if address sharing is in place > One use that comes to mind is bringing IPv6 connectivity to machines inside a legacy IPv4-only datacenter where the network gear does not support IPv6. --90e6ba1efb46252b940506b8d80a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 11:05 PM, Ole Troan <otroan@employees.org> wrote:
for my education, any idea w= hat use cases there are / could be for direct 6to4 connectivity?
given that:
=C2=A0- you shouldn't put 6to4 addresses in DNS
=C2=A0- 6to4 likely breaks if address sharing is in place
<= div>
One use that comes to mind is bringing IPv6 connectivity= to machines inside a legacy IPv4-only datacenter where the network gear do= es not support IPv6.
--90e6ba1efb46252b940506b8d80a-- From nobody Fri Oct 31 07:35:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30D11A9039 for ; Fri, 31 Oct 2014 07:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr-Axsuabl1c for ; Fri, 31 Oct 2014 07:35:57 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [46.20.246.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA46E1A9038 for ; Fri, 31 Oct 2014 07:35:52 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id DC965100A037C; Fri, 31 Oct 2014 14:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414766150; bh=I7/R1PFGLpmdk8tjLL3iXQLFHcenlZ2cYuRRqkEqJzw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=gy+nW0iJDcw3Du7bRERZ/CYQ7SN4g2C3OZ6MGFQ7pqTvD9KQGQEwmAoIxGrq7ELv4 uZiH+qDqEbzRMk78x1OSberLYHSVog8IHnt7XDZB9gvV5wLeQxxUi6VDDl3/hlkE96 OEGBnUd9oWE3ntj1DJA1C7LvJALS0NWus0a6vOG2adFq47Vsaz7JM9LUBbtnTaj4Wc gXeF+szcUxs/oNeFEtUdk0ncUp9HaGq4/TBqQucU8Z9y3i7vb2Q/rVX53Yaetv71od QPBzLG4kxyFe7LIkK3/vq5UkaZnQmxNhj/bmKlAd6AVvgmPHECTH7tVBwmk4Y5Me7z jYzNvLD774R3Q== Message-ID: <54539E44.90602@massar.ch> Date: Fri, 31 Oct 2014 15:35:48 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Lorenzo Colitti , Ole Troan References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LfxBzn75WcZhJvEjvNxgpgF2h_k Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:35:59 -0000 On 2014-10-31 15:30, Lorenzo Colitti wrote: > On Fri, Oct 31, 2014 at 11:05 PM, Ole Troan > wrote: > > for my education, any idea what use cases there are / could be for > direct 6to4 connectivity? > given that: > - you shouldn't put 6to4 addresses in DNS > - 6to4 likely breaks if address sharing is in place > > > One use that comes to mind is bringing IPv6 connectivity to machines > inside a legacy IPv4-only datacenter where the network gear does not > support IPv6. Put a box on each Ethernet segment that does support IPv6, effectively putting a second IPv6-only router everywhere. That 'box' could be one of the servers that you already have on that segment. Any other model, eg putting a tunnel on every host, will not scale (though, with Puppet or other it won't be a big pain...) I don't see where 6to4 comes into play there. Greets, Jeroen From nobody Fri Oct 31 07:37:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37BF1A9038 for ; Fri, 31 Oct 2014 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BmrFv7NYBZm for ; Fri, 31 Oct 2014 07:37:00 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE65A1A8AA9 for ; Fri, 31 Oct 2014 07:37:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2A8C82083F for ; Fri, 31 Oct 2014 10:37:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 31 Oct 2014 10:37:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=tKWZL/s3W9aM9rxWspNyAC Suldg=; b=Jo23KpogNUW4vxryAEpmlNnoZpe/2erkMx3F2KRTI2ZaKoLDlwfe1Z Pt5CeLrnbmETdXv+m7Xlli4Mi//31qk2P/gorOhhZuQqoaJ/xrfSj9bFOTLRwCYA ChjNQeD0Jjxog4QEH4J/qn/nixj+IFiq9MgLLUFjG3kLUn7P7OaHI= X-Sasl-enc: 4HQz9yvwMOWGe7kwNGioSDKTQV4jtglMXNP9VX/o91/m 1414766219 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 56DA06800FF; Fri, 31 Oct 2014 10:36:59 -0400 (EDT) Message-ID: <54539E80.40301@network-heretics.com> Date: Fri, 31 Oct 2014 10:36:48 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Metzler, Dan J" , Alexandru Petrescu , Brian E Carpenter , Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/EU8RBtR0s3WHDhrIxRyHKUp2dq4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:37:05 -0000 On 10/31/2014 10:21 AM, Metzler, Dan J wrote: > I agree with the statement regarding mentioning alternatives in the document, (perhaps in the introduction?), but I'd point out the tunneling protocol(s) that could be used as an alternative, and then if desired, optionally list some tunnel brokers along with that information. Hurricane Electric is 6in4 or straight tunneling in protocol 41, which is not affected by this document. > > I wonder if perhaps some of the confusion from the discussion on this list is from a faulty assumption that this document might be getting rid of the protocols used by the tunnel brokers. > For example, if a Hurricane Electric tunnel relied on 6to4, that may lead one to the impression that one should no longer use a tunnel broker like Hurricane Electric because of the statement that 6to4 is deprecated. I've seen protocol 41 being blocked - literally transmitted packets from one host to another (with no NAT in between) where protocol 6 packets got through and protocol 41 packets didn't. That breaks both 6to4 and 6in4. I've read accounts that indicate that other providers are also doing this. One of the things I don't want is an RFC published that legitimizes this in any sense, even an oblique one. > I saw 6rd was mentioned pretty well, but that's more of a temporary transitional solution for an organization like an ISP, should they decide to implement IPv6, which is what differentiates from configured tunnel brokers that let you bypass the slow to adopt ISPs. (I realize 6rd was explained more from the context of differentiating from 6to4.) Yeah, 6rd isn't an alternative from the point of view of a user/customer needing a way to exchange IPv6 packets with hosts on other networks, and without v6 support from his ISP. Keith From nobody Fri Oct 31 07:41:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC11A903B for ; Fri, 31 Oct 2014 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnSCGoPb99vO for ; Fri, 31 Oct 2014 07:41:33 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19D31A9039 for ; Fri, 31 Oct 2014 07:41:33 -0700 (PDT) Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 539C96136; Fri, 31 Oct 2014 07:41:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ole Troan In-Reply-To: Date: Fri, 31 Oct 2014 15:41:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47A53E4A-BF74-4B1F-9198-0BD3829673A5@employees.org> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jJfP-5cafPL7EOIkhcKujjelbH0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:41:35 -0000 Lorenzo, > for my education, any idea what use cases there are / could be for = direct 6to4 connectivity? > given that: > - you shouldn't put 6to4 addresses in DNS > - 6to4 likely breaks if address sharing is in place >=20 > One use that comes to mind is bringing IPv6 connectivity to machines = inside a legacy IPv4-only datacenter where the network gear does not = support IPv6. but it wouldn't be IPv6 connectivity since you cannot reach the IPv6 = Internet using 6to4 anymore. would it be useful in that case to be able to build a topologically = restricted IPv6 overlay network? e.g. for local IPv6 only applications = in the data centre? isn't that much more likely to lead to breakage? cheers, Ole= From nobody Fri Oct 31 07:44:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347B51A9063 for ; Fri, 31 Oct 2014 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc-R6Z-z7-pr for ; Fri, 31 Oct 2014 07:44:00 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF691A9064 for ; Fri, 31 Oct 2014 07:43:59 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id x19so1406273ier.19 for ; Fri, 31 Oct 2014 07:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=owGT8mBw78vANKbXpbASlgalpxmR6MPqj8RWh1F5JyY=; b=FEKtr3hS5WbXbbtnwBXmXZ7CQxfpJbPgzMWuppD5IGH6NOTwCa1jop9mLbK+YyBZRv PImRnT8k73QB3Ggx+T+IeVKS5dkSc4o+OLn/f4xjYkjRhjWXkNq7k22QwuDbzIVut8ZU V9hcCY70Jqavbgz5dpFepSrCaMeo01iP/SGPjyFayMuIKj90QZyxsySrhM8wBMrbItL6 o+DRuDH3ZnuB5bLdYq77he/H/wOPgLKGz4rkTNmaZaHDqD2bj6cJyTQ/HE+frsnTyLmd yI38v+AA/CZDbTGuZ8BE5WKKzUTZAmctPz0kDuveWeIbx7jZt3MyhZ3RMz637a1jj7p5 BVdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=owGT8mBw78vANKbXpbASlgalpxmR6MPqj8RWh1F5JyY=; b=ENunC+lREKH3ICxxo2dtjTBusv7qboqhG9WEF3YwK7rLYDcPrx5qHWEg2/PwfjNXUb kLDsirehY28DdoDgaUzmNT0PFuYHmXFAliVDTYWScd7Xtv6iel7iMOm/WuDYAb9Q0xiI qEEdLvR8Di0wgTfYEKxaDlxcMgc+TmtOCrWUWKGTrrn9dFk//afgd6t5xuh+1acrt502 5nqq7CGtLbAo5QBINiHWNbVoPN6lEWnY2Cmv2H0HeDDWzOJVg4E01z+pIe1EtDUU6WCS 9p1iaeaVjYnWz9B6rk4uIWdRW/Xqz8YGY7qbD9obj5GWSesfvbPp8JPBW30RmVn5Wa/0 1whw== X-Gm-Message-State: ALoCoQkA+TDFwaLCpKO81kVcG11AucBS8todeYnLLO+eFV9ATt8WmSK55+KVA4KCA9wQMY835uoS X-Received: by 10.107.162.16 with SMTP id l16mr28060933ioe.54.1414766639356; Fri, 31 Oct 2014 07:43:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.176.203 with HTTP; Fri, 31 Oct 2014 07:43:39 -0700 (PDT) In-Reply-To: <47A53E4A-BF74-4B1F-9198-0BD3829673A5@employees.org> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> <47A53E4A-BF74-4B1F-9198-0BD3829673A5@employees.org> From: Lorenzo Colitti Date: Fri, 31 Oct 2014 23:43:39 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=001a1140a1b4fac36d0506b906bf Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/05lm7H_OWToptAn3rMgYn0c7CIA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:44:01 -0000 --001a1140a1b4fac36d0506b906bf Content-Type: text/plain; charset=UTF-8 On Fri, Oct 31, 2014 at 11:41 PM, Ole Troan wrote: > > One use that comes to mind is bringing IPv6 connectivity to machines > inside a legacy IPv4-only datacenter where the network gear does not > support IPv6. > > but it wouldn't be IPv6 connectivity since you cannot reach the IPv6 > Internet using 6to4 anymore. > It would be local IPv6 connectivity. But the datacenter might not allow direct access to the Internet anyway, even on IPv4, so that might not be a problem. > would it be useful in that case to be able to build a topologically > restricted IPv6 overlay network? e.g. for local IPv6 only applications in > the data centre? > isn't that much more likely to lead to breakage? > 6to4 *is* an overlay network. --001a1140a1b4fac36d0506b906bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 11:41 PM, Ole Troan <otroan@employees.org> wrote:
> One us= e that comes to mind is bringing IPv6 connectivity to machines inside a leg= acy IPv4-only datacenter where the network gear does not support IPv6.

but it wouldn't be IPv6 connectivity since you cannot reach the = IPv6 Internet using 6to4 anymore.

It wo= uld be local IPv6 connectivity. But the datacenter might not allow direct a= ccess to the Internet anyway, even on IPv4, so that might not be a problem.=
=C2=A0
would it be useful in that case to be able to build a topologically restric= ted IPv6 overlay network? e.g. for local IPv6 only applications in the data= centre?
isn't that much more likely to lead to breakage?
<= br>
6to4 *is* an overlay network.
--001a1140a1b4fac36d0506b906bf-- From nobody Fri Oct 31 07:45:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186381A9067 for ; Fri, 31 Oct 2014 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkV7NCLhalU4 for ; Fri, 31 Oct 2014 07:45:14 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED4F1A9064 for ; Fri, 31 Oct 2014 07:45:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5B25620813 for ; Fri, 31 Oct 2014 10:45:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 31 Oct 2014 10:45:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=fYY3fO4uERN58qdTNukWDm H+x7s=; b=N+26N9NGoDDm9dUE1CYy33kWAvlvBedr4/TqeuLUs2BzHDEO8K3Ys/ 0kVlLWzXBk7CX9oAsqpXK5SF+Lr8AJ2g9f1nno3MJ4B46Rx557ElU64mg+tdNy2C Y81scI737fsELbaqpO5o6rkE9gsoAkWpKpklIeGlm8IQFyEOLaeHU= X-Sasl-enc: Nqff31CTDyUrxFB01RPmQGR5bMmd9N1xvi98Qdh+zQvC 1414766713 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E0F43680124; Fri, 31 Oct 2014 10:45:12 -0400 (EDT) Message-ID: <5453A06E.6030705@network-heretics.com> Date: Fri, 31 Oct 2014 10:45:02 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Gert Doering References: <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> In-Reply-To: <20141031143018.GI31092@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hEzUgobFn5plnDTSZCfmHQQdWKM Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:45:19 -0000 On 10/31/2014 10:30 AM, Gert Doering wrote: > Hi, > > On Fri, Oct 31, 2014 at 10:17:44AM -0400, Keith Moore wrote: >>> Doesn't make a big difference in the grand scheme - peer to peer 6to4 >>> is known to work, no matter how implemented, while 6to4-to-native is >>> known to not-work except in controlled environments >> The latter statement is simply false. > So, you know better than the people who actually *measure* and come to > that conclusion based on observable reality? Measurements taken under different conditions will yield different results. "observable reality" includes both kinds of results. > Call me impressed. > > Ever occurred to you that you might have just been lucky that 6to4-to-native > worked from your personal vantage points (due to topological closeness > to well-maintained relays in the forward and back direction), but that > the Internet is slightly bigger than what you can see *and* nobody will > guarantee you that this relay will still be there tomorrow? Has it ever occurred to you that I've been using 6to4 since before the RFC was published and that I've seen a lot of different behaviors by now? Has it ever occurred to you that I could pick ISPs on the basis of whether they were hostile to 6to4? Of course I'm aware that relay routers can go away - that's why I have no problem (ok, not much problem) with deprecating RFC 3068. But in my case the relay router didn't go away - it appears that one of my ISPs (soon to be ex-ISP) started blocking it. (because I'm getting ICMP net unreachables). When to some degree the problems with 6to4 result from operator attacks on it, I don't think that's something that IETF should be supporting - I think IETF should be calling operators out on it. > (Could someone just find out which relay Keith is using and break it, > like, introduce 30% packet loss? Might be more convincing than just > measurements and results) Because you don't really care about measurements and results? Keith From nobody Fri Oct 31 07:53:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75F1A9043 for ; Fri, 31 Oct 2014 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noQipbE8SR0C for ; Fri, 31 Oct 2014 07:53:51 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A981A902F for ; Fri, 31 Oct 2014 07:53:50 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8FCC760797 for ; Fri, 31 Oct 2014 15:53:48 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4C1BB60872 for ; Fri, 31 Oct 2014 15:53:48 +0100 (CET) Received: (qmail 96981 invoked by uid 1007); 31 Oct 2014 15:53:48 +0100 Date: Fri, 31 Oct 2014 15:53:48 +0100 From: Gert Doering To: Keith Moore Message-ID: <20141031145348.GJ31092@Space.Net> References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZDCXMAZNx0UVtWzg" Content-Disposition: inline In-Reply-To: <5453A06E.6030705@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Bf0oKXLTmFkXOy68XNaAxtbaW0M Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:53:53 -0000 --ZDCXMAZNx0UVtWzg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Oct 31, 2014 at 10:45:02AM -0400, Keith Moore wrote: > Of course I'm aware that relay routers can go away - that's why I have=20 > no problem (ok, not much problem) with deprecating RFC 3068. But in my=20 > case the relay router didn't go away - it appears that one of my ISPs=20 > (soon to be ex-ISP) started blocking it. (because I'm getting ICMP net= =20 > unreachables). So would you be fine with the document saying "3065 is good, 3068 should be deprecated"? =46rom your e-mails it is still fully unclear to me whether you're talking about peer-to-peer 6to4 or 6to4-to-native, and to which part you're=20 objecting - and it has been said often enough that nobody will take=20 away your peer-to-peer 6to4 (and the draft is actually fairly clear about that). > When to some degree the problems with 6to4 result from operator attacks= =20 > on it, I don't think that's something that IETF should be supporting - I= =20 > think IETF should be calling operators out on it. The problem with 6to4-to-native isn't operators actively attacking relays, more operators loosing interest in proper maintenance - as in "the person who set this up left the company, nobody knows it's still there, the router is overloaded and drops packets". Since nobody is paying for it, and it's very hard to actually figure out who to yell at in the generic relay case, this is just a model that is not sustainable, without any malevolence involved - no matter how often=20 you call it "attacking". > > (Could someone just find out which relay Keith is using and break it, > > like, introduce 30% packet loss? Might be more convincing than just > > measurements and results) >=20 > Because you don't really care about measurements and results? Oh, I do. (And while I *do* maintain and monitor my relay, I have spent enough time debugging 6to4 with "some other relay being used for the return path" to understand that this is not the solution we're looking for, no matter what the problem is) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ZDCXMAZNx0UVtWzg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVFOifN9WwGXkzn/FAQIjiQ/+N/WdFD9+Jr4Hvc/am9wUSCp0QKXXCiBg x48L0AbnTlJE0CFyum9oqBWN68R20mDj9AdG5ED/zpvWn1FoeLYIcqf3KmQy8KW5 JWpS0yNwsLHBYvA4mSXaBRKncHGR/jeAUdjTtHUGFXMnJD6gDIt3Q/k9sVsXTkPl BY6GIXKEEx4SW+IfCLYzhgNItCPI5y40doHELE1Kh84Gwa3escuIroXcqwydYjVE dpI3Dm8UUd2hb4incGMiPGh2obfIrXlIEva+ElUhswaT3UzbvMvQ43L2gVqVtMCK NgsChJHWvnrXdSCJGjsY6X+fJOexAJOwuU6Wvgx90ZGh6jwHq58kkiH3yR842FgY bO+PJSt4sdcz8OZUTCZYKhRzv7mhofJF1EL5UX0WZQQW6ol/iWOlEXAtasr1BNNo 8OVPE2qeo7JS5SjHZYj/FHWrEACK9ectSjNfIJ7jf4BZOVSBDsL0BNnjMLuMc/+Z vxpHVMZ0FVOE+LqeYejhK74yrpAricUB41e2rSTt6VMUzIyuTseBuW1Le86/nY/v t3rSql6QLfXOSORgUOBXhChByGDy3zCJRXzPX1sxLShehREsxqNO9qchH1BRcPWE L6z0ppinVVJIoZ7LTy+E9muroyUY/fcvKh3vN4wNrCmCZ63/KrPze9BLA4YcWCOY x59RCm5kuIE= =9ecx -----END PGP SIGNATURE----- --ZDCXMAZNx0UVtWzg-- From nobody Fri Oct 31 07:54:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A967A1A9089 for ; Fri, 31 Oct 2014 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBCceLFQfMDS for ; Fri, 31 Oct 2014 07:54:48 -0700 (PDT) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CF01A9084 for ; Fri, 31 Oct 2014 07:54:25 -0700 (PDT) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 09:54:24 -0500 From: "Metzler, Dan J" To: Keith Moore , Alexandru Petrescu , Brian E Carpenter , Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsewgABzRwD//6ydEA== Date: Fri, 31 Oct 2014 14:54:23 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> In-Reply-To: <54539E80.40301@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VTC2Cdz-WBLVfQ_RZgaY1r6Jeqc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:54:50 -0000 > -----Original Message----- > From: Keith Moore [mailto:moore@network-heretics.com] > Sent: Friday, October 31, 2014 9:37 AM > To: Metzler, Dan J; Alexandru Petrescu; Brian E Carpenter; Owen DeLong > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt= - > alternatives to 6to4 >=20 > On 10/31/2014 10:21 AM, Metzler, Dan J wrote: > > I agree with the statement regarding mentioning alternatives in the > document, (perhaps in the introduction?), but I'd point out the tunneling > protocol(s) that could be used as an alternative, and then if desired, > optionally list some tunnel brokers along with that information. Hurrica= ne > Electric is 6in4 or straight tunneling in protocol 41, which is not affec= ted by > this document. > > > > I wonder if perhaps some of the confusion from the discussion on this l= ist > is from a faulty assumption that this document might be getting rid of th= e > protocols used by the tunnel brokers. > > For example, if a Hurricane Electric tunnel relied on 6to4, that may le= ad > one to the impression that one should no longer use a tunnel broker like > Hurricane Electric because of the statement that 6to4 is deprecated. >=20 > I've seen protocol 41 being blocked - literally transmitted packets from = one > host to another (with no NAT in between) where protocol 6 packets > got through and protocol 41 packets didn't. That breaks both 6to4 and > 6in4. I've read accounts that indicate that other providers are also doi= ng > this. >=20 > One of the things I don't want is an RFC published that legitimizes this = in any > sense, even an oblique one. >=20 I didn't see anything that implied support for blocking protocol 41 in this= draft. Adding language in support of 6in4 as an alternative would certainly not le= gitimize the blocking of protocol 41. Am I missing something? That said, if you already have native IPv6 available, I can see where a pro= vider might want to block it. From nobody Fri Oct 31 08:04:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A6A1A908D for ; Fri, 31 Oct 2014 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLEQVs4deOko for ; Fri, 31 Oct 2014 08:04:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD41A909B for ; Fri, 31 Oct 2014 08:04:10 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9VF32Tt016770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 08:03:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9VF32Tt016770 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414767783; bh=aWAem69HwxoXHS9xTx/I2GDkkRU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=je8722VfgzX/NvrPKO+Z0CyMd9RJBfzqsqDlshLb4cqHgY+fWpADeEYZgwPnuSFO/ xQmG14k5QCYVLfY4Ez6MRIzhVwxRGa1EEH6WGXxwSDPIETrbOPqENTBIy7dZotuqHo llAZ7jIEeBYFrb2CY9UeleXHMvKSqzg1FjkkJPoo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <5452D73F.9000504@gmail.com> Date: Fri, 31 Oct 2014 08:02:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0640C5CC-201C-482A-8A6E-D48911B825E0@delong.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> <5452D73F.9000504@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 Oct 2014 08:03:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/X0TZ0p4g8sVq_BI_N94b4rmSoOQ Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:04:16 -0000 >>=20 >> It=E2=80=99s not that uncommon today. DDWRT generally supports it. = Almost all of the IPv6 capable consumer grade routers from D-Link, = Netgear, Apple, et al support it. >=20 > You mean support for manually configured tunnels per RFC 4213, or = what? > (My FritzBox has great native IPv6 support but no tunnel support that > I can find, and my D-Link box is old.) Yes=E2=80=A6 Manually configured tunnels. Not sure which RFC, but if you = look at the instructions available on http://tunnelbroker.net you will find a great many examples for various routers, including for = example, the Apple Airports complete with screenshots. Owen >=20 > Brian >=20 >>> I predict that this will not change, but we might see pressure for >>> 464xlat in CPEs. >>=20 >> 464xlat isn=E2=80=99t currently there. 6in4 is pretty common in my = experience. >>=20 >> YMMV. >>=20 >> Owen >>=20 >>=20 >>=20 From nobody Fri Oct 31 08:24:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098E61ACCEE for ; Fri, 31 Oct 2014 08:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, GB_I_INVITATION=-2, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFlyCNWbVJAH for ; Fri, 31 Oct 2014 08:24:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 661691A902D for ; Fri, 31 Oct 2014 08:23:58 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9VFNAi1018207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 08:23:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9VFNAi1018207 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414768991; bh=sCnDtG75lDxh8vN3syuTPvwT/y0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=1ClUvCtgdHJFmwgRlz7/kr3XyIOjtXE+vRt/YMIzov9ctAzU4ApdSiASH8bE0Qj0E I4H5l4DQCqhMQG5k04yQRBAzHw4G49y/NQrY34JEw+KdXiUj+zTrKXi1AwKC2Wbao3 qrtD5nCM6ZcHB9Yd0OPEBrebDc+qkxafc2J//Qyo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <54536C7D.20301@gmail.com> Date: Fri, 31 Oct 2014 08:23:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51A70A26-696C-47D9-8345-8FE6B41AF729@delong.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 Oct 2014 08:23:11 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wRAHK6LdKgkjl4xNkcBDcLcjkH0 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:24:10 -0000 > On Oct 31, 2014, at 4:03 AM, Alexandru Petrescu = wrote: >=20 > Hi Brian, >=20 > I take advantage of your invitation to suggest text changes although I = am not sure it covers topics unrelated to the one discussed in that = email. >=20 > I think the document should mention what are the recommended = alternatives. Until now we see recommendations of particular tunnel = brokers such as Hurricane Electric's (is it really that company behind = it or just a reuse from a distant past?) and SixXs or AYIYA, and also = recommendations to move to native IPv6. >=20 > There should be balance between these recommendations, because: >=20 > - tunnel broker should be considered as intermediate solution to = native IPv6 and as such may incur additional renumbering efforts. > - tunnel broker offers some advantages over 6to4, e.g. IPsec security = is possible because it's not an anycast address. > - tunnel broker creates new inconvenients, e.g. a new 'focal point' or = single point of failure. > - tunnel brokers seem well used and maintained. A tunnel broker is only a single point of failure if you use only one = tunnel to one tunnel broker. If you use diversity of tunnel brokers, and/or a tunnel broker and other = transit, it is not a single point of failure at all. Owen >=20 > Alex >=20 > Le 31/10/2014 01:12, Brian E Carpenter a =E9crit : >> On 31/10/2014 07:10, Owen DeLong wrote: >>>> p.s. Aside from the potential of this proposal to break things for = people who are currently successfully using 6to4 and who do not yet have = a native v6 alternative available, other things that bug me rather = strongly about this document are its implicit position(s) that (a) = IP-in-IP tunneling is something you shouldn't expect to work and = therefore shouldn't be doing and (b) you shouldn't be using tunneling to = bypass your ISPs routing. I am emphatically opposed to both of those = positions and feel that this document takes a really carrier-centric = (and customer-hostile) view that is not appropriate for IETF to be = taking. >>=20 >> I really don't see that in the document. The problems with anycast = 6to4 >> are not generic problems of protocol 41, and afaik the blocking of >> protocol 41, when it occurs, is mainly done by corporate firewalls. >> Enterprises would often like to block any kind of non-encrypted >> IP-in-IP tunnel because they view them as security bypasses. Anyway, >> please suggest text changes. >>=20 >> Brian >>=20 >>> I agree with both of these objections. >>>=20 >>> Owen >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 From nobody Fri Oct 31 08:29:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4BB1A902D for ; Fri, 31 Oct 2014 08:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0tVzs94bano for ; Fri, 31 Oct 2014 08:29:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id AF3ED1A0115 for ; Fri, 31 Oct 2014 08:29:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XkE8Y-0000EbC; Fri, 31 Oct 2014 16:29:14 +0100 Message-Id: To: Gert Doering From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> In-reply-to: Your message of "Fri, 31 Oct 2014 15:30:18 +0100 ." <20141031143018.GI31092@Space.Net> Date: Fri, 31 Oct 2014 16:29:12 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4KsqMyi9vh7BdkF9lXtPc_-EA8w Cc: v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:29:18 -0000 In your letter dated Fri, 31 Oct 2014 15:30:18 +0100 you wrote: >Ever occurred to you that you might have just been lucky that 6to4-to-native >worked from your personal vantage points (due to topological closeness >to well-maintained relays in the forward and back direction), but that >the Internet is slightly bigger than what you can see *and* nobody will >guarantee you that this relay will still be there tomorrow? > >(Could someone just find out which relay Keith is using and break it, >like, introduce 30% packet loss? Might be more convincing than just >measurements and results) Random data point, a ping from all IPv6 capable probes on RIPE Atlas to one target, gives: (all probes) 388 rcvd":0 2 rcvd":1 9 rcvd":2 2140 rcvd":3 (probes with a 6to4 address) 12 rcvd":0 1 rcvd":2 36 rcvd":3 3 ICMP echo requests were sent, this is the number of probes that report a certain number of replies. I'd say that based on these stats, 6to4 probes are not a lot worse than average. From nobody Fri Oct 31 08:32:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228071A902D for ; Fri, 31 Oct 2014 08:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HccwKWZ1uOPk for ; Fri, 31 Oct 2014 08:31:55 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D396D1A906E for ; Fri, 31 Oct 2014 08:31:54 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8C7E462A8B for ; Fri, 31 Oct 2014 16:31:53 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 47275608D0 for ; Fri, 31 Oct 2014 16:31:53 +0100 (CET) Received: (qmail 4502 invoked by uid 1007); 31 Oct 2014 16:31:53 +0100 Date: Fri, 31 Oct 2014 16:31:53 +0100 From: Gert Doering To: Philip Homburg Message-ID: <20141031153153.GM31092@Space.Net> References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tcYwBgz2SUatb/MO" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NkNhI7vWOTBk_H2k1NaJq7CY88U Cc: v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:31:57 -0000 --tcYwBgz2SUatb/MO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Oct 31, 2014 at 04:29:12PM +0100, Philip Homburg wrote: > I'd say that based on these stats, 6to4 probes are not a lot worse than a= verage. Is "send a one-way ping" a useful metric for "we have a problem with return relays" or "the RTT increases in a way that this is way worse than IPv4"? But it's interesting how poor IPv6 reliability for "Atlas probes with IPv6" is. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --tcYwBgz2SUatb/MO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVFOrad9WwGXkzn/FAQJOQA//YyiujiQ5cOD8mEfttVvOJvGbGe/eg28D AZzchpWBjQX+x5lox2pR3iYbq86Y690ppYSqHclloyZVmnzXDbbNovC/lGP29egU wG9H18x48KrLUyfh2/RoQo/7dWY57WllgtRSZVD0b6DV8lrsQofmfiPx9l5BTqp3 6O6gcX2u5jMaCNqsjc3U/Vfe1hEAkR75WOY3HmlJd2i8p2wsx54Qms+byYOAklvB Lr+kgoC1iA0aGhfh+hXEjVWY6nRqce+1A17c6awA7DupTAwBQhUDgFm1qIHsQ02b UQPeizn3fdoKP0Cr6nYHhkVFNF+Rh549ORt1EMleBDrY6QZV47mipQto3nXdfh5J pDmigMZLeEJ1KPsoHCsdEsF/6jU0DOOxlsGVGou0vhIsK06WPdi86+P+BJQC6wju wL/ZcUyomsxl0pW4Qn9k/M9IBigKAzPKeK/URN5mZNrzEr5e3cjYBW3OQ4zh8nME fE1XTMl64gTW7A76RS4M4DEgCikVyQ3wLCNOE1KMeKMJbqhgri9rBsJFHrZUM0f5 ToFPSztOTnlOIrLp5gNNfNYjdn3duIPwDKoO2ICocxee/SmQyCnhfvv54mnpqRT0 VN28Y0YYFqOl+YdNHjezq7sPK2ATjAGOIHwOKV/sBYmK8XC/HNHR8DbwILgZCTz7 aqTA7pTiGIs= =/CZt -----END PGP SIGNATURE----- --tcYwBgz2SUatb/MO-- From nobody Fri Oct 31 08:34:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C237F1A90B7 for ; Fri, 31 Oct 2014 08:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFUhlQXXj2dU for ; Fri, 31 Oct 2014 08:34:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A7C0D1A9091 for ; Fri, 31 Oct 2014 08:34:12 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9VFSmLC018491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 08:28:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9VFSmLC018491 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414769329; bh=qon8GZTLhxXUfY85EJkIAmmTzhQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=C9S79ysEbcfFiSwRnXQB72JUczMFY5QxHo8xtK1aTUwhjT1D91njsPBAbQL/f8n+A pof2BNfmlYWeJysntkQXn5VQXrzKF02LciVqYaZUpO5zLq2+SMvRwD4JvKcCdVy1oN OdUuxgagaeCO1JmQaFVm0j0WB2wWg2imFcdPPstE= Content-Type: multipart/alternative; boundary="Apple-Mail=_11DBC1DB-B942-4CB6-97F2-2D0D5D032B1A" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Fri, 31 Oct 2014 08:28:43 -0700 Message-Id: <5E0121DB-11B6-4226-BE91-3657C1BACF9C@delong.com> References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589DB489@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E1C67@nkgeml506-mbx.china.huawei.com> <54514014.40604@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45589E2D44@nkgeml506-mbx.china.huawei.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 Oct 2014 08:28:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/B7-Jyx71E5p3y3uhFEDfo3r-SzM Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:34:13 -0000 --Apple-Mail=_11DBC1DB-B942-4CB6-97F2-2D0D5D032B1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 31, 2014, at 5:57 AM, Lorenzo Colitti = wrote: >=20 > On Fri, Oct 31, 2014 at 7:38 PM, Andrew =F0=9F=91=BD Yourtchenko = > wrote: > Now, of course it is a lot of additional testing work, so adding > anything like that into the document would be contingent on more > participants of WG saying it is a useful idea vs. shipping the > document as is. >=20 > The way I see it, the value of the document is in the testing, not in = the operational guidance (of which there is very little). Thus, more = testing would increase the value of the document. +1 Owen --Apple-Mail=_11DBC1DB-B942-4CB6-97F2-2D0D5D032B1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 31, 2014, at 5:57 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Fri, Oct 31, 2014 at 7:38 PM, Andrew =F0=9F=91=BD= Yourtchenko <ayourtch@gmail.com> wrote:
Now, of course it is a = lot of additional testing work, so adding
anything like that into the document would be contingent on more
participants of WG saying it is a useful idea vs. shipping the
document as is.

The way I see it, the value of the = document is in the testing, not in the operational guidance (of which = there is very little). Thus, more testing would increase the value of = the document.

+1

Owen
= --Apple-Mail=_11DBC1DB-B942-4CB6-97F2-2D0D5D032B1A-- From nobody Fri Oct 31 08:38:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1331A9029 for ; Fri, 31 Oct 2014 08:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH9tcsKZ_KrE for ; Fri, 31 Oct 2014 08:38:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DC97A1A011E for ; Fri, 31 Oct 2014 08:38:34 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9VFXVkN018777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 08:33:31 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9VFXVkN018777 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414769613; bh=4fURVuGhOkc6QkDTfzswPcbdk2o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=kViMq5bOtThm5TB1bpcjT+3lsH5rWznqpdlihcq1uL02B5UXnn2RgC6AACguswTRL 885JzgYZnZZGXRyFYEL1q3+wZU2o2eagQKSPdyPxSXVfarrEqvoMjjgRJGR+KdGFqZ J4VA9XDP9NjdfwwYOHimECV7RQI/k/L1gH4gQIfA= Content-Type: multipart/alternative; boundary="Apple-Mail=_E8FE7A57-1DF8-4603-820A-2ECB9D4CD80D" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: Date: Fri, 31 Oct 2014 08:33:25 -0700 Message-Id: <4DED0D21-AD0E-4983-BE25-741590B0CD6E@delong.com> References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <929CBC54-691A-4D35-AAF5-1F02C7D84073@lists.zabbadoz.net> <617295AC-ABF0-451C-BA9C-4BEA048DD19A@nominum.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 Oct 2014 08:33:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/f7mQrqwhWEVK9kry-AYNYmlBt3w Cc: IPv6 Operations , "Bjoern A. Zeeb" Subject: Re: [v6ops] I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:38:36 -0000 --Apple-Mail=_E8FE7A57-1DF8-4603-820A-2ECB9D4CD80D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 31, 2014, at 6:23 AM, Eric Vyncke (evyncke) = wrote: >=20 >=20 >=20 > From: Simon Perreault > >> We need more and more to think of source IP addresses as ephemeral = things. Just like you don't care which ephemeral source port gets picked = by the OS when you call connect(), you shouldn't care about which source = address is picked when calling connect_by_name() or whatever other = HE-like API out there. >>=20 >=20 >=20 > Ephemeral and probably less and less meaningful That=E2=80=99s all well and good, except when source address selection = goes horribly wrong, you=E2=80=99re in a world of hurt if the API = doesn=E2=80=99t provide a mechanism for override. Owen --Apple-Mail=_E8FE7A57-1DF8-4603-820A-2ECB9D4CD80D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 31, 2014, at 6:23 AM, Eric Vyncke (evyncke) <evyncke@cisco.com> = wrote:



From: Simon Perreault = <sperreault@jive.com>
We need more and more to think of source IP = addresses as ephemeral things. Just like you don't care which ephemeral = source port gets picked by the OS when you call connect(), you shouldn't = care about which source address is picked when calling connect_by_name() or whatever other HE-like API out = there.

Ephemeral and probably less and less = meaningful

That=E2=80=99s all well and good, except when source = address selection goes horribly wrong, you=E2=80=99re in a world of hurt = if the API doesn=E2=80=99t provide a mechanism for = override.

Owen

= --Apple-Mail=_E8FE7A57-1DF8-4603-820A-2ECB9D4CD80D-- From nobody Fri Oct 31 08:39:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3BA1A9029 for ; Fri, 31 Oct 2014 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOLTFbZ0cw8P for ; Fri, 31 Oct 2014 08:39:31 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA21C1A011E for ; Fri, 31 Oct 2014 08:39:30 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9VFd41x016819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2014 15:39:24 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <5453AD17.2030202@foobar.org> Date: Fri, 31 Oct 2014 15:39:03 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Philip Homburg , Gert Doering References: <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UFQPgqxh5_3tjLuE8QOKuuJhxSw Cc: v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:39:33 -0000 On 31/10/2014 15:29, Philip Homburg wrote: > Random data point, a ping from all IPv6 capable probes on RIPE Atlas to one > target, gives: > (all probes) > 388 rcvd":0 > 2 rcvd":1 > 9 rcvd":2 > 2140 rcvd":3 > > (probes with a 6to4 address) > 12 rcvd":0 > 1 rcvd":2 > 36 rcvd":3 > > 3 ICMP echo requests were sent, this is the number of probes that report a certain number of replies. > > I'd say that based on these stats, 6to4 probes are not a lot worse than average. 100% packet loss reported by: non 6to4 probes: (388-12)/(2140-36) = 17.8% 6to4 probes: 12/36 = 33.3% So there's a substantial difference. That said, it would be a mistake to treat this as data - the low 6to4 sample size will not generate statistically significant numbers. Nick From nobody Fri Oct 31 08:51:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176951ACD0C for ; Fri, 31 Oct 2014 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfUWYIPSWR2d for ; Fri, 31 Oct 2014 08:51:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 432AB1A9049 for ; Fri, 31 Oct 2014 08:51:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XkET9-0000DGC; Fri, 31 Oct 2014 16:50:31 +0100 Message-Id: To: Nick Hilliard From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453AD17.2030202@foobar.org> In-reply-to: Your message of "Fri, 31 Oct 2014 15:39:03 +0000 ." <5453AD17.2030202@foobar.org> Date: Fri, 31 Oct 2014 16:50:21 +0100 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_23ptoeFHfCyLyioogm5MlRixNM Cc: v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:51:26 -0000 In your letter dated Fri, 31 Oct 2014 15:39:03 +0000 you wrote: >100% packet loss reported by: > >non 6to4 probes: (388-12)/(2140-36) = 17.8% >6to4 probes: 12/36 = 33.3% > >So there's a substantial difference. That said, it would be a mistake to >treat this as data - the low 6to4 sample size will not generate >statistically significant numbers. I'm sort of surprised we are having this discussion. Assuming 6to4 users are just a tiny fraction of all IPv6 users, and that there is way more brokenness than just 6to4, what's the point of actively trying to kill 6to4? Let the relays run on auto-pilot and die of old age. And let applications deal with brokenness in general. Note: lots of RIPE Atlas probes end up with ULA addresses even when there is fine IPv4 connectivity. To me that seems like a way more interesting failure mode than a few broken 6to4 connections. From nobody Fri Oct 31 09:01:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A61ACD29 for ; Fri, 31 Oct 2014 09:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPstBd6LH8AY for ; Fri, 31 Oct 2014 09:00:58 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D1D1ACD03 for ; Fri, 31 Oct 2014 09:00:57 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s9VG0Pdl017065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2014 16:00:45 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <5453B219.3000303@foobar.org> Date: Fri, 31 Oct 2014 16:00:25 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Philip Homburg References: <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453AD17.2030202@foobar.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fxvS5uM7WG26iqVpzwmw9EykMC8 Cc: v6ops@ietf.org, Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:01:01 -0000 On 31/10/2014 15:50, Philip Homburg wrote: > I'm sort of surprised we are having this discussion. Assuming 6to4 users are just a > tiny fraction of all IPv6 users, and that there is way more brokenness than just 6to4, > what's the point of actively trying to kill 6to4? Nobody's trying to kill it. The document is a statement from the IETF that 6to4 is moribund as a protocol and that future developments should steer clear of it. Right now there are two standards track RFCs which explicitly means that 6to4 is recommended for production use by the IETF. The move to historic status changes that status to: "no longer recommended for use". There's more information on what historic status means here: https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html Nick From nobody Fri Oct 31 09:03:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322591ACD32 for ; Fri, 31 Oct 2014 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3VxQ65cvPXk for ; Fri, 31 Oct 2014 09:03:00 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050BA1ACD2C for ; Fri, 31 Oct 2014 09:03:00 -0700 (PDT) Received: from [192.168.10.30] (cm-84.215.22.20.getinternet.no [84.215.22.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 693146280; Fri, 31 Oct 2014 09:01:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ole Troan In-Reply-To: <54539989.9030901@network-heretics.com> Date: Fri, 31 Oct 2014 17:01:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18C57D2A-DE83-465C-9A00-E7B9C595C513@employees.org> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> <54539989.9030901@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Mm_OU7sRf16_kYTRb7IKrnQEyo0 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:03:02 -0000 Keith, >> for my education, any idea what use cases there are / could be for = direct 6to4 connectivity? >=20 > Any application that uses IPv6 and involves some hosts that don't have = native (non-NATted) IPv4 access. I was thinking of this in a post deprecated rfc3068 world. where 6to4 = out of the box was less likely to give access to the IPv6 Internet. = would then an isolated 6to4 overlay have value? >> given that: >> - you shouldn't put 6to4 addresses in DNS >=20 > There's nothing wrong with putting 6to4 addresses in DNS, just like = there's nothing wrong with putting ULIAs in DNS. sure, as long as all hosts/applications throw all the spaghetti on the = wall that works. >> - 6to4 likely breaks if address sharing is in place > What do you mean by "address sharing"? (If you mean the same v4 = address is associated with multiple end sites using carrier-side NAT, I = agree.) or any of the umpteen other ways. MAP-E, MAP-T, 4rd, LW4over6, DS-lite, = NAT444, +++. most of these apart from NAT444, would have native IPv6 = though, and presumably updated gear where 6to4 code isn't there. >> just speculating here; is it because tunnelling bypasses filters / = throttling? if so doesn't e.g. peer applications bypass that by other = means? > No, it's because global v4 addresses are scarce and 6to4 provides a = way around that. 6to4 doesn't really do that. cheers, Ole= From nobody Fri Oct 31 09:19:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3E21A0060 for ; Fri, 31 Oct 2014 09:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ePjKY2rYGUT for ; Fri, 31 Oct 2014 09:19:57 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DD9651ACCFC for ; Fri, 31 Oct 2014 09:19:54 -0700 (PDT) Received: from [10.20.0.185] ([192.31.187.123]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s9VGIC9S021353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Oct 2014 09:18:13 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s9VGIC9S021353 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1414772294; bh=m3xcTWdci/qCFSx+jmT6xTkKvlo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Awvxc/sjnfjLCz6FgA8DOtF9ZKubSQMbsuIP5ysuzU6Jx8zuRU+e5nXoG/1/Nsx3m vTzakX7xs1SEfFJI97gn4Iysh19mhmQxYRxcafO9Uz37asQMt8+ZqI19V4UqytrH++ LyKhe8qS2GhdrIEYYh5QYeg5FFPEPET5XXU71xZg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Owen DeLong In-Reply-To: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> Date: Fri, 31 Oct 2014 09:18:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> To: "Metzler, Dan J" X-Mailer: Apple Mail (2.1990.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 31 Oct 2014 09:18:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qSl4t6yiRBgPkTzWSLTZX6HfL8E Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:19:58 -0000 >=20 > I didn't see anything that implied support for blocking protocol 41 in = this draft. > Adding language in support of 6in4 as an alternative would certainly = not legitimize the blocking of protocol 41. > Am I missing something? >=20 > That said, if you already have native IPv6 available, I can see where = a provider might want to block it. >=20 Observable reality is that AT&T is blocking protocol 41 where IPv6 is = NOT available. Owen From nobody Fri Oct 31 09:55:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020201A008F for ; Fri, 31 Oct 2014 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFw3xUCasVtc for ; Fri, 31 Oct 2014 09:55:36 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946111A0099 for ; Fri, 31 Oct 2014 09:55:36 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hq12so396788vcb.8 for ; Fri, 31 Oct 2014 09:55:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ilw0P77fzrob2c1kW0cv71OMUZZQsxB2qe3tj/oCyRs=; b=C26dSK70JeXDbv8sdWzFAOESVZq7XY71cnYaIATfpeQc6lk/RpgDfo2DZS0Q8cToZ9 hNgidawHbwUigsQRNHyIs6Bm1XPpkm2LgQckpD7W0Ub+3A2ahf0WTjXQNRT9uamk4YKG swFTyp+B8+2pQV7gjRHBn6VkXNr8UsWWsnl/RBzA5+uGSb6oghqtcI9oHASZvm1ynnuq GUevA41qFUYy26nKM3a9qtfEqImR6U0+KD5BtpGPe9mHBytwHIgafhC8giJ9bVOhOJWu TjvyK5B9/DlKuSviCF/LXnOsn3UOJ7KA0lPAu6vtAeYZrv4+qylxRxl8/ec8r6FXE8yE UVGg== X-Gm-Message-State: ALoCoQmc/a4/s807mXQZz8/seKqy+LwhnWzwp3Ay/u6R8n4I8TMBLpyreg2y3J+aA8IIo571DqpF MIME-Version: 1.0 X-Received: by 10.52.75.168 with SMTP id d8mr1116334vdw.19.1414774535560; Fri, 31 Oct 2014 09:55:35 -0700 (PDT) Received: by 10.31.10.65 with HTTP; Fri, 31 Oct 2014 09:55:35 -0700 (PDT) In-Reply-To: <20141031145348.GJ31092@Space.Net> References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> <20141031145348.GJ31092@Space.Net> Date: Fri, 31 Oct 2014 09:55:35 -0700 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=bcaec5016039a136540506badddb Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L7HLZz5NvEziLw79USSEAtEos20 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 16:55:39 -0000 --bcaec5016039a136540506badddb Content-Type: text/plain; charset=UTF-8 On Fri, Oct 31, 2014 at 7:53 AM, Gert Doering wrote: > On Fri, Oct 31, 2014 at 10:45:02AM -0400, Keith Moore wrote: > > Of course I'm aware that relay routers can go away - that's why I have > > no problem (ok, not much problem) with deprecating RFC 3068. [...] > > So would you be fine with the document saying "3065 is good, 3068 should > be deprecated"? > I'm just catching up to this discussion now, and I'd like to reaffirm my support for moving RFC 3068 to historic, but I'd also like to express my desire to hesitate with moving RFC 3065 to historic while IPv4 is still the dominant version. My concern is that moving RFC 3065 to Historic status and marking the 2002::/16 prefix as deprecated and recommending "no new implementations" will send a message to the large enterprises currently maintaining the dominant host operating system dual-stack IPv4/IPv6 implementations that "removing from existing implementations" is also appropriate at this time. I think the case for going beyond removing support for anycast 6to4 relay routers to removing all support for host-to-host 6to4 is not very strong. Elsewhere in this thread, Lorenzo offered one reason to keep from instructing IANA to mark the 2002::/16 prefix as deprecated, and I sympathize with his view. I think it stands in contrast to the assertion that usage of pure RFC 3065, i.e. without RFC 3068, can reasonably be described as practically nil. I could offer other similar reasons. Some people are certainly using RFC 3065 (not RFC 3068) today to solve real problems they are facing while IPv4 is still the dominant IP version in deployed equipment. It's my view that moving only RFC 3068 to Historic should have the practical effect of making the 6to4 addresses into a special kind of unique local address suitable for use in private where IPv4-only routes are still operationally dominant. While IPv4 is still in widespread use, I think having a tunnel mechanism in most host operating systems, which is designed to allow these unique-local global scope addresses to be useful on private networks or between peers in bilateral agreement, is a good idea, and I sort of wish this draft had been written expressly to communicate that view. I believe that telling OS engineers to remove all support for 6to4 now, which is how I think this current draft will be interpreted in practice when published, will have the effect of taking away a useful tool for IPv6 transition from people who are faced with real problems caused by legacy deployments of IPv4-only network equipment that has not yet reached its end of life. I do understand [and sympathize to some extent] with those who would like to burn 6to4 entirely to the ground and salt the earth where it once grew. The damage attributable to RFC 3068 is considerable, and I can well appreciate the urge to post giant warning signs around its perimeter at a distance of several kilometers cautioning even the most skilled adventurers of the grave risks of approaching it under any circumstances. Nevertheless, I do feel like moving RFC 3065 to Historic at this time is premature. Shorter james: I would prefer to move only RFC 3068 to Historic now, and not to move RFC 3065 to Historic until IPv4 is no longer the dominant IP version. -- james woodyatt Nest Labs, Communications Engineering --bcaec5016039a136540506badddb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 31, 2014 at 7:53 AM, Gert Doering <gert@space.net> wrot= e:
On Fri, Oct 31, 2014 at 10:45:02AM = -0400, Keith Moore wrote:
> Of course I'm aware that relay routers can go away - that's wh= y I have
> no problem (ok, not much problem) with deprecating RFC 3068. [...]

So would you be fine with the document saying "3065 is good, 30= 68 should
be deprecated"?

I'm just catching up to this discussion now, and= I'd like to reaffirm my support for moving RFC 3068 to historic, but I= 'd also like to express my desire to hesitate with moving RFC 3065 to h= istoric while IPv4 is still the dominant version.

My concern is that moving = RFC 3065 to Historic status and marking the 2002::/16 prefix as deprecated = and recommending "no new implementations" will send a message to = the large enterprises currently maintaining the dominant host operating sys= tem dual-stack IPv4/IPv6 implementations that "removing from existing = implementations" is also appropriate at this time.=C2=A0 I think the c= ase for going beyond removing support for anycast 6to4 relay routers to rem= oving all support for host-to-host 6to4 is not very strong.

<= /div>
Elsewhere in this thread, Lorenzo off= ered one reason to keep from instructing IANA to mark the 2002::/16 prefix = as deprecated, and I sympathize with his view.=C2=A0 I think it stands in c= ontrast to the assertion that usage of pure RFC 3065, i.e. without RFC 3068= , can reasonably be described as practically nil.=C2=A0 I could offer other= similar reasons. Some people are certainly using RFC 3065 (not RFC 3068) t= oday to solve real problems they are facing while IPv4 is still the dominan= t IP version in deployed equipment.

It's my view that moving only RFC 3068 to= Historic should have the practical effect of making the 6to4 addresses int= o a special kind of unique local address suitable for use in private where = IPv4-only routes are still operationally dominant.=C2=A0 While IPv4 is stil= l in widespread use, I think having a tunnel mechanism in most host operati= ng systems, which is designed to allow these unique-local global scope addr= esses to be useful on private networks or between peers in bilateral agreem= ent, is a good idea, and I sort of wish this draft had been written express= ly to communicate that view.=C2=A0 I believe that telling OS engineers to r= emove all support for 6to4 now, which is how I think this current draft wil= l be interpreted in practice when published, will have the effect of taking= away a useful tool for IPv6 transition from people who are faced with real= problems caused by legacy deployments of IPv4-only network equipment that = has not yet reached its end of life.

I do understand [and sympathize to some exte= nt] with those who would like to burn 6to4 entirely to the ground and salt = the earth where it once grew. The damage attributable to RFC 3068 is consid= erable, and I can well appreciate the urge to post giant warning signs arou= nd its perimeter at a distance of several kilometers cautioning even the mo= st skilled adventurers of the grave risks of approaching it under any circu= mstances. Nevertheless, I do feel like moving RFC 3065 to Historic at this = time is premature.

Shorter james: I would prefer to move only RFC 3068 to Histori= c now, and not to move RFC 3065 to Historic until IPv4 is no longer the dom= inant IP version.

--
j= ames woodyatt <jhw= @nestlabs.com>
Nest Labs, Communications Engineering
--bcaec5016039a136540506badddb-- From nobody Fri Oct 31 10:02:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062FE1A00A9 for ; Fri, 31 Oct 2014 10:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLh8Or7i_acr for ; Fri, 31 Oct 2014 10:02:30 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99A21A00CD for ; Fri, 31 Oct 2014 10:02:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9VH2SK0002914; Fri, 31 Oct 2014 12:02:28 -0500 Received: from XCH-BLV-107.nw.nos.boeing.com (xch-blv-107.nw.nos.boeing.com [130.247.25.123]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9VH2IDl002820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Oct 2014 12:02:19 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-107.nw.nos.boeing.com ([169.254.7.99]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 10:02:13 -0700 From: "Templin, Fred L" To: James Woodyatt , IPv6 Ops WG Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP9SuJWwON9vu93Ui5VNj8/MCQtJxKbZzQ Date: Fri, 31 Oct 2014 17:02:12 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> <20141031145348.GJ31092@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KtZJN4j0Pw_JJR9GBAuzHAjlapk Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:02:32 -0000 PiBidXQgSSdkIGFsc28gbGlrZSB0byBleHByZXNzIG15IGRlc2lyZSB0byBoZXNpdGF0ZSB3aXRo IG1vdmluZyBSRkMgMzA2NSB0byBoaXN0b3JpYw0KDQpSRkMgMzA2NSBpcyBhbHJlYWR5IG9ic29s ZXRlZCBieSBSRkMgNTA2NS4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5n LmNvbQ0K From nobody Fri Oct 31 10:06:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D521A008F for ; Fri, 31 Oct 2014 10:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O09p0LUm_DG6 for ; Fri, 31 Oct 2014 10:06:10 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71781A00E1 for ; Fri, 31 Oct 2014 10:06:10 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id le20so3130061vcb.17 for ; Fri, 31 Oct 2014 10:06:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RuEty9XlpjsQ3gh0rG0hXrLL4/7SRqah0uiVXSKnwQ0=; b=BVEdC3y5gOoH4uZsl6wBlWgNfSl6oDNtBLjfmgvCbdv2tyJR4NbSCiVGVO/l25TNVq l1MJ7wjl5qsUvydejEmkd8ZAtl7iDQmyZV90xdLcLE/GCTK9vC1Bq7fLC3gimCtYHXyf XV8R2RR73DFZUNabGpyvzxHYC/6Kcp8npz1vPDE2hNSm9MJC1liNK95zkmlI33zM+F// 9vGSEkoJGELXA1qqxRSp+YTnoXJpDDy7hNRDXocVy1pSbrPPVde/Q1TdrusBw0gHOubC rtkjwcfyLZXG+smD8Caw58vJCmlqs29ppO0XKoW1tY49fUj3oGkrxIWdl7HFJekP6sLD FyBA== X-Gm-Message-State: ALoCoQnfzIl4tpssmtoIZYziL0yGuqR1NlnajuF/RPWSsYdX8Pid2M2/bURLeGOl6TV4ibv29dlG MIME-Version: 1.0 X-Received: by 10.52.242.73 with SMTP id wo9mr2292639vdc.43.1414775169669; Fri, 31 Oct 2014 10:06:09 -0700 (PDT) Received: by 10.31.10.65 with HTTP; Fri, 31 Oct 2014 10:06:09 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> <20141031145348.GJ31092@Space.Net> <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 31 Oct 2014 10:06:09 -0700 Message-ID: From: James Woodyatt To: IPv6 Ops WG Content-Type: multipart/alternative; boundary=001a1135f8046d39980506bb0397 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/gd3wRdyQMMExHmmg4J4SjFL_hnQ Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:06:14 -0000 --001a1135f8046d39980506bb0397 Content-Type: text/plain; charset=UTF-8 My mistake. I meant RFC 3056. I should have double-checked my memory of the relevant RFC number. On Fri, Oct 31, 2014 at 10:02 AM, Templin, Fred L wrote: > > but I'd also like to express my desire to hesitate with moving RFC 3065 > to historic > > RFC 3065 is already obsoleted by RFC 5065. > > Thanks - Fred > fred.l.templin@boeing.com > -- james woodyatt Nest Labs, Communications Engineering --001a1135f8046d39980506bb0397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My mistake.=C2=A0 I meant RFC 3056.=C2=A0 I should have do= uble-checked my memory of the relevant RFC number.

On Fri, Oct 31, 2014 at 10:02 AM, Te= mplin, Fred L <Fred.L.Templin@boeing.com> wrote:
=
> but I'd also like = to express my desire to hesitate with moving RFC 3065 to historic

RFC 3065 is already obsoleted by RFC 5065.

Thanks - Fred
fred.l.templin@boeing.com<= br>



--
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering
=
--001a1135f8046d39980506bb0397-- From nobody Fri Oct 31 10:15:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C5B1A001C for ; Fri, 31 Oct 2014 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcTzdoaAKpCG for ; Fri, 31 Oct 2014 10:15:19 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959631A00E8 for ; Fri, 31 Oct 2014 10:15:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9VHFIWT022559; Fri, 31 Oct 2014 10:15:19 -0700 Received: from XCH-BLV-305.nw.nos.boeing.com (xch-blv-305.nw.nos.boeing.com [130.247.25.217]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9VHFBNF022344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Oct 2014 10:15:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.24]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 10:15:11 -0700 From: "Templin, Fred L" To: James Woodyatt , IPv6 Ops WG Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt Thread-Index: AQHP9SuJWwON9vu93Ui5VNj8/MCQtJxKbZzQgAB3U4D//4teMA== Date: Fri, 31 Oct 2014 17:15:10 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D7595D@XCH-BLV-504.nw.nos.boeing.com> References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> <20141031145348.GJ31092@Space.Net> <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FFm2wcVMsh3r1X-Z5TT6wDVU7n4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:15:22 -0000 PiBNeSBtaXN0YWtlLiAgSSBtZWFudCBSRkMgMzA1Ni4gIEkgc2hvdWxkIGhhdmUgZG91YmxlLWNo ZWNrZWQgbXkgbWVtb3J5IG9mIHRoZSByZWxldmFudCBSRkMgbnVtYmVyLg0KDQpObyB3b3JyaWVz OyBJIHRoaW5rIEkgc2F3IHNvbWVvbmUgZWxzZSBqdXh0YXBvc2UgdGhlIDUgYW5kIDYgaW4gYW4g ZWFybGllciBtZXNzYWdlIHRvby4NCg0KV2hpbGUgSSBoYXZlIHRoZSBmbG9vciwgSSBrbm93IG9m IGF0IGxlYXN0IG9uZSBlbnRlcnByaXNlIHRoYXQgdXNlcyBwdWJsaWMgSVB2NCBhZGRyZXNzZXMN CmludGVybmFsbHkuIFNvbWUgZGV2aWNlcyBpbnNpZGUgdGhlIGVudGVycHJpc2Ugc2VlIHRoZSBw dWJsaWMgYWRkcmVzc2VzIGFuZCB0aGVuIGFzc3VtZQ0KdGhleSBjYW4gdXNlIDZ0bzQuIFRoZXkg dGhlbiBzZXQgdXAgYSA2dG80IHZpcnR1YWwgaW50ZXJmYWNlIHdpdGggYSAyMDAyOiogYWRkcmVz cyBhc3NpZ25lZCwNCmkuZS4sIGV2ZW4gdGhvdWdoIHRoZSBlbnRlcnByaXNlIGhhcyBub3QgZGVw bG95ZWQgYSA2dG80IHNlcnZpY2UuDQoNCldoYXQgd291bGQgZGVwcmVjYXRpb24gbWVhbiB0byB0 aGlzIGNsYXNzIG9mIGRldmljZXM/DQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJv ZWluZy5jb20NCg== From nobody Fri Oct 31 10:15:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24BD1A006F for ; Fri, 31 Oct 2014 10:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkZzqohmHPFZ for ; Fri, 31 Oct 2014 10:15:32 -0700 (PDT) Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752D91A9074 for ; Fri, 31 Oct 2014 10:15:32 -0700 (PDT) Received: from yomi.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id 266B2100A0380; Fri, 31 Oct 2014 17:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1414775729; bh=hFc3NuzI6rYoGQoQPAt8606ZMgsISlDwHPp+Ybr80/4=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=aN2Jcs62A2opMUIqO272ZAcYQsNslUicXeiUkSKumMLd4nMOHMiNfUxq1ndICZQ0c drrYIbrUKaz0W+EaqEWiLYEjIBI8sCBRhqolepFpbCrVCs8Uikwb09bDVAgQk4wgUE vOfXv3W5OKmsqhoIJ0xBcN7jmTxUKxVpSECL3l54BO+rkxGk158LwQ6Iz4kCDdW3rM Y+27SluYyN9O0udBWg1s12MNMQY6aGHugUpEC1V7momRIoflWG3/kIeXGaFgoe8KiE KhjwNXlQOQIGL8T4IcE66JUOKrTzGWh4UmuLqJMhZiEU0q7zeoLZ/It8Zjn6VkSCW8 RtUj7QsbBQpWA== Message-ID: <5453C3AE.5070502@massar.ch> Date: Fri, 31 Oct 2014 18:15:26 +0100 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: Brian E Carpenter References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <5452C039.6080208@gmail.com> <57BA54BD-563C-4401-A40C-6517AF0C6549@delong.com> <5452D73F.9000504@gmail.com> <0640C5CC-201C-482A-8A6E-D48911B825E0@delong.com> In-Reply-To: <0640C5CC-201C-482A-8A6E-D48911B825E0@delong.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/colbj-SCJgeUiCP-BjQNVvX5No8 Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:15:38 -0000 > You mean support for manually configured tunnels per RFC 4213, or what? > (My FritzBox has great native IPv6 support but no tunnel support that > I can find, and my D-Link box is old.) Fritz!Box definitely has tunnel support. Fritz!Box even has built-in SixXS tunnel support (proto-41 + heartbeat + TIC for configuration. And there is even a node in New Zealand. Greets, Jeroen From nobody Fri Oct 31 11:15:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119871A0101 for ; Fri, 31 Oct 2014 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm1pQAGNmwJk for ; Fri, 31 Oct 2014 11:15:09 -0700 (PDT) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB7C1A03A3 for ; Fri, 31 Oct 2014 11:15:07 -0700 (PDT) Received: from ITSNT440.iowa.uiowa.edu ([169.254.2.50]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 13:15:05 -0500 From: "Metzler, Dan J" To: Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9Pun1rGmcYX0fkWgMLUTtZ60wZxKJsewgABzRwD//6ydEIAAb7GA///B4hA= Date: Fri, 31 Oct 2014 18:15:04 +0000 Message-ID: <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC315F@ITSNT440.iowa.uiowa.edu> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> In-Reply-To: <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qG7Obyk5MlODk8FwUnoNU4Pqjtw Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:15:13 -0000 > -----Original Message----- > From: Owen DeLong [mailto:owen@delong.com] > Sent: Friday, October 31, 2014 11:18 AM > To: Metzler, Dan J > Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt= - > alternatives to 6to4 >=20 > > > > I didn't see anything that implied support for blocking protocol 41 in = this > draft. > > Adding language in support of 6in4 as an alternative would certainly no= t > legitimize the blocking of protocol 41. > > Am I missing something? > > > > That said, if you already have native IPv6 available, I can see where a > provider might want to block it. > > >=20 > Observable reality is that AT&T is blocking protocol 41 where IPv6 is NOT > available. >=20 > Owen I don't have any kind of business relationship with AT&T, but if I were a c= ustomer, I'd be asking them for my native IPv6 access at that point. I don= 't pretend to suggest that there aren't people blocking protocol 41 for no = reason other than fear, and I generally don't think it's good for a provide= r to block protocol 41 until they've provided some alternative. Here's a conversation I had with someone from a somewhat small ISP downstre= am from a larger ISP. Q: "So do you have any plans for deploying IPv6?" A: "Not really. We've got other projects we're working on, and our custome= rs haven't really asked for it." Q: "Well if you wait until your customers are demanding it, considering mos= t of them are unaware of anything called IPv4, let alone IPv6, won't it be = too late?" A: "Well, we've been watching the traffic, and we just haven't seen any dem= and for it." Q: "How would you recognize the demand?" A: "Well, we haven't seen any tunneling, like Teredo or 6to4 traffic." I've never forgotten that exchange because I think it is somewhat represent= ative of the attitude of some ISPs in general, who are not simply running o= ut of IPv4 address space because they obtained it long ago, and one benefit= of tunneling like this, is just to show ISPs that there is demand. For si= tuations like that, an ISP can get rid of these tunnels by beginning an IPv= 6 implementation, which perhaps just starts as 6rd. With regard to the document in question though, since it does not deprecate= protocol 41 or even lobby against its use, I don't see how that particular= issue is relevant. We're just talking about 6to4, which is a layer above = protocol 41. The point is I'm in favor of providing reliable tunnel mechan= isms to get IPv6 connectivity where network providers refuse to provide nat= ive IPv6, but 6to4 as implemented today, is probably not the best option fo= r that. - Dan Metzler From nobody Fri Oct 31 11:35:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645EC1A19F1 for ; Fri, 31 Oct 2014 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rEIs6PyMJkQ for ; Fri, 31 Oct 2014 11:35:26 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97241A19EE for ; Fri, 31 Oct 2014 11:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9930; q=dns/txt; s=iport; t=1414780525; x=1415990125; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oT/3V3tfNPwZs2DLlQwKrHN0ndjDwnUpP10QjJRUpyA=; b=Gv4gBUNQctwJg3lENhgsdzeKpeKh+Cq1XAx2SC6PKG6targRMCtGlG8L R08N14FpjtiWCPT3s+e4axhxzm3e/QPv3hScP+c7cp++gn2eQnQE20Tn8 ojdHE1Jj1CX3VwGNZztUbKvq0qLfcVKAs39SAWBlWpQXA/Ln1+aB+JVDU s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFALPVU1StJA2E/2dsb2JhbABcgw5UWASDAsg3gWcBC4Z3VAKBGRYBAQEBAX2EAwEBAwEBAQEgSwkCBQsCAQgULgICIQYLJQIEDgUJBYgeAwkJDbYhji4NhkABAQEBAQEBAQEBAQEBAQEBAQEBAQEXjlaCKQ0EBwmCbjaBHgWSFYITgVJohQWCEYExPIMOimCGbYI0gURsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="asc'?scan'208,217";a="92214887" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 31 Oct 2014 18:35:25 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9VIZOoG012530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 18:35:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 13:35:24 -0500 From: "Fred Baker (fred)" To: Marc Blanchet Thread-Topic: [v6ops] Fwd: [sunset4] New Version Notification for draft-song-sunset4-ipv6only-dns-00.txt Thread-Index: AQHP9Tlv4sBYm1iupES/4ohIsThXOg== Date: Fri, 31 Oct 2014 18:35:24 +0000 Message-ID: <9DAE1A1A-C9F4-4D2E-B7AB-FB6ABDBF4807@cisco.com> References: <2E38DB4E-0CF2-49B1-B2A7-ED3C97841B85@viagenie.ca> In-Reply-To: <2E38DB4E-0CF2-49B1-B2A7-ED3C97841B85@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_875E87BD-558F-47E5-AB28-417C57CCB18D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/88g9P-1grugQtWCTJOXCTm70dwU Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: [sunset4] New Version Notification for draft-song-sunset4-ipv6only-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:35:28 -0000 --Apple-Mail=_875E87BD-558F-47E5-AB28-417C57CCB18D Content-Type: multipart/alternative; boundary="Apple-Mail=_5F76136C-2895-4DAA-B151-DAC3657CDBCC" --Apple-Mail=_5F76136C-2895-4DAA-B151-DAC3657CDBCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 31, 2014, at 6:55 AM, Marc Blanchet = wrote: > Hello, > this draft has been posted to sunset4, but has some v6 operational = perspective, which is why I=E2=80=99m forwarding to this mailing list.=20= Thanks, Mark. Yes, v6ops chairs would like discussion please. > Marc (co-chair sunset4) >=20 >> D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >>=20 >> Date: 27 octobre 2014 22:00:52 UTC=E2=88=924 >> De: Davey Song >> =C3=80: "sunset4@ietf.org" >> Objet: [sunset4] Fwd: New Version Notification for = draft-song-sunset4-ipv6only-dns-00.txt >>=20 >> Hi folks, I have just post a new draft on IPv6-only DNS development. = Comments are welcome!!=20 >>=20 >> A new version of I-D, draft-song-sunset4-ipv6only-dns-00.txt >> has been successfully submitted by Linjian Song and posted to the >> IETF repository. >>=20 >> Name: draft-song-sunset4-ipv6only-dns >> Revision: 00 >> Title: Considerations on IPv6-only DNS Development >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 8 >> URL: = http://www.ietf.org/internet-drafts/draft-song-sunset4-ipv6only-dns-00.txt= >> Status: = https://datatracker.ietf.org/doc/draft-song-sunset4-ipv6only-dns/ >> Htmlized: = http://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns-00 >>=20 >>=20 >> Abstract: >> Deployment of IPv6-only networks are impacted by assumptions of >> IPv4-only or dual-stack transition scenarios. For example, these >> assumptions are in the operations of DNS. This memo is problem >> statement and hopes to eventually propose a mitigation technique. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_5F76136C-2895-4DAA-B151-DAC3657CDBCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 31, 2014, at 6:55 AM, Marc = Blanchet <marc.blanchet@viagenie.ca>= ; wrote:

Hello,
 this draft has been posted to sunset4, = but has some v6 operational perspective, which is why I=E2=80=99m = forwarding to this mailing = list. 

Thanks, Mark. Yes, v6ops chairs would = like discussion please.

Marc (co-chair sunset4)

D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :

Date: 27 octobre 2014 22:00:52 UTC=E2=88=924
De: Davey Song <songlinjian@gmail.com>
=C3=80: "sunset4@ietf.org" <sunset4@ietf.org>
Objet: [sunset4] Fwd: New Version Notification for = draft-song-sunset4-ipv6only-dns-00.txt

Hi folks, I have = just post a new draft on IPv6-only DNS development. Comments are = welcome!! 

A new version of I-D, = draft-song-sunset4-ipv6only-dns-00.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:          =  draft-song-sunset4-ipv6only-dns
Revision:       00
Title:          Considerations on IPv6-only DNS = Development
Document date:  2014-10-27
Group:          Individual Submission
Pages:          8
URL:            http://www.ietf.org/internet-drafts/draft-song-sunset4-ipv6only= -dns-00.txt
Status:         https://datatracker.ietf.org/doc/draft-song-sunset4-ipv6only-dn= s/
Htmlized:       http://tools.ietf.org/html/draft-song-sunset4-ipv6only-dns-00


Abstract:
   Deployment of IPv6-only networks are impacted by = assumptions of
   IPv4-only or dual-stack transition scenarios.  For = example, these
   assumptions are in the operations of DNS.  This memo = is problem
   statement and hopes to eventually propose a mitigation = technique.




Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
sunset4 = mailing list
sunset4@ietf.org
https://www.ietf.or= g/mailman/listinfo/sunset4

_____________________________________________= __
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_5F76136C-2895-4DAA-B151-DAC3657CDBCC-- --Apple-Mail=_875E87BD-558F-47E5-AB28-417C57CCB18D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUU9ZtbjEdbHIsm0MRApe0AKDAN6o3uRck/YBlx4aJFQeRd5+A+ACgpzGm kyNlmGPV0DrDKgTpNzyMwTQ= =iIwU -----END PGP SIGNATURE----- --Apple-Mail=_875E87BD-558F-47E5-AB28-417C57CCB18D-- From nobody Fri Oct 31 11:56:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D241A0389 for ; Fri, 31 Oct 2014 11:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRh6xw8iZsMw for ; Fri, 31 Oct 2014 11:55:58 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E6A721A0072 for ; Fri, 31 Oct 2014 11:55:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 96336870074; Fri, 31 Oct 2014 19:55:56 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC2Fo-erVzgs; Fri, 31 Oct 2014 19:55:56 +0100 (CET) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 6B631870048; Fri, 31 Oct 2014 19:55:56 +0100 (CET) Message-ID: <5453DB13.3090507@globis.net> Date: Fri, 31 Oct 2014 19:55:15 +0100 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Templin, Fred L" References: <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> <20141031145348.GJ31092@Space.Net> <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D7595D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D7595D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tbLW6yVgkznegv7Vf3l4IBVCba8 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:55:59 -0000 Templin, Fred L wrote: >> My mistake. I meant RFC 3056. I should have double-checked my memory of the relevant RFC number. > No worries; I think I saw someone else juxtapose the 5 and 6 in an earlier message too. > > While I have the floor, I know of at least one enterprise that uses public IPv4 addresses > internally. Some devices inside the enterprise see the public addresses and then assume > they can use 6to4. They then set up a 6to4 virtual interface with a 2002:* address assigned, > i.e., even though the enterprise has not deployed a 6to4 service. > > What would deprecation mean to this class of devices? > > Thanks - Fred > fred.l.templin@boeing.com I suspect very little will change in practice. My own experience is that 6to4 was rarely turned on intentionally, but quite often unintentionally, causing harm. Turning it off unintentionally, or removing the feature completely, is more likely to be beneficial rather than harmful IMHO. I'm not per se against retaining RFC3056 for use between consenting adults where it has been explicitly configured. I certainly didn't like the implementation assumptions of it being enabled automatically (but that has already been fixed in 6343 Section 4.1), and marking 6to4 preferable to pure or NATted IPv4 by default in 3484 (which has also already been fixed in 6724 Section 10.7). Your mileage may vary with currently deployed production code, and writing another IETF doc won't likely change that, whether it marks 6to4 as historic or not. You might have to pay a higher maintenance fee though to retain this premium feature. OTOH 3068 IMHO does need to be labelled harmful and historic. -- Regards, RayH From nobody Fri Oct 31 12:41:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB19E1A00BB for ; Fri, 31 Oct 2014 12:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipdysBVAV21y for ; Fri, 31 Oct 2014 12:40:57 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4329C1A00DB for ; Fri, 31 Oct 2014 12:40:57 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so8341961pab.34 for ; Fri, 31 Oct 2014 12:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0PP1b52gNgD3KjYnmBMytojr92rADWlyzc7+IAaWew4=; b=oMZtcSw0Wxxjkm9gdOmCOc7i96yoNmmfikWZ7nnIZd9z1lxEiwZPEdE5RNM0uhwFDT jf/Q4mBIL8lNPxKBX3fJDglTUHRR2z4ycMmJwQVeddVXoHxG0h+BSW90MTa3lo1CjgFT HbsR76SMFyQLj2pGYkRu/NOOD2ptU8lWtlsJDL1/bwfDNVA/GbRzjz0PHEhLOvMsn51p X5HL8LvizlX9jNreezrO7DIY9JhaUUWKgE/5gN5/IpQchxdM/Ze1Jp7OgOZYmka5s0qP vxMojpcGltfFoe0hq+cV4F8+XpaTwUmpcieH3DUVLWxRsOX3MnPQzDEvaB6PCemSy5p9 iGhQ== X-Received: by 10.70.103.204 with SMTP id fy12mr26591321pdb.110.1414784456983; Fri, 31 Oct 2014 12:40:56 -0700 (PDT) Received: from [192.168.178.23] (247.200.69.111.dynamic.snap.net.nz. [111.69.200.247]) by mx.google.com with ESMTPSA id ib8sm10676333pad.43.2014.10.31.12.40.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 12:40:55 -0700 (PDT) Message-ID: <5453E5CF.9030807@gmail.com> Date: Sat, 01 Nov 2014 08:41:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> In-Reply-To: <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8EjJppNLXJBi4wGWfFsSYO-QmZc Cc: Keith Moore , "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:40:59 -0000 On 01/11/2014 05:18, Owen DeLong wrote: >> I didn't see anything that implied support for blocking protocol 41 in this draft. >> Adding language in support of 6in4 as an alternative would certainly not legitimize the blocking of protocol 41. >> Am I missing something? >> >> That said, if you already have native IPv6 available, I can see where a provider might want to block it. >> > > Observable reality is that AT&T is blocking protocol 41 where IPv6 is NOT available. This illustrates rather neatly why in my opinion it would be a mistake to start listing alternatives to 6to4 in *this* document. We have been designing a ridiculously large number of coexistence techniques since 1994, and look where it's got us. I don't object to adding a statement that there are various tunneling mechanisms that do not have the same problems as 6to4, but attempting to describe and pseudo-recommend them would just start a non-convergent discussion. (Well, it's already started.) Let's just whack one mole at a time. Brian From nobody Fri Oct 31 12:45:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EE91A0118 for ; Fri, 31 Oct 2014 12:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1NrdBa4MkCg for ; Fri, 31 Oct 2014 12:45:24 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E091A00DB for ; Fri, 31 Oct 2014 12:45:23 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fa1so8258360pad.25 for ; Fri, 31 Oct 2014 12:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=obXhFJUnFq0O+xMXFsuj/toAFDVQi/f+nEiIl0NBAak=; b=mevNaq5gCq7mnl8Z2PHQL3XUswy9hsZQxh743AVUXPR314wfbl2iY/wVk2AypRDUYk XJgII6zmIt+Q0OhedVAqTX3WxYEw09t6B93xtNJZ307Tww3bY4Vos5RsQc3umscu/T8A XE8j9rOGFDv57FeqlD+G/zmvMywaVnmQL4uByMjuGu5LwgPRfnFFj4bn60RYo3bvQCrk VMwTnVLWb20pqFLwZ6EGQuglYUPRztQq8Cpro/OZTPdwQDKPQOojjbShgHLxKGoqVA9z +4ynw4345fI7yRVehYsNkAmz66DR1eSF+L4pc+x+enUUV6RCa15jOMzF25AKi3D5oe/p 8xGQ== X-Received: by 10.70.10.195 with SMTP id k3mr26615045pdb.41.1414784723654; Fri, 31 Oct 2014 12:45:23 -0700 (PDT) Received: from [192.168.178.23] (247.200.69.111.dynamic.snap.net.nz. [111.69.200.247]) by mx.google.com with ESMTPSA id f7sm10666229pdj.15.2014.10.31.12.45.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 12:45:22 -0700 (PDT) Message-ID: <5453E6DA.1070101@gmail.com> Date: Sat, 01 Nov 2014 08:45:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <20141021102955.GA31092@Space.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sxaAP95oXQu-cYo290deL53k1cE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:45:26 -0000 On 01/11/2014 02:43, Eric Vyncke (evyncke) wrote: > I also support the suggestion to only impact RFC 3068 and leave some direct 6to4 connectivity 'current'. > > BTW, adding 192.88.99.0/24 to the bogons will not really help in anyway as the client (the entry point in the 6to4 tunnel) will not be able to signal the IPv6 node of lack of IPv6 connectivity in most implementations. As discussed in RFC 6343, indeed. No news here. But if there is no route, diagnostics should be easier. Brian > > From: Lorenzo Colitti > > Date: mardi 21 octobre 2014 15:34 > Would it make sense to move only 3068 to historic, and not 3056? > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Oct 31 13:28:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C961A0117 for ; Fri, 31 Oct 2014 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEbZEW-ncjwV for ; Fri, 31 Oct 2014 13:28:36 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D62D1A004D for ; Fri, 31 Oct 2014 13:28:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9VKSZGP002776; Fri, 31 Oct 2014 13:28:36 -0700 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9VKSSmn002715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Oct 2014 13:28:28 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.158]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 13:28:27 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 Thread-Index: AQHP9UKlQGCpmuF8O0OCEDZA5GJKI5xKpt8g Date: Fri, 31 Oct 2014 20:28:26 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D75CE2@XCH-BLV-504.nw.nos.boeing.com> References: <20141021063829.20337.35646.idtracker@ietfa.amsl.com> <545050FE.8020807@network-heretics.com> <545054DD.9020406@network-heretics.com> <5BEEBBB9-4A85-4238-9015-EC3378F3346F@delong.com> <5452D3F3.50304@gmail.com> <54536C7D.20301@gmail.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2897@ITSNT440.iowa.uiowa.edu> <54539E80.40301@network-heretics.com> <9062DD5BB047BF4C96BCE0CB9DA96D1B4DEC2A50@ITSNT440.iowa.uiowa.edu> <0DCF626A-AF15-40FB-881D-91C368D9065A@delong.com> <5453E5CF.9030807@gmail.com> In-Reply-To: <5453E5CF.9030807@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DtDkuAVU6EysfC5FBuBHWFlaQLw Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 20:28:38 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Friday, October 31, 2014 12:41 PM > To: Owen DeLong > Cc: Keith Moore; v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt= - alternatives to 6to4 >=20 > On 01/11/2014 05:18, Owen DeLong wrote: > >> I didn't see anything that implied support for blocking protocol 41 in= this draft. > >> Adding language in support of 6in4 as an alternative would certainly n= ot legitimize the blocking of protocol 41. > >> Am I missing something? > >> > >> That said, if you already have native IPv6 available, I can see where = a provider might want to block it. > >> > > > > Observable reality is that AT&T is blocking protocol 41 where IPv6 is N= OT available. >=20 > This illustrates rather neatly why in my opinion it would be a mistake > to start listing alternatives to 6to4 in *this* document. We have > been designing a ridiculously large number of coexistence techniques > since 1994, and look where it's got us. I don't object to adding a statem= ent > that there are various tunneling mechanisms that do not have the same > problems as 6to4, but attempting to describe and pseudo-recommend them > would just start a non-convergent discussion. (Well, it's already started= .) Or, we could just say "use AERO" and be done with it. But, AERO is not a coexistence technique - it is long-term evolution (to borrow an apt phrase)= . Thanks - Fred fred.l.templin@boeing.com > Let's just whack one mole at a time. >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Oct 31 14:40:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A115E1A6EF0 for ; Fri, 31 Oct 2014 14:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qQA_6xkqm5A for ; Fri, 31 Oct 2014 14:40:18 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF4A1A6EED for ; Fri, 31 Oct 2014 14:40:18 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D6BB9631A0 for ; Fri, 31 Oct 2014 22:40:16 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9AFEF60B7C for ; Fri, 31 Oct 2014 22:40:16 +0100 (CET) Received: (qmail 59862 invoked by uid 1007); 31 Oct 2014 22:40:16 +0100 Date: Fri, 31 Oct 2014 22:40:16 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20141031214016.GS31092@Space.Net> References: <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> <20141031143018.GI31092@Space.Net> <5453A06E.6030705@network-heretics.com> <20141031145348.GJ31092@Space.Net> <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832D758F5@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5hXdfNRn05cE8Omafeu2VX5pAE0 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:40:20 -0000 Hi, On Fri, Oct 31, 2014 at 05:02:12PM +0000, Templin, Fred L wrote: > > but I'd also like to express my desire to hesitate with moving RFC 3065 to historic > > RFC 3065 is already obsoleted by RFC 5065. James was quite obviously talking about 3056 (and 3068). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Oct 31 15:48:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169931A7021 for ; Fri, 31 Oct 2014 15:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANnT8grFKW6Y for ; Fri, 31 Oct 2014 15:48:08 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAC21A8549 for ; Fri, 31 Oct 2014 15:48:08 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AE4D020315 for ; Fri, 31 Oct 2014 18:48:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 31 Oct 2014 18:48:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:content-type; s=smtpout; bh=nDaCB0W7Zzs NB16m06JkEjsKRQA=; b=bsYX+qCUNTfhXoiLvlET57uoZsh+uhoO+42j1kfH2Lx UXFbYJRAETEgMwA/MHKKFqLNcak+Gk0zZCjDlbcZNsPgCo+NDwiwtTA95eAHlmTq 6ppr7mFXQ4e7MrXDJh3MPRgagRA95mkpi5h2rN+k99zXupYKmbtSE5dcpF8q/CzU = X-Sasl-enc: IkR4qgcgpatOZ7zXK2wiPzJdGC6sS+UDpAeEEM43YiWK 1414795687 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 459FCC00016; Fri, 31 Oct 2014 18:48:07 -0400 (EDT) Message-ID: <5454119C.3090601@network-heretics.com> Date: Fri, 31 Oct 2014 18:47:56 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="------------010106060003020705090308" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XzRUSi9DHGvpxLXkreFrBe9q2ss Subject: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:48:12 -0000 This is a multi-part message in MIME format. --------------010106060003020705090308 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Rather than reply individually to every message, I thought I'd just try to summarize here. 1. I think RFC 3068 should be reclassified as Historic. A document should be published documenting this change, and the reasons for it, and recommending that relay routers be switched off. The primary reason for this reclassification should be that the 3068 mechanism relies on a v4 anycast address to implement a service location mechanism for a service that is controversial, and thus, some carriers don't wish to support it. Related problems are (a) because the RFC 3068 6to4 relay service uses anycast addresses, it's difficult to diagnose and trace problems with it, and (b) because there's no explicit relationship between a RFC 3068 6to4 relay and its users (on either side) there's also no clear support path. It might be worth pointing out that similar problems could occur with any use of anycast addresses. But the other use of anycast that crosses network boundaries of which I'm aware (e.g. root DNS servers) is not controversial - everybody accepts that it's vital that DNS roots be reachable. (It's sad that far fewer considered IPv6 transition an essential service, but I understand that supporting a 6to4 relay router is a greater burden than just forwarding packets to a root server that someone else maintains.) I recommend defining a sunset date, say N months after document publication, to give everyone ample time to adapt but also to avoid having everyone else's relay routers swamped. --- The above applies to RFC 3068 routers accepting traffic at the 6to4 IPv4 anycast address and forwarding packets into the IPv6 network. It might be worth separately addressing the question of IPv6 routers advertising the 2002:/16 prefix and forwarding packets into the IPv4 network. I don't think the two cases are quite symmetrical, and it seems possible that it causes fewer problems for a v6 router to advertise 2002:/16 than for a v4 router to advertise 192.88.99/24. If nothing else, it's easy to traceroute the v6 side and figure out whether the traffic gets to the relay router, but the traceroute from the 6to4 side doesn't tell you much because the whole path over v4 just looks like one hop. Having v6->v4 relay routers still be operational would permit sites using 6to4 to explicitly configure an explicit 6in4 tunnel to a relay router reachable via v4. But the "lack of an explicit relationship" problem would remain. I have also heard rumors of routers advertising 2002:/16 but which only forwarded packets to a subset of IPv4 space. So there's a separate problem here, though I don't know how serious it is. In general it might be a Bad Idea for multiple ASes to ever originate advertisements to the same prefix. 2. The utility of protocol 41 in particular, and network transparency in general, should be affirmed. Perhaps this would be most clearly expressed in a separate document, but I'll be happy for any statement I can get. I've seen and heard of too many cases of carriers blocking protocol 41 even between hosts using static IPv4 addresses. 3. Regarding RFC 3056: I think it should not be deprecated, as I think this sends the wrong message to carriers and network operators that have actively attacked 6to4. However, unless some relay capability between 6to4 sites and native v6 can be salvaged (explicitly configured v4->v6, advertised 2002:/16 on the v6 side), it's certainly fair to say that RFC 3056 has less general applicability. Consumer router vendors certainly shouldn't be touting 6to4 support as "IPv6 support". So some sort of revised applicability statement for RFC 3056 might be in order. If people are really attached to document classification as a way to do this, perhaps reclassifying it as Experimental or Informational would be appropriate. 4. However the above actions are labeled, they make it all the more obvious that the Internet community lacks an obvious, recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism that can be implemented in a host or router (both are needed, but these could be separate mechanisms) and enabled with minimal user effort. This seems like a gaping and embarrassing hole and a serious impediment to the universal use of IPv6, as there will continue to be legacy IPv4-only networks for some time. Attempting to learn from the 6to4 experience, it appears that such a mechanism: (a) should not rely on IPv4 anycast for service discovery, at least not across network boundaries; (b) should have an explicit relationship between a user/customer and any v4-v6 relays; (c) should work through NATs; (d) should allow the user's ISP to provide the service (and allow that service to be automatically discovered), but not force the user to rely on his ISP to do so; and (e) there should be a well-defined mechanism to allow a network operator to filter or defeat the service for hosts on his network, while making it clear to the users of those hosts that that's what's happening. *IMO our efforts should be focused on identifying/developing/refining/recommending such a mechanism, much more than on trying to figure out exactly how to kill 6to4 or any other existing transition mechanism.* Provide a better way for people who are stuck (some or all of the time) on IPv4-only networks to use IPv6, and nobody (including me) will need to care about 6to4. The need for 6to4 hasn't gone away, it's just that the network has become much more hostile to it than when the mechanism was first defined. Keith --------------010106060003020705090308 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Rather than reply individually to every message, I thought I'd just try to summarize here.

1. I think RFC 3068 should be reclassified as Historic.

A document should be published documenting this change, and the reasons for it, and recommending that relay routers be switched off.  

The primary reason for this reclassification should be that the 3068 mechanism relies on a v4 anycast address to implement a service location mechanism for a service that is controversial, and thus, some carriers don't wish to support it.   Related problems are (a) because the RFC 3068 6to4 relay service uses anycast addresses, it's difficult to diagnose and trace problems with it, and (b) because there's no explicit relationship between a RFC 3068 6to4 relay and its users (on either side) there's also no clear support path.

It might be worth pointing out that similar problems could occur with any use of anycast addresses.  But the other use of anycast that crosses network boundaries of which I'm aware (e.g. root DNS servers) is not controversial - everybody accepts that it's vital that DNS roots be reachable.   (It's sad that far fewer considered IPv6 transition an essential service, but I understand that supporting a 6to4 relay router is a greater burden than just forwarding packets to a root server that someone else maintains.)

I recommend defining a sunset date, say N months after document publication, to give everyone ample time to adapt but also to avoid having everyone else's relay routers swamped.

---

The above applies to RFC 3068 routers accepting traffic at the 6to4 IPv4 anycast address and forwarding packets into the IPv6 network.   It might be worth separately addressing the question of IPv6 routers advertising the 2002:/16 prefix and forwarding packets into the IPv4 network.   I don't think the two cases are quite symmetrical, and it seems possible that it causes fewer problems for a v6 router to advertise 2002:/16 than for a v4 router to advertise 192.88.99/24.   If nothing else, it's easy to traceroute the v6 side and figure out whether the traffic gets to the relay router, but the traceroute from the 6to4 side doesn't tell you much because the whole path over v4 just looks like one hop.

Having v6->v4 relay routers still be operational would permit sites using 6to4 to explicitly configure an explicit 6in4 tunnel to a relay router reachable via v4.    But the "lack of an explicit relationship" problem would remain.    I have also heard rumors of routers advertising 2002:/16 but which only forwarded packets to a subset of IPv4 space.   So there's a separate problem here, though I don't know how serious it is.   In general it might be a Bad Idea for multiple ASes to ever originate advertisements to the same prefix.

2.  The utility of protocol 41 in particular, and network transparency in general, should be affirmed.   Perhaps this would be most clearly expressed in a separate document, but I'll be happy for any statement I can get.   I've seen and heard of too many cases of carriers blocking protocol 41 even between hosts using static IPv4 addresses.

3.  Regarding  RFC 3056:   I think it should not be deprecated, as I think this sends the wrong message to carriers and network operators that have actively attacked 6to4.  However, unless some relay capability between 6to4 sites and native v6 can be salvaged (explicitly configured v4->v6, advertised 2002:/16 on the v6 side), it's certainly fair to say that RFC 3056 has less general applicability.    Consumer router vendors certainly shouldn't be touting 6to4 support as "IPv6 support".   

So some sort of revised applicability statement for RFC 3056 might be in order.    If people are really attached to document classification as a way to do this, perhaps reclassifying it as Experimental or Informational would be appropriate.

4.  However the above actions are labeled, they make it all the more obvious that the Internet community lacks an obvious, recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism that can be implemented in a host or router (both are needed, but these could be separate mechanisms) and enabled with minimal user effort.   This seems like a gaping and embarrassing hole and a serious impediment to the universal use of IPv6, as there will continue to be legacy IPv4-only networks for some time.  

Attempting to learn from the 6to4 experience, it appears that such a mechanism: (a) should not rely on IPv4 anycast for service discovery, at least not across network boundaries; (b) should have an explicit relationship between a user/customer and any v4-v6 relays; (c) should work through NATs; (d) should allow the user's ISP to provide the service (and allow that service to be automatically discovered), but not force the user to rely on his ISP to do so; and (e) there should be a well-defined mechanism to allow a network operator to filter or defeat the service for hosts on his network, while making it clear to the users of those hosts that that's what's happening.

IMO our efforts should be focused on identifying/developing/refining/recommending such a mechanism, much more than on trying to figure out exactly how to kill 6to4 or any other existing transition mechanism.   Provide a better way for people who are stuck (some or all of the time) on IPv4-only networks to use IPv6, and nobody (including me) will need to care about 6to4.   The need for 6to4 hasn't gone away, it's just that the network has become much more hostile to it than when the mechanism was first defined.

Keith

--------------010106060003020705090308-- From nobody Fri Oct 31 16:08:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984F21A1A20 for ; Fri, 31 Oct 2014 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0skDXJrYVshH for ; Fri, 31 Oct 2014 16:07:53 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA771A86F7 for ; Fri, 31 Oct 2014 16:07:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9VN7iEs023317; Fri, 31 Oct 2014 16:07:44 -0700 Received: from XCH-BLV-208.nw.nos.boeing.com (xch-blv-208.nw.nos.boeing.com [10.57.37.5]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9VN7YZJ023246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Oct 2014 16:07:34 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.185]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 16:07:33 -0700 From: "Templin, Fred L" To: Keith Moore , "v6ops@ietf.org WG" Thread-Topic: [v6ops] my recommendation re: 6to4 Thread-Index: AQHP9VzQ4wRvtBZjb0mzKuHwNHu235xK0P5w Date: Fri, 31 Oct 2014 23:07:32 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> In-Reply-To: <5454119C.3090601@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832D75F09XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qe91Nlho_syJZDpdtvif_rQENds Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:07:58 -0000 --_000_2134F8430051B64F815C691A62D9831832D75F09XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VpdGgsDQoNCkp1c3QgYSBjb3VwbGUgb2YgcXVpY2sgY29tbWVudHM6DQoNCjQuICBIb3dl dmVyIHRoZSBhYm92ZSBhY3Rpb25zIGFyZSBsYWJlbGVkLCB0aGV5IG1ha2UgaXQgYWxsIHRoZSBt b3JlIG9idmlvdXMgdGhhdCB0aGUgSW50ZXJuZXQgY29tbXVuaXR5IGxhY2tzIGFuIG9idmlvdXMs IHJlY29tbWVuZGVkLCBhbmQgZ2VuZXJhbGx5LWFwcGxpY2FibGUgSVB2Ni1vdmVyLUlQdjQgdHVu bmVsaW5nIG1lY2hhbmlzbSB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBhIGhvc3Qgb3Igcm91 dGVyIChib3RoIGFyZSBuZWVkZWQsIGJ1dCB0aGVzZSBjb3VsZCBiZSBzZXBhcmF0ZSBtZWNoYW5p c21zKSBhbmQgZW5hYmxlZCB3aXRoIG1pbmltYWwgdXNlciBlZmZvcnQuICAgVGhpcyBzZWVtcyBs aWtlIGEgZ2FwaW5nIGFuZCBlbWJhcnJhc3NpbmcgaG9sZSBhbmQgYSBzZXJpb3VzIGltcGVkaW1l bnQgdG8gdGhlIHVuaXZlcnNhbCB1c2Ugb2YgSVB2NiwgYXMgdGhlcmUgd2lsbCBjb250aW51ZSB0 byBiZSBsZWdhY3kgSVB2NC1vbmx5IG5ldHdvcmtzIGZvciBzb21lIHRpbWUuDQoNCk1heWJlLCBi dXQgaXQgZG9lcyAgbm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYmUgaXAtcHJvdG8tNDEgYmFzZWQu IEZvciBleGFtcGxlLCB0dW5uZWxzDQpvdmVyIFVEUCBhcmUgcHJvYmFibHkgbW9yZSBsaWtlbHkg dG8gdHJhdmVyc2UgbWlkZGxlYm94ZXMgKGluY2x1ZGluZyBOQVRzLCBvZiBjb3Vyc2UpLg0KQW5k LCBpdCBuZWVkIG5vdCBiZSBzcGVjaWZpYyB0byBJUHY2LW92ZXItSVB2NCDigJMgaXQgd291bGQg YmUgbXVjaCBiZXR0ZXIgdG8gaGF2ZSBhIHNpbmdsZQ0KbWVjaGFuaXNtIHRoYXQgY2FuIHN1cHBv cnQgdHVubmVsaW5nIG9mIElQdlgtb3Zlci1JUHZZIGZvciBhbnkgdmFsdWVzIG9mIFggYW5kIFku DQoNCklNTyBvdXIgZWZmb3J0cyBzaG91bGQgYmUgZm9jdXNlZCBvbiBpZGVudGlmeWluZy9kZXZl bG9waW5nL3JlZmluaW5nL3JlY29tbWVuZGluZyBzdWNoIGEgbWVjaGFuaXNtLCBtdWNoIG1vcmUg dGhhbiBvbiB0cnlpbmcgdG8gZmlndXJlIG91dCBleGFjdGx5IGhvdyB0byBraWxsIDZ0bzQgb3Ig YW55IG90aGVyIGV4aXN0aW5nIHRyYW5zaXRpb24gbWVjaGFuaXNtLg0KDQpJIHRha2UgaXQgZnJv bSB0aGUgZW1waGFzaXMgdGhhdCB5b3UgdHJ1bHkgYmVsaWV2ZSB0aGVyZSBpcyBhIGdhcCB0aGF0 IG5lZWRzIHRvIGJlIGZpbGxlZC4NCkhhdmUgYSBsb29rIGF0IEFFUk8gYXMgYW4gZW1lcmdpbmcg c2VydmljZSB0aGF0IGNvdWxkIHNhdGlzZnkgdGhlIG5lZWQuDQoNClRoYW5rcyDigJMgRnJlZA0K ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZWl0aCBNb29yZQ0KU2VudDogRnJpZGF5LCBP Y3RvYmVyIDMxLCAyMDE0IDM6NDggUE0NClRvOiB2Nm9wc0BpZXRmLm9yZyBXRw0KU3ViamVjdDog W3Y2b3BzXSBteSByZWNvbW1lbmRhdGlvbiByZTogNnRvNA0KDQpSYXRoZXIgdGhhbiByZXBseSBp bmRpdmlkdWFsbHkgdG8gZXZlcnkgbWVzc2FnZSwgSSB0aG91Z2h0IEknZCBqdXN0IHRyeSB0byBz dW1tYXJpemUgaGVyZS4NCg0KMS4gSSB0aGluayBSRkMgMzA2OCBzaG91bGQgYmUgcmVjbGFzc2lm aWVkIGFzIEhpc3RvcmljLg0KDQpBIGRvY3VtZW50IHNob3VsZCBiZSBwdWJsaXNoZWQgZG9jdW1l bnRpbmcgdGhpcyBjaGFuZ2UsIGFuZCB0aGUgcmVhc29ucyBmb3IgaXQsIGFuZCByZWNvbW1lbmRp bmcgdGhhdCByZWxheSByb3V0ZXJzIGJlIHN3aXRjaGVkIG9mZi4NCg0KVGhlIHByaW1hcnkgcmVh c29uIGZvciB0aGlzIHJlY2xhc3NpZmljYXRpb24gc2hvdWxkIGJlIHRoYXQgdGhlIDMwNjggbWVj aGFuaXNtIHJlbGllcyBvbiBhIHY0IGFueWNhc3QgYWRkcmVzcyB0byBpbXBsZW1lbnQgYSBzZXJ2 aWNlIGxvY2F0aW9uIG1lY2hhbmlzbSBmb3IgYSBzZXJ2aWNlIHRoYXQgaXMgY29udHJvdmVyc2lh bCwgYW5kIHRodXMsIHNvbWUgY2FycmllcnMgZG9uJ3Qgd2lzaCB0byBzdXBwb3J0IGl0LiAgIFJl bGF0ZWQgcHJvYmxlbXMgYXJlIChhKSBiZWNhdXNlIHRoZSBSRkMgMzA2OCA2dG80IHJlbGF5IHNl cnZpY2UgdXNlcyBhbnljYXN0IGFkZHJlc3NlcywgaXQncyBkaWZmaWN1bHQgdG8gZGlhZ25vc2Ug YW5kIHRyYWNlIHByb2JsZW1zIHdpdGggaXQsIGFuZCAoYikgYmVjYXVzZSB0aGVyZSdzIG5vIGV4 cGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgUkZDIDMwNjggNnRvNCByZWxheSBhbmQgaXRz IHVzZXJzIChvbiBlaXRoZXIgc2lkZSkgdGhlcmUncyBhbHNvIG5vIGNsZWFyIHN1cHBvcnQgcGF0 aC4NCg0KSXQgbWlnaHQgYmUgd29ydGggcG9pbnRpbmcgb3V0IHRoYXQgc2ltaWxhciBwcm9ibGVt cyBjb3VsZCBvY2N1ciB3aXRoIGFueSB1c2Ugb2YgYW55Y2FzdCBhZGRyZXNzZXMuICBCdXQgdGhl IG90aGVyIHVzZSBvZiBhbnljYXN0IHRoYXQgY3Jvc3NlcyBuZXR3b3JrIGJvdW5kYXJpZXMgb2Yg d2hpY2ggSSdtIGF3YXJlIChlLmcuIHJvb3QgRE5TIHNlcnZlcnMpIGlzIG5vdCBjb250cm92ZXJz aWFsIC0gZXZlcnlib2R5IGFjY2VwdHMgdGhhdCBpdCdzIHZpdGFsIHRoYXQgRE5TIHJvb3RzIGJl IHJlYWNoYWJsZS4gICAoSXQncyBzYWQgdGhhdCBmYXIgZmV3ZXIgY29uc2lkZXJlZCBJUHY2IHRy YW5zaXRpb24gYW4gZXNzZW50aWFsIHNlcnZpY2UsIGJ1dCBJIHVuZGVyc3RhbmQgdGhhdCBzdXBw b3J0aW5nIGEgNnRvNCByZWxheSByb3V0ZXIgaXMgYSBncmVhdGVyIGJ1cmRlbiB0aGFuIGp1c3Qg Zm9yd2FyZGluZyBwYWNrZXRzIHRvIGEgcm9vdCBzZXJ2ZXIgdGhhdCBzb21lb25lIGVsc2UgbWFp bnRhaW5zLikNCg0KSSByZWNvbW1lbmQgZGVmaW5pbmcgYSBzdW5zZXQgZGF0ZSwgc2F5IE4gbW9u dGhzIGFmdGVyIGRvY3VtZW50IHB1YmxpY2F0aW9uLCB0byBnaXZlIGV2ZXJ5b25lIGFtcGxlIHRp bWUgdG8gYWRhcHQgYnV0IGFsc28gdG8gYXZvaWQgaGF2aW5nIGV2ZXJ5b25lIGVsc2UncyByZWxh eSByb3V0ZXJzIHN3YW1wZWQuDQoNCi0tLQ0KDQpUaGUgYWJvdmUgYXBwbGllcyB0byBSRkMgMzA2 OCByb3V0ZXJzIGFjY2VwdGluZyB0cmFmZmljIGF0IHRoZSA2dG80IElQdjQgYW55Y2FzdCBhZGRy ZXNzIGFuZCBmb3J3YXJkaW5nIHBhY2tldHMgaW50byB0aGUgSVB2NiBuZXR3b3JrLiAgIEl0IG1p Z2h0IGJlIHdvcnRoIHNlcGFyYXRlbHkgYWRkcmVzc2luZyB0aGUgcXVlc3Rpb24gb2YgSVB2NiBy b3V0ZXJzIGFkdmVydGlzaW5nIHRoZSAyMDAyOi8xNiBwcmVmaXggYW5kIGZvcndhcmRpbmcgcGFj a2V0cyBpbnRvIHRoZSBJUHY0IG5ldHdvcmsuICAgSSBkb24ndCB0aGluayB0aGUgdHdvIGNhc2Vz IGFyZSBxdWl0ZSBzeW1tZXRyaWNhbCwgYW5kIGl0IHNlZW1zIHBvc3NpYmxlIHRoYXQgaXQgY2F1 c2VzIGZld2VyIHByb2JsZW1zIGZvciBhIHY2IHJvdXRlciB0byBhZHZlcnRpc2UgMjAwMjovMTYg dGhhbiBmb3IgYSB2NCByb3V0ZXIgdG8gYWR2ZXJ0aXNlIDE5Mi44OC45OS8yNC4gICBJZiBub3Ro aW5nIGVsc2UsIGl0J3MgZWFzeSB0byB0cmFjZXJvdXRlIHRoZSB2NiBzaWRlIGFuZCBmaWd1cmUg b3V0IHdoZXRoZXIgdGhlIHRyYWZmaWMgZ2V0cyB0byB0aGUgcmVsYXkgcm91dGVyLCBidXQgdGhl IHRyYWNlcm91dGUgZnJvbSB0aGUgNnRvNCBzaWRlIGRvZXNuJ3QgdGVsbCB5b3UgbXVjaCBiZWNh dXNlIHRoZSB3aG9sZSBwYXRoIG92ZXIgdjQganVzdCBsb29rcyBsaWtlIG9uZSBob3AuDQoNCkhh dmluZyB2Ni0+djQgcmVsYXkgcm91dGVycyBzdGlsbCBiZSBvcGVyYXRpb25hbCB3b3VsZCBwZXJt aXQgc2l0ZXMgdXNpbmcgNnRvNCB0byBleHBsaWNpdGx5IGNvbmZpZ3VyZSBhbiBleHBsaWNpdCA2 aW40IHR1bm5lbCB0byBhIHJlbGF5IHJvdXRlciByZWFjaGFibGUgdmlhIHY0LiAgICBCdXQgdGhl ICJsYWNrIG9mIGFuIGV4cGxpY2l0IHJlbGF0aW9uc2hpcCIgcHJvYmxlbSB3b3VsZCByZW1haW4u ICAgIEkgaGF2ZSBhbHNvIGhlYXJkIHJ1bW9ycyBvZiByb3V0ZXJzIGFkdmVydGlzaW5nIDIwMDI6 LzE2IGJ1dCB3aGljaCBvbmx5IGZvcndhcmRlZCBwYWNrZXRzIHRvIGEgc3Vic2V0IG9mIElQdjQg c3BhY2UuICAgU28gdGhlcmUncyBhIHNlcGFyYXRlIHByb2JsZW0gaGVyZSwgdGhvdWdoIEkgZG9u J3Qga25vdyBob3cgc2VyaW91cyBpdCBpcy4gICBJbiBnZW5lcmFsIGl0IG1pZ2h0IGJlIGEgQmFk IElkZWEgZm9yIG11bHRpcGxlIEFTZXMgdG8gZXZlciBvcmlnaW5hdGUgYWR2ZXJ0aXNlbWVudHMg dG8gdGhlIHNhbWUgcHJlZml4Lg0KDQoyLiAgVGhlIHV0aWxpdHkgb2YgcHJvdG9jb2wgNDEgaW4g cGFydGljdWxhciwgYW5kIG5ldHdvcmsgdHJhbnNwYXJlbmN5IGluIGdlbmVyYWwsIHNob3VsZCBi ZSBhZmZpcm1lZC4gICBQZXJoYXBzIHRoaXMgd291bGQgYmUgbW9zdCBjbGVhcmx5IGV4cHJlc3Nl ZCBpbiBhIHNlcGFyYXRlIGRvY3VtZW50LCBidXQgSSdsbCBiZSBoYXBweSBmb3IgYW55IHN0YXRl bWVudCBJIGNhbiBnZXQuICAgSSd2ZSBzZWVuIGFuZCBoZWFyZCBvZiB0b28gbWFueSBjYXNlcyBv ZiBjYXJyaWVycyBibG9ja2luZyBwcm90b2NvbCA0MSBldmVuIGJldHdlZW4gaG9zdHMgdXNpbmcg c3RhdGljIElQdjQgYWRkcmVzc2VzLg0KDQozLiAgUmVnYXJkaW5nICBSRkMgMzA1NjogICBJIHRo aW5rIGl0IHNob3VsZCBub3QgYmUgZGVwcmVjYXRlZCwgYXMgSSB0aGluayB0aGlzIHNlbmRzIHRo ZSB3cm9uZyBtZXNzYWdlIHRvIGNhcnJpZXJzIGFuZCBuZXR3b3JrIG9wZXJhdG9ycyB0aGF0IGhh dmUgYWN0aXZlbHkgYXR0YWNrZWQgNnRvNC4gIEhvd2V2ZXIsIHVubGVzcyBzb21lIHJlbGF5IGNh cGFiaWxpdHkgYmV0d2VlbiA2dG80IHNpdGVzIGFuZCBuYXRpdmUgdjYgY2FuIGJlIHNhbHZhZ2Vk IChleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdjQtPnY2LCBhZHZlcnRpc2VkIDIwMDI6LzE2IG9uIHRo ZSB2NiBzaWRlKSwgaXQncyBjZXJ0YWlubHkgZmFpciB0byBzYXkgdGhhdCBSRkMgMzA1NiBoYXMg bGVzcyBnZW5lcmFsIGFwcGxpY2FiaWxpdHkuICAgIENvbnN1bWVyIHJvdXRlciB2ZW5kb3JzIGNl cnRhaW5seSBzaG91bGRuJ3QgYmUgdG91dGluZyA2dG80IHN1cHBvcnQgYXMgIklQdjYgc3VwcG9y dCIuDQoNClNvIHNvbWUgc29ydCBvZiByZXZpc2VkIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZv ciBSRkMgMzA1NiBtaWdodCBiZSBpbiBvcmRlci4gICAgSWYgcGVvcGxlIGFyZSByZWFsbHkgYXR0 YWNoZWQgdG8gZG9jdW1lbnQgY2xhc3NpZmljYXRpb24gYXMgYSB3YXkgdG8gZG8gdGhpcywgcGVy aGFwcyByZWNsYXNzaWZ5aW5nIGl0IGFzIEV4cGVyaW1lbnRhbCBvciBJbmZvcm1hdGlvbmFsIHdv dWxkIGJlIGFwcHJvcHJpYXRlLg0KDQo0LiAgSG93ZXZlciB0aGUgYWJvdmUgYWN0aW9ucyBhcmUg bGFiZWxlZCwgdGhleSBtYWtlIGl0IGFsbCB0aGUgbW9yZSBvYnZpb3VzIHRoYXQgdGhlIEludGVy bmV0IGNvbW11bml0eSBsYWNrcyBhbiBvYnZpb3VzLCByZWNvbW1lbmRlZCwgYW5kIGdlbmVyYWxs eS1hcHBsaWNhYmxlIElQdjYtb3Zlci1JUHY0IHR1bm5lbGluZyBtZWNoYW5pc20gdGhhdCBjYW4g YmUgaW1wbGVtZW50ZWQgaW4gYSBob3N0IG9yIHJvdXRlciAoYm90aCBhcmUgbmVlZGVkLCBidXQg dGhlc2UgY291bGQgYmUgc2VwYXJhdGUgbWVjaGFuaXNtcykgYW5kIGVuYWJsZWQgd2l0aCBtaW5p bWFsIHVzZXIgZWZmb3J0LiAgIFRoaXMgc2VlbXMgbGlrZSBhIGdhcGluZyBhbmQgZW1iYXJyYXNz aW5nIGhvbGUgYW5kIGEgc2VyaW91cyBpbXBlZGltZW50IHRvIHRoZSB1bml2ZXJzYWwgdXNlIG9m IElQdjYsIGFzIHRoZXJlIHdpbGwgY29udGludWUgdG8gYmUgbGVnYWN5IElQdjQtb25seSBuZXR3 b3JrcyBmb3Igc29tZSB0aW1lLg0KDQpBdHRlbXB0aW5nIHRvIGxlYXJuIGZyb20gdGhlIDZ0bzQg ZXhwZXJpZW5jZSwgaXQgYXBwZWFycyB0aGF0IHN1Y2ggYSBtZWNoYW5pc206IChhKSBzaG91bGQg bm90IHJlbHkgb24gSVB2NCBhbnljYXN0IGZvciBzZXJ2aWNlIGRpc2NvdmVyeSwgYXQgbGVhc3Qg bm90IGFjcm9zcyBuZXR3b3JrIGJvdW5kYXJpZXM7IChiKSBzaG91bGQgaGF2ZSBhbiBleHBsaWNp dCByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHVzZXIvY3VzdG9tZXIgYW5kIGFueSB2NC12NiByZWxh eXM7IChjKSBzaG91bGQgd29yayB0aHJvdWdoIE5BVHM7IChkKSBzaG91bGQgYWxsb3cgdGhlIHVz ZXIncyBJU1AgdG8gcHJvdmlkZSB0aGUgc2VydmljZSAoYW5kIGFsbG93IHRoYXQgc2VydmljZSB0 byBiZSBhdXRvbWF0aWNhbGx5IGRpc2NvdmVyZWQpLCBidXQgbm90IGZvcmNlIHRoZSB1c2VyIHRv IHJlbHkgb24gaGlzIElTUCB0byBkbyBzbzsgYW5kIChlKSB0aGVyZSBzaG91bGQgYmUgYSB3ZWxs LWRlZmluZWQgbWVjaGFuaXNtIHRvIGFsbG93IGEgbmV0d29yayBvcGVyYXRvciB0byBmaWx0ZXIg b3IgZGVmZWF0IHRoZSBzZXJ2aWNlIGZvciBob3N0cyBvbiBoaXMgbmV0d29yaywgd2hpbGUgbWFr aW5nIGl0IGNsZWFyIHRvIHRoZSB1c2VycyBvZiB0aG9zZSBob3N0cyB0aGF0IHRoYXQncyB3aGF0 J3MgaGFwcGVuaW5nLg0KDQpJTU8gb3VyIGVmZm9ydHMgc2hvdWxkIGJlIGZvY3VzZWQgb24gaWRl bnRpZnlpbmcvZGV2ZWxvcGluZy9yZWZpbmluZy9yZWNvbW1lbmRpbmcgc3VjaCBhIG1lY2hhbmlz bSwgbXVjaCBtb3JlIHRoYW4gb24gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgZXhhY3RseSBob3cgdG8g a2lsbCA2dG80IG9yIGFueSBvdGhlciBleGlzdGluZyB0cmFuc2l0aW9uIG1lY2hhbmlzbS4gICBQ cm92aWRlIGEgYmV0dGVyIHdheSBmb3IgcGVvcGxlIHdobyBhcmUgc3R1Y2sgKHNvbWUgb3IgYWxs IG9mIHRoZSB0aW1lKSBvbiBJUHY0LW9ubHkgbmV0d29ya3MgdG8gdXNlIElQdjYsIGFuZCBub2Jv ZHkgKGluY2x1ZGluZyBtZSkgd2lsbCBuZWVkIHRvIGNhcmUgYWJvdXQgNnRvNC4gICBUaGUgbmVl ZCBmb3IgNnRvNCBoYXNuJ3QgZ29uZSBhd2F5LCBpdCdzIGp1c3QgdGhhdCB0aGUgbmV0d29yayBo YXMgYmVjb21lIG11Y2ggbW9yZSBob3N0aWxlIHRvIGl0IHRoYW4gd2hlbiB0aGUgbWVjaGFuaXNt IHdhcyBmaXJzdCBkZWZpbmVkLg0KDQpLZWl0aA0K --_000_2134F8430051B64F815C691A62D9831832D75F09XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIEtlaXRoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCBhIGNvdXBsZSBvZiBxdWljayBj b21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4mbmJzcDsgSG93ZXZlciB0aGUgYWJv dmUgYWN0aW9ucyBhcmUgbGFiZWxlZCwgdGhleSBtYWtlIGl0IGFsbCB0aGUgbW9yZSBvYnZpb3Vz IHRoYXQgdGhlIEludGVybmV0IGNvbW11bml0eSBsYWNrcyBhbiBvYnZpb3VzLCByZWNvbW1lbmRl ZCwgYW5kIGdlbmVyYWxseS1hcHBsaWNhYmxlIElQdjYtb3Zlci1JUHY0IHR1bm5lbGluZyBtZWNo YW5pc20gdGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBob3N0IG9yIHJvdXRlcg0KIChib3Ro IGFyZSBuZWVkZWQsIGJ1dCB0aGVzZSBjb3VsZCBiZSBzZXBhcmF0ZSBtZWNoYW5pc21zKSBhbmQg ZW5hYmxlZCB3aXRoIG1pbmltYWwgdXNlciBlZmZvcnQuJm5ic3A7Jm5ic3A7IFRoaXMgc2VlbXMg bGlrZSBhIGdhcGluZyBhbmQgZW1iYXJyYXNzaW5nIGhvbGUgYW5kIGEgc2VyaW91cyBpbXBlZGlt ZW50IHRvIHRoZSB1bml2ZXJzYWwgdXNlIG9mIElQdjYsIGFzIHRoZXJlIHdpbGwgY29udGludWUg dG8gYmUgbGVnYWN5IElQdjQtb25seSBuZXR3b3JrcyBmb3INCiBzb21lIHRpbWUuJm5ic3A7Jm5i c3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TWF5YmUsIGJ1dCBpdCBkb2VzJm5ic3A7IG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGJlIGlwLXBy b3RvLTQxIGJhc2VkLiBGb3IgZXhhbXBsZSwgdHVubmVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5vdmVyIFVEUCBhcmUgcHJvYmFibHkgbW9yZSBsaWtlbHkgdG8gdHJhdmVyc2UgbWlk ZGxlYm94ZXMgKGluY2x1ZGluZyBOQVRzLCBvZiBjb3Vyc2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5BbmQsIGl0IG5lZWQgbm90IGJlIHNwZWNpZmljIHRvIElQdjYtb3Zlci1JUHY0 IOKAkyBpdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBoYXZlIGEgc2luZ2xlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPm1lY2hhbmlzbSB0aGF0IGNhbiBzdXBwb3J0IHR1bm5lbGluZyBv ZiBJUHZYLW92ZXItSVB2WSBmb3IgYW55IHZhbHVlcyBvZiBYIGFuZCBZLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5JTU8gb3VyIGVmZm9ydHMgc2hvdWxkIGJlIGZvY3VzZWQgb24gaWRlbnRp ZnlpbmcvZGV2ZWxvcGluZy9yZWZpbmluZy9yZWNvbW1lbmRpbmcgc3VjaCBhIG1lY2hhbmlzbSwg bXVjaCBtb3JlIHRoYW4gb24gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgZXhhY3RseSBob3cgdG8ga2ls bCA2dG80IG9yIGFueSBvdGhlciBleGlzdGluZyB0cmFuc2l0aW9uIG1lY2hhbmlzbS48L2I+Jm5i c3A7Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0YWtlIGl0IGZyb20gdGhlIGVtcGhhc2lzIHRoYXQgeW91IHRydWx5IGJlbGlldmUg dGhlcmUgaXMgYSBnYXAgdGhhdCBuZWVkcyB0byBiZSBmaWxsZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhhdmUgYSBsb29rIGF0IEFFUk8gYXMgYW4gZW1lcmdpbmcgc2VydmljZSB0 aGF0IGNvdWxkIHNhdGlzZnkgdGhlIG5lZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlaXRoIE1vb3JlPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgT2N0b2JlciAzMSwgMjAxNCAzOjQ4IFBNPGJyPg0KPGI+VG86PC9iPiB2Nm9wc0BpZXRmLm9y ZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdjZvcHNdIG15IHJlY29tbWVuZGF0aW9uIHJlOiA2 dG80PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5SYXRoZXIgdGhhbiByZXBseSBpbmRpdmlkdWFsbHkgdG8g ZXZlcnkgbWVzc2FnZSwgSSB0aG91Z2h0IEknZCBqdXN0IHRyeSB0byBzdW1tYXJpemUgaGVyZS48 YnI+DQo8YnI+DQoxLiBJIHRoaW5rIFJGQyAzMDY4IHNob3VsZCBiZSByZWNsYXNzaWZpZWQgYXMg SGlzdG9yaWMuPGJyPg0KPGJyPg0KQSBkb2N1bWVudCBzaG91bGQgYmUgcHVibGlzaGVkIGRvY3Vt ZW50aW5nIHRoaXMgY2hhbmdlLCBhbmQgdGhlIHJlYXNvbnMgZm9yIGl0LCBhbmQgcmVjb21tZW5k aW5nIHRoYXQgcmVsYXkgcm91dGVycyBiZSBzd2l0Y2hlZCBvZmYuJm5ic3A7Jm5ic3A7DQo8YnI+ DQo8YnI+DQpUaGUgcHJpbWFyeSByZWFzb24gZm9yIHRoaXMgcmVjbGFzc2lmaWNhdGlvbiBzaG91 bGQgYmUgdGhhdCB0aGUgMzA2OCBtZWNoYW5pc20gcmVsaWVzIG9uIGEgdjQgYW55Y2FzdCBhZGRy ZXNzIHRvIGltcGxlbWVudCBhIHNlcnZpY2UgbG9jYXRpb24gbWVjaGFuaXNtIGZvciBhIHNlcnZp Y2UgdGhhdCBpcyBjb250cm92ZXJzaWFsLCBhbmQgdGh1cywgc29tZSBjYXJyaWVycyBkb24ndCB3 aXNoIHRvIHN1cHBvcnQgaXQuJm5ic3A7Jm5ic3A7IFJlbGF0ZWQgcHJvYmxlbXMNCiBhcmUgKGEp IGJlY2F1c2UgdGhlIFJGQyAzMDY4IDZ0bzQgcmVsYXkgc2VydmljZSB1c2VzIGFueWNhc3QgYWRk cmVzc2VzLCBpdCdzIGRpZmZpY3VsdCB0byBkaWFnbm9zZSBhbmQgdHJhY2UgcHJvYmxlbXMgd2l0 aCBpdCwgYW5kIChiKSBiZWNhdXNlIHRoZXJlJ3Mgbm8gZXhwbGljaXQgcmVsYXRpb25zaGlwIGJl dHdlZW4gYSBSRkMgMzA2OCA2dG80IHJlbGF5IGFuZCBpdHMgdXNlcnMgKG9uIGVpdGhlciBzaWRl KSB0aGVyZSdzIGFsc28gbm8gY2xlYXINCiBzdXBwb3J0IHBhdGguPGJyPg0KPGJyPg0KSXQgbWln aHQgYmUgd29ydGggcG9pbnRpbmcgb3V0IHRoYXQgc2ltaWxhciBwcm9ibGVtcyBjb3VsZCBvY2N1 ciB3aXRoIGFueSB1c2Ugb2YgYW55Y2FzdCBhZGRyZXNzZXMuJm5ic3A7IEJ1dCB0aGUgb3RoZXIg dXNlIG9mIGFueWNhc3QgdGhhdCBjcm9zc2VzIG5ldHdvcmsgYm91bmRhcmllcyBvZiB3aGljaCBJ J20gYXdhcmUgKGUuZy4gcm9vdCBETlMgc2VydmVycykgaXMgbm90IGNvbnRyb3ZlcnNpYWwgLSBl dmVyeWJvZHkgYWNjZXB0cyB0aGF0IGl0J3Mgdml0YWwNCiB0aGF0IEROUyByb290cyBiZSByZWFj aGFibGUuJm5ic3A7Jm5ic3A7IChJdCdzIHNhZCB0aGF0IGZhciBmZXdlciBjb25zaWRlcmVkIElQ djYgdHJhbnNpdGlvbiBhbiBlc3NlbnRpYWwgc2VydmljZSwgYnV0IEkgdW5kZXJzdGFuZCB0aGF0 IHN1cHBvcnRpbmcgYSA2dG80IHJlbGF5IHJvdXRlciBpcyBhIGdyZWF0ZXIgYnVyZGVuIHRoYW4g anVzdCBmb3J3YXJkaW5nIHBhY2tldHMgdG8gYSByb290IHNlcnZlciB0aGF0IHNvbWVvbmUgZWxz ZSBtYWludGFpbnMuKTxicj4NCjxicj4NCkkgcmVjb21tZW5kIGRlZmluaW5nIGEgc3Vuc2V0IGRh dGUsIHNheSBOIG1vbnRocyBhZnRlciBkb2N1bWVudCBwdWJsaWNhdGlvbiwgdG8gZ2l2ZSBldmVy eW9uZSBhbXBsZSB0aW1lIHRvIGFkYXB0IGJ1dCBhbHNvIHRvIGF2b2lkIGhhdmluZyBldmVyeW9u ZSBlbHNlJ3MgcmVsYXkgcm91dGVycyBzd2FtcGVkLjxicj4NCjxicj4NCi0tLTxicj4NCjxicj4N ClRoZSBhYm92ZSBhcHBsaWVzIHRvIFJGQyAzMDY4IHJvdXRlcnMgYWNjZXB0aW5nIHRyYWZmaWMg YXQgdGhlIDZ0bzQgSVB2NCBhbnljYXN0IGFkZHJlc3MgYW5kIGZvcndhcmRpbmcgcGFja2V0cyBp bnRvIHRoZSBJUHY2IG5ldHdvcmsuJm5ic3A7Jm5ic3A7IEl0IG1pZ2h0IGJlIHdvcnRoIHNlcGFy YXRlbHkgYWRkcmVzc2luZyB0aGUgcXVlc3Rpb24gb2YgSVB2NiByb3V0ZXJzIGFkdmVydGlzaW5n IHRoZSAyMDAyOi8xNiBwcmVmaXggYW5kIGZvcndhcmRpbmcgcGFja2V0cw0KIGludG8gdGhlIElQ djQgbmV0d29yay4mbmJzcDsmbmJzcDsgSSBkb24ndCB0aGluayB0aGUgdHdvIGNhc2VzIGFyZSBx dWl0ZSBzeW1tZXRyaWNhbCwgYW5kIGl0IHNlZW1zIHBvc3NpYmxlIHRoYXQgaXQgY2F1c2VzIGZl d2VyIHByb2JsZW1zIGZvciBhIHY2IHJvdXRlciB0byBhZHZlcnRpc2UgMjAwMjovMTYgdGhhbiBm b3IgYSB2NCByb3V0ZXIgdG8gYWR2ZXJ0aXNlIDE5Mi44OC45OS8yNC4gJm5ic3A7IElmIG5vdGhp bmcgZWxzZSwgaXQncyBlYXN5IHRvIHRyYWNlcm91dGUNCiB0aGUgdjYgc2lkZSBhbmQgZmlndXJl IG91dCB3aGV0aGVyIHRoZSB0cmFmZmljIGdldHMgdG8gdGhlIHJlbGF5IHJvdXRlciwgYnV0IHRo ZSB0cmFjZXJvdXRlIGZyb20gdGhlIDZ0bzQgc2lkZSBkb2Vzbid0IHRlbGwgeW91IG11Y2ggYmVj YXVzZSB0aGUgd2hvbGUgcGF0aCBvdmVyIHY0IGp1c3QgbG9va3MgbGlrZSBvbmUgaG9wLg0KPGJy Pg0KPGJyPg0KSGF2aW5nIHY2LSZndDt2NCByZWxheSByb3V0ZXJzIHN0aWxsIGJlIG9wZXJhdGlv bmFsIHdvdWxkIHBlcm1pdCBzaXRlcyB1c2luZyA2dG80IHRvIGV4cGxpY2l0bHkgY29uZmlndXJl IGFuIGV4cGxpY2l0IDZpbjQgdHVubmVsIHRvIGEgcmVsYXkgcm91dGVyIHJlYWNoYWJsZSB2aWEg djQuJm5ic3A7Jm5ic3A7Jm5ic3A7IEJ1dCB0aGUgJnF1b3Q7bGFjayBvZiBhbiBleHBsaWNpdCBy ZWxhdGlvbnNoaXAmcXVvdDsgcHJvYmxlbSB3b3VsZCByZW1haW4uJm5ic3A7Jm5ic3A7Jm5ic3A7 IEkgaGF2ZSBhbHNvIGhlYXJkIHJ1bW9ycw0KIG9mIHJvdXRlcnMgYWR2ZXJ0aXNpbmcgMjAwMjov MTYgYnV0IHdoaWNoIG9ubHkgZm9yd2FyZGVkIHBhY2tldHMgdG8gYSBzdWJzZXQgb2YgSVB2NCBz cGFjZS4mbmJzcDsmbmJzcDsgU28gdGhlcmUncyBhIHNlcGFyYXRlIHByb2JsZW0gaGVyZSwgdGhv dWdoIEkgZG9uJ3Qga25vdyBob3cgc2VyaW91cyBpdCBpcy4mbmJzcDsmbmJzcDsgSW4gZ2VuZXJh bCBpdCBtaWdodCBiZSBhIEJhZCBJZGVhIGZvciBtdWx0aXBsZSBBU2VzIHRvIGV2ZXIgb3JpZ2lu YXRlIGFkdmVydGlzZW1lbnRzDQogdG8gdGhlIHNhbWUgcHJlZml4Ljxicj4NCjxicj4NCjIuJm5i c3A7IFRoZSB1dGlsaXR5IG9mIHByb3RvY29sIDQxIGluIHBhcnRpY3VsYXIsIGFuZCBuZXR3b3Jr IHRyYW5zcGFyZW5jeSBpbiBnZW5lcmFsLCBzaG91bGQgYmUgYWZmaXJtZWQuJm5ic3A7Jm5ic3A7 IFBlcmhhcHMgdGhpcyB3b3VsZCBiZSBtb3N0IGNsZWFybHkgZXhwcmVzc2VkIGluIGEgc2VwYXJh dGUgZG9jdW1lbnQsIGJ1dCBJJ2xsIGJlIGhhcHB5IGZvciBhbnkgc3RhdGVtZW50IEkgY2FuIGdl dC4mbmJzcDsmbmJzcDsgSSd2ZSBzZWVuIGFuZCBoZWFyZCBvZiB0b28gbWFueSBjYXNlcw0KIG9m IGNhcnJpZXJzIGJsb2NraW5nIHByb3RvY29sIDQxIGV2ZW4gYmV0d2VlbiBob3N0cyB1c2luZyBz dGF0aWMgSVB2NCBhZGRyZXNzZXMuDQo8YnI+DQo8YnI+DQozLiZuYnNwOyBSZWdhcmRpbmcmbmJz cDsgUkZDIDMwNTY6Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgaXQgc2hvdWxkIG5vdCBiZSBkZXByZWNh dGVkLCBhcyBJIHRoaW5rIHRoaXMgc2VuZHMgdGhlIHdyb25nIG1lc3NhZ2UgdG8gY2FycmllcnMg YW5kIG5ldHdvcmsgb3BlcmF0b3JzIHRoYXQgaGF2ZSBhY3RpdmVseSBhdHRhY2tlZCA2dG80LiZu YnNwOyBIb3dldmVyLCB1bmxlc3Mgc29tZSByZWxheSBjYXBhYmlsaXR5IGJldHdlZW4gNnRvNCBz aXRlcyBhbmQgbmF0aXZlIHY2IGNhbiBiZSBzYWx2YWdlZA0KIChleHBsaWNpdGx5IGNvbmZpZ3Vy ZWQgdjQtJmd0O3Y2LCBhZHZlcnRpc2VkIDIwMDI6LzE2IG9uIHRoZSB2NiBzaWRlKSwgaXQncyBj ZXJ0YWlubHkgZmFpciB0byBzYXkgdGhhdCBSRkMgMzA1NiBoYXMgbGVzcyBnZW5lcmFsIGFwcGxp Y2FiaWxpdHkuJm5ic3A7Jm5ic3A7Jm5ic3A7IENvbnN1bWVyIHJvdXRlciB2ZW5kb3JzIGNlcnRh aW5seSBzaG91bGRuJ3QgYmUgdG91dGluZyA2dG80IHN1cHBvcnQgYXMgJnF1b3Q7SVB2NiBzdXBw b3J0JnF1b3Q7LiAmbmJzcDsmbmJzcDsNCjxicj4NCjxicj4NClNvIHNvbWUgc29ydCBvZiByZXZp c2VkIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGZvciBSRkMgMzA1NiBtaWdodCBiZSBpbiBvcmRl ci4mbmJzcDsmbmJzcDsmbmJzcDsgSWYgcGVvcGxlIGFyZSByZWFsbHkgYXR0YWNoZWQgdG8gZG9j dW1lbnQgY2xhc3NpZmljYXRpb24gYXMgYSB3YXkgdG8gZG8gdGhpcywgcGVyaGFwcyByZWNsYXNz aWZ5aW5nIGl0IGFzIEV4cGVyaW1lbnRhbCBvciBJbmZvcm1hdGlvbmFsIHdvdWxkIGJlIGFwcHJv cHJpYXRlLjxicj4NCjxicj4NCjQuJm5ic3A7IEhvd2V2ZXIgdGhlIGFib3ZlIGFjdGlvbnMgYXJl IGxhYmVsZWQsIHRoZXkgbWFrZSBpdCBhbGwgdGhlIG1vcmUgb2J2aW91cyB0aGF0IHRoZSBJbnRl cm5ldCBjb21tdW5pdHkgbGFja3MgYW4gb2J2aW91cywgcmVjb21tZW5kZWQsIGFuZCBnZW5lcmFs bHktYXBwbGljYWJsZSBJUHY2LW92ZXItSVB2NCB0dW5uZWxpbmcgbWVjaGFuaXNtIHRoYXQgY2Fu IGJlIGltcGxlbWVudGVkIGluIGEgaG9zdCBvciByb3V0ZXIgKGJvdGggYXJlIG5lZWRlZCwNCiBi dXQgdGhlc2UgY291bGQgYmUgc2VwYXJhdGUgbWVjaGFuaXNtcykgYW5kIGVuYWJsZWQgd2l0aCBt aW5pbWFsIHVzZXIgZWZmb3J0LiZuYnNwOyZuYnNwOyBUaGlzIHNlZW1zIGxpa2UgYSBnYXBpbmcg YW5kIGVtYmFycmFzc2luZyBob2xlIGFuZCBhIHNlcmlvdXMgaW1wZWRpbWVudCB0byB0aGUgdW5p dmVyc2FsIHVzZSBvZiBJUHY2LCBhcyB0aGVyZSB3aWxsIGNvbnRpbnVlIHRvIGJlIGxlZ2FjeSBJ UHY0LW9ubHkgbmV0d29ya3MgZm9yIHNvbWUgdGltZS4mbmJzcDsmbmJzcDsNCjxicj4NCjxicj4N CkF0dGVtcHRpbmcgdG8gbGVhcm4gZnJvbSB0aGUgNnRvNCBleHBlcmllbmNlLCBpdCBhcHBlYXJz IHRoYXQgc3VjaCBhIG1lY2hhbmlzbTogKGEpIHNob3VsZCBub3QgcmVseSBvbiBJUHY0IGFueWNh c3QgZm9yIHNlcnZpY2UgZGlzY292ZXJ5LCBhdCBsZWFzdCBub3QgYWNyb3NzIG5ldHdvcmsgYm91 bmRhcmllczsgKGIpIHNob3VsZCBoYXZlIGFuIGV4cGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVu IGEgdXNlci9jdXN0b21lciBhbmQgYW55IHY0LXY2DQogcmVsYXlzOyAoYykgc2hvdWxkIHdvcmsg dGhyb3VnaCBOQVRzOyAoZCkgc2hvdWxkIGFsbG93IHRoZSB1c2VyJ3MgSVNQIHRvIHByb3ZpZGUg dGhlIHNlcnZpY2UgKGFuZCBhbGxvdyB0aGF0IHNlcnZpY2UgdG8gYmUgYXV0b21hdGljYWxseSBk aXNjb3ZlcmVkKSwgYnV0IG5vdCBmb3JjZSB0aGUgdXNlciB0byByZWx5IG9uIGhpcyBJU1AgdG8g ZG8gc287IGFuZCAoZSkgdGhlcmUgc2hvdWxkIGJlIGEgd2VsbC1kZWZpbmVkIG1lY2hhbmlzbSB0 byBhbGxvdw0KIGEgbmV0d29yayBvcGVyYXRvciB0byBmaWx0ZXIgb3IgZGVmZWF0IHRoZSBzZXJ2 aWNlIGZvciBob3N0cyBvbiBoaXMgbmV0d29yaywgd2hpbGUgbWFraW5nIGl0IGNsZWFyIHRvIHRo ZSB1c2VycyBvZiB0aG9zZSBob3N0cyB0aGF0IHRoYXQncyB3aGF0J3MgaGFwcGVuaW5nLjxicj4N Cjxicj4NCjxiPklNTyBvdXIgZWZmb3J0cyBzaG91bGQgYmUgZm9jdXNlZCBvbiBpZGVudGlmeWlu Zy9kZXZlbG9waW5nL3JlZmluaW5nL3JlY29tbWVuZGluZyBzdWNoIGEgbWVjaGFuaXNtLCBtdWNo IG1vcmUgdGhhbiBvbiB0cnlpbmcgdG8gZmlndXJlIG91dCBleGFjdGx5IGhvdyB0byBraWxsIDZ0 bzQgb3IgYW55IG90aGVyIGV4aXN0aW5nIHRyYW5zaXRpb24gbWVjaGFuaXNtLjwvYj4mbmJzcDsm bmJzcDsgUHJvdmlkZSBhIGJldHRlciB3YXkgZm9yIHBlb3BsZSB3aG8gYXJlDQogc3R1Y2sgKHNv bWUgb3IgYWxsIG9mIHRoZSB0aW1lKSBvbiBJUHY0LW9ubHkgbmV0d29ya3MgdG8gdXNlIElQdjYs IGFuZCBub2JvZHkgKGluY2x1ZGluZyBtZSkgd2lsbCBuZWVkIHRvIGNhcmUgYWJvdXQgNnRvNC4m bmJzcDsmbmJzcDsgVGhlIG5lZWQgZm9yIDZ0bzQgaGFzbid0IGdvbmUgYXdheSwgaXQncyBqdXN0 IHRoYXQgdGhlIG5ldHdvcmsgaGFzIGJlY29tZSBtdWNoIG1vcmUgaG9zdGlsZSB0byBpdCB0aGFu IHdoZW4gdGhlIG1lY2hhbmlzbSB3YXMgZmlyc3QNCiBkZWZpbmVkLjxicj4NCjxicj4NCktlaXRo PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2134F8430051B64F815C691A62D9831832D75F09XCHBLV504nwnosb_-- From nobody Fri Oct 31 16:11:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22A1A6F80 for ; Fri, 31 Oct 2014 16:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oDHl0OK05vF for ; Fri, 31 Oct 2014 16:11:49 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6010B1A038F for ; Fri, 31 Oct 2014 16:11:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C7CD5207C4 for ; Fri, 31 Oct 2014 19:11:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 31 Oct 2014 19:11:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type; s= smtpout; bh=O81lN/9k9NonQg1y3WS3bl3nCwA=; b=a2rgKwXONoLl/zAcz9Sh mXAL/x/0jRv9joZERXkHPhCV1FUnsOZHxQtpXeIzSQTntPjL51U6yApjGHQMyXoG 6IK9HxsSjiNMRiA6rMTvA9FVINmMIYPoJScIPtazHZrRC1yfHpTvEePiMSiCAdAO rweS5bqXS9iIbCjUa5x5WVY= X-Sasl-enc: G6i2E/rrFHcWzwqFPAgSI90UBdyg1k/qfb+vd8LSAPg5 1414797108 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 54BCC68010C; Fri, 31 Oct 2014 19:11:48 -0400 (EDT) Message-ID: <54541729.1030307@network-heretics.com> Date: Fri, 31 Oct 2014 19:11:37 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "v6ops@ietf.org WG" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------090000090801050008060105" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v_-9DdsVSXPvcjsgDZnXDTgHX14 Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:11:51 -0000 This is a multi-part message in MIME format. --------------090000090801050008060105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/31/2014 07:07 PM, Templin, Fred L wrote: > > Hi Keith, > > Just a couple of quick comments: > > 4. However the above actions are labeled, they make it all the more > obvious that the Internet community lacks an obvious, recommended, and > generally-applicable IPv6-over-IPv4 tunneling mechanism that can be > implemented in a host or router (both are needed, but these could be > separate mechanisms) and enabled with minimal user effort. This > seems like a gaping and embarrassing hole and a serious impediment to > the universal use of IPv6, as there will continue to be legacy > IPv4-only networks for some time. > > Maybe, but it does not necessarily need to be ip-proto-41 based. > Concur. And as you point out, that wouldn't work over NATs. > *IMO our efforts should be focused on > identifying/developing/refining/recommending such a mechanism, much > more than on trying to figure out exactly how to kill 6to4 or any > other existing transition mechanism.* > > I take it from the emphasis that you truly believe there is a gap that > needs to be filled. > Indeed I do, though it's possible that either I missed one that satisfies the criteria, or there are some mechanisms that only need a bit of tweaking (like a service discovery mechanism). But the message was already long enough so I didn't want to try to start a discussion about the merits of specific approaches in the same message. How do you feel about the criteria (a)-(e) that I listed? Are they sufficient? Keith p.s. I'll take a look at AERO. --------------090000090801050008060105 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/31/2014 07:07 PM, Templin, Fred L wrote:

Hi Keith,

 

Just a couple of quick comments:

 

4.  However the above actions are labeled, they make it all the more obvious that the Internet community lacks an obvious, recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism that can be implemented in a host or router (both are needed, but these could be separate mechanisms) and enabled with minimal user effort.   This seems like a gaping and embarrassing hole and a serious impediment to the universal use of IPv6, as there will continue to be legacy IPv4-only networks for some time.  

 

Maybe, but it does  not necessarily need to be ip-proto-41 based.


Concur.   And as you point out, that wouldn't work over NATs.

 IMO our efforts should be focused on identifying/developing/refining/recommending such a mechanism, much more than on trying to figure out exactly how to kill 6to4 or any other existing transition mechanism.  

 

I take it from the emphasis that you truly believe there is a gap that needs to be filled.


Indeed I do, though it's possible that either I missed one that satisfies the criteria, or there are some mechanisms that only need a bit of tweaking (like a service discovery mechanism).    But the message was already long enough so I didn't want to try to start a discussion about the merits of specific approaches in the same message.

How do you feel about the criteria (a)-(e) that I listed?   Are they sufficient?

Keith

p.s. I'll take a look at AERO.

--------------090000090801050008060105-- From nobody Fri Oct 31 16:33:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC61A8745 for ; Fri, 31 Oct 2014 16:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiZiEyA3WaZX for ; Fri, 31 Oct 2014 16:33:28 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05051A875F for ; Fri, 31 Oct 2014 16:33:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9VNXREf024488; Fri, 31 Oct 2014 16:33:27 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (xch-blv-404.nw.nos.boeing.com [130.247.25.157]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9VNXL7J024459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Oct 2014 16:33:22 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.12]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 16:33:21 -0700 From: "Templin, Fred L" To: Keith Moore , "v6ops@ietf.org WG" Thread-Topic: [v6ops] my recommendation re: 6to4 Thread-Index: AQHP9VzQ4wRvtBZjb0mzKuHwNHu235xK0P5wgAB5q4D//47TMA== Date: Fri, 31 Oct 2014 23:33:21 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D75F73@XCH-BLV-504.nw.nos.boeing.com> References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <54541729.1030307@network-heretics.com> In-Reply-To: <54541729.1030307@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832D75F73XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ex-01WQFI5-Bf_CBABWLkFQhsUQ Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:33:30 -0000 --_000_2134F8430051B64F815C691A62D9831832D75F73XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VpdGgsDQoNCkhvdyBkbyB5b3UgZmVlbCBhYm91dCB0aGUgY3JpdGVyaWEgKGEpLShlKSB0 aGF0IEkgbGlzdGVkPyAgIEFyZSB0aGV5IHN1ZmZpY2llbnQ/DQoNCkkgdGhvdWdodCB0aGV5IHNv dW5kZWQgZmluZSwgYnV0IHdvdWxkIGFsc28gYWRkIHRoYXQgdGhlIHNhbWUgbWVjaGFuaXNtcyB0 aGF0DQp3b3VsZCBiZSBhcHBsaWVkIGluIElTUCBuZXR3b3JrcyBzaG91bGQgYWxzbyBiZSBhcHBs aWNhYmxlIGZvciBlbnRlcnByaXNlIG5ldHdvcmtzDQphbmQgYW55IG90aGVyIG1hbm5lciBvZiBu ZXR3b3JrIHRoYXQgcHJvdmlkZXMgYmFzaWMgY29ubmVjdGl2aXR5IHRvIHRoZSBlbmQgdXNlci4N Ck1vYmlsaXR5IGFuZCBzZWN1cml0eSBhcmUgb3RoZXIgYXNwZWN0cyB0aGF0IG1heSBhbHNvIG5l ZWQgdG8gYmUgY29uc2lkZXJlZC4NCg0KVGhhbmtzIOKAkyBGcmVkDQpmcmVkLmwudGVtcGxpbkBi b2VpbmcuY29tDQoNCkZyb206IEtlaXRoIE1vb3JlIFttYWlsdG86bW9vcmVAbmV0d29yay1oZXJl dGljcy5jb21dDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMzEsIDIwMTQgNDoxMiBQTQ0KVG86IFRl bXBsaW4sIEZyZWQgTDsgdjZvcHNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIG15 IHJlY29tbWVuZGF0aW9uIHJlOiA2dG80DQoNCk9uIDEwLzMxLzIwMTQgMDc6MDcgUE0sIFRlbXBs aW4sIEZyZWQgTCB3cm90ZToNCkhpIEtlaXRoLA0KDQpKdXN0IGEgY291cGxlIG9mIHF1aWNrIGNv bW1lbnRzOg0KDQo0LiAgSG93ZXZlciB0aGUgYWJvdmUgYWN0aW9ucyBhcmUgbGFiZWxlZCwgdGhl eSBtYWtlIGl0IGFsbCB0aGUgbW9yZSBvYnZpb3VzIHRoYXQgdGhlIEludGVybmV0IGNvbW11bml0 eSBsYWNrcyBhbiBvYnZpb3VzLCByZWNvbW1lbmRlZCwgYW5kIGdlbmVyYWxseS1hcHBsaWNhYmxl IElQdjYtb3Zlci1JUHY0IHR1bm5lbGluZyBtZWNoYW5pc20gdGhhdCBjYW4gYmUgaW1wbGVtZW50 ZWQgaW4gYSBob3N0IG9yIHJvdXRlciAoYm90aCBhcmUgbmVlZGVkLCBidXQgdGhlc2UgY291bGQg YmUgc2VwYXJhdGUgbWVjaGFuaXNtcykgYW5kIGVuYWJsZWQgd2l0aCBtaW5pbWFsIHVzZXIgZWZm b3J0LiAgIFRoaXMgc2VlbXMgbGlrZSBhIGdhcGluZyBhbmQgZW1iYXJyYXNzaW5nIGhvbGUgYW5k IGEgc2VyaW91cyBpbXBlZGltZW50IHRvIHRoZSB1bml2ZXJzYWwgdXNlIG9mIElQdjYsIGFzIHRo ZXJlIHdpbGwgY29udGludWUgdG8gYmUgbGVnYWN5IElQdjQtb25seSBuZXR3b3JrcyBmb3Igc29t ZSB0aW1lLg0KDQpNYXliZSwgYnV0IGl0IGRvZXMgIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGJl IGlwLXByb3RvLTQxIGJhc2VkLg0KDQpDb25jdXIuICAgQW5kIGFzIHlvdSBwb2ludCBvdXQsIHRo YXQgd291bGRuJ3Qgd29yayBvdmVyIE5BVHMuDQoNCg0KIElNTyBvdXIgZWZmb3J0cyBzaG91bGQg YmUgZm9jdXNlZCBvbiBpZGVudGlmeWluZy9kZXZlbG9waW5nL3JlZmluaW5nL3JlY29tbWVuZGlu ZyBzdWNoIGEgbWVjaGFuaXNtLCBtdWNoIG1vcmUgdGhhbiBvbiB0cnlpbmcgdG8gZmlndXJlIG91 dCBleGFjdGx5IGhvdyB0byBraWxsIDZ0bzQgb3IgYW55IG90aGVyIGV4aXN0aW5nIHRyYW5zaXRp b24gbWVjaGFuaXNtLg0KDQpJIHRha2UgaXQgZnJvbSB0aGUgZW1waGFzaXMgdGhhdCB5b3UgdHJ1 bHkgYmVsaWV2ZSB0aGVyZSBpcyBhIGdhcCB0aGF0IG5lZWRzIHRvIGJlIGZpbGxlZC4NCg0KSW5k ZWVkIEkgZG8sIHRob3VnaCBpdCdzIHBvc3NpYmxlIHRoYXQgZWl0aGVyIEkgbWlzc2VkIG9uZSB0 aGF0IHNhdGlzZmllcyB0aGUgY3JpdGVyaWEsIG9yIHRoZXJlIGFyZSBzb21lIG1lY2hhbmlzbXMg dGhhdCBvbmx5IG5lZWQgYSBiaXQgb2YgdHdlYWtpbmcgKGxpa2UgYSBzZXJ2aWNlIGRpc2NvdmVy eSBtZWNoYW5pc20pLiAgICBCdXQgdGhlIG1lc3NhZ2Ugd2FzIGFscmVhZHkgbG9uZyBlbm91Z2gg c28gSSBkaWRuJ3Qgd2FudCB0byB0cnkgdG8gc3RhcnQgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBt ZXJpdHMgb2Ygc3BlY2lmaWMgYXBwcm9hY2hlcyBpbiB0aGUgc2FtZSBtZXNzYWdlLg0KDQpIb3cg ZG8geW91IGZlZWwgYWJvdXQgdGhlIGNyaXRlcmlhIChhKS0oZSkgdGhhdCBJIGxpc3RlZD8gICBB cmUgdGhleSBzdWZmaWNpZW50Pw0KDQpLZWl0aA0KDQpwLnMuIEknbGwgdGFrZSBhIGxvb2sgYXQg QUVSTy4NCg== --_000_2134F8430051B64F815C691A62D9831832D75F73XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBLZWl0aCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGRvIHlvdSBmZWVsIGFib3V0 IHRoZSBjcml0ZXJpYSAoYSktKGUpIHRoYXQgSSBsaXN0ZWQ/Jm5ic3A7Jm5ic3A7IEFyZSB0aGV5 IHN1ZmZpY2llbnQ/PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSB0aG91Z2h0IHRoZXkgc291bmRlZCBmaW5lLCBidXQgd291bGQgYWxzbyBhZGQg dGhhdCB0aGUgc2FtZSBtZWNoYW5pc21zIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+d291bGQgYmUgYXBwbGllZCBpbiBJU1AgbmV0d29ya3Mgc2hvdWxkIGFsc28gYmUgYXBwbGlj YWJsZSBmb3IgZW50ZXJwcmlzZSBuZXR3b3JrczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5hbmQgYW55IG90aGVyIG1hbm5lciBvZiBuZXR3b3JrIHRoYXQgcHJvdmlkZXMgYmFzaWMgY29u bmVjdGl2aXR5IHRvIHRoZSBlbmQgdXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TW9iaWxpdHkgYW5kIHNlY3VyaXR5IGFyZSBvdGhlciBhc3BlY3RzIHRoYXQgbWF5IGFsc28gbmVl ZCB0byBiZSBjb25zaWRlcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIOKAkyBGcmVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4gS2VpdGggTW9vcmUgW21haWx0bzptb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMzEsIDIwMTQgNDoxMiBQTTxi cj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMOyB2Nm9wc0BpZXRmLm9yZyBXRzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBteSByZWNvbW1lbmRhdGlvbiByZTogNnRvNDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMC8z MS8yMDE0IDA3OjA3IFBNLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIEtlaXRoLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCBhIGNvdXBsZSBvZiBxdWlj ayBjb21tZW50czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4mbmJzcDsgSG93ZXZlciB0aGUg YWJvdmUgYWN0aW9ucyBhcmUgbGFiZWxlZCwgdGhleSBtYWtlIGl0IGFsbCB0aGUgbW9yZSBvYnZp b3VzIHRoYXQgdGhlIEludGVybmV0IGNvbW11bml0eSBsYWNrcyBhbiBvYnZpb3VzLCByZWNvbW1l bmRlZCwgYW5kIGdlbmVyYWxseS1hcHBsaWNhYmxlIElQdjYtb3Zlci1JUHY0IHR1bm5lbGluZyBt ZWNoYW5pc20gdGhhdCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBob3N0IG9yIHJvdXRlcg0KIChi b3RoIGFyZSBuZWVkZWQsIGJ1dCB0aGVzZSBjb3VsZCBiZSBzZXBhcmF0ZSBtZWNoYW5pc21zKSBh bmQgZW5hYmxlZCB3aXRoIG1pbmltYWwgdXNlciBlZmZvcnQuJm5ic3A7Jm5ic3A7IFRoaXMgc2Vl bXMgbGlrZSBhIGdhcGluZyBhbmQgZW1iYXJyYXNzaW5nIGhvbGUgYW5kIGEgc2VyaW91cyBpbXBl ZGltZW50IHRvIHRoZSB1bml2ZXJzYWwgdXNlIG9mIElQdjYsIGFzIHRoZXJlIHdpbGwgY29udGlu dWUgdG8gYmUgbGVnYWN5IElQdjQtb25seSBuZXR3b3JrcyBmb3INCiBzb21lIHRpbWUuJm5ic3A7 Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk1heWJlLCBidXQgaXQgZG9lcyZuYnNwOyBub3QgbmVjZXNzYXJpbHkgbmVlZCB0 byBiZSBpcC1wcm90by00MSBiYXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpDb25jdXIuJm5ic3A7Jm5ic3A7IEFuZCBh cyB5b3UgcG9pbnQgb3V0LCB0aGF0IHdvdWxkbid0IHdvcmsgb3ZlciBOQVRzLjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxiPklNTyBvdXIg ZWZmb3J0cyBzaG91bGQgYmUgZm9jdXNlZCBvbiBpZGVudGlmeWluZy9kZXZlbG9waW5nL3JlZmlu aW5nL3JlY29tbWVuZGluZyBzdWNoIGEgbWVjaGFuaXNtLCBtdWNoIG1vcmUgdGhhbiBvbiB0cnlp bmcgdG8gZmlndXJlIG91dCBleGFjdGx5DQogaG93IHRvIGtpbGwgNnRvNCBvciBhbnkgb3RoZXIg ZXhpc3RpbmcgdHJhbnNpdGlvbiBtZWNoYW5pc20uPC9iPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0YWtl IGl0IGZyb20gdGhlIGVtcGhhc2lzIHRoYXQgeW91IHRydWx5IGJlbGlldmUgdGhlcmUgaXMgYSBn YXAgdGhhdCBuZWVkcyB0byBiZSBmaWxsZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpJbmRlZWQgSSBkbywgdGhvdWdoIGl0J3MgcG9zc2libGUgdGhhdCBlaXRoZXIgSSBt aXNzZWQgb25lIHRoYXQgc2F0aXNmaWVzIHRoZSBjcml0ZXJpYSwgb3IgdGhlcmUgYXJlIHNvbWUg bWVjaGFuaXNtcyB0aGF0IG9ubHkgbmVlZCBhIGJpdCBvZiB0d2Vha2luZyAobGlrZSBhIHNlcnZp Y2UgZGlzY292ZXJ5IG1lY2hhbmlzbSkuJm5ic3A7Jm5ic3A7Jm5ic3A7IEJ1dCB0aGUgbWVzc2Fn ZSB3YXMgYWxyZWFkeSBsb25nIGVub3VnaCBzbyBJIGRpZG4ndCB3YW50IHRvIHRyeSB0bw0KIHN0 YXJ0IGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgbWVyaXRzIG9mIHNwZWNpZmljIGFwcHJvYWNoZXMg aW4gdGhlIHNhbWUgbWVzc2FnZS48YnI+DQo8YnI+DQpIb3cgZG8geW91IGZlZWwgYWJvdXQgdGhl IGNyaXRlcmlhIChhKS0oZSkgdGhhdCBJIGxpc3RlZD8mbmJzcDsmbmJzcDsgQXJlIHRoZXkgc3Vm ZmljaWVudD88YnI+DQo8YnI+DQpLZWl0aDxicj4NCjxicj4NCnAucy4gSSdsbCB0YWtlIGEgbG9v ayBhdCBBRVJPLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_2134F8430051B64F815C691A62D9831832D75F73XCHBLV504nwnosb_-- From nobody Fri Oct 31 16:34:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BD21A870D for ; Fri, 31 Oct 2014 16:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB0dvjrxZv2A for ; Fri, 31 Oct 2014 16:34:15 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB831A873C for ; Fri, 31 Oct 2014 16:34:15 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B252120677 for ; Fri, 31 Oct 2014 19:34:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 31 Oct 2014 19:34:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type; s= smtpout; bh=UCF1dVYpjPLbuTpcO9ql+WxB+U0=; b=pvBi0kDaD9VyvO6ORrri /6R/jkFTwn/kDdkdekw/NWimxEGe1vbxRJXwk05eMLqQ6IPh75CwwNUts5VHxSxS IZqxtrakjn0sHH0YLM08M/9zRlFM2nxaqMBTmilvopvn3gF2gl3/fvq+GBII1bWY kVd4dk+Tfb2TZ6cjeRDu59Q= X-Sasl-enc: xSjkVGkKOF3DV/E7zeZtWPPXzlU++0lRc4XLcLnud7Ly 1414798454 Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 47B2EC00006; Fri, 31 Oct 2014 19:34:14 -0400 (EDT) Message-ID: <54541C6B.6070606@network-heretics.com> Date: Fri, 31 Oct 2014 19:34:03 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Templin, Fred L" , "v6ops@ietf.org WG" References: <5454119C.3090601@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F09@XCH-BLV-504.nw.nos.boeing.com> <54541729.1030307@network-heretics.com> <2134F8430051B64F815C691A62D9831832D75F73@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D75F73@XCH-BLV-504.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------080300000906010807030707" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KveGysn_gn4CzXHZgSwHhPZB48M Subject: Re: [v6ops] my recommendation re: 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:34:17 -0000 This is a multi-part message in MIME format. --------------080300000906010807030707 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/31/2014 07:33 PM, Templin, Fred L wrote: > > Hi Keith, > > How do you feel about the criteria (a)-(e) that I listed? Are they > sufficient? > > I thought they sounded fine, but would also add that the same > mechanisms that > > would be applied in ISP networks should also be applicable for > enterprise networks > > and any other manner of network that provides basic connectivity to > the end user. > > Mobility and security are other aspects that may also need to be > considered. > Makes sense. Keith --------------080300000906010807030707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/31/2014 07:33 PM, Templin, Fred L wrote:

Hi Keith,

 

How do you feel about the criteria (a)-(e) that I listed?   Are they sufficient?

 

I thought they sounded fine, but would also add that the same mechanisms that

would be applied in ISP networks should also be applicable for enterprise networks

and any other manner of network that provides basic connectivity to the end user.

Mobility and security are other aspects that may also need to be considered.

Makes sense.

Keith


--------------080300000906010807030707-- From nobody Fri Oct 31 17:07:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C14F1A8755 for ; Fri, 31 Oct 2014 17:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mr0QP50z6Be for ; Fri, 31 Oct 2014 17:07:33 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5AE1A8752 for ; Fri, 31 Oct 2014 17:07:32 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bj1so8658745pad.17 for ; Fri, 31 Oct 2014 17:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4Q/BaorL66nUrdeM5TLmJa42qqEqp6nBtvFRB3gq3fI=; b=eSF8idIpwD1KmsjIR4TXa3w0radxZYkwDA/Be+3m8znhAC0o+lRCT6CqJ3uVFjQzRB zJEky3e9cnnosx0GD9syAlF3mwp4a/76zRnPYdx5g4OKBkDDAxLzmGGnWBUdQb4vvYvI GWPJnxbfZ0rgVg755FvuI/4h7oh6izhHN6Zes12zSM8z8drQ4G7XuGaO+r0wrhDYo6W1 KRD5V/PJvWmbWxHoquIL0OUo/t24rlN2AYt6TdGBugFC2pvPvpCTmGTF8K2pWc87eQf8 xAKjOKtkChLaOmYCZhQyzOZ5u81ovY5ATIycMFm4AJxKnBsbB6kukgHAl2pBL4VqNdsx bKpA== X-Received: by 10.70.118.1 with SMTP id ki1mr28241000pdb.69.1414800452158; Fri, 31 Oct 2014 17:07:32 -0700 (PDT) Received: from [192.168.178.23] (247.200.69.111.dynamic.snap.net.nz. [111.69.200.247]) by mx.google.com with ESMTPSA id po6sm10896898pbb.56.2014.10.31.17.07.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 17:07:31 -0700 (PDT) Message-ID: <5454244C.6060507@gmail.com> Date: Sat, 01 Nov 2014 13:07:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <545054DD.9020406@network-heretics.com> <54505F43.5020203@gmail.com> <20141030185237.GR31092@Space.Net> <54528FAE.3050907@network-heretics.com> <20141030204115.GT31092@Space.Net> <5452A333.7060300@network-heretics.com> <54533A0F.1050502@massar.ch> <5453968F.6070103@network-heretics.com> <20141031140800.GH31092@Space.Net> <54539A08.5090707@network-heretics.com> In-Reply-To: <54539A08.5090707@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/mxhUnCG6rqOdwmg_GaysPq-SmQk Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 00:07:36 -0000 Bundling up a few short points: On 01/11/2014 03:17, Keith Moore wrote: ... >> Doesn't make a big difference in the grand scheme - peer to peer 6to4 >> is known to work, no matter how implemented, while 6to4-to-native is >> known to not-work except in controlled environments > > The latter statement is simply false. Well, the statement needs to be deconstructed. 1. 6to4-to-native, not using the anycast method, works if and only if routing is carefully configured as described in RFC 3056. It's critical, for example, that every native IPv6 host involved sees a route to 2002::/16 that leads to a properly configured return relay. 2. 6to4-to-native using the anycast method fails in a quite high proportion of cases because of all the issues descrived in RFC 6343. On 01/11/2014 06:15, Templin, Fred L wrote: > While I have the floor, I know of at least one enterprise that uses public IPv4 addresses > internally. Some devices inside the enterprise see the public addresses and then assume > they can use 6to4. They then set up a 6to4 virtual interface with a 2002:* address assigned, > i.e., even though the enterprise has not deployed a 6to4 service. > > What would deprecation mean to this class of devices? Until somebody upgrades the host software in a way that removes 6to4, nothing, as far as I can see. It's just the same as p2p 6to4 on the Internet, isn't it? Brian