From nobody Sun Nov 1 08:17:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8A33A0B67 for ; Sun, 1 Nov 2020 08:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, LH_URI_DOM_IN_PATH=1.533, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ril.com header.b=VoDsdnLk; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=rilcloud.onmicrosoft.com header.b=RJLSB1Gy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl9-kzIQFcFA for ; Sun, 1 Nov 2020 08:17:24 -0800 (PST) Received: from gwsmtp011.ril.com (gwsmtp011.ril.com [116.50.78.50]) (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 EDCFD3A0B66 for ; Sun, 1 Nov 2020 08:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ril.com; i=@ril.com; q=dns/txt; s=ril; t=1604247443; x=1635783443; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YjghprfcqTjvGolczwaV9GvxzyYLI2b8CYR6hvtCVOw=; b=VoDsdnLkokSIn8kCn52Hm5Ll0917BpgSShF9uabi7QNAdyPGz1/kD+ES aeWWNz/lbhN2wYrF9ZcnYW4+iWZppp9ZYJAoTH7wLbvHc5DQbLVf0zfyW a4+OOR0YFbA4EvnXwyj3XrdTz1PY6FxUdx1DnBqR+5p5P0k45MHCFWdNM A=; Authentication-Results: gwsmtp011.ril.com; dkim=pass (signature verified) header.i=@rilcloud.onmicrosoft.com IronPort-SDR: EW2z0/ykOGyOBbcfkNAB2ZPP6/scobLvEDN+m1oAosobPflWKkcdsnDgfL9CRvAtd5Lj0AiZ+C tGmFWsuC4ofQ== X-IronPort-AV: E=Sophos;i="5.77,442,1596479400"; d="scan'208,217";a="131801475" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TC316XK45mGtwoPtvSspeSbRME8kEabFquaWPFw4rCLQ6xra5G2vImddf1auh1dMTpfYnMrTL3qat+t/rKtdyjwdcTgKZ/Taq9cIPJ9vf/dYgod5Zm/kerq4dWh43jdQ/hha4sA2LZrrH6bY5Utsk/UjEIZa/CAng2c4Pq4pcyCUDM78Lnw5+i31h6h8JQAT8AOcV01osmpr8uwMfxGydqBb4/i2+WET7Dtl+JIxX0EwtlfncMCdH9jgdBGF5QyV0XtWV0fC9Tll2qAXSMig6j743oH3hyy3MqXryVXJGuPVxwGmfIPtEf197EFDoFEXcMWjRXciacB9LH3tJX2TLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z9TfHB3KCV2gizmiNee/SpbjfEOXe2i6kyPS3XXE8AQ=; b=dqJPRPHFKb8DxUa7g1nDu1gF9DaOzxFq/u6Vsn7xXMFyChacop+lsi2IzX4ijdoujT7XWCVHHDn74cn/m71wGqx/Hfz1na+z5h2LHivoPB6+0CspkXcBo2sisJ8gXcuWv0485d+SAlya/y8AhCUYzIKmyIu+h6IxFwAvl0fGS73Qv7eJgBIJy8jcJ09hU1yfU+lX3HuZnTnqCvh7p+xySRreKUWDzy2QMBR5kbZ57LK6c/SSp+2hOgjqy5j3uaXfYLNNFLgXxovzrRNsjuMCGiHO4KA4wOPy/5roEpo5ulfVbrSAelXeWpxAEkYQKErEvd7boDJuGmVZL5kgHLH9rQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ril.com; dmarc=pass action=none header.from=ril.com; dkim=pass header.d=ril.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rilcloud.onmicrosoft.com; s=selector2-rilcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z9TfHB3KCV2gizmiNee/SpbjfEOXe2i6kyPS3XXE8AQ=; b=RJLSB1Gy1/z1nivjtbxTnVD+EqTEamt8+EAfFlRxFSVGbr08VLm2YaIvC5q7lVAkXW6SEGQbh3RpuKCjIHW/7+8yqaFP6ZI+BNfvcvOdCU3Q+ZSTXvOtU+mLN9d7AtiQ+dVlW3yJw5YtWOT2/ZY8OammtOHZYsSH/hgVqjrAVXg= From: Rajesh A Shinde To: Fred Baker , IPv6 Operations CC: Warren Kumari , Ramesh R Chandra , Ron Bonica Thread-Topic: [External]Developing v6ops agenda Thread-Index: AQHWrlIGspRyZZEWEU6vSg5UeFz+w6myzKlOgACq4yA= Date: Sun, 1 Nov 2020 16:17:07 +0000 Message-ID: References: <461B659C-FC97-4C1C-A78C-D7C05297D74C@gmail.com> In-Reply-To: <461B659C-FC97-4C1C-A78C-D7C05297D74C@gmail.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f51c7f16-7fd2-4d17-d5b1-08d87e819418 x-ms-traffictypediagnostic: BMXPR01MB3397: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pmWl2WSmucsrFWxzVDg1iiAdsoZyCjudVZmrKlhVsd0P8Aen/z0LMMPBp/jxpH1nTVmugYKI/qmFZrUzfLrVDfncAGFiiZbALuTW41ZCnhH9vcQ5rF9AN8YO8jjzbvKLhNU5Tr3R7uQ5ix1gFgZT1OeoYTbKEDlXpnN5pqyGYtiFuy+FiM2X3dTNj0JZzEAoJOHsm2QPRPJ6s31TSjT4NPlUylixEkFI/AL9TeDYuJGADwDejNmzaACcZlT7ib+cSZwcpf0Hg/3IaoljMvuTB+isAd2ZgRQMG3CNDeQu2YQdXCVTsosaR5I363Rb4O8zKpMiY7zlOoC517gdZVpk570OzYqZ+KNm8TwQU+ci1Mt/AD8aEaXTLsQ3PbKvr5d/XHO1ONcjvVQcJ3i/i1OBlcLGwk21TamPwcCmmyBVm73ExVHx0oJX91ucIbDq1OkH x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR0101MB1586.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(39860400002)(136003)(366004)(376002)(316002)(110136005)(45080400002)(33656002)(66556008)(54906003)(478600001)(71200400001)(76116006)(83380400001)(66476007)(64756008)(66946007)(2906002)(166002)(66446008)(6506007)(53546011)(7696005)(86362001)(52536014)(8676002)(55016002)(5660300002)(8936002)(186003)(4326008)(26005)(966005)(9686003)(32563001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: zEjMcLNFC/Y6HMlEkMjCeNKumGs8h2gKdSXn7eSF41gWS/+6F0Dt9o44G3c7Jd5BlZ/9SJMnJiQgSrxUNWdUvVBCBOhCnVVeIousQNK4ijHwmQUN0tjDC3sUX5rDUtrUWZhRsbUPEZZm6vGdKAb0Yr9GuUfRr3VNBcV/ecOrDtowzgHtoCeKxUxvL0te3CERRw8nL8Ho9LVKltN2hutW19vLs7CmtvjouAPxMrkcl0KH4N0nyOfP3XHvJ9l85nFVu4ck8fSw8t72jFvmhitosJoOcHDHVKBdEBjhGM/gBP8vdaUppYKK8x6PtKv9DpT/gVXEgFxUvcx0S01UuL2Mtf+Vbw59io+QU9SFDDDmHqbDwov54jSIlSL8/3e8300mGIEOG5e3KTC1CPbBKBrfmfakQY1eDD5tvhKC2IGhovyso9LyE3U18S/T9LJB+OXNzRqBvcOaibbuN4FfsQ29U0lCdeFD++Z44G412vas6AryCP/SY0vzjTKPCXsjfZkx8H8NdPqd8eYyUQwTe7NEpRSMesBk3lPR3lJqqvG9DwYUf+yzVT5yaV7+m98SEyhRuiU9etu9vtAHvO1cUXCgqD0r9WNAwGH6zaMICfPgV6GsLtJkTDq1hsNY0BwJnjRyxqA5EFcTBGZQ579iKLtIdw== Content-Type: multipart/alternative; boundary="_000_BM1PR0101MB15860BF10BC525D99ACFCE6DB9130BM1PR0101MB1586_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BM1PR0101MB1586.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f51c7f16-7fd2-4d17-d5b1-08d87e819418 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2020 16:17:07.2462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fe1d95a9-4ce1-41a5-8eab-6dd43aa26d9f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kSZJvt5yekDg3TmdKQhEwwgP2SyOTzHPdpiEm54lSez+xsSxrmDFVVVTNke+gHjymTKtkGnhC7BThqu7Tikd/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BMXPR01MB3397 X-OriginatorOrg: ril.com Archived-At: Subject: Re: [v6ops] [External]Developing v6ops agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 16:17:27 -0000 --_000_BM1PR0101MB15860BF10BC525D99ACFCE6DB9130BM1PR0101MB1586_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks Fred for sharing the v6ops agenda. We will definitely come out with paper on "lessons the IETF should learn fr= om operational experience" and "any suggestions on how to boost enterprise = deployment?". This would be helpful for all including competition. Thanks & Regards, Rajesh A Shinde 8452848048 From: Fred Baker Sent: 01 November 2020 11:31 To: IPv6 Operations Cc: Rajesh A Shinde ; Warren Kumari ; Ramesh R Chandra ; Ron Bonica Subject: [External]Developing v6ops agenda The e-mail below is from an external source. Please do not open attachments= or click links from an unknown or suspicious origin. Ron and I are developing the agenda for IETF 109. I'm forwarding you an edi= ted version of the note I sent him and the authors of current work. An impo= rtant file, attached, is what I call the "raw agenda data"; it all derives = from the data tracker, but rearranged in a way that makes sense to me. One = of the important points is drafts that have been "updated"; that's a time r= eference, and refers to the end of IETF 108. It also contains pointers to m= ailing list commentary, the draft, a diff against the next older version if= any, and the relevant data tracker page. As I see it, most of our drafts need an update, and I would encourage the a= uthors to do so. The new HBH draft has next to no IETF commentary, so my in= ference is that it's not something the operators are interested in - at lea= st not yet. draft-vf-v6ops-ipv6-deployment has a few comments from the list= , which I would encourage the authors to review and update the draft in res= ponse to. In the "raw agenda data" file (attached), you'll find a link to a= ll discussion of the drafts on any IETF list. Ramesh Chandra will give a talk on Reliance JIO's deployment experience. (F= or those unfamiliar with Reliance, see https://ind01.safelinks.protection.o= utlook.com/?url=3Dhttps%3A%2F%2Fstats.labs.apnic.net%2Fipv6%2FAS55836%3Fc%3= DIN%26p%3D1%26v%3D1%26w%3D30%26x%3D1&data=3D04%7C01%7CRajesh.A.Shinde%4= 0ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd43aa26= d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D881kZ2S= 1ngacbd2l49VKblLWBYMYUlqjmwpfy8E2sk0%3D&reserved=3D0; there are five In= dian ISPs that rank highly in observed IPv6 traffic, and rather a number th= at are in the "me too" state.) I have asked him for "lessons the IETF shoul= d learn from operational experience" and "any suggestions on how to boost e= nterprise deployment?". Our proposed agenda is at https://ind01.safelinks.p= rotection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fproceedings%2F109= %2Fagenda%2Fagenda-109-v6ops-00&data=3D04%7C01%7CRajesh.A.Shinde%40ril.= com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd43aa26d9f%7= C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DDgNSdF%2FE9B= jk84vcNsbZ1og7yvnbNUjVECCX%2FaQf4Lc%3D&reserved=3D0; comments solicited. I also noticed https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D4f41f608-10daca84-4f407cf7-ac= 1f6b00f158-b32463b77efafe6c%26q%3D1%26e%3D1b2492ea-1290-48e7-a306-9e7d51bb5= 29a%26u%3Dhttps%253A%252F%252Fwww.nojitter.com%252Fenterprise-networking%25= 2Fshould-enterprises-avoid-or-embrace-ipv6&data=3D04%7C01%7CRajesh.A.Sh= inde%40ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd= 43aa26d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3De= UcKGLf2WSnYQMi%2FQGRcP8INOdPXdO3RgJjsbBVNzE4%3D&reserved=3D0, and start= ed to think about dropping the guy a note. Then I decided not to; he repeat= s a lot of ages-old marketing hype that doesn't necessarily correspond to a= nything I think is real, and never thought made sense. We have over 1000 ro= ot servers worldwide, all of which respond to IPv6 addresses if the network= supports the technology (sometimes an issue) - so what's the case for an I= ndia-specific IPv6-only root server? India only has 43 IPv6-capable servers= (cf https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpr= otect2.fireeye.com%2Fv1%2Furl%3Fk%3D9581ccb3-ca1af03f-9580464c-ac1f6b00f158= -8f882a6dd6a636bc%26q%3D1%26e%3D1b2492ea-1290-48e7-a306-9e7d51bb529a%26u%3D= https%253A%252F%252Froot-servers.org%252F&data=3D04%7C01%7CRajesh.A.Shi= nde%40ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd4= 3aa26d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL= jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DJU= rOGg%2FgZDmEjZWYRfO64aLYTTKm4tpGKDLFdr1FZwA%3D&reserved=3D0)... But it did make me think about enterprise management, how many misconceptio= ns they have, and how much money they're spending that IPv6 deployment woul= d free up. I'm not sure what to do with that. I'd like to believe that we c= an be part of the solution to whatever we decide the actual problem is. You= r opinions would be helpful - an "IPv6 marketing hype dispelled" draft, per= haps? Or "Native IPv6 in enterprise deployment"? An important part of that = is to note that upstream ISPs frequently have IPv6 deployed, but enterprise= customers are not using it, even though actually turning it on is not all = that difficult or time-consuming, and Jen spoke at IETF 108 about turning I= Pv4 off. So - how do we encourage enterprise deployment and adoption? I sho= uld think part of that has to do with the public-facing services - mail and= web. Part of that has been figuring out how to use IPv6 to talk with someo= ne that desperately wants to cling to expensive IPv4 internally, but I want= to promote native deployment. Maybe, and here I take a page out of Mythic = Beast's book, charge more for IPv4 service? "Confidentiality Warning: This message and any attachments are intended onl= y for the use of the intended recipient(s). = are confidential and may be privileged. If you are not the intended recipie= nt. you are hereby notified that any = review. re-transmission. conversion to hard copy. copying. circulation or o= ther use of this message and any attachments is = strictly prohibited. If you are not the intended recipient. please notify t= he sender immediately by return email. = and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ens= ure no viruses are present in this email. = The company cannot accept responsibility for any loss or damage arising fro= m the use of this email or attachment." --_000_BM1PR0101MB15860BF10BC525D99ACFCE6DB9130BM1PR0101MB1586_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Thanks Fred for sharing the v6ops agenda= .

 

We will definitely come out with paper o= n "lessons the IETF should learn from operational experience&qu= ot; and "any suggestions on how to boost enterprise deployment?". This would be helpful for all including competition.

 

Thanks & Regards,

 

Rajesh A Shinde

8452848048

 

 

 

From: Fred Baker <fredbaker.ietf@gmail.com>
Sent: 01 November 2020 11:31
To: IPv6 Operations <v6ops@ietf.org>
Cc: Rajesh A Shinde <Rajesh.A.Shinde@ril.com>; Warren Kumari &= lt;warren@kumari.net>; Ramesh R Chandra <Ramesh.R.Chandra@ril.com>= ; Ron Bonica <rbonica@juniper.net>
Subject: [External]Developing v6ops agenda

 

The e-mail below is f= rom an external source. Please do not open attachments or click links from = an unknown or suspicious origin.

Ron and I are developing the agenda for IETF 109. I'm forwarding you an edi= ted version of the note I sent him and the authors of current work. An impo= rtant file, attached, is what I call the "raw agenda data"; it al= l derives from the data tracker, but rearranged in a way that makes sense to me. One of the important points is drafts tha= t have been "updated"; that's a time reference, and refers to the= end of IETF 108. It also contains pointers to mailing list commentary, the= draft, a diff against the next older version if any, and the relevant data tracker page.

As I see it, most of our drafts need an update, and I would encourage the a= uthors to do so. The new HBH draft has next to no IETF commentary, so my in= ference is that it's not something the operators are interested in - at lea= st not yet. draft-vf-v6ops-ipv6-deployment has a few comments from the list, which I would encourage the authors to r= eview and update the draft in response to. In the "raw agenda data&quo= t; file (attached), you'll find a link to all discussion of the drafts on a= ny IETF list.

Ramesh Chandra will give a talk on Reliance JIO's deployment experience. (F= or those unfamiliar with Reliance, see https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fstats.l= abs.apnic.net%2Fipv6%2FAS55836%3Fc%3DIN%26p%3D1%26v%3D1%26w%3D30%26x%3D1&am= p;amp;data=3D04%7C01%7CRajesh.A.Shinde%40ril.com%7Ce533ecf2bba646dee2a508d8= 7e2bc830%7Cfe1d95a94ce141a58eab6dd43aa26d9f%7C0%7C0%7C637398073794874479%7C= Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL= CJXVCI6Mn0%3D%7C1000&amp;sdata=3D881kZ2S1ngacbd2l49VKblLWBYMYUlqjmwpfy8= E2sk0%3D&amp;reserved=3D0; there are five Indian ISPs that rank highly in observed IPv6 traffic, and = rather a number that are in the "me too" state.) I have asked him= for "lessons the IETF should learn from operational experience" = and "any suggestions on how to boost enterprise deployment?". Our proposed agenda is at https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fproceedings%2F109%2Fagenda%2Fagenda-109-v6ops-00&amp;data=3D04%= 7C01%7CRajesh.A.Shinde%40ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d9= 5a94ce141a58eab6dd43aa26d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbG= Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 1000&amp;sdata=3DDgNSdF%2FE9Bjk84vcNsbZ1og7yvnbNUjVECCX%2FaQf4Lc%3D&= ;amp;reserved=3D0; comments solicited.

I also noticed https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fprotect= 2.fireeye.com%2Fv1%2Furl%3Fk%3D4f41f608-10daca84-4f407cf7-ac1f6b00f158-b324= 63b77efafe6c%26q%3D1%26e%3D1b2492ea-1290-48e7-a306-9e7d51bb529a%26u%3Dhttps= %253A%252F%252Fwww.nojitter.com%252Fenterprise-networking%252Fshould-enterp= rises-avoid-or-embrace-ipv6&amp;data=3D04%7C01%7CRajesh.A.Shinde%40ril.= com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd43aa26d9f%7= C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DeUcKGLf2= WSnYQMi%2FQGRcP8INOdPXdO3RgJjsbBVNzE4%3D&amp;reserved=3D0, and started to think about dropping the guy a note. Then I decided not to;= he repeats a lot of ages-old marketing hype that doesn't necessarily corre= spond to anything I think is real, and never thought made sense. We have ov= er 1000 root servers worldwide, all of which respond to IPv6 addresses if the network supports the technol= ogy (sometimes an issue) - so what's the case for an India-specific IPv6-on= ly root server? India only has 43 IPv6-capable servers (cf https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fprotect= 2.fireeye.com%2Fv1%2Furl%3Fk%3D9581ccb3-ca1af03f-9580464c-ac1f6b00f158-8f88= 2a6dd6a636bc%26q%3D1%26e%3D1b2492ea-1290-48e7-a306-9e7d51bb529a%26u%3Dhttps= %253A%252F%252Froot-servers.org%252F&amp;data=3D04%7C01%7CRajesh.A.Shin= de%40ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd43= aa26d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata= =3DJUrOGg%2FgZDmEjZWYRfO64aLYTTKm4tpGKDLFdr1FZwA%3D&amp;reserved=3D0)...

But it did make me think about enterprise management, how many misconceptio= ns they have, and how much money they're spending that IPv6 deployment woul= d free up. I'm not sure what to do with that. I'd like to believe that we c= an be part of the solution to whatever we decide the actual problem is. Your opinions would be helpful - an "= ;IPv6 marketing hype dispelled" draft, perhaps? Or "Native IPv6 i= n enterprise deployment"? An important part of that is to note that up= stream ISPs frequently have IPv6 deployed, but enterprise customers are not using it, even though actually turning it on is not all = that difficult or time-consuming, and Jen spoke at IETF 108 about turning I= Pv4 off. So - how do we encourage enterprise deployment and adoption? I sho= uld think part of that has to do with the public-facing services - mail and web. Part of that has been figu= ring out how to use IPv6 to talk with someone that desperately wants to cli= ng to expensive IPv4 internally, but I want to promote native deployment. M= aybe, and here I take a page out of Mythic Beast's book, charge more for IPv4 service?

 


"Confidentiality Warning: This = message and any attachments are intended only for the use of the intended r= ecipient(s), are confidential and may be privileged. If you are not the int= ended recipient, you are hereby notified that any review, re-transmission, = conversion to hard copy, copying, circulation or other use of this message = and any attachments is strictly prohibited. If you are not the intended rec= ipient, please notify the sender immediately by return email and delete thi= s message and any attachments from your system.

Virus Warning:= Although the company has taken reasonable precautions to ensure n= o viruses are present in this email. The company cannot accept responsibili= ty for any loss or damage arising from the use of this email or attachment.= "

--_000_BM1PR0101MB15860BF10BC525D99ACFCE6DB9130BM1PR0101MB1586_-- From nobody Sun Nov 1 22:15:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD443A0DEB for ; Sun, 1 Nov 2020 22:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f34Ql-C2it5F for ; Sun, 1 Nov 2020 22:15:30 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408463A0DEA for ; Sun, 1 Nov 2020 22:15:30 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id o129so10190437pfb.1 for ; Sun, 01 Nov 2020 22:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KFszSSTZgka1nKV4WgGSsC8v8+rcSboSWW8NlxydAjc=; b=EuvSLubO7mwRaUGkE0gmpNWd+d/1y8taZisKVexCydTP+fjw/jzKFPiqCEPsXVAXtN VIdbbave1MUoZl2/DRu+H4W3enK/457EnsqYZlAvTHFLgzz9FqheK0JS1cflZB5PQPmT +jEFedUTJeEWm2OjISTwh5gf/1LQu9fQaeOsUI1OVFE2GLpN6S67r+gI4CPJIwIc3xwO ZJqghd8GBA7QMG76ggQCHOrDJJpRSPQJDeoGL3SszL0DFVQpv0qF0iElibWtFSIzyLMD YWxdZ5saXijbSX+dh30eFQdky6h0Fm8DJX/hK+ieHHz521BDgoZhJjtl8DePY6TQph8s Q8uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KFszSSTZgka1nKV4WgGSsC8v8+rcSboSWW8NlxydAjc=; b=nvMOOLgFYPyr5graDCOm4nAj72ISKtL5og50lEhTA4Ioc9iWlFqbWSi1bUtPviMrV4 s9JJjAdNO4iJ1hTklZEqTSIUFz9nBXVXjZhEska6K50gVMDVS/pSjxqcz6bIgqoESYNb vbQxu4R/8rbgfYBjXi/f/0jrS08iA91oZTxZcPSDMfs+pqzKgkCJYV4zdVum6Qo+XKCM OkUOnCTjpE7UVr58Jd1T+lPoa/RhTvNImhVl/pTXLi+Xy1P+fiCDJLKTd1nXWGxQhQTU oNCI9iBbnWgsvBuOEniQNi0rRFUrJOwcm50CHGOZUZY5/ALlb579TicYvW+enCxfWUCo Z5rA== X-Gm-Message-State: AOAM532OXvjwVjOC3i2MA3xuGutGtQyslI3d8RNBC0HpNNgPnUCc7V0X kJWBZ8F6kKXy27pyysQCWenf8buZFUgV+Q== X-Google-Smtp-Source: ABdhPJwoCkTeZAy+dA4NbOz3bi48sm/ixifio+nG8oQs47rtkJD6Q14A5dkBmBitk2qA0wdd3exEWQ== X-Received: by 2002:a62:29c4:0:b029:18a:9f3a:3c41 with SMTP id p187-20020a6229c40000b029018a9f3a3c41mr10776455pfp.50.1604297729615; Sun, 01 Nov 2020 22:15:29 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id p19sm12419678pfn.204.2020.11.01.22.15.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 22:15:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) From: Fred Baker In-Reply-To: Date: Sun, 1 Nov 2020 22:15:27 -0800 Cc: IPv6 Operations , Warren Kumari , Ramesh R Chandra , Ron Bonica Content-Transfer-Encoding: quoted-printable Message-Id: <3E7B0752-839F-4FA0-9F4D-276CE43AC4A5@gmail.com> References: <461B659C-FC97-4C1C-A78C-D7C05297D74C@gmail.com> To: Rajesh A Shinde X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: Re: [v6ops] [External]Developing v6ops agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 06:15:34 -0000 Thanks. Looking forward to your remarks. > On Nov 1, 2020, at 8:17 AM, Rajesh A Shinde = wrote: >=20 > Thanks Fred for sharing the v6ops agenda. > =20 > We will definitely come out with paper on "lessons the IETF should = learn from operational experience" and "any suggestions on how to boost = enterprise deployment?". This would be helpful for all including = competition.=20 > =20 > Thanks & Regards, > =20 > Rajesh A Shinde > 8452848048 > =20 > =20 > =20 > From: Fred Baker =20 > Sent: 01 November 2020 11:31 > To: IPv6 Operations > Cc: Rajesh A Shinde ; Warren Kumari = ; Ramesh R Chandra ; Ron = Bonica > Subject: [External]Developing v6ops agenda > =20 > The e-mail below is from an external source. Please do not open = attachments or click links from an unknown or suspicious origin. >=20 > Ron and I are developing the agenda for IETF 109. I'm forwarding you = an edited version of the note I sent him and the authors of current = work. An important file, attached, is what I call the "raw agenda data"; = it all derives from the data tracker, but rearranged in a way that makes = sense to me. One of the important points is drafts that have been = "updated"; that's a time reference, and refers to the end of IETF 108. = It also contains pointers to mailing list commentary, the draft, a diff = against the next older version if any, and the relevant data tracker = page. >=20 > As I see it, most of our drafts need an update, and I would encourage = the authors to do so. The new HBH draft has next to no IETF commentary, = so my inference is that it's not something the operators are interested = in - at least not yet. draft-vf-v6ops-ipv6-deployment has a few comments = from the list, which I would encourage the authors to review and update = the draft in response to. In the "raw agenda data" file (attached), = you'll find a link to all discussion of the drafts on any IETF list. >=20 > Ramesh Chandra will give a talk on Reliance JIO's deployment = experience. (For those unfamiliar with Reliance, = seehttps://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fsta= ts.labs.apnic.net%2Fipv6%2FAS55836%3Fc%3DIN%26p%3D1%26v%3D1%26w%3D30%26x%3= D1&data=3D04%7C01%7CRajesh.A.Shinde%40ril.com%7Ce533ecf2bba646dee2a508= d87e2bc830%7Cfe1d95a94ce141a58eab6dd43aa26d9f%7C0%7C0%7C637398073794874479= %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha= WwiLCJXVCI6Mn0%3D%7C1000&sdata=3D881kZ2S1ngacbd2l49VKblLWBYMYUlqjmwpfy= 8E2sk0%3D&reserved=3D0; there are five Indian ISPs that rank highly = in observed IPv6 traffic, and rather a number that are in the "me too" = state.) I have asked him for "lessons the IETF should learn from = operational experience" and "any suggestions on how to boost enterprise = deployment?". Our proposed agenda is at = https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fproceedings%2F109%2Fagenda%2Fagenda-109-v6ops-00&data=3D04%7C= 01%7CRajesh.A.Shinde%40ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95= a94ce141a58eab6dd43aa26d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbG= Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C1000&sdata=3DDgNSdF%2FE9Bjk84vcNsbZ1og7yvnbNUjVECCX%2FaQf4Lc%3D&r= eserved=3D0; comments solicited. >=20 > I also noticed = https://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fprotec= t2.fireeye.com%2Fv1%2Furl%3Fk%3D4f41f608-10daca84-4f407cf7-ac1f6b00f158-b3= 2463b77efafe6c%26q%3D1%26e%3D1b2492ea-1290-48e7-a306-9e7d51bb529a%26u%3Dht= tps%253A%252F%252Fwww.nojitter.com%252Fenterprise-networking%252Fshould-en= terprises-avoid-or-embrace-ipv6&data=3D04%7C01%7CRajesh.A.Shinde%40ril= .com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6dd43aa26d9f= %7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DeUcKGLf2= WSnYQMi%2FQGRcP8INOdPXdO3RgJjsbBVNzE4%3D&reserved=3D0, and started = to think about dropping the guy a note. Then I decided not to; he = repeats a lot of ages-old marketing hype that doesn't necessarily = correspond to anything I think is real, and never thought made sense. We = have over 1000 root servers worldwide, all of which respond to IPv6 = addresses if the network supports the technology (sometimes an issue) - = so what's the case for an India-specific IPv6-only root server? India = only has 43 IPv6-capable servers = (cfhttps://ind01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpro= tect2.fireeye.com%2Fv1%2Furl%3Fk%3D9581ccb3-ca1af03f-9580464c-ac1f6b00f158= -8f882a6dd6a636bc%26q%3D1%26e%3D1b2492ea-1290-48e7-a306-9e7d51bb529a%26u%3= Dhttps%253A%252F%252Froot-servers.org%252F&data=3D04%7C01%7CRajesh.A.S= hinde%40ril.com%7Ce533ecf2bba646dee2a508d87e2bc830%7Cfe1d95a94ce141a58eab6= dd43aa26d9f%7C0%7C0%7C637398073794874479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= =3DJUrOGg%2FgZDmEjZWYRfO64aLYTTKm4tpGKDLFdr1FZwA%3D&reserved=3D0)... >=20 > But it did make me think about enterprise management, how many = misconceptions they have, and how much money they're spending that IPv6 = deployment would free up. I'm not sure what to do with that. I'd like to = believe that we can be part of the solution to whatever we decide the = actual problem is. Your opinions would be helpful - an "IPv6 marketing = hype dispelled" draft, perhaps? Or "Native IPv6 in enterprise = deployment"? An important part of that is to note that upstream ISPs = frequently have IPv6 deployed, but enterprise customers are not using = it, even though actually turning it on is not all that difficult or = time-consuming, and Jen spoke at IETF 108 about turning IPv4 off. So - = how do we encourage enterprise deployment and adoption? I should think = part of that has to do with the public-facing services - mail and web. = Part of that has been figuring out how to use IPv6 to talk with someone = that desperately wants to cling to expensive IPv4 internally, but I want = to promote native deployment. Maybe, and here I take a page out of = Mythic Beast's book, charge more for IPv4 service?=20 >=20 > =20 >=20 >=20 > "Confidentiality Warning: This message and any attachments are = intended only for the use of the intended recipient(s), are confidential = and may be privileged. If you are not the intended recipient, you are = hereby notified that any review, re-transmission, conversion to hard = copy, copying, circulation or other use of this message and any = attachments is strictly prohibited. If you are not the intended = recipient, please notify the sender immediately by return email and = delete this message and any attachments from your system. >=20 > Virus Warning: Although the company has taken reasonable precautions = to ensure no viruses are present in this email. The company cannot = accept responsibility for any loss or damage arising from the use of = this email or attachment." >=20 From nobody Sun Nov 1 22:19:53 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7233A0DEB for ; Sun, 1 Nov 2020 22:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynvZ9NS3h4h6 for ; Sun, 1 Nov 2020 22:19:50 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91913A0DEA for ; Sun, 1 Nov 2020 22:19:49 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id i26so9883564pgl.5 for ; Sun, 01 Nov 2020 22:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=dlG+uOEbBUly4XfgQctjso1+6noEvn8fb1Ak8rxI7lc=; b=NwVftvkNXtPMcVIlgHSU65r1ske8cOCdbciDTt41nSbe/QExZnc3PjzIyXIs9V2ODo owMwm4R3U2gm/Z9fE/S9rJA3kTp+x0NUYa/Qz7UP7tdjx/FuVdAqhoufqvP2QsB2Du+w tlKAr1YCze8W3mK+Ol/NxWrPQa1k/Acz7doaGmFxKAP2tJGdBPIQ4KG7FGnoat1bdwpI sVeH2Iv1zE3F9p7Hz0lglNMw5knQQPDLlPZT8Jfo6DrIt2J7EXvMJSny3p2IwFBaPSro ArAlAq7bM/Ka8he6D0TZ6Sog5Z+tdDt0k0yxtImk0bU1LQ2QOXRQ24/u3mbWsTWnUr0a /aaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=dlG+uOEbBUly4XfgQctjso1+6noEvn8fb1Ak8rxI7lc=; b=B4C3yEd87/T8HTZTAfWN1Ct/k+0MjcByyQX2D6LRphAfMoufbHdUnFGqaznSHvJkHk pDC1ePn6s1J0hRp8+Xi84tl2RB0fcVq7w3QVP6fB+xB3WHEe/tyFwUs3b7ruvuku9Ah7 k9ZD+89B59X+KIa1B+KzQ83KrVFr80duMs1MomsN838QqDrvervW+f1bvG6oaK70Csj2 uWay6dVahKLQbur8OlKbsld+BgGI/t8jZbFsfni3JXIqITqe9R5YMf1qG0nlq3UjXQxP qo7BVhrteuvEq5KF3N+UjnEedsES1Jeg5kQMmkJ1A6XGDCNaQqFAKVYYvOhvRi6a+BbT vGYA== X-Gm-Message-State: AOAM533GP5oMXLKKQQ2brxA696WONHl0D1fzd3LsVVFHpmaRbmIzebyo Fewa7+Svk5j4O3bLECLBCFx9HPX/h8wkxA== X-Google-Smtp-Source: ABdhPJwhM3Y+UB7/Q105HWqP9XEUGvsB+9TO4IasbbNoqUa7dmHhO6aiYWkc6396vnK01W1jCLmwBQ== X-Received: by 2002:a65:684d:: with SMTP id q13mr12339791pgt.372.1604297989190; Sun, 01 Nov 2020 22:19:49 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id n125sm6937295pfn.127.2020.11.01.22.19.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 22:19:48 -0800 (PST) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_0426C309-AFD0-4D62-8D39-97FE0987F117" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Message-Id: <174917AE-64CF-46EF-98DB-22F201FF02BC@gmail.com> References: <160348774476.5087.14120480502097534270@ietfa.amsl.com> To: IPv6 Operations , Ramesh R Chandra , Rajesh A Shinde Date: Sun, 1 Nov 2020 22:19:47 -0800 X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: [v6ops] Fwd: v6ops - Requested session has been scheduled for IETF 109 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 06:19:52 -0000 --Apple-Mail=_0426C309-AFD0-4D62-8D39-97FE0987F117 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI. > Begin forwarded message: > > From: "\"IETF Secretariat\"" > Subject: v6ops - Requested session has been scheduled for IETF 109 > Date: October 23, 2020 at 2:15:44 PM PDT > To: , > Cc: v6ops@ietf.org, warren@kumari.net > > Dear Fred Baker, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > > v6ops Session 1 (2:00 requested) > Thursday, 19 November 2020, Session III 1600-1800 > Room Name: Room 4 size: 504 > --------------------------------------------- > > > iCalendar: https://datatracker.ietf.org/meeting/109/sessions/v6ops.ics > > Request Information: > > > --------------------------------------------------------- > Working Group Name: IPv6 Operations > Area Name: Operations and Management Area > Session Requester: Fred Baker > > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 100 > Conflicts to Avoid: > Chair Conflict: spring lsr 6man intarea idr > > Key Participant Conflict: rtgwg tsvarea panrg grow tsvwg > > > > > > People who must be present: > Fred Baker > Ron Bonica > Warren "Ace" Kumari > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > --Apple-Mail=_0426C309-AFD0-4D62-8D39-97FE0987F117 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI. 

Begin forwarded = message:

From: = "\"IETF Secretariat\"" <agenda@ietf.org>
Subject: = v6ops - Requested = session has been scheduled for IETF 109
Date: = October 23, 2020 at 2:15:44 PM = PDT
To: = <fredbaker.ietf@gmail.com>, <v6ops-chairs@ietf.org>
Cc: v6ops@ietf.org, warren@kumari.net

Dear Fred Baker,

The session(s) that you have requested have = been scheduled.
Below is the scheduled session information = followed by
the original request.


   v6ops Session 1 (2:00 = requested)
   Thursday, 19 November 2020, = Session III 1600-1800
   Room Name: Room 4 = size: 504
=    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/109/sessions/v6ops.ics=

Request Information:


---------------------------------------------------------
Working Group Name: IPv6 Operations
Area Name: = Operations and Management Area
Session Requester: Fred = Baker


Number of Sessions: = 1
Length of Session(s):  2 Hours
Number = of Attendees: 100
Conflicts to Avoid:
= Chair Conflict: spring lsr 6man intarea idr

= Key Participant Conflict: rtgwg tsvarea panrg grow tsvwg




People who must be present:
 Fred = Baker
 Ron Bonica
 Warren = &quot;Ace&quot; Kumari

Resources = Requested:

Special Requests:

---------------------------------------------------------



= --Apple-Mail=_0426C309-AFD0-4D62-8D39-97FE0987F117-- From nobody Sun Nov 1 22:29:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B513A0DEF for ; Sun, 1 Nov 2020 22:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibl1p5IFKL8E for ; Sun, 1 Nov 2020 22:28:57 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8923A0DEE for ; Sun, 1 Nov 2020 22:28:57 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id w65so10215885pfd.3 for ; Sun, 01 Nov 2020 22:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=clMyG4Cnr4+Q2XE/DEnpVBxgkXgLHyeBmGbgwklobXM=; b=o4PBvT92ldB6zrAluhETu6tOpoZqzNuEutkSenDoLrSZI6p8yYYUtWvPuTiECalCE4 VZdgUBc24LWNXkZ5BvmWa88rjPLjiiOfTOwXKxj7lqWnpbQoLoobr1yzWMuTKLDj5srJ KooJprQiqH8HV/756ZEoLvSYOJyknDqZP4GQOUBLS2HLbhb2c+0QynFMfPWEdc2TxzUU 3lwgkvpUC/mMTMCFTmGHcT5CvfD4VsHncZqa+/7QRgPfLFMrEaQQexK74zkUcSOADIEV LXext+vQEtNAlS2fr5QXJLuoVwpJ4iOEqRidVUu6b5glJOx1Xz/UF6l+l/JX43O6vQ0H QvNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=clMyG4Cnr4+Q2XE/DEnpVBxgkXgLHyeBmGbgwklobXM=; b=DvyrvFzvHTFf482c7JnxB/78dAeeA+VcfchFpsyWIoaVYkxxQz2jDTK6NdUrNl5IEx OW2LspHroFfI5oI6EqpzHEN0k+MvmW/E/wWV8MzzKGHWCfNG82jchex6KwxH94RMlzXc KGZcZChi499ecITl+CyOmAJuVkKn1+1P//vBicVRb0w5AQ5hbs3xfzbBqMvsNMFhO9Bo ipgz2RE9aLhID3lYeXGwwxewYc1gXF4s11fFWMQ/+mUom9m43ICNQFFjyDJX7GKE1NfH nfXPeqGzIiC73NkwoC7WmoBtEvhUcPjyMwfujv1HRqTw7BP0W2D1KphgvZF8/Rd2UoHc rrpg== X-Gm-Message-State: AOAM5323YqCD9n5Sjedoy7tn6vnbTg87KgCv/zI1qlojl4uwVMwGx8iP NVNR/AsDlTumjE5BsTTjZbRa8ILT3BUvEg== X-Google-Smtp-Source: ABdhPJwMZjgMEFTtpvRusXZ9O4aS6F5eTlylXZUNhX17J8433ThHHKAop8B/8sjsHrpRfs2uQzQvLQ== X-Received: by 2002:a62:6883:0:b029:163:ee70:1e59 with SMTP id d125-20020a6268830000b0290163ee701e59mr20320989pfc.5.1604298537076; Sun, 01 Nov 2020 22:28:57 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id b67sm12609041pfa.151.2020.11.01.22.28.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 22:28:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) From: Fred Baker In-Reply-To: Date: Sun, 1 Nov 2020 22:28:55 -0800 Cc: Warren Kumari , IPv6 Operations , Fernando Gont Content-Transfer-Encoding: quoted-printable Message-Id: <8777D157-7721-45B5-ADAE-483E340EDF6D@gmail.com> References: <46512217-610D-4CD4-A3F4-D7589D537A54@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: Re: [v6ops] Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 06:28:59 -0000 > On Oct 22, 2020, at 1:28 PM, Fernando Gont = wrote: >=20 >> If the IESG doesn't want this published in it's current form I would >> prefer it was sent back to the wg for a respin. >=20 > A respin for what? Let me echo Fernando's question. Warren (and the IESG) are essentially = asking for a respin that can be carried out by the RFC Editor, which is = a pretty minor change. I'm willing enough to take this back to the = working group, do the respin, and resubmit, which I suspect Alice/Sandy/ = et al might prefer. But the question is - is there anything that needs = to be touched besides the issues raised in the ballot = (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ballot/= )? What specifically do you want edited, and in what way? I would kind of hope that if you had a major issue, you might have = raised it since November 2019.= From nobody Sun Nov 1 22:35:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8098E3A0DFA for ; Sun, 1 Nov 2020 22:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGLjxREBijtW for ; Sun, 1 Nov 2020 22:35:05 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382143A0DEF for ; Sun, 1 Nov 2020 22:35:05 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id c20so10212504pfr.8 for ; Sun, 01 Nov 2020 22:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXBscXVaxsJlnat0JK8lq5+EjeYEWytYUoGD5rfH/sE=; b=CjzbXiq9Lp4BaxxPEMJNDK3kZUHOcfaUg8wjZlAw+uqI21rvhR/k2VUrBdvrdDTWvY GompQ+WYR58xgN/mrtlzbP5il6tmwisjiXg29Sr+CDLEbdAfSjw9jotcuhixeDts7qd5 jdKrqoBw6aMHosquKScYTw4LAN/FT/msSd4Od0DP9SkCz64qrKFDXFm7hpfVKRtmMIaG DJwsvfmzGplL6DwbIvlBBlZ1j2rKAyx6AYjvlKgi7UJaml+9PXqJgk+TxnTGezDdT+EV QnctJX01eD4TGJ6OzvMIWiExKWWKEECdVrbYo1YCl2tf8CI971m8iH36eHIsX7stfusN e3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXBscXVaxsJlnat0JK8lq5+EjeYEWytYUoGD5rfH/sE=; b=shFHuWklqf7aYQmpNLSR13AbmhUtbFpvCOQHexzJCXLqqdi2TPqCSgWLKk3smjL/+L EllmJEKPrCcEuseUmLYJkhIXmEKAmEzE+tmMNjssbh9HxqT2MEsJRvZgknSU7nqBP8dk +JSo3M8AVLwXRDIql+mKDHHvJ2dq/GGwVzWIYvB4ZSU4drAk09LkmIAmwKTNF226z3Ti WkCzH+JQvg0f9u/SE0oo5vvmWahs+Owt1k4hpIx7YFWazD2SgdnbM2IqckK11M3DEwKB VjRhcYrLIOBDrP6myfnsg49OwOlTyA2+kjHGLgEd/Dt4xRqi6Rfw79KlqBmGO8gvVKbj qFLw== X-Gm-Message-State: AOAM531r9LOFMBD8N+RD5iP86yRyor9XV8LAbbf6W8H/kK4Qk9DM+9sS xMR+l2AQbxcwigyJt6QJHTo= X-Google-Smtp-Source: ABdhPJwO+ko73pPDSCs26xo6n0kCASuX31Zod+XSprnqlVe9nCWTX0N421VHb/5GLf1meDQEy3LPsw== X-Received: by 2002:a17:90a:2fc5:: with SMTP id n5mr10152078pjm.174.1604298904628; Sun, 01 Nov 2020 22:35:04 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id kx6sm9614636pjb.46.2020.11.01.22.35.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 22:35:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) From: Fred Baker In-Reply-To: Date: Sun, 1 Nov 2020 22:35:02 -0800 Cc: Gyan Mishra , Greg Mirsky , Jeff Tantsura , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <49AEE43E-3C39-4B85-AEB7-321BFF5ABBC6@gmail.com> References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> To: Mark Smith X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 06:35:07 -0000 > On Oct 29, 2020, at 1:42 AM, Mark Smith = wrote: >=20 > I've thought that the use of Anycast would increase, and have thought = that it would be useful to have a specially designated anycast prefix. = It has also occurred to me that anycast has some of the properties of = unicast as well as some of the properties of multicast, so could be seen = to fit in between unicast and multicast (1:1 -> 1:Any -> 1:Many) That's a reasonable description of anycast as deployed. My question in that would be exactly what you might want to change. We = have some pretty widespread use of anycast today = (https://www.iana.org/domains/root/servers https://root-servers.org), = and to my knowledge it seems to work just fine. If we're going to = replace existing anycast with some sort of anycast prefix, the first big = change we have to make is in BGP; it can advertise a unicast prefix or = address, but can't, today at least, advertise an anycast prefix.Then we = have to tell hosts that they can send traffic to such addresses and = should. I think we should have a good reason if we're going to boil the = ocean.= From nobody Mon Nov 2 00:16:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585723A09D6; Mon, 2 Nov 2020 00:16:23 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS-CJdeA6ngh; Mon, 2 Nov 2020 00:16:19 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2E83A0957; Mon, 2 Nov 2020 00:16:18 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id h5so7009656vsp.3; Mon, 02 Nov 2020 00:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MdNhwYiCflLXMO+Sjoy4DbwnlrD9qfbkD58XwH9IzEo=; b=i+ms5ibQu6EyLaerWUxjM+Fo45Hb8VB3cFXJH+SQBznVqk0aTP+Gg7Wz/8G17qadH/ RwKBnOdgKaw+qX6CNQh00iWYbIc7XL9fKk/JSDuLilWEym/3oT9sGyVUKSxxaR3yKXrK JvqJLjboWRXkeqlaWXDIiTu+CmDSZZ282Cy139vegP3lcNnQerlj1KPwh2pCTKsjXd6O aBFm9dnoOLMKzI33ulLK5Co1m0sNL329jJqTMMxxZmM3SCMy3yp7tX6bFmzzLj5830D+ j6UNi9LEsgXpJNAxptv4JS0m3KZJBhDAdyM3H0EMIEBh34E9i4M+3To0sNRJm0k2dFgz DeLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MdNhwYiCflLXMO+Sjoy4DbwnlrD9qfbkD58XwH9IzEo=; b=gTnuLj7RB4QZZ/qKc9F89HadxugfDeaRrkOYrfOwW7rQ9Uu2Tk6shGifu/WbPKrl+V RGai9hsJ36PF++hZNKLPgywlZTt1g1MAscDF9gCLw6Oqw+EBOTda/VC9g+NBATHl5dd3 qeYb+kz3uWIvdwbbpkxZ5YXjYjFE+Bv5DxFZSdlpjFaSXG7JGwYIbM7JQjaSBGlxe8jm RNvlRAKbrWR097uaaOJ/2wOYgvDYyQ/S6lt/NtvYI3DBVbawGFF7W+qo+gWwmeMZ8lJw 7s9Up7YhD999tSXNdH7hMmHJX61WXbqU5ppEnBYIcTdSVo7qbO6TjsjXeHbvr/+o89kQ KGog== X-Gm-Message-State: AOAM531pf+/mqtFfNQM5SBGOmx0Ns7vUvhq6Bp5wrf4lRdVdq4VK83Vk a6hnjm9uu9PelCslUzVNMwg70eiGab/fLosVyFV3LgSExrmtYWoe X-Google-Smtp-Source: ABdhPJx1g0861yraHODT7pWQFfuGKkNVq0NF/X3mxWlz2PETB5xNRyDETZjGEAlz1Uks5lOiaTkxTPy4IJ+MVI4hmFY= X-Received: by 2002:a67:e9c5:: with SMTP id q5mr3539944vso.5.1604304977524; Mon, 02 Nov 2020 00:16:17 -0800 (PST) MIME-Version: 1.0 References: <160409741440.1448.13198358900339210436@ietfa.amsl.com> In-Reply-To: From: Gyan Mishra Date: Mon, 2 Nov 2020 03:10:12 -0500 Message-ID: To: 6MAN <6man@ietf.org>, IPv6 Operations , Dmytro Shytyi , Alexandre Petrescu , Naveen Kottapalli , Gyan Mishra , Dusan Mudric , Ole Troan , Bob Hinden Content-Type: multipart/alternative; boundary="0000000000004bf8d605b31b5cd5" Archived-At: Subject: [v6ops] Fwd: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 08:16:23 -0000 --0000000000004bf8d605b31b5cd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear 6MAN, This draft addresses a solution to change SLAAC's historical fixed 64 bit boundary to variable PIO so that VLSM masking is supported just as it is today with static & DHCPv6 & DHCPv6 PD. This ensures that parity is maintained between the three address deployment mechanisms that exist today with IPv6. This draft as well addresses the MAJOR gap that exists today with lack of parity and the historical framework of the impact of this lack of partify that has existed since the IPv6 specification was published 20+ years ago. We have a problem statement draft below that is referenced in this draft that goes over in detail the problem that exists today with the SLAAC fixed 64 bit boundary and ramifications and reasons for the necessary change to SLAAC to eliminate the historical 64 bit fixed boundary. As far as the solution goes one of our authors Dmytryo has been able to successfully test on Linux kernel signaling PIO flag and maintaining backwards compatibility that with the flag set the prefix length can be increased to 127 bits and the station-id generated via either RFC 4941 or RFC 7217. Modified EUI64 is not an available option for variable slaac as due to MAC dependency the IID is increased to 64bit. ! SLAAC Problem Statement https://tools.ietf.org/html/draft-mishra-v6ops-variable-slaac-problem-stmt-= 01 Bob & Ole, Please review. Based on the feedback received from 6MAN, I would to request a time slot on IETF 109. Kind Regards Gyan ---------- Forwarded message --------- From: Mishra, Gyan S Date: Fri, Oct 30, 2020 at 6:50 PM Subject: Fwd: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt To: Hayabusanew ---------- Forwarded message --------- From: Date: Fri, Oct 30, 2020 at 6:36 PM Subject: [E] New Version Notification for draft-mishra-6man-variable-slaac-01.txt To: Dmytro Shytyi , Alexandre Petrescu < alexandre.petrescu@cea.fr>, Naveen Kottapalli , Gyan Mishra , Dusan Mudric , Alexandre Petrescu A new version of I-D, draft-mishra-6man-variable-slaac-01.txt has been successfully submitted by Gyan Mishra and posted to the IETF repository. Name: draft-mishra-6man-variable-slaac Revision: 01 Title: SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) Document date: 2020-10-30 Group: Individual Submission Pages: 33 URL: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archive= _id_draft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01.txt&d=3DDwICaQ&c=3DudBTRv= FvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-R= fNVLML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DtM5EVDjoyI9t= NSKrsyLcrBNPCR0ZSrdGMQbB1ma8FwY&e=3D Status: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dmishra-2D6man-2Dvariable-2Dslaac_&d=3DDwICaQ&c=3DudBTRvFvXC5Dh= qg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML2= 8ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DigBIeoMkz1AGxGrUPJr= eLee5t2-3B4dzdHgYb7Gv2LI&e=3D Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_html_draft-2Dmishra-2D6man-2Dvariable-2Dslaac&d=3DDwICaQ&c=3DudBTRvFvX= C5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNV= LML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DwKpc7lhDGYVktyD= -CF5EtH1aqYAYHFwTV3sjoBE9pcU&e=3D Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhq= g7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28= ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DUWiqt_BgJ6xpv0JVlvJf= 53yAMQ1XzVuNb7wK-TIvJQA&e=3D Diff: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff= -3Furl2-3Ddraft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01&d=3DDwICaQ&c=3DudBT= RvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D= -RfNVLML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3D6fGNxKPLE-= TIAgDExR1Tdu-3mQCqTTF1JfNmnsGWE6o&e=3D Abstract: This draft proposes the use of arbitrary length prefixes in PIO for SLAAC. A prefix of length 65 in PIO, for example, would be permitted to form an addresses whose interface identifier length is length 63, which allows several benefits. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. 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. The IETF Secretariat --=20 *Gyan Mishra* *Network Solutions A**rchitect & SME* *Data Center Planning | Common Core | Development & Engineering Lab ServicesGlobal Technology Services | ITNUC* *O 240 970-6287M 301 502-134713101 Columbia Pike Rm 304-D*Silver Spring, MD 20904 *IETF & ISOC Member since 2015* https://www.ietf.org/ https://www.internetsociety.org/ --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000004bf8d605b31b5cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear 6MAN,=C2=A0

This draft addresses a= solution to change SLAAC's historical fixed 64 bit boundary to variabl= e PIO so that VLSM masking is supported just as it is today with static &am= p; DHCPv6 & DHCPv6 PD.=C2=A0=C2=A0

This ensure= s that parity is maintained between the three address deployment mechanisms= that exist today with IPv6.=C2=A0 This draft as well addresses the MAJOR g= ap that exists today with lack of parity and the historical framework of th= e impact of this lack of partify that=C2=A0has existed since the IPv6 speci= fication was published 20+ years ago.=C2=A0

We hav= e a problem statement draft below that is referenced in this draft that goe= s over in detail the problem that exists today with the SLAAC fixed=C2=A064= bit boundary and ramifications and reasons for the necessary change to SLA= AC to eliminate the historical 64 bit fixed boundary.=C2=A0

<= /div>
As far as the solution goes one of our authors Dmytryo=C2=A0has b= een able to successfully test on Linux kernel signaling PIO flag and mainta= ining backwards compatibility that with the flag set the prefix length can = be increased to 127 bits and the station-id generated via either RFC 4941 o= r RFC 7217.=C2=A0 Modified EUI64 is not an available option for variable sl= aac as due to MAC dependency the IID is increased to 64bit.
Bob & Ole,

Please review.=C2= =A0 Based on the feedback received from 6MAN, I would to request a time slo= t on IETF 109.

Kind Regards

Gyan

---------- Forwarded message ---------
From: Mishra, Gyan S <gyan.s.mishra@verizon.com>= ;
Date: Fri, Oct 30, 2020 at 6:50 PM
Subject: Fwd: [E] New Ver= sion Notification for draft-mishra-6man-variable-slaac-01.txt
To: Hayabu= sanew <hayabusagsm@gmail.com>




---------- Forwarded message ---------
Fr= om: <internet-drafts@ietf.org>
Date: Fri, Oct 30,= 2020 at 6:36 PM
Subject: [E] New Version Notification for draft-mishra-= 6man-variable-slaac-01.txt
To: Dmytro Shytyi <dmytro.shytyi@sfr.com>, Alexandr= e Petrescu <alexandre.petrescu@cea.fr>, Naveen Kottapalli <nkottapalli@benu.net>, Gy= an Mishra <gyan.s.mishra@verizon.com>, Dusan Mudric <dmudric@ciena.com>, Alexandre Petr= escu <Ale= xandre.Petrescu@cea.fr>



A new version of I-D, draft-mishra-6man-variable-slaac-01.txt
has been successfully submitted by Gyan Mishra and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-6man-variable-sl= aac
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of arbitrary l= ength in PIO (Variable SLAAC)
Document date:=C2=A0 2020-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 33
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_a= rchive_id_draft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01.txt&d=3DDwICaQ&= amp;c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0U= Y8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2A= uZcmo&s=3DtM5EVDjoyI9tNSKrsyLcrBNPCR0ZSrdGMQbB1ma8FwY&e=3D
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc= _draft-2Dmishra-2D6man-2Dvariable-2Dslaac_&d=3DDwICaQ&c=3DudBTRvFvX= C5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-= RfNVLML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DigB= IeoMkz1AGxGrUPJreLee5t2-3B4dzdHgYb7Gv2LI&e=3D
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_ht= ml_draft-2Dmishra-2D6man-2Dvariable-2Dslaac&d=3DDwICaQ&c=3DudBTRvFv= XC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D= -RfNVLML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DwK= pc7lhDGYVktyD-CF5EtH1aqYAYHFwTV3sjoBE9pcU&e=3D
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urld= efense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dmish= ra-2D6man-2Dvariable-2Dslaac-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UH= pJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28= ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTisZc2AuZcmo&s=3DUWiqt_BgJ6xp= v0JVlvJf53yAMQ1XzVuNb7wK-TIvJQA&e=3D
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _rfcdiff-3Furl2-3Ddraft-2Dmishra-2D6man-2Dvariable-2Dslaac-2D01&d=3DDwI= CaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4m= qq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DwnsNiYabLrE1DDtosohrpOVFaPE1KhLTis= Zc2AuZcmo&s=3D6fGNxKPLE-TIAgDExR1Tdu-3mQCqTTF1JfNmnsGWE6o&e=3D =

Abstract:
=C2=A0 =C2=A0This draft proposes the use of arbitrary length prefixes in PI= O for
=C2=A0 =C2=A0SLAAC.=C2=A0 A prefix of length 65 in PIO, for example, would = be permitted
=C2=A0 =C2=A0to form an addresses whose interface identifier length is leng= th 63,
=C2=A0 =C2=A0which allows several benefits.

=C2=A0 =C2=A0In the past, various IPv6 addressing models have been proposed= based
=C2=A0 =C2=A0on a subnet hierarchy embedding a 64-bit prefix.=C2=A0 The las= t remnant of
=C2=A0 =C2=A0IPv6 classful addressing is a inflexible interface identifier<= br> =C2=A0 =C2=A0boundary at /64.=C2=A0 This document proposes flexibility to t= he fixed
=C2=A0 =C2=A0position of that boundary for interface addressing.




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.

The IETF Secretariat




--


Gyan Mishra

Network Solutions Architect & SME

Data Center Planning | Common Core | Development & Engineering La= b Services
Global Technology Services | ITNUC

O 240 970-6287
M 301 502-1347
13101 Columbia Pike Rm 304= -D
Silver Spring, MD 20904


IETF=C2=A0 & ISOC Member sinc= e 2015

https://www.ietf.org/

https://www.in= ternetsociety.org/




--


Gyan Mishra

= Network Solutions Architect=C2=A0

M 301 502-1347<= br>13101 Columbia Pike=C2=A0
Silver Spring, MD

=
--0000000000004bf8d605b31b5cd5-- From nobody Mon Nov 2 00:20:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A03A0A35; Mon, 2 Nov 2020 00:20:55 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P5S1S6oSl1L; Mon, 2 Nov 2020 00:20:53 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CBD3A09E8; Mon, 2 Nov 2020 00:20:53 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id r14so2058049vsa.13; Mon, 02 Nov 2020 00:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aJ6w9469W6MfJuvR72XBpgZwluL0ztxhcxpn2EaAC0I=; b=aL4DLvTCP49l03h1qWWdCqjR3arvdvHfILF+FavyzORO99geWmyoEeYp8iqvSbEDFy +WkAOwXHF6kRI4LXqmyFRLMtzaglajLrKmYRtVky8LTqKCxpgeiY0xkp4rtLl7M4JVwG ZFG561KWCOheQUbOYLSdMuR2soKe3z21YjAG0mvj0iqQ3KiWascq0wyuVEHZyFgE8Oe/ 7smZ7bgCCvU7tbWxrDDQnfnZX84VEstjQ9j5vu9owQlRxy4JaVLqRjwupz/yDZ2IsAAw Pc1TdFJSf9KVvtelA3uX05o/SufuoTAFhHdEOo0k3Pj6HJkFFn3TrRSwDL64EBd5m1mF 46ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aJ6w9469W6MfJuvR72XBpgZwluL0ztxhcxpn2EaAC0I=; b=A9ElLmo+mRSKSILM34NHBoSlo9dFVF7Fsa8HSfXhUTso2mbCWXVT4tLthkdu6EnEuH L7pbbPWBtrRptXd/UUwfWwvPpru0/C/3BDE1bJB71QO2GfsLAvfFcRaLm4SGHKWPQtZ3 TlRuWKv3M1OYXRaFOSv198aF7m8algEQLSeKc/lCTXaghKcQDRO/lmUHU5eJg6UF9QJQ Gx2jSXnig9FHJTg+d1DWmTaMGJSwGRQkMKzbh4YYM3R33ueYfYTi3ch+d4euZzvlr2Nq 3BlShRq2e6eRe87evDOqkcxL8uEGnj3tk6uvl7tS8m6ji9+KVT7lDx54u7nMmh2GCbS/ dVjw== X-Gm-Message-State: AOAM53334hKa3IbPg8Ci24/eM7Tu8RywnEIn8Zw8i8ZcO0G1/MYNzyQh ICjQ3CR0378U0Yx3wJHbpp8cvXSPjMd4QaoJRLGWOjt42lWVcYmg X-Google-Smtp-Source: ABdhPJwbVHD8UmUWSse7RbIYK2HmFRufmtBxr0B7qHIKJPGC8OrH2ceqfxXtLWusmM0RkYHK05Txs+A8hdZ/FromUnU= X-Received: by 2002:a05:6102:342:: with SMTP id e2mr13387305vsa.60.1604305251930; Mon, 02 Nov 2020 00:20:51 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> In-Reply-To: From: Gyan Mishra Date: Mon, 2 Nov 2020 03:14:46 -0500 Message-ID: To: IPv6 Operations , 6MAN <6man@ietf.org>, Naveen Kottapalli , Alexandre Petrescu , Gyan Mishra , Dusan Mudric , Dmytro Shytyi , Ole Troan , Bob Hinden Content-Type: multipart/alternative; boundary="000000000000a715fa05b31b6cb0" Archived-At: Subject: [v6ops] Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 08:20:56 -0000 --000000000000a715fa05b31b6cb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear v6OPS, This draft addresses the problem statement to change SLAAC's historical fixed 64 bit boundary to variable PIO so that VLSM masking is supported just as it is today with static & DHCPv6 & DHCPv6 PD. This change to SLAAC to variable, ensures that parity is maintained between the three address deployment mechanisms that exist today with IPv6. This draft as well addresses the MAJOR gap that exists today with lack of parity and the historical framework of the impact of this lack of partify that has existed since the IPv6 specification was published 20+ years ago. We have a solutions draft below that is referenced in this draft that goes over in detail the solution on 6MAN. ! Variable SLAAC https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ Bob & Ole, Please review. Based on the feedback received from 6MAN, I would like to request a time slot on IETF 109. Kind Regards Gyan ---------- Forwarded message --------- From: Mishra, Gyan S Date: Fri, Oct 30, 2020 at 6:50 PM Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt To: Hayabusanew ---------- Forwarded message --------- From: Date: Fri, Oct 30, 2020 at 6:46 PM Subject: [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt To: Naveen Kottapalli , Alexandre Petrescu < alexandre.petrescu@cea.fr>, Gyan Mishra , Alexandre Petrescu , Dusan Mudric < dmudric@ciena.com>, Dmytro Shytyi A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt has been successfully submitted by Gyan Mishra and posted to the IETF repository. Name: draft-mishra-v6ops-variable-slaac-problem-stmt Revision: 01 Title: SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Statement Document date: 2020-10-30 Group: Individual Submission Pages: 12 URL: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archive= _id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D Status: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwICaQ= &c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rx= BBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr= _lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3DDw= ICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8n= n2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&= c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxB= BO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DBW= r8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D Diff: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff= -3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D Abstract: In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. 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. The IETF Secretariat --=20 *Gyan Mishra* *Network Solutions A**rchitect & SME* *Data Center Planning | Common Core | Development & Engineering Lab ServicesGlobal Technology Services | ITNUC* *O 240 970-6287M 301 502-134713101 Columbia Pike Rm 304-D*Silver Spring, MD 20904 *IETF & ISOC Member since 2015* https://www.ietf.org/ https://www.internetsociety.org/ --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a715fa05b31b6cb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 Dear v6OPS,

This draft addr= esses the problem statement to change SLAAC's historical fixed 64 bit b= oundary to variable PIO so that VLSM masking is supported just as it is tod= ay with static & DHCPv6 & DHCPv6 PD.=C2=A0=C2=A0

This change to SLAAC to variable, ensures that parity is maintained = between the three address deployment mechanisms that exist today with IPv6.= =C2=A0 This draft as well addresses the MAJOR gap that exists today with la= ck of parity and the historical framework of the impact of this lack of par= tify that=C2=A0has existed since the IPv6 specification was published 20+ y= ears ago.=C2=A0

We have a solutions draft below th= at is referenced in this draft that goes over in detail the solution on 6MA= N.

! Variable SLAAC

Bob & Ole,

Please review.=C2=A0 Based= on the feedback received from 6MAN, I would like to request a time slot on= IETF 109.

Kind Regards

G= yan



---------- Forwarded message ---------
Fro= m: Mishra, Gyan S = <gyan.s.= mishra@verizon.com>
Date: Fri, Oct 30, 2020 at 6:50 PM
= Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-= slaac-problem-stmt-01.txt
To: Hayabusanew <hayabusagsm@gmail.com>




-----= ----- Forwarded message ---------
From: <internet-drafts@ietf= .org>
Date: Fri, Oct 30, 2020 at 6:46 PM
Subject: [E] N= ew Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-= 01.txt
To: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petre= scu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petres= cu <Alexa= ndre.Petrescu@cea.fr>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.c= om>



A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt=
has been successfully submitted by Gyan Mishra and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-variable-s= laac-problem-stmt
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of arbitrary l= ength in PIO (Variable SLAAC) - A Problem Statement
Document date:=C2=A0 2020-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dhttps= -3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dpr= oblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LR= xpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZ= pKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-cXn0FCho9ZftXjO-TuT= H19Nr6MO5spHMPP0xR4&e=3D
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt= _&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625= Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc= &e=3D
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2= Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&am= p;r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB= 625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3Kwlk= tF8&e=3D
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF= 34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1Nsu= ITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e= =3D
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttp= s-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dsla= ac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ= 3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m= =3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQw7BqnqoVfmkBjFXkE= WMDk_QEIRHI-11QPkt3b1bU&e=3D

Abstract:
=C2=A0 =C2=A0In the past, various IPv6 addressing models have been proposed= based
=C2=A0 =C2=A0on a subnet hierarchy embedding a 64-bit prefix.=C2=A0 The las= t remnant of
=C2=A0 =C2=A0IPv6 classful addressing is a inflexible interface identifier<= br> =C2=A0 =C2=A0boundary at /64.=C2=A0 This document details the 64-bit bounda= ry problem
=C2=A0 =C2=A0statement.




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.

The IETF Secretariat




--


Gyan Mishra

Network Solutions Architect & SME

Data Center Planning | Common Core | Development & Engineering La= b Services
Global Technology Services | ITNUC

O 240 970-6287
M 301 502-1347
13101 Columbia Pike Rm 304= -D
Silver Spring, MD 20904


IETF=C2=A0 & ISOC Member sinc= e 2015

https://www.ietf.org/

https://www.in= ternetsociety.org/




--


Gyan Mishra

= Network Solutions Architect=C2=A0

M 301 502-1347<= br>13101 Columbia Pike=C2=A0
Silver Spring, MD

=
--000000000000a715fa05b31b6cb0-- From nobody Mon Nov 2 01:12:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40073A0B67 for ; Mon, 2 Nov 2020 01:12:44 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvARDBwiug5U for ; Mon, 2 Nov 2020 01:12:42 -0800 (PST) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E713A0B62 for ; Mon, 2 Nov 2020 01:12:42 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id 91so3746640uar.5 for ; Mon, 02 Nov 2020 01:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XsRcV0MN/RppY6aiXiU0qsXcsdFxIeTUvFBr5vM5W4E=; b=FqcNNWA6yNiMlGIUttqpziWGMQsqfbOyx1LB5K2ebjlTwTqLhURvPE6pYBKSz2ptiy kcto9LHnVH6ohCtrZKMZ6TZ2Theykf8ymXbfw7usA9gjQV+OIwaaWtDKHxunr6F/eY3A eqsZXRNbNhD2tFBRvCKz/6n2RV+qb3rMTs9dA/Yi4mRgHubProV8dbxshmk+VggaMa0/ ySygSKiSS/Bx/qlQ7/xZcxFC7pKdxLwT77KWZmkS+na62FJ20mCAC6BD4ywUJDuugM5+ zD+xgsaT5nkYEwFm8c4hXepbKkYFzilNxxAgeJNDovXEtcDKfvOA0T5DBhJbQ+Ihj/ry Cofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XsRcV0MN/RppY6aiXiU0qsXcsdFxIeTUvFBr5vM5W4E=; b=EqsLtbx3ulsTQySxT6Ij6dhyivC2pba/cv4SrcNyvgTXdXc4PKBe9kvlW1cPaJUJh0 AsNjThf636FSb5zktRNBivfSPQwvxtuSid/k4dzqQbKjHRU8pEfYkHxd70sru11bVPSz X7hpcOemYWkfJYghRVEpD9wI3Vii8ksJGUpSwTe5zMXU/CPMZLyo7q1ReLkzmEln1NP1 wT3M8e/U0caISb1UGma/Q8fZflUE3+MDQf6HHeFHQ3djuczD+4kNCbBlHW/PDggvTSqj Tv+RaSixW8cBypkHZudXCxZ55YqJJ+7AGIa/Hg9ZIzn8UO1+2GCSa0t7N5gTjS6iZB4t wfsg== X-Gm-Message-State: AOAM531TCJkk+qYVcCxxofiZKgnbrVQu+q9DTsOex1wbmnNadmVoefQW XdsEDuymL4zCqVOaOIlEfsaO5Lm641JlM5lMhmQ= X-Google-Smtp-Source: ABdhPJwr7wWAg9O1fBEW1VbyubXDdz5oY2CUQzE6FcrWsgrv22Ekx/4FeSbInk9NWCC3bpJlHfa/RXhlXCd+BwJj/EQ= X-Received: by 2002:ab0:293:: with SMTP id 19mr2173217uah.106.1604308361793; Mon, 02 Nov 2020 01:12:41 -0800 (PST) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: From: Gyan Mishra Date: Mon, 2 Nov 2020 04:12:31 -0500 Message-ID: To: Mark Smith Cc: Greg Mirsky , Jeff Tantsura , v6ops list Content-Type: multipart/alternative; boundary="00000000000003d25b05b31c2629" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 09:12:45 -0000 --00000000000003d25b05b31c2629 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 29, 2020 at 4:43 AM Mark Smith wrote: > Hi Gyan, > > On Wed, 28 Oct 2020, 09:10 Gyan Mishra, wrote: > >> Hi Mark >> >> >> >> Gyan> That is definitely an interesting idea and I think makes sense >> and viable for sure. There maybe other use cases I am thinking out loud >> maybe with BIER IPv6 MVPN and possible some other use cases. I wonder >> even for the SRv6 locator maybe having a special range outside of GUI >> allocation as it has special handling with steering. >> >> Another question related to IPv6 Anycast. IPv6 has built in anycast >> address, I believe it=E2=80=99s the last 7 bits subnet router Anycast ad= dress. >> Since any routable prefix can be Anycasted for services proximity routin= g, >> what is the real use case or functionality of the IPv6 built in Anycast >> /121 range. >> > > > There isn't really an IPv6 anycast range, IPv6 anycast addresses come out > of the unicast address space, and are only designated as anycast either b= y > announcing a "unicast" route from multiple different locations on purpose > (if it's not on purpose, it's a fault), and by configuring the host with > the anycast address to know that it is an anycast address. > > I've thought that the use of Anycast would increase, and have thought tha= t > it would be useful to have a specially designated anycast prefix. It has > also occurred to me that anycast has some of the properties of unicast as > well as some of the properties of multicast, so could be seen to fit in > between unicast and multicast (1:1 -> 1:Any -> 1:Many) > > "IPv6 Formal Anycast and Functional Anycast Addresses" > > IETF 106 presentation - > https://www.ietf.org/proceedings/106/slides/slides-106-6man-sessa-ipv6-fo= rmal-anycast-addresses-and-functional-anycast-addresses-00.pdf > > Draft - > https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-= 01 > Gyan> Thanks for the info! > > Regards, > Mark. > > > > > >> >>> Regards, >>> Mark. >>> >>> >>>> Thanks >>>> >>>> Gyan >>>> >>>> On Mon, Oct 26, 2020 at 9:22 PM Mark Smith >>>> wrote: >>>> >>>>> Hi Gyan, >>>>> >>>>> Sorry not to get back to you sooner. >>>>> >>>>> On Tue, 20 Oct 2020 at 00:26, Gyan Mishra >>>>> wrote: >>>>> > >>>>> > >>>>> > Hi Mark >>>>> > >>>>> > What ended up happening with this draft >>>>> >>>>> I let it expire, as I didn't think it would be adopted by the WG. >>>>> >>>>> There seemed to be a bit of resistance to it as people said that ULAs >>>>> could be used instead. >>>>> >>>>> The link local prefix is also required on any IPv6 interface, per >>>>> RFC4291, so there is supposed to be a link-local /64 on the loopback >>>>> interface(s) providing many addresses to which a process could be >>>>> separately bound, although a drawback of using the link-local prefix >>>>> is having to deal with scope/zone IDs (although Linux doesn't comply >>>>> with that requirement, it doesn't have a link-local address on the >>>>> loopback interface by default). >>>>> >>>>> > and was the work picked up in any other draft. >>>>> >>>>> Not as far as I'm aware. >>>>> >>>>> What is your use case? >>>>> >>>>> Regards, >>>>> Mark. >>>>> >>>>> >>>>> > >>>>> > Thanks >>>>> > >>>>> > Gyan >>>>> > >>>>> > Sent from my iPhone >>>>> >>>> -- >>>> >>>> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions A**rchitect * >>>> >>>> >>>> >>>> *M 301 502-134713101 Columbia Pike >>>> *Silver >>>> Spring, MD >>>> >>>> >>>> -- >> >> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> *Silver >> Spring, MD >> >> >> -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000003d25b05b31c2629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 29, 2020 at 4:43 AM Mark Smith <markzzzsmith@gmail.com> wrote:
Hi= Gyan,

On Wed, 28 Oct 2020, 09:10 Gyan Mishra, <hayabusagsm@gmail.com> wrote= :
Hi Mark=C2=A0

<snip>
<= div>

=C2=A0 =C2=A0 Gyan> That is definitely an interesting idea and I think= makes sense and viable for sure.=C2=A0 There maybe other use cases I am th= inking out loud maybe with BIER IPv6 =C2=A0MVPN and possible some other use= cases.=C2=A0 I wonder even for the SRv6 locator maybe having a special ran= ge outside of GUI allocation as it has special handling with steering. =C2= =A0

Another question rel= ated to IPv6 Anycast.=C2=A0 IPv6 has built in anycast address, I believe it= =E2=80=99s the last 7 bits subnet router Anycast address.=C2=A0 Since any r= outable prefix can be Anycasted for services proximity routing, =C2=A0what = is the real use case or functionality of the IPv6 built in Anycast /121 ran= ge. =C2=A0


There isn't really an IPv6 anycast range, IPv6 anycast addresses come = out of the unicast address space, and are only designated as anycast either= by announcing a "unicast" route from multiple different location= s on purpose (if it's not on purpose, it's a fault), and by configu= ring the host with the anycast address to know that it is an anycast addres= s.

I've thought that the use of Any= cast would increase, and have thought that it would be useful to have a spe= cially designated anycast prefix. It has also occurred to me that anycast h= as some of the properties of unicast as well as some of the properties of m= ulticast, so could be seen to fit in between unicast and multicast (1:1 -&g= t; 1:Any -> 1:Many)

"IPv6 Formal Anycast a= nd Functional Anycast Addresses"

=C2=A0 =C2=A0Gyan> Thanks for the info!

Re= gards,
Mark.



=C2=A0

Regards,
Mark.

=

Thanks=C2= =A0

Gyan

<= div class=3D"gmail_quote">
On Mon, Oct= 26, 2020 at 9:22 PM Mark Smith <ma= rkzzzsmith@gmail.com> wrote:
Hi Gyan,

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
> Hi Mark
>
> What ended up happening with this draft

I let it expire, as I didn't think it would be adopted by the WG.

There seemed to be a bit of resistance to it as people said that ULAs
could be used instead.

The link local prefix is also required on any IPv6 interface, per
RFC4291, so there is supposed to be a link-local /64 on the loopback
interface(s) providing many addresses to which a process could be
separately bound, although a drawback of using the link-local prefix
is having to deal with scope/zone IDs (although Linux doesn't comply with that requirement, it doesn't have a link-local address on the
loopback interface by default).

> and was the work picked up in any other draft.

Not as far as I'm aware.

What is your use case?

Regards,
Mark.


>
> Thanks
>
> Gyan
>
> Sent from my iPhone
--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
<= a href=3D"https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silv= er+Spring,+MD?entry=3Dgmail&source=3Dg" rel=3D"noreferrer" target=3D"_b= lank">Silver Spring, MD


--


Gyan Mishr= a

Network Sol= utions Archit= ect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


--
--00000000000003d25b05b31c2629-- From nobody Mon Nov 2 01:28:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EF73A0C38 for ; Mon, 2 Nov 2020 01:28:16 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waCQZu4ejPYh for ; Mon, 2 Nov 2020 01:28:14 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D29D3A0C1F for ; Mon, 2 Nov 2020 01:28:14 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id k125so2816160vka.11 for ; Mon, 02 Nov 2020 01:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gfBB2+gka1XW6jYRG3yntsZTEL/QfyxB74f8UdBd8Fo=; b=Hoo5xYNedSznRuoZw3grUNtrsywuByERY0IP3krVYnFb6cT63gjQoDIBjXDe5gAajF S6XxjYEk6eNfGgis8rJSVUsmk/r6PtbZBcCTIJbXkzcxodiUmOSkZEZZNFnltspd5C6n Gr8z5kq/49qjTDavnFX3tmalqoI9sHRer75MapU2rahVPt2CTRO60EKydWiEGolQqej/ I3l8U9DiNd8pGATwqgxBZkU/PzGBF7fEdm/9CTYwp+BvgSMCZbRvh1SEgrw96g5SN4kT pkmTRST3Q+TMnk7slfPtK5lObbFVT5BxdqEpEeAQoyeJqtwwYNNwGqPu4tf1kgj5aZPE RFhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gfBB2+gka1XW6jYRG3yntsZTEL/QfyxB74f8UdBd8Fo=; b=tyaV4Hk+ZLiVwjpcoVv2fcTYew5p64gv4gklsaQniY+x49JmAFRQ6ULLa/2qv2kS4M /jbDrjlGKw2G3gApy66mDWURWFNh6IEEkn3drLU/rF4g33AnhnIZVWgmabRDx0vRNB7H wJ72EW0BqKla26XqPiJ4y6IswXATWIHyijKGHgSX0dmlPAGvsrfXX3wSXB5ms9G2cEgW rq64/Ex56t3iGuGYYxoIFfpSMB1CDQ2cYcPsJqU0ErmOmFV1uijrNc6zeTuW1Zfb9nLo PhH3H7bJxsExqI1gOV+pei5eTA35bICG7G0bgzPMEbeA0roE/LRCBFpMr7m7mecNzEE2 hIRA== X-Gm-Message-State: AOAM532V4ILZXEFp0RLSILzNVKFfQeeGwAFPgThyKumkQJDKcUrtyZ4u /MezlEyruEYXyfhTil8tPmAADLmoUqg079LfNOQ= X-Google-Smtp-Source: ABdhPJymhOn0zoglNqt3u1lOdvsxwvrHTrtO8cZkcTqbgkOaRHLBX++8Ob5smKH7gcaWqXYIjz3KebnLrFyzOoVn2t8= X-Received: by 2002:a1f:a791:: with SMTP id q139mr12278200vke.25.1604309293390; Mon, 02 Nov 2020 01:28:13 -0800 (PST) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> <49AEE43E-3C39-4B85-AEB7-321BFF5ABBC6@gmail.com> In-Reply-To: <49AEE43E-3C39-4B85-AEB7-321BFF5ABBC6@gmail.com> From: Gyan Mishra Date: Mon, 2 Nov 2020 04:28:02 -0500 Message-ID: To: Fred Baker Cc: Greg Mirsky , Jeff Tantsura , Mark Smith , v6ops list Content-Type: multipart/alternative; boundary="0000000000008ade7505b31c5d7b" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 09:28:16 -0000 --0000000000008ade7505b31c5d7b Content-Type: text/plain; charset="UTF-8" On Mon, Nov 2, 2020 at 1:35 AM Fred Baker wrote: > > > > On Oct 29, 2020, at 1:42 AM, Mark Smith wrote: > > > > I've thought that the use of Anycast would increase, and have thought > that it would be useful to have a specially designated anycast prefix. It > has also occurred to me that anycast has some of the properties of unicast > as well as some of the properties of multicast, so could be seen to fit in > between unicast and multicast (1:1 -> 1:Any -> 1:Many) > > That's a reasonable description of anycast as deployed. Gyan> Agreed > > > My question in that would be exactly what you might want to change. We > have some pretty widespread use of anycast today ( > https://www.iana.org/domains/root/servers https://root-servers.org), and > to my knowledge it seems to work just fine. If we're going to replace > existing anycast with some sort of anycast prefix, the first big change we > have to make is in BGP; it can advertise a unicast prefix or address, but > can't, today at least, advertise an anycast prefix.Then we have to tell > hosts that they can send traffic to such addresses and should. I think we > should have a good reason if we're going to boil the ocean. Gyan> Good point and as you mention services such as DNS, NTP predominantly but even Syslog, snmp, netflow have gone the way of Anycast VIP advertisement via a lb for proximity routing to unicast address for a just about any service can be done the ASM way and works very well. I think with IPv6 a lot of thought was put into the addressing schema I am guessing like the built in Anycast range out of the GUI range without a use case but hopes for if you build they will come which I guess never happened. So then I guess it never took of as it would require some changes to BGP. Working with BGP on parameters and codepoint development in some of the other WGs, if there is a real gain or use case for an Anycast BGP SAFI I could author a draft to make it happen but I would need to figure out the why and what gap is not being filled by the existing Anycast capability via unicast today which has been widely proliferated. > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000008ade7505b31c5d7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

--0000000000008ade7505b31c5d7b-- From nobody Mon Nov 2 05:25:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88713A0810 for ; Mon, 2 Nov 2020 05:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-oWRl1XXu_T for ; Mon, 2 Nov 2020 05:25:28 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41F33A0FBB for ; Mon, 2 Nov 2020 05:25:28 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id 133so11103843pfx.11 for ; Mon, 02 Nov 2020 05:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7/CCxnEYNQ0R1rQb+uMB0LsQwwvE841Qn0h4c8YxR/o=; b=FkGsdTXKBb8MVIolGosQIJI0eseg4urEUACTtRmma9ht6ajv4EIG8x2Lk7zol4jJUC 3J7y0hjHQ6Eo8xA78mQJKiay4fpeutTBUDerNYBdBB3NjfGgMBN5y5llMvGjk/jFmeSz YEinlHsat/seQptDLoLlHryF6+OgoNGbla/e2HnizHjFoLrPGCdo/MG94ns95E4lTvbY oYe8Rp0AYIQ+nA5X3kRfsZNkBI9266+odIKibvLgMVn+Dtm73arip2iiqnMXQ3f1/Gwk 4upNCAPcHUPsv8eZkiOMXe4dxQq7LpMFlNO4jxw+/zOdAMDgrCoLcAyDN3pY1hryEmY5 tJqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7/CCxnEYNQ0R1rQb+uMB0LsQwwvE841Qn0h4c8YxR/o=; b=FS8GS76IZCjNYmxE000ZS0VtqCsHQVnN0uFA+cWjbAHR2VAEh0mN1Ha/64AuoOofxL xQ5VpziYqzSB9wQZl399ZwyiFUpt1XMzM4M/aia3rkASlJnkZtUAcItzdtT7B/AyD7vh fyDsRYxh/6z7qf13vmMkSMRIdFPb+3r9Jrf/dj7IBPEH2QhJdUL4+jQArctUveGwmI9q EKerDZZ5sxfnnPdbXOTy0WRdh3E0b2j09VqED9f5bbWX2Suf/WeSJyg5QQTjHMIgj7CD Mghmx+3/NcCtdiE8tNpMqqB1KTsXW4KHxjLPNul1i2ypPev0UoII64ICgsz5CgrR6Ii6 PLAQ== X-Gm-Message-State: AOAM531vqXPV5CMJOP0jYgAitvrIJTsNWlfQYHcuI5sXmzUTS3UPwGNy wIBiA321YX+jB9/TT4ixtlNCxemERW+1iw== X-Google-Smtp-Source: ABdhPJzBK9a63FVmz1u4Yp5DUZikVxOietQfllBvj9tLHfL8e6bGAeiMCnQfBAA8BUE9TRsWSbbiPQ== X-Received: by 2002:a63:f445:: with SMTP id p5mr13149180pgk.293.1604323526500; Mon, 02 Nov 2020 05:25:26 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id x15sm1338793pjh.21.2020.11.02.05.25.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 05:25:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) From: Fred Baker In-Reply-To: Date: Mon, 2 Nov 2020 05:25:23 -0800 Cc: Naveen Kottapalli , Alexandre Petrescu , Gyan Mishra , Dusan Mudric , Dmytro Shytyi , Ole Troan , Bob Hinden , Gyan Mishra Content-Transfer-Encoding: quoted-printable Message-Id: <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 13:25:31 -0000 Let me ask a question of the operators. This draft, as of today, is in = discussion in 6man and will probably be discussed in the 6man meeting. I = have not offered the authors a slot in v6ops, as it is not being = discussed here. That said, it is presumably a solution to an operational = problem, in that the prefix that SLAAC is being used to generate an = address in is not exactly 64 bits. Soliciting opinions on the problem: is this something that needs a = solution? On the solution: what do you think of it? Does it have holes? > On Nov 2, 2020, at 12:14 AM, Gyan Mishra = wrote: >=20 > Dear v6OPS, >=20 > This draft addresses the problem statement to change SLAAC's = historical fixed 64 bit boundary to variable PIO so that VLSM masking is = supported just as it is today with static & DHCPv6 & DHCPv6 PD. =20 >=20 > This change to SLAAC to variable, ensures that parity is maintained = between the three address deployment mechanisms that exist today with = IPv6. This draft as well addresses the MAJOR gap that exists today with = lack of parity and the historical framework of the impact of this lack = of partify that has existed since the IPv6 specification was published = 20+ years ago.=20 >=20 > We have a solutions draft below that is referenced in this draft that = goes over in detail the solution on 6MAN. >=20 > ! Variable SLAAC > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >=20 > Bob & Ole, >=20 > Please review. Based on the feedback received from 6MAN, I would like = to request a time slot on IETF 109. >=20 > Kind Regards >=20 > Gyan >=20 >=20 >=20 > ---------- Forwarded message --------- > From: Mishra, Gyan S > Date: Fri, Oct 30, 2020 at 6:50 PM > Subject: Fwd: [E] New Version Notification for = draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > To: Hayabusanew >=20 >=20 >=20 >=20 > ---------- Forwarded message --------- > From: > Date: Fri, Oct 30, 2020 at 6:46 PM > Subject: [E] New Version Notification for = draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > To: Naveen Kottapalli , Alexandre Petrescu = , Gyan Mishra , = Alexandre Petrescu , Dusan Mudric = , Dmytro Shytyi >=20 >=20 >=20 > A new version of I-D, = draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > has been successfully submitted by Gyan Mishra and posted to the > IETF repository. >=20 > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > Revision: 01 > Title: SLAAC with prefixes of arbitrary length in PIO = (Variable SLAAC) - A Problem Statement > Document date: 2020-10-30 > Group: Individual Submission > Pages: 12 > URL: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archiv= e_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mq= q0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D=20 > Status: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn= 2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D=20 > Htmlized: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0U= Y8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MA= oo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D=20 > Htmlized: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D=20 > Diff: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdif= f-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4= mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oD= x27MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D=20 >=20 > Abstract: > In the past, various IPv6 addressing models have been proposed = based > on a subnet hierarchy embedding a 64-bit prefix. The last remnant = of > IPv6 classful addressing is a inflexible interface identifier > boundary at /64. This document details the 64-bit boundary problem > statement. >=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 >=20 >=20 > --=20 >=20 >=20 > Gyan Mishra > Network Solutions Architect & SME > Data Center Planning | Common Core | Development & Engineering Lab = Services > Global Technology Services | ITNUC > O 240 970-6287 > M 301 502-1347 > 13101 Columbia Pike Rm 304-D > Silver Spring, MD 20904 >=20 > IETF & ISOC Member since 2015 > https://www.ietf.org/ > https://www.internetsociety.org/ >=20 >=20 >=20 >=20 > --=20 >=20 >=20 > Gyan Mishra > Network Solutions Architect=20 > M 301 502-1347 > 13101 Columbia Pike=20 > Silver Spring, MD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 2 05:33:15 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF763A0D38 for ; Mon, 2 Nov 2020 05:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5qmQoZhOYGq for ; Mon, 2 Nov 2020 05:33:09 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F533A0799 for ; Mon, 2 Nov 2020 05:33:09 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id s24so8124976ioj.13 for ; Mon, 02 Nov 2020 05:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GNwPyTb0LO7cTW5llbeWNSjz4hgm1Ju5MCWMtl1eA34=; b=Tb0F3zwqEK3tdxEntCdo7abQLdAQggLpXc2H2aqHZ8LDJa+zObIqsdsn/+vSi64b5I gBMhcqnYWxzeooxzP0cmP2zdWLtgRdQIskIgi6bk/RTAwHHQD4mHmU0Y/zEFYnnCzj1z rV4nOVv+1jhRtNAUlYMVlCAo2NfP/nJMkW+PbNuUJhl1lGG8tspRJDMzlPtVTUvjlKnQ wyH1+m3xk2N30MTDGeZ0Z0eVM0EW3yc0SlyexigxvlTDMikskBHLKip6Ptg5rkP/2tL2 BGs/bi+QbNxIO5Gs+Qa72mC+VuUbAO2l20+PGTEt3KdBP94iaOQGlQEO9lt0VNp5TV6G J9kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GNwPyTb0LO7cTW5llbeWNSjz4hgm1Ju5MCWMtl1eA34=; b=MsTLcNRGm63vnoUrjb5pFoyjvG7y/mwHEv4J3fcpVAELE8qQrqX4TPiXISRBvvVle9 PZ77InbzkrK1j56p1EYzwWVuBiWk4T6xhpWGBrwCWB2PEAadx5l5kXZyEnbqiq9cGX0G iD+b0Cb3gbRJDPaxmmJLd09tn06vyDdyR1ghkdWtPZP9IxDrlNaLPieiv7TNAZJeY3Jr cjPfTpSrz1Gx6ekRLCiXACOhwMSHlEeQFzLQpWbBwU3P/XL/J3F/GOEEopnCdfrw087U pUffdeIomQJ26oRJUa14ZnRo5o1x7nt8PGRtPogh6OwUC9iTvc5aHSNSe/dc8UMjcz9U nCzw== X-Gm-Message-State: AOAM531QxDQVy97/KZwOybp7O13XcQKUKrij2ugzeNk+HkCSeerA6Zhp rqqb6zcqvPb2RskvtO3RB6fylTSo1S8iootpd8p6QA== X-Google-Smtp-Source: ABdhPJxQgSmczJGZvnTvxrczx+26vTSRd+D1tMkrXKn2pVlur7I2zdXeoKLIDnYu1kc177IvprzCblDhPhb9MuQ7frM= X-Received: by 2002:a02:a808:: with SMTP id f8mr3020367jaj.84.1604323988040; Mon, 02 Nov 2020 05:33:08 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> In-Reply-To: <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> From: Lorenzo Colitti Date: Mon, 2 Nov 2020 22:32:56 +0900 Message-ID: To: Fred Baker Cc: IPv6 Operations , Naveen Kottapalli , Dmytro Shytyi , Gyan Mishra , Alexandre Petrescu Content-Type: multipart/alternative; boundary="00000000000069dd0a05b31fc905" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 13:33:12 -0000 --00000000000069dd0a05b31fc905 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable AFAICS this is a straight violation of the text in RFC 4291 which says that interface IDs are 64 bits long. As such, I don't see the point in discussing it unless there is reason to believe that that text will change. There was a very long and very heated discussion about that text a few years ago when the 6man tried to take 4291 to full standard. That consumed a lot of WG time and ultimately resulted in no changes. I expect there are still going to be very strong opinions on both sides. If we are to reopen that discussion now, it should happen in 6man, not v6ops. That way those discussions will at least only happen in one place. On Mon, Nov 2, 2020 at 10:25 PM Fred Baker wrote= : > Let me ask a question of the operators. This draft, as of today, is in > discussion in 6man and will probably be discussed in the 6man meeting. I > have not offered the authors a slot in v6ops, as it is not being discusse= d > here. That said, it is presumably a solution to an operational problem, i= n > that the prefix that SLAAC is being used to generate an address in is not > exactly 64 bits. > > Soliciting opinions on the problem: is this something that needs a > solution? On the solution: what do you think of it? Does it have holes? > > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra wrote: > > > > Dear v6OPS, > > > > This draft addresses the problem statement to change SLAAC's historical > fixed 64 bit boundary to variable PIO so that VLSM masking is supported > just as it is today with static & DHCPv6 & DHCPv6 PD. > > > > This change to SLAAC to variable, ensures that parity is maintained > between the three address deployment mechanisms that exist today with > IPv6. This draft as well addresses the MAJOR gap that exists today with > lack of parity and the historical framework of the impact of this lack of > partify that has existed since the IPv6 specification was published 20+ > years ago. > > > > We have a solutions draft below that is referenced in this draft that > goes over in detail the solution on 6MAN. > > > > ! Variable SLAAC > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > Bob & Ole, > > > > Please review. Based on the feedback received from 6MAN, I would like > to request a time slot on IETF 109. > > > > Kind Regards > > > > Gyan > > > > > > > > ---------- Forwarded message --------- > > From: Mishra, Gyan S > > Date: Fri, Oct 30, 2020 at 6:50 PM > > Subject: Fwd: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > To: Hayabusanew > > > > > > > > > > ---------- Forwarded message --------- > > From: > > Date: Fri, Oct 30, 2020 at 6:46 PM > > Subject: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > To: Naveen Kottapalli , Alexandre Petrescu < > alexandre.petrescu@cea.fr>, Gyan Mishra , > Alexandre Petrescu , Dusan Mudric < > dmudric@ciena.com>, Dmytro Shytyi > > > > > > > > A new version of I-D, > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > has been successfully submitted by Gyan Mishra and posted to the > > IETF repository. > > > > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > > Revision: 01 > > Title: SLAAC with prefixes of arbitrary length in PIO (Variabl= e > SLAAC) - A Problem Statement > > Document date: 2020-10-30 > > Group: Individual Submission > > Pages: 12 > > URL: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archi= ve_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > Status: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY= 8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo= &s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2r= xBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D > > Diff: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdi= ff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4m= qq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > Abstract: > > In the past, various IPv6 addressing models have been proposed based > > on a subnet hierarchy embedding a 64-bit prefix. The last remnant o= f > > IPv6 classful addressing is a inflexible interface identifier > > boundary at /64. This document details the 64-bit boundary problem > > statement. > > > > > > > > > > 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 > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect & SME > > Data Center Planning | Common Core | Development & Engineering Lab > Services > > Global Technology Services | ITNUC > > O 240 970-6287 > > M 301 502-1347 > > 13101 Columbia Pike Rm 304-D > > Silver Spring, MD 20904 > > > > IETF & ISOC Member since 2015 > > https://www.ietf.org/ > > https://www.internetsociety.org/ > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > _______________________________________________ > > 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 > --00000000000069dd0a05b31fc905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
AFAICS this is a straight violation of the text in RFC 429= 1 which says that interface IDs are 64 bits long. As such, I don't see = the point in discussing it unless there is reason to believe that that text= will change.

There was a very long and very heated disc= ussion about that text a few years ago when the 6man tried to take 4291 to = full standard. That consumed a lot of WG time and ultimately resulted in no= changes. I expect there are still going to be very strong opinions on both= sides. If we are to reopen that discussion now, it should happen in 6man, = not v6ops. That way those discussions will at least only happen in one plac= e.

On Mon, Nov 2, 2020 at 10:25 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
Let me ask a question of th= e operators. This draft, as of today, is in discussion in 6man and will pro= bably be discussed in the 6man meeting. I have not offered the authors a sl= ot in v6ops, as it is not being discussed here. That said, it is presumably= a solution to an operational problem, in that the prefix that SLAAC is bei= ng used to generate an address in is not exactly 64 bits.

Soliciting opinions on the problem: is this something that needs a solution= ? On the solution: what do you think of it? Does it have holes?

> On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>=C2=A0 =C2=A0Dear v6OPS,
>
> This draft addresses the problem statement to change SLAAC's histo= rical fixed 64 bit boundary to variable PIO so that VLSM masking is support= ed just as it is today with static & DHCPv6 & DHCPv6 PD.=C2=A0
>
> This change to SLAAC to variable, ensures that parity is maintained be= tween the three address deployment mechanisms that exist today with IPv6.= =C2=A0 This draft as well addresses the MAJOR gap that exists today with la= ck of parity and the historical framework of the impact of this lack of par= tify that has existed since the IPv6 specification was published 20+ years = ago.
>
> We have a solutions draft below that is referenced in this draft that = goes over in detail the solution on 6MAN.
>
> ! Variable SLAAC
> https://datatracker.ietf.org/= doc/draft-mishra-6man-variable-slaac/
>
> Bob & Ole,
>
> Please review.=C2=A0 Based on the feedback received from 6MAN, I would= like to request a time slot on IETF 109.
>
> Kind Regards
>
> Gyan
>
>
>
> ---------- Forwarded message ---------
> From: Mishra, Gyan S <gyan.s.mishra@verizon.com>
> Date: Fri, Oct 30, 2020 at 6:50 PM
> Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-vari= able-slaac-problem-stmt-01.txt
> To: Hayabusanew <hayabusagsm@gmail.com>
>
>
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Oct 30, 2020 at 6:46 PM
> Subject: [E] New Version Notification for draft-mishra-v6ops-variable-= slaac-problem-stmt-01.txt
> To: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petrescu@= cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petrescu &= lt;Alexandre= .Petrescu@cea.fr>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.com>
>
>
>
> A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-stmt-0= 1.txt
> has been successfully submitted by Gyan Mishra and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-varia= ble-slaac-problem-stmt
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of arbitr= ary length in PIO (Variable SLAAC) - A Problem Statement
> Document date:=C2=A0 2020-10-30
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dh= ttps-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-= 2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3m= Z3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m= =3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-cXn0FCho9ZftXjO= -TuTH19Nr6MO5spHMPP0xR4&e=3D
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__d= atatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem= -2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ= &r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYR= nxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8= Q9kHxc&e=3D
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__data= tracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dprobl= em-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBT= Q&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oY= RnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3= KwlktF8&e=3D
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625= Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI= &e=3D
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariabl= e-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJ= lPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU= &m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQw7BqnqoVfmk= BjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D
>
> Abstract:
>=C2=A0 =C2=A0 In the past, various IPv6 addressing models have been pro= posed based
>=C2=A0 =C2=A0 on a subnet hierarchy embedding a 64-bit prefix.=C2=A0 Th= e last remnant of
>=C2=A0 =C2=A0 IPv6 classful addressing is a inflexible interface identi= fier
>=C2=A0 =C2=A0 boundary at /64.=C2=A0 This document details the 64-bit b= oundary problem
>=C2=A0 =C2=A0 statement.
>
>
>
>
> 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. >
> The IETF Secretariat
>
>
>
>
> --
>
>
> Gyan Mishra
> Network Solutions Architect & SME
> Data Center Planning | Common Core | Development & Engineering Lab= Services
> Global Technology Services | ITNUC
> O 240 970-6287
> M 301 502-1347
> 13101 Columbia Pike Rm 304-D
> Silver Spring, MD 20904
>
> IETF=C2=A0 & ISOC Member since 2015
> https://www.ietf.org/
> https://www.internetsociety.org/
>
>
>
>
> --
>
>
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
> _______________________________________________
> 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
--00000000000069dd0a05b31fc905-- From nobody Mon Nov 2 05:44:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60743A0D96 for ; Mon, 2 Nov 2020 05:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dfRpM6fGrDF for ; Mon, 2 Nov 2020 05:43:53 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA933A0A81 for ; Mon, 2 Nov 2020 05:43:53 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id r10so6838402plx.3 for ; Mon, 02 Nov 2020 05:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGqZqMwrmWQk9eCh5tmsS3lLaYHiqy6T5mVUL0+Dsoo=; b=Dmjw+uQ2636Jxo7UpkhOrRz3T+7sIS+F79K2J80n8d0TxKD3+fwbfWvISe5XLQZ+WS ZUvfx0mhoOZWzjWbQvfMRastAsFDzPWBNrbsMvVjZoIjohfTgC4EJkAL1wkh6oI4p5tI 5pwYfFHHXs+ph8t7dJZOfHNCHwsKHtFriWaiPvPPcLAXWcDE+nWw3g223YAwxS443O9o U2glY2wKTOXxs2mVduEhxzxcrXTIwQ4E4Ob2FHx6WNWLlad+UKNau7Ll908nWnMZhhN1 MShgtVhJ5P3W6J68/B2HrrMnVX8PHAvmGT9HthzR9ms99Gl9mvJMTsToZ4Z3+Z4mKUeM z5dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sGqZqMwrmWQk9eCh5tmsS3lLaYHiqy6T5mVUL0+Dsoo=; b=I3Kaf7RK8Sf8Izm6G5he/JikCJyAYpyjlhIRpoQYM4Fy5FF3z0RCXRsyLTccB4R9Gb k4lcPw/l/K9AClhxORTD0iqHfBy0vDSY+zmajhhuHnF45NoLADMAyWrAmt4lG0mY1yya BRFcRHtBb7EUMZDSafymfLxV2wslVNxUFXXohj8Elj0xdxKQOs2TM1sGZ/qKGWwH7DGo PpGf5OiJ2h5umu0WCwVj780HKjl+42yTfEp/cYu2TdQjJY0RQaF23iBOxr9qUMW+568K Q681s5UN3boeb/i5kbqYB3lD0FansmAZPgs7zEiROnKtn3hm/fyN73NHhdJ8XIqPNtEB zuwA== X-Gm-Message-State: AOAM532TJpPzZYEv/jnvDFeFXf8ebsdS0t7LgyKIzSsNJ37Yu7asuEMs sl/KTpbaaRQwD3m/OGi0tu0= X-Google-Smtp-Source: ABdhPJx6hvwAjFZbRBA3ojb/Vp+HT1E+kZrtvAhCY56BOUgT7cO2EqgFg83rbTa0TMlRtk20bOGW5A== X-Received: by 2002:a17:902:6907:b029:d6:99d8:3ff5 with SMTP id j7-20020a1709026907b02900d699d83ff5mr17365797plk.44.1604324632956; Mon, 02 Nov 2020 05:43:52 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id g4sm3167524pgu.81.2020.11.02.05.43.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 05:43:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) From: Fred Baker In-Reply-To: Date: Mon, 2 Nov 2020 05:43:50 -0800 Cc: IPv6 Operations , Naveen Kottapalli , Dmytro Shytyi , Gyan Mishra , Alexandre Petrescu Content-Transfer-Encoding: quoted-printable Message-Id: <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com> References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 13:43:55 -0000 > On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti = wrote: >=20 > AFAICS this is a straight violation of the text in RFC 4291 which says = that interface IDs are 64 bits long. As such, I don't see the point in = discussing it unless there is reason to believe that that text will = change. I'm not disputing the point. My question is a little different, though. = If we preclude discussion on the basis that one of the tablets brought = down the mountain has different words chiseled into it, we preclude = operational input to it - and if it solves an operational problem, we = kill that solution. My question is: do we see a problem that might argue = for 4291's specification to change? Absent a problem, we don't need a solution, and that might be an = important data point to 6man.= From nobody Mon Nov 2 05:50:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229FE3A0FFA for ; Mon, 2 Nov 2020 05:50:04 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PkIUDB9Y64W2 for ; Mon, 2 Nov 2020 05:50:03 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003493A0FF6 for ; Mon, 2 Nov 2020 05:50:02 -0800 (PST) Received: from astfgl.hanazo.no (unknown [IPv6:2001:420:44c1:1250:107d:ab32:eb22:a23d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id EEEDE4E11ADB; Mon, 2 Nov 2020 13:50:01 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5BA8D42FB94C; Mon, 2 Nov 2020 14:49:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: otroan@employees.org In-Reply-To: <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com> Date: Mon, 2 Nov 2020 14:49:59 +0100 Cc: Lorenzo Colitti , Naveen Kottapalli , Dmytro Shytyi , IPv6 Operations , Alexandre Petrescu , Gyan Mishra Content-Transfer-Encoding: quoted-printable Message-Id: References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 13:50:04 -0000 >> AFAICS this is a straight violation of the text in RFC 4291 which = says that interface IDs are 64 bits long. As such, I don't see the point = in discussing it unless there is reason to believe that that text will = change. >=20 > I'm not disputing the point. My question is a little different, = though. If we preclude discussion on the basis that one of the tablets = brought down the mountain has different words chiseled into it, we = preclude operational input to it - and if it solves an operational = problem, we kill that solution. My question is: do we see a problem that = might argue for 4291's specification to change? >=20 > Absent a problem, we don't need a solution, and that might be an = important data point to 6man. Changing the 64 bit boundary is a solution. Permissionless extension of the network is a problem (one mentioned in = the draft). While the draft has a particular solution in mind, I wouldn't mind = discussing the problems the draft enumerates. Cheers, Ole= From nobody Mon Nov 2 07:30:36 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E885F3A08C0; Mon, 2 Nov 2020 07:30:33 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OsTlmt-auxy3; Mon, 2 Nov 2020 07:30:32 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 40C0F3A0141; Mon, 2 Nov 2020 07:30:32 -0800 (PST) Received: from lhreml749-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E9D90EA95D5E75EC84C1; Mon, 2 Nov 2020 15:30:30 +0000 (GMT) Received: from fraeml708-chm.china.huawei.com (10.206.15.36) by lhreml749-chm.china.huawei.com (10.201.108.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 2 Nov 2020 15:30:30 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 2 Nov 2020 16:30:30 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Mon, 2 Nov 2020 16:30:30 +0100 From: Giuseppe Fioccola To: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" CC: "draft-vf-v6ops-ipv6-deployment@ietf.org" , Nalini Elkins , Sebastien Lourdez Thread-Topic: New Version Notification for draft-vf-v6ops-ipv6-deployment-01.txt Thread-Index: AQHWsSu2osD0XAJo1k+GoLlz3W62E6m09SLA Date: Mon, 2 Nov 2020 15:30:30 +0000 Message-ID: References: <160433036425.17038.8514593154109759474@ietfa.amsl.com> In-Reply-To: <160433036425.17038.8514593154109759474@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.213.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:30:34 -0000 RGVhciBBbGwsDQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIG9mIGRyYWZ0 LXZmLXY2b3BzLWlwdjYtZGVwbG95bWVudC4NClRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgc29tZSBj b21tZW50cyByZWNlaXZlZCBvbiB0aGUgbGlzdCBhbmQgb2ZmbGluZSwgaW4gcGFydGljdWxhciB3 ZSBoYXZlIGV4dGVuZGVkIHRoZSBzZWN0aW9uIGFib3V0IHRoZSBDYWxsIGZvciBBY3Rpb24uIFdl IGFsc28gd2VsY29tZWQgdHdvIG5ldyBjb2F1dGhvcnM6IE5hbGluaSBFbGtpbnMgYW5kIFNlYmFz dGllbiBMb3VyZGV6Lg0KDQpZb3VyIGlucHV0cyBhbmQgY29tbWVudHMgYXJlIGFsd2F5cyB3ZWxj b21lLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkdpdXNlcHBlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyLCAyMDIwIDQ6MTkgUE0N ClRvOiBTZWJhc3RpZW4gTG91cmRleiA8c2ViYXN0aWVuLmxvdXJkZXpAcG9zdC5sdT47IEdpdXNl cHBlIEZpb2Njb2xhIDxnaXVzZXBwZS5maW9jY29sYUBodWF3ZWkuY29tPjsgTmFsaW5pIEVsa2lu cyA8bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20+OyBQYW9sbyBWb2xwYXRvIDxwYW9s by52b2xwYXRvQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXZmLXY2b3BzLWlwdjYtZGVwbG95bWVudC0wMS50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtdmYtdjZvcHMtaXB2Ni1kZXBsb3ltZW50LTAxLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHaXVzZXBwZSBGaW9jY29sYSBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC12Zi12Nm9wcy1pcHY2LWRl cGxveW1lbnQNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlJUHY2IERlcGxveW1lbnQgU3RhdHVzDQpE b2N1bWVudCBkYXRlOgkyMDIwLTExLTAyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6CQkyNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUv aWQvZHJhZnQtdmYtdjZvcHMtaXB2Ni1kZXBsb3ltZW50LTAxLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZmLXY2b3BzLWlwdjYtZGVw bG95bWVudC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXZmLXY2b3BzLWlwdjYtZGVwbG95bWVudA0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12Zi12Nm9wcy1pcHY2LWRlcGxveW1lbnQt MDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtdmYtdjZvcHMtaXB2Ni1kZXBsb3ltZW50LTAxDQoNCkFic3RyYWN0Og0KICAgTG9va2luZyBn bG9iYWxseSwgSVB2NiBpcyBncm93aW5nIGZhc3RlciB0aGFuIElQdjQgYW5kIHRoaXMgbWVhbnMN CiAgIHRoYXQgdGhlIGNvbGxlY3RpdmUgd2lzZG9tIG9mIHRoZSBuZXR3b3JraW5nIGluZHVzdHJ5 IGhhcyBzZWxlY3RlZA0KICAgSVB2NiBmb3IgdGhlIGZ1dHVyZS4gIFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYW4gb3ZlcnZpZXcgb2YgSVB2Ng0KICAgdHJhbnNpdGlvbiBkZXBsb3ltZW50IHN0YXR1 cyBhbmQgYSB2aWV3IG9uIGhvdyB0aGUgdHJhbnNpdGlvbiB0byBJUHY2DQogICBpcyBwcm9ncmVz c2luZyBhbW9uZyBuZXR3b3JrIG9wZXJhdG9ycyB0aGF0IGFyZSBpbnRyb2R1Y2luZyBJUHY2IG9y DQogICBoYXZlIGFscmVhZHkgYWRvcHRlZCBhbiBJUHY2LW9ubHkgc29sdXRpb24uICBJdCBhbHNv IGFpbXMgdG8gYW5hbHl6ZQ0KICAgdGhlIHRyYW5zaXRpb24gY2hhbGxlbmdlcyBhbmQgdGhlcmVm b3JlIGVuY291cmFnZSBhY3Rpb25zIGFuZCBtb3JlDQogICBpbnZlc3RpZ2F0aW9ucyBvbiBzb21l IGFyZWFzIHRoYXQgYXJlIHN0aWxsIHVuZGVyIGRpc2N1c3Npb24uICBUaGUNCiAgIG92ZXJhbGwg SVB2NiBpbmNlbnRpdmVzIGFyZSBhbHNvIGV4YW1pbmVkLg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0K From nobody Mon Nov 2 09:05:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498683A0B74 for ; Mon, 2 Nov 2020 09:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKqGZqdXubAd for ; Mon, 2 Nov 2020 09:05:05 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FB13A0D93 for ; Mon, 2 Nov 2020 09:05:01 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id f15so4123792uaq.9 for ; Mon, 02 Nov 2020 09:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MkLUdCRrWWCcI69/SKlTGiGkJDA43+rmn3oMfoPpwIk=; b=bABBZCyI5PzPAetFpGsDZy4uj01tnWxgJCWZNS/fKCw/4WuPqLfsVsjtZnmIQJheuV oaOZowvo+mS4JwThBD+F7YJQGFERqpnqEcxQZlJisC5rYOabRj1xdj7BKKBYkFXGOAfj +QwOUOsP86EjTgdKLhOxHja/Ee//LP8Hgnq2ahYcafGpApo8E4ZnDHYBWBQCmVWNVcWB LzcvBlwG1vl9TlZrtKMGsuqa8LEcBUeHVXG2esIV9qjmb3KQitmLrnmIofURoqXBeqid frmhyLZeV7K0tdp9qKl/Pd0NCkdg9IpV9lQ7k++ACWXhX3l7WMjMm2iunepjSBzD/umC 3XtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MkLUdCRrWWCcI69/SKlTGiGkJDA43+rmn3oMfoPpwIk=; b=oqZsdFPEf1Ken867ZK3R54KzmkrlUmTaMh9k1S+pSHe3tMi7xFL6o0IR+Mid0ESQKU 1HBWbqpog0DsRJ2/OZqVlvUrWoyZvVgqntR4g872sQhyxsIj2O4wqbNtYh50c71BAI6l rNVT10mzblwGAp5i0CiffKHIabpmrnUfwGmqb0y0ounS4N8kDKqR2E5A2+cnp/5LFOWm HBk0gQnbqz0OtP+XDSYjsSnBPAPpJtVzEoqssh6SPo3irwJjiYaXp6GwWvv+0UnE4JrZ vOuizvLz1eZBy9Cb4/dy0dZEWTrKCkgNmgC5k0Iu/jW3w5UmaG267vMNd7ykZGZHdw6I UDxA== X-Gm-Message-State: AOAM533K3atbHkFkqW2l4TraSApnAK18XY20fyBQ20Lgvqr6c8TMaY3Z 0mKIIwrg+gNFkwKHFuJZz9N0eFPLMaKM5rUwfkA= X-Google-Smtp-Source: ABdhPJzE4RZhRldElHxTLayS7BDCm59H5Y9cV8j6OyA+zb6gxJbehbsW6EH15inBd3M9xy5ivrJcOQhhMMRhpDgwFew= X-Received: by 2002:ab0:6994:: with SMTP id t20mr8109085uaq.111.1604336700215; Mon, 02 Nov 2020 09:05:00 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com> In-Reply-To: From: Gyan Mishra Date: Mon, 2 Nov 2020 12:04:49 -0500 Message-ID: To: otroan@employees.org Cc: Alexandre Petrescu , Dmytro Shytyi , Fred Baker , Gyan Mishra , IPv6 Operations , Naveen Kottapalli Content-Type: multipart/alternative; boundary="0000000000001dd78605b322bf42" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:05:08 -0000 --0000000000001dd78605b322bf42 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 2, 2020 at 8:50 AM wrote: > >> AFAICS this is a straight violation of the text in RFC 4291 which says > that interface IDs are 64 bits long. As such, I don't see the point in > discussing it unless there is reason to believe that that text will change. > > > > I'm not disputing the point. My question is a little different, though. > If we preclude discussion on the basis that one of the tablets brought down > the mountain has different words chiseled into it, we preclude operational > input to it - and if it solves an operational problem, we kill that > solution. My question is: do we see a problem that might argue for 4291's > specification to change? > > > > Absent a problem, we don't need a solution, and that might be an > important data point to 6man. > > Changing the 64 bit boundary is a solution. > Permissionless extension of the network is a problem (one mentioned in the > draft). > > While the draft has a particular solution in mind, I wouldn't mind > discussing the problems the draft enumerates. Gyan> Yes, please discuss > > > Cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000001dd78605b322bf42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 2, 2020 at 8:50 AM <otroan@employees.org> wrote:
>> AFAICS this is a straight violation of the text i= n RFC 4291 which says that interface IDs are 64 bits long. As such, I don&#= 39;t see the point in discussing it unless there is reason to believe that = that text will change.
>
> I'm not disputing the point. My question is a little different, th= ough. If we preclude discussion on the basis that one of the tablets brough= t down the mountain has different words chiseled into it, we preclude opera= tional input to it - and if it solves an operational problem, we kill that = solution. My question is: do we see a problem that might argue for 4291'= ;s specification to change?
>
> Absent a problem, we don't need a solution, and that might be an i= mportant data point to 6man.

Changing the 64 bit boundary is a solution.
Permissionless extension of the network is a problem (one mentioned in the = draft).

While the draft has a particular solution in mind, I wouldn't mind disc= ussing the problems the draft enumerates.
=C2=A0 =C2=A0Gyan> Yes, please discuss=C2=A0


Cheers,
Ole
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--
--0000000000001dd78605b322bf42-- From nobody Mon Nov 2 09:14:48 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F893A0F47 for ; Mon, 2 Nov 2020 09:14:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4alwSVVg_X3 for ; Mon, 2 Nov 2020 09:14:37 -0800 (PST) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77933A0D93 for ; Mon, 2 Nov 2020 09:14:08 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id a10so797878uan.12 for ; Mon, 02 Nov 2020 09:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pHumDDiuGv75Gl3JtIcf3ZozjygJ61KCXkRUMJ1CG5A=; b=B/tya94YoltWr+Nh5zbOu6wmQ64/rU5lACd850FrHXlQhj8EIkXGGcgqwrbWJMqv/q S4qaMC6WIe7O7YuVNmdgYKeKc8oKBzFkwqpQ8JiKtdJUoDkfrD07HRUvbfysiInmMsz0 tYmAhCvudiyK3iPD+BPmLlOjCkfEPvvckPiYegN6r75/pdjolowc6EZdljp8QDbRVSdj eIhtrWlHp6fffSwW1jX7mCz9UJ3LfOpMIfi7gpcJmpDUj173ke2U3GggbCNRXGhi/9rZ jiuIoDp8IrmSmNX7PTwdz0/KaRl0xHKCjoj0eLq6NdWYFFTCDOCnMB2XjyRzWWTGX7iC Bodw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pHumDDiuGv75Gl3JtIcf3ZozjygJ61KCXkRUMJ1CG5A=; b=MwpSKhixKaf4e+7B9Gu5iVdbJ6sD04yZY7FFkGe5QzbV03P2MgeW3rNe8ZySeb/mGg Zb4SfYWAIF16/3csDYJpgeyJyGIx+SLIcmU97DNk1zSUYKa/Eq9NrY7wltEoeROwYeFV FhdsjRqGraby1wmHpmBCQKtz/PdX6wb8Htwux6Rmcpbf0lFxcWImdzKa1phOQZMmD49I KgPJZvITof6/yF6QwlxzRsqKrJo0xh2Clex9EH5m03eLIatD8ZurPvX3BenP3R06fKnC ESwcD/aixykpvPEb+HfwFVVx7F05fXjq/EuWe7fa+T11GqPdWuDdOdngfwQMyCFiSgfF J+AA== X-Gm-Message-State: AOAM531ejcwYNn9EBgRAST/wemdl9dGnOIXS1xn0KhOQ/CfmQUKAsMpz ktwK6Xp4NMdOOIsJZPt8/VbTsbJ3RVg8rC91Xhc= X-Google-Smtp-Source: ABdhPJw5brxPDD2nxxJo7zFMy0Lv8poHPQwQL4f9akQ+C2nlpBlcRmN82sXjDNBOl0pm183qd8XLWXttvPa0/jdAPjA= X-Received: by 2002:ab0:2986:: with SMTP id u6mr4382119uap.118.1604337247772; Mon, 02 Nov 2020 09:14:07 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> In-Reply-To: <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> From: Gyan Mishra Date: Mon, 2 Nov 2020 12:13:57 -0500 Message-ID: To: Fred Baker Cc: Alexandre Petrescu , Bob Hinden , Dmytro Shytyi , Dusan Mudric , Gyan Mishra , IPv6 Operations , Naveen Kottapalli , Ole Troan Content-Type: multipart/alternative; boundary="000000000000c0e32e05b322dfce" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:14:46 -0000 --000000000000c0e32e05b322dfce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 2, 2020 at 8:25 AM Fred Baker wrote: > Let me ask a question of the operators. This draft, as of today, is in > discussion in 6man and will probably be discussed in the 6man meeting. I > have not offered the authors a slot in v6ops, as it is not being discusse= d > here. That said, it is presumably a solution to an operational problem, i= n > that the prefix that SLAAC is being used to generate an address in is not > exactly 64 bits. > Gyan> Agreed on 6MAN slot. Yes, solution to operational problem. We would discuss both problem and solution during the time slot so I think 6MAN would be the right spot. Correct. > > Soliciting opinions on the problem: is this something that needs a > solution? On the solution: what do you think of it? Does it have holes? Gyan> Yes soliciting opinions on the problem is the first step and poking holes on v6ops before we get to solution - so v6ops ML is perfect spot for that. > > > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra wrote: > > > > Dear v6OPS, > > > > This draft addresses the problem statement to change SLAAC's historical > fixed 64 bit boundary to variable PIO so that VLSM masking is supported > just as it is today with static & DHCPv6 & DHCPv6 PD. > > > > This change to SLAAC to variable, ensures that parity is maintained > between the three address deployment mechanisms that exist today with > IPv6. This draft as well addresses the MAJOR gap that exists today with > lack of parity and the historical framework of the impact of this lack of > partify that has existed since the IPv6 specification was published 20+ > years ago. > > > > We have a solutions draft below that is referenced in this draft that > goes over in detail the solution on 6MAN. > > > > ! Variable SLAAC > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > Bob & Ole, > > > > Please review. Based on the feedback received from 6MAN, I would like > to request a time slot on IETF 109. > > > > Kind Regards > > > > Gyan > > > > > > > > ---------- Forwarded message --------- > > From: Mishra, Gyan S > > Date: Fri, Oct 30, 2020 at 6:50 PM > > Subject: Fwd: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > To: Hayabusanew > > > > > > > > > > ---------- Forwarded message --------- > > From: > > Date: Fri, Oct 30, 2020 at 6:46 PM > > Subject: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > To: Naveen Kottapalli , Alexandre Petrescu < > alexandre.petrescu@cea.fr>, Gyan Mishra , > Alexandre Petrescu , Dusan Mudric < > dmudric@ciena.com>, Dmytro Shytyi > > > > > > > > A new version of I-D, > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > has been successfully submitted by Gyan Mishra and posted to the > > IETF repository. > > > > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > > Revision: 01 > > Title: SLAAC with prefixes of arbitrary length in PIO (Variabl= e > SLAAC) - A Problem Statement > > Document date: 2020-10-30 > > Group: Individual Submission > > Pages: 12 > > URL: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archi= ve_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > Status: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY= 8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo= &s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2r= xBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D > > Diff: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdi= ff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4m= qq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > Abstract: > > In the past, various IPv6 addressing models have been proposed based > > on a subnet hierarchy embedding a 64-bit prefix. The last remnant o= f > > IPv6 classful addressing is a inflexible interface identifier > > boundary at /64. This document details the 64-bit boundary problem > > statement. > > > > > > > > > > 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 > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect & SME > > Data Center Planning | Common Core | Development & Engineering Lab > Services > > Global Technology Services | ITNUC > > O 240 970-6287 > > M 301 502-1347 > > 13101 Columbia Pike Rm 304-D > > Silver Spring, MD 20904 > > > > IETF & ISOC Member since 2015 > > https://www.ietf.org/ > > https://www.internetsociety.org/ > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000c0e32e05b322dfce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

--000000000000b32ea305b3447d91-- From nobody Wed Nov 4 04:15:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE86E3A1043; Wed, 4 Nov 2020 04:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=B1MktgzC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kotZp5V7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeANEOdazlhT; Wed, 4 Nov 2020 04:14:56 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C563A1056; Wed, 4 Nov 2020 04:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22747; q=dns/txt; s=iport; t=1604492096; x=1605701696; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M0tilv3r4Zfb+NnKPNnGJCQE1zBxdNBxYZYtZ+7PZvA=; b=B1MktgzCevgwVmrEwx+AKG7t/tVODpdztkAnQtj2yiQXQSFmfJP1p7vY DcapmF1ffzJdm3BpIjolmCxGZfFM2yeBXiILR1PbvrVR1YEt/wpYvFPSI pZyvAcPsFVQe+r7YU+d16UHSdsLSvO4cC+dcn7fiK+dV7P7a9pvsB+rDW A=; IronPort-PHdr: =?us-ascii?q?9a23=3AJUIGDhb8dgoaNUbZPXpJaR//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD4re4vNAzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXxYlTTpju56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0CABlmqJf/4gNJK1igliBUiMuB3B?= =?us-ascii?q?ZLy4KhDODSQONUIoTiX2Eb4EugSUDVAsBAQENAQEYAQoKAgQBAYFVgnUCF4F?= =?us-ascii?q?1AiU2Bw4CAwEBCwEBBQEBAQIBBgRxhWEBC4VyAQEBBAEBEBEdAQEsCwELBAI?= =?us-ascii?q?BCBEEAQEkBAMCAgIfBgsUCQgCBA4FIoMEAYF+TQMuAQ6kEwKBO4hodoEygwQ?= =?us-ascii?q?BAQWFBA0LghADBoE4gnKDcYEGhVEbggCBECgcgk8+ghtCAQGBdg+CcTOCLJA?= =?us-ascii?q?8gmo+hxqMDJBHVAqCbZV2hRMDH6Ftk02NZpJeAgQCBAUCDgEBBYFbCikqgS1?= =?us-ascii?q?wFTsqAYI+UBcCDY4rFxSDOoUUhUR0OAIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,450,1596499200"; d="scan'208,217";a="598762787" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2020 12:14:55 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A4CEtqc011911 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2020 12:14:55 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 4 Nov 2020 06:14:54 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 4 Nov 2020 06:14:54 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 4 Nov 2020 06:14:54 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YRFCYal+8gDWN1sqQwMGV+3DW55/ewFT8TFUvfruEYtv8SJXLyTWQvUglAEwm7DJKTrmV+smzlmVpH+CBEO7PT/XkKGF4ioWDoizFfTOYOecXG9I5NmcTT0P8JutsB0UWleJ6yBuNTao7LoxgQAiodHlXXbDpMjwT3tU3lrgLZ8A5jD1Vi7RzzYtdhvlGR7YW+0Zt3YSKtgqqSGAXPEFduS+miJ4i1tp0vDBRWMRWlpuoFC4D58BhipA/UfXX1FEk810bjL8gFb8OunxShEP9QwSh3Oy5Myy876NHmIbMxcr2DQ1D2yNzI5kJfUWm5YASYpNBeuVksX5mtlqKWbJbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0tilv3r4Zfb+NnKPNnGJCQE1zBxdNBxYZYtZ+7PZvA=; b=m6BX8vGmcoXycDEqI0DnopiKANvaFf9O3mFj/W6yZqDeCM4ntWQ+hDyhb54bDUEf/DeNLUZrKKUgByuo/LNBqQtB0/or8MxTkgDgHtfQDZKBHf0qk92iC1Qb85d/NricyxOrPY7cglA5FVLnYmorpraMNDbGuVULU6Eqc4fXrQ6k75QlFaGqDRdY9fICCorJ62ZpauWrPbqIifUmNkveCKUVidgDD8nA9cRu57OZb1ekgTd2SkM+RR7//IQaM6N85mKMASauVcAoBlG1yNq/NaYHNTsUhDUs5HkreKhMWf9iqmU7mWGaoZoRUtEy1mgDFrondrssB11CQlsV79WvlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0tilv3r4Zfb+NnKPNnGJCQE1zBxdNBxYZYtZ+7PZvA=; b=kotZp5V7myiqkczJ+TEXp6z9NC9z1L0PEoFV5IbQZi2+HGV6Lig7TGwZAI14gm8Xsxw3bCAnRQfkQzlOgrzXbSyAz/LC1CrPSnjMI2reUDg+KhmwIOIP8aC78fnjWiVa6AFncaxVhb/u8cRkqvLn5wBiaqqq8ELQl0Ug05yh/gg= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN8PR11MB3748.namprd11.prod.outlook.com (2603:10b6:408:86::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Wed, 4 Nov 2020 12:14:52 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::1dc1:e7f4:84ef:3711]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::1dc1:e7f4:84ef:3711%6]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 12:14:52 +0000 From: "Bernie Volz (volz)" To: "ianfarrer@gmx.com" CC: Jen Linkova , Michael Richardson , dhcwg , v6ops list Thread-Topic: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWoWMb7h/SuZNgk0iBKtkQ2d57eamVg+CAgAJkrICAFvSAAIAJKGCX Date: Wed, 4 Nov 2020 12:14:52 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebc0f29f-f401-40b6-a5ff-08d880bb3c22 x-ms-traffictypediagnostic: BN8PR11MB3748: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3JidtTGftCoyjZtIEcKW3D1nK1zDvltcMyOm91LiYus34lfinkMG5kQYYH1T8mFXiuXk1T0zWmnMdjOBoszEXFPjyc6HWY7c7I5HhXfePmjEMxFR3aC3T3/0LpZv1R12t2ZOoZGtkaXIUjbs0TgYeI8yHE+90rC1jS3OF9R8kGZBCcbbeCiHybznbgmFrc4QYjOsa9Zs4qOxkkNFtbN8yO4cfmFxFoA9R8ZMdo7Pc5wk0+AblB/6w57M9rzI3NJ6qCAFFq7Oo9In6B4Ty0joYDe1tsGqgCfXLC91u6RJQ+seCrEdDfJhlo6yoEQ14P0uNEzzP8qpj6HLW8n7PJt5ZECvhLFEnhUfvm0ofwz2TK74X/1uIq39ogRxuYIrUo0kCR/eA1u+UyufTtRzjE58alcHFnOht+V93BxjNlBFavFQHWxzlIpGnJCLgE0ONshjBqjMJYEEsIOAZ4Qu7Fmpup5OaprqYhjlyUq+MhCNtvY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(376002)(396003)(39860400002)(366004)(5660300002)(6512007)(8676002)(66946007)(91956017)(186003)(66574015)(316002)(71200400001)(8936002)(6486002)(2906002)(6506007)(33656002)(6916009)(86362001)(53546011)(66476007)(76116006)(2616005)(54906003)(478600001)(4326008)(83380400001)(26005)(66556008)(64756008)(966005)(66446008)(36756003)(518174003)(401264004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: c0IrlHNi8Xid7IGEjzt+F9+jFHLvKrtfrsTOsRk4/8PK2RiL7n4Ocrx4XNv0hW75CCWkngiqTjy+smDqyQv/bW+fWn4vMuLZfmW3I+GFdZdAQ5Mr970SLT+uXlenRb7G4f/FcRAxMsyTCbWhIyc/TUTWyRFlZRmC+4HFnxFkcCvZ1XAQcY4Go6MAzNbIu21woSID2FkRb1mXIJIttaJU21z2id0E0QBaOaED85y/FtfTvlXM0FGJAX5SkUc1/FT2l3RRBl2tPJ57g4a5+4sbax+S5XEmqpGi7FQwQIYV29xezDJYW3CsqW7gH0kme4TIOjArqCFe2E2Dt4TkFHbuRpKD1+Ng0fwIyOn2oFpyuLY7GkAJF2YlCzjszgAzNw+RCypNqFMtpZgVzPXjjkahuyCWcvA7nZdBkhwikKd7NQWFXfYF6Nm/26q8dexzSJa0HfGjEvAWoeQQktZuJzwnX+chccmG4trfsZmBYPxv92we9x1PI46zLmhoHRX3PfwlGM2+ynFZZcCwNgSqvlrjkk0x9XvikAbuEjPxBeJYrjs3+gSpjhSjWdfoRuVWjnLp5d3DXfNmFuOhDMFIgb8GLKvIJgCWE+5q/wcaXXxTX0hYL3/hN4MNTVSY8s1+fvICPOe8OW5t5t3rCcXIAd2Dew== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BDA018BA70A64DC392FA21506C72F6D9ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebc0f29f-f401-40b6-a5ff-08d880bb3c22 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 12:14:52.8159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mx2uPz95Ht9EWaGX79p8TbYwSsiMxh+j3aJ+KLDEwoUykquO8swQzYSap6aspcVa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3748 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 12:14:59 -0000 --_000_BDA018BA70A64DC392FA21506C72F6D9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgLi4uIGxvb2tzIGdvb2QgYnV0IHBlcmhhcHMgTUFDIGFkZHJlc3MgaXMgdG9vIEV0aGVybmV0 IHNwZWNpZmljIGFuZCBqdXN0IGxpbmstbGF5ZXIgYWRkcmVzcyB3b3VsZCBiZSBiZXR0ZXI/DQoN Ci0gQmVybmllDQoNCk9uIE9jdCAyOSwgMjAyMCwgYXQgMTI6MjQgUE0sICJpYW5mYXJyZXJAZ214 LmNvbSIgPGlhbmZhcnJlckBnbXguY29tPiB3cm90ZToNCg0K77u/DQpIaSwNCg0KU29ycnkgZm9y IHRoZSBkZWxheSBpbiByZXBseSwgSeKAmXZlIGJlZW4gb3V0IG9mIHRoZSBvZmZpY2UgZm9yIHRo ZSBsYXN0IGZldyB3ZWVrcyBmb3IgdmFyaW91cyByZWFzb25zLg0KDQpIZXJl4oCZcyBhIG5ldyB3 b3JkaW5nIHByb3Bvc2FsIGluY29ycG9yYXRpbmcgSmVuICYgQmVybmll4oCZcyBzdWdnZXN0aW9u czoNCg0KUi00DQpUbyBwcmV2ZW50IHJvdXRpbmcgbG9vcHMsIHRoZSByZWxheSBTSE9VTEQgaW1w bGVtZW50IGEgY29uZmlndXJhYmxlIHBvbGljeSB0byBkcm9wIHBhY2tldHMNCnJlY2VpdmVkIG9u IGEgREhDUC1QRCBjbGllbnQgZmFjaW5nIGludGVyZmFjZSB3aXRoIGEgZGVzdGluYXRpb24gYWRk cmVzcyBpbiBhIHByZWZpeCBkZWxlZ2F0ZWQNCnRvIGEgY2xpZW50IGNvbm5lY3RlZCB0byB0aGF0 IGludGVyZmFjZSwgYXMgZm9sbG93czogIEZvciBwb2ludC10by1wb2ludCBsaW5rcywgd2hlbiB0 aGUgcGFja2V04oCZcw0KaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZXMgbWF0Y2guIEZvciBt dWx0aS1hY2Nlc3MgbGlua3MsIHdoZW4gdGhlIHBhY2tldOKAmXMgaW5ncmVzcyBhbmQNCmVncmVz cyBpbnRlcmZhY2UgbWF0Y2gsIGFuZCB0aGUgc291cmNlIE1BQyBhbmQgbmV4dC1ob3AgTUFDIGFk ZHJlc3NlcyBtYXRjaC4gQW4NCklDTVB2NiBUeXBlIDEsIENvZGUgNiAoRGVzdGluYXRpb24gVW5y ZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0byBkZXN0aW5hdGlvbikgZXJyb3IgbWVzc2FnZSBNQVkN CmJlIHNlbnQgYXMgcGVyIFtSRkM0NDQzXSwgc2VjdGlvbiAzLjEuICBUaGUgSUNNUCBwb2xpY3kg U0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS4NCg0KVGhhbmtzLA0KSWFuDQoNCk9uIDE1LiBPY3QgMjAy MCwgYXQgMDM6NTEsIEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbTxtYWlsdG86ZnVycnkx M0BnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gV2VkLCBPY3QgMTQsIDIwMjAgYXQgMTI6NDQgQU0g QmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+ PiB3cm90ZToNCklmIG5vdCwgcGVyaGFwcyB3ZSBqdXN0IHNheToNCg0KUi00DQpUbyBwcmV2ZW50 IHJvdXRpbmcgbG9vcHMsIHRoZSByZWxheSBTSE9VTEQgaW1wbGVtZW50IGEgY29uZmlndXJhYmxl IHBvbGljeSB0byBkcm9wIHRyYWZmaWMgcmVjZWl2ZWQgZnJvbSBhbiB1cGxpbmsgaW50ZXJmYWNl IGFzIGZvbGxvd3M6DQoNCkknbSBub3Qgc3VyZSAnZnJvbSBhbiB1cGxpbmsgaW50ZXJmYWNlJyBt YWtlcyBzZW5zZS4gSW4gdGhlIGNhc2Ugb2YgYQ0Kcm91dGluZyBsb29wIGNhdXNlZCBieSBhbiBh bW5lc2lhYyBESENQLVBEIGNsaWVudCBpdCB3b3VsZCBiZSBhDQpkb3duc3RyZWFtIGludGVyZmFj ZS4NClRoZSBzY2VuYXJpbyB3aGVuIHN1Y2ggdHJhZmZpYyBhcnJpdmVzIGZyb20gYW4gdXBsaW5r IGludGVyZmFjZSBpcw0KJ3RoZSB1cGxpbmsgcm91dGVyIGJlbGlldmVzIHRoZSBwcmVmaXggaXMg ZGVsZWdhdGVkIHRvIHRoZSBjbGllbnQgYnV0DQp0aGUgcmVsYXkgZG9lcyBub3QgaGF2ZSBhIHJv dXRlIHBvaW50aW5nIHRvIHRoZSBjbGllbnQgc28gaXQgc2VuZHMNCnRyYWZmaWMgYmFjaycgLSBz byBtb3JlIGxpa2VseSAnYW4gYW1uZXNpYWMgcmVsYXknIGNhc2UuDQoNCkZvciBwb2ludC10by1w b2ludCBsaW5rcywgd2hlbiB0aGUgcGFja2V0J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFj ZXMgbWF0Y2guIEZvciBtdWx0aS1hY2Nlc3MgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzIGluZ3Jl c3MgYW5kIGVncmVzcyBpbnRlcmZhY2UgbWF0Y2gsIGFuZCB0aGUgc291cmNlIE1BQyBhbmQgbmV4 dC1ob3AgTUFDIGFkZHJlc3NlcyBtYXRjaC4gQW4gSUNNUHY2IFR5cGUgMSwgQ29kZSA2IChEZXN0 aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvDQpkZXN0aW5hdGlvbikgZXJyb3Ig bWVzc2FnZSBNQVkgYmUgc2VudCBhcyBwZXIgW1JGQzQ0NDNdLCBzZWN0aW9uIDMuMS4gIFRoZSBJ Q01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0KDQotIEJlcm5pZQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWFuZmFycmVyQGdteC5jb208bWFpbHRvOmlhbmZh cnJlckBnbXguY29tPiA8aWFuZmFycmVyQGdteC5jb208bWFpbHRvOmlhbmZhcnJlckBnbXguY29t Pj4NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTMsIDIwMjAgOToxNiBBTQ0KVG86IE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxt YW4uY2E+PjsgSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdt YWlsLmNvbT4+DQpDYzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86 dm9sekBjaXNjby5jb20+PjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRm Lm9yZz4+OyA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj47IHY2b3Bz IGxpc3QgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW2RoY3dnXSBbdjZvcHNdIFtFWFRFUk5BTF0gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxh eSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1y ZXF1aXJlbWVudHMNCg0KSGksDQoNClRoYW5rcyBmb3IgYWxsIG9mIHRoZSBkaXNjdXNzaW9uIG9u IHRoaXMuIFdl4oCZdmUgcmV3b3JrZWQgdGhlIHJlcXVpcmVtZW50IGFzIGZvbGxvd3M6DQoNClIt NA0KVG8gcHJldmVudCByb3V0aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBh IGNvbmZpZ3VyYWJsZSBwb2xpY3kgdG8gZHJvcCBjbGllbnQgdHJhZmZpYyBhcyBmb2xsb3dzOiAg Rm9yIHBvaW50LXRvLXBvaW50IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdyZXNzIGFuZCBl Z3Jlc3MgaW50ZXJmYWNlcyBtYXRjaC4gRm9yIG11bHRpLWFjY2VzcyBsaW5rcywgd2hlbiB0aGUg cGFja2V0J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBtYXRjaCwgYW5kIHRoZSBzb3Vy Y2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1hdGNoLiBBbiBJQ01QdjYgVHlwZSAx LCBDb2RlIDYgKERlc3RpbmF0aW9uIFVucmVhY2hhYmxlLCByZWplY3Qgcm91dGUgdG8NCmRlc3Rp bmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gIFRo ZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0KDQpUaGFua3MsDQpJYW4NCg0K T24gOS4gT2N0IDIwMjAsIGF0IDE3OjQxLCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNh bmRlbG1hbi5jYTxtYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj4gd3JvdGU6DQoNCg0KSmVu IExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT4+IHdy b3RlOg0KSSB0aGluayB0aGVyZSBpcyBjb25mdXNpb24gcmU6IHRoZSBzY2VuYXJpbyB3ZSBhcmUg dGFsa2luZyBhYm91dC4NCkkndmUgYXR0YWNoZWQgdGhlIGRpYWdyYW0gZm9yIHRoZSBjYXNlIHdo aWNoIGNvbmNlcm5zIG1lLg0KU286DQotIFRoZSBSZWxheSBSIGhhcyBhbiBpbnRlcmZhY2UgZXRo MCBjb25uZWN0ZWQgdG8gYSBzd2l0Y2ggUy4NCi0gRGV2aWNlcyBBIGFuZCBCIGFyZSBjb25uZWN0 ZWQgdG8gdGhlIHNhbWUgc3dpdGNoIGFuZCB1c2luZyBSIGFzIGENCmRlZmF1bHQgZ2F0ZXdheS4N Ci0gVGhlIHByZWZpeCAyMDAxOmRiODo6LzU2IHdhcyBkZWxlZ2F0ZWQgdG8gYSBjbGllbnQgQSB2 aWEgdGhlIHJlbGF5IFIuDQoNCmEgZnJpZW5kbHkgYW1lbmRtZW50IHRvIHlvdXIgZXhhbXBsZSB0 byBhaWQgaW4gaHVtYW4gY29tcHJlaGVuc2lvbjoNCiAgIH0gLSBUaGUgcHJlZml4IDIwMDE6ZGI4 OjAwMDA6MDEyMzovNjQgd2FzIGRlbGVnYXRlZCB0byBhIGNsaWVudCBBIHZpYSB0aGUgcmVsYXkg Ui4NCiAgIH0gIC0gUiBpbnN0YWxscyBhIHJvdXRlIGZvciAyMDAxOmRiODowMDAwOjAxMjM6LzY0 IHRvd2FyZHMgQSB2aWEgZXRoMC4NCg0KLSBUaGUgZGV2aWNlIEIgKHdoaWNoIGhhcyBhbiBhZGRy ZXNzIE5PVCBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LA0KYnV0IGZyb20gYW5vdGhlciAvNjQg YXNzaWduZWQgdG8gdGhhdCBjb21tb24gbGluaywgbGV0J3Mgc2F0DQoyMDAxOmRiODpjYWZlOjov NjQpIHNlbmRzIGEgcGFja2V0IHRvIGFuIGFkZHJlc3MgZnJvbSB0aGUgZGVsZWdhdGVkDQoNCm5v dywgbXkgYnJhaW4gY2FuIG1vcmUgY2xlYXJseSBzZWUgdGhhdCAyMDAxOmRiODpjYWZlOjovNjQg aXMgbm90DQp3aXRoaW4gMjAwMTpkYjg6MDAwMDowMTIzOi82NCwgd2hpbGUgSSBoYWQgdG8gdXNl IGEgZmV3IGV4dHJhIGJyYWluDQpjZWxscyB0byBzZWUgdGhhdCBpdCB3YXNuJ3QgaW4gdGhhdCA6 Oi81NiA6LSkNCg0KV2hhdCBJJ2QgZXhwZWN0IHRvIGhhcHBlbiAod2l0aCBESENQLVBEIG9yIHdp dGhvdXQgLSBlLmcuIGlmIFIgaGFzIGENCnN0YXRpYyByb3V0ZSB0b3dhcmRzIEEsIG5vdCBhIGR5 bmFtaWMgcm91dGUgcHJvZHVjZWQgYnkgUEQpOg0KLSB0aGUgcGFja2V0IGlzIHNlbnQgdG8gQS4g V2VsbCwgaWYgQSBkb2VzIG5vdCBoYXZlIGEgcm91dGUgdG8NCjIwMDE6ZGI4Ojo0MiB0aGVuIGlu ZGVlZCBhIHJvdXRpbmcgbG9vcCBtaWdodCBoYXBwZW4uIEJ1dCBpZiBBIGRvZXMNCmhhdmUgYSBy b3V0ZSwgdGhlIHBhY2tldCB3aWxsIGJlIGRlbGl2ZXJlZC4NCg0KV2hhdCBzZWVtcyB0byBiZSBy ZXF1aXJlZCBieSBSNDoNCi0gUiBkZXRlY3RzIHRoYXQgdGhlIHBhY2tldCBpcyByZWNlaXZlZCB2 aWEgZXRoMCBhbmQgbmVlZHMgdG8gYmUgc2VudA0KYmFjayB0byBldGgwLiBSNCBzZWVtcyB0byBy ZXF1aXJlIHN1Y2ggcGFja2V0cyB0byBiZSBkcm9wcGVkLg0KU28gaWYgQiB3b3VsZCBuZXZlciBi ZSBhYmxlIHRvIGNvbW11bmljYXRlIHRvIGFueSBhZGRyZXNzIGluIHRoZQ0KZGVsZWdhdGVkIHBy ZWZpeCwgcmlnaHQ/DQoNCkFtIEkgbWlzc2luZyBhbnl0aGluZz8NCg0KSSB0aGluayB0aGF0IHlv dSBnb3QgaXQgcmlnaHQuDQoNClBlcmhhcHMgdGhlIG1pc3NpbmcgcGllY2Ugb2YgdGhlIHJ1bGUg aXMgZG9u4oCZdCBzZW5kIGl0IGJhY2sgdG8gd2hlcmUgaXQgY2FtZSBmcm9tLCBiYXNlZCBvbiBs aW5rIGxheWVyIGFkZHJlc3NlcyAob3IgbGluayBpZiBwb2ludC10by1wb2ludCkuDQoNClllcy4g SWYgUjQgd2FzIHNheWluZyAnZHJvcCB0aGUgcGFja2V0IGlmIGl0IGNvbWVzIGZyb20gdGhlIHNh bWUNCmxpbmstbGF5ZXIgYWRkcmVzcyB5b3UgYXJlIGdvaW5nIHRvIHNlbmQgaXQgYmFjaycgLSBp dCB3b3VsZCBtYWtlDQp0b3RhbCBzZW5zZS4gQnV0IEkgZG9uJ3QgdGhpbmsgcm91dGVycyBkbyAq dGhhdCouDQoNClllcywgaWYgd2UgbWFkZSB0aGUgY2hlY2sgb24gTDIgYWRkcmVzcywgdGhlbiBp dCB3b3VsZCB3b3JrLg0KQW5kIEkgYWdyZWUgdGhhdCByb3V0ZXJzIGFyZSBleGFjdGx5IGRvaW5n IHRoYXQuDQoNCkkgdGhpbmsgdGhhdCBpdCBhbHNvIHdvcmtzIGlmIEIgaXMgYSByb3V0ZXIgd2l0 aCBhZGRpdGlvbmFsIGludGVyZmFjZXMNCmRvd25zdHJlYW0sIHVubGVzcyB0aGVyZSBhcmUgbXVs dGlwbGUgcGF0aHMuDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1h bi5jYTxtYWlsdG86bWNyK0lFVEZAc2FuZGVsbWFuLmNhPj4gICAuIG8gTyAoIElQdjYgScO4VCBj b25zdWx0aW5nICkNCiAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3 YSBhbmQgV29ybGR3aWRlDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlz dHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0NClNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg0K --_000_BDA018BA70A64DC392FA21506C72F6D9ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI aSAuLi4gbG9va3MgZ29vZCBidXQgcGVyaGFwcyBNQUMgYWRkcmVzcyBpcyB0b28gRXRoZXJuZXQg c3BlY2lmaWMgYW5kIGp1c3QgbGluay1sYXllciBhZGRyZXNzIHdvdWxkIGJlIGJldHRlcj88YnI+ DQo8YnI+DQo8ZGl2IGRpcj0ibHRyIj4tIEJlcm5pZTwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJy Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gT2N0IDI5LCAyMDIwLCBhdCAxMjoyNCBQTSwg JnF1b3Q7aWFuZmFycmVyQGdteC5jb20mcXVvdDsgJmx0O2lhbmZhcnJlckBnbXguY29tJmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2IGNsYXNzPSIiPkhpLDwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY29s b3I9IiMwMDAwMDAiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyIgY2xhc3M9IiI+U29ycnkgZm9yIHRoZSBkZWxheSBpbiByZXBseSwgSeKAmXZlIGJlZW4g b3V0IG9mIHRoZSBvZmZpY2UgZm9yIHRoZSBsYXN0IGZldyB3ZWVrcyBmb3IgdmFyaW91cyByZWFz b25zLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNvbG9yPSIjMDAw MDAwIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsiIGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsiIGNsYXNzPSIiPkhlcmXigJlzIGEgbmV3IHdvcmRpbmcgcHJvcG9zYWwg aW5jb3Jwb3JhdGluZzwvc3Bhbj48L2ZvbnQ+Jm5ic3A7SmVuICZhbXA7IEJlcm5pZeKAmXMgc3Vn Z2VzdGlvbnM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Ui00PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRvIHBy ZXZlbnQgcm91dGluZyBsb29wcywgdGhlIHJlbGF5IFNIT1VMRCBpbXBsZW1lbnQgYSBjb25maWd1 cmFibGUgcG9saWN5IHRvIGRyb3AgcGFja2V0czxiciBjbGFzcz0iIj4NCnJlY2VpdmVkIG9uIGEg REhDUC1QRCBjbGllbnQgZmFjaW5nIGludGVyZmFjZSB3aXRoIGEgZGVzdGluYXRpb24gYWRkcmVz cyBpbiBhIHByZWZpeCBkZWxlZ2F0ZWQ8YnIgY2xhc3M9IiI+DQp0byBhIGNsaWVudCBjb25uZWN0 ZWQgdG8gdGhhdCBpbnRlcmZhY2UsIGFzIGZvbGxvd3M6ICZuYnNwO0ZvciBwb2ludC10by1wb2lu dCBsaW5rcywmbmJzcDt3aGVuIHRoZSBwYWNrZXTigJlzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmlu Z3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZhY2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtz LCB3aGVuIHRoZSBwYWNrZXTigJlzJm5ic3A7aW5ncmVzcyBhbmQ8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+ZWdyZXNzIGludGVyZmFjZSBtYXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhv cCBNQUMgYWRkcmVzc2VzIG1hdGNoLiBBbjxiciBjbGFzcz0iIj4NCklDTVB2NiBUeXBlIDEsIENv ZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0byBkZXN0aW5hdGlv bikgZXJyb3IgbWVzc2FnZSBNQVk8YnIgY2xhc3M9IiI+DQpiZSBzZW50IGFzIHBlciBbUkZDNDQ0 M10sIHNlY3Rpb24gMy4xLiAmbmJzcDtUaGUgSUNNUCBwb2xpY3kgU0hPVUxEIGJlIGNvbmZpZ3Vy YWJsZS48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JYW48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAxNS4g T2N0IDIwMjAsIGF0IDAzOjUxLCBKZW4gTGlua292YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZ1cnJ5 MTNAZ21haWwuY29tIiBjbGFzcz0iIj5mdXJyeTEzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFdlZCwgT2N0IDE0LCAyMDIwIGF0IDEyOjQ0IEFNIEJlcm5p ZSBWb2x6ICh2b2x6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZvbHpAY2lzY28uY29tIiBjbGFzcz0i Ij52b2x6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPklmIG5vdCwgcGVyaGFwcyB3ZSBqdXN0IHNheTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSLTQ8YnIgY2xhc3M9IiI+DQpUbyBwcmV2ZW50IHJvdXRp bmcgbG9vcHMsIHRoZSByZWxheSBTSE9VTEQgaW1wbGVtZW50IGEgY29uZmlndXJhYmxlIHBvbGlj eSB0byBkcm9wIHRyYWZmaWMgcmVjZWl2ZWQgZnJvbSBhbiB1cGxpbmsgaW50ZXJmYWNlIGFzIGZv bGxvd3M6PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSdtIG5v dCBzdXJlICdmcm9tIGFuIHVwbGluayBpbnRlcmZhY2UnIG1ha2VzIHNlbnNlLiBJbiB0aGUgY2Fz ZSBvZiBhPGJyIGNsYXNzPSIiPg0Kcm91dGluZyBsb29wIGNhdXNlZCBieSBhbiBhbW5lc2lhYyBE SENQLVBEIGNsaWVudCBpdCB3b3VsZCBiZSBhPGJyIGNsYXNzPSIiPg0KZG93bnN0cmVhbSBpbnRl cmZhY2UuPGJyIGNsYXNzPSIiPg0KVGhlIHNjZW5hcmlvIHdoZW4gc3VjaCB0cmFmZmljIGFycml2 ZXMgZnJvbSBhbiB1cGxpbmsgaW50ZXJmYWNlIGlzPGJyIGNsYXNzPSIiPg0KJ3RoZSB1cGxpbmsg cm91dGVyIGJlbGlldmVzIHRoZSBwcmVmaXggaXMgZGVsZWdhdGVkIHRvIHRoZSBjbGllbnQgYnV0 PGJyIGNsYXNzPSIiPg0KdGhlIHJlbGF5IGRvZXMgbm90IGhhdmUgYSByb3V0ZSBwb2ludGluZyB0 byB0aGUgY2xpZW50IHNvIGl0IHNlbmRzPGJyIGNsYXNzPSIiPg0KdHJhZmZpYyBiYWNrJyAtIHNv IG1vcmUgbGlrZWx5ICdhbiBhbW5lc2lhYyByZWxheScgY2FzZS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Gb3IgcG9pbnQtdG8t cG9pbnQgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzIGluZ3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZh Y2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdy ZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlIG1hdGNoLCBhbmQgdGhlIHNvdXJjZSBNQUMgYW5kIG5l eHQtaG9wIE1BQyBhZGRyZXNzZXMgbWF0Y2guIEFuIElDTVB2NiBUeXBlDQogMSwgQ29kZSA2IChE ZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvPGJyIGNsYXNzPSIiPg0KZGVz dGluYXRpb24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYXMgcGVyIFtSRkM0NDQzXSwgc2Vj dGlvbiAzLjEuICZuYnNwO1RoZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0gQmVybmllPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiA8 YSBocmVmPSJtYWlsdG86aWFuZmFycmVyQGdteC5jb20iIGNsYXNzPSIiPmlhbmZhcnJlckBnbXgu Y29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbmZhcnJlckBnbXguY29tIiBjbGFzcz0iIj5p YW5mYXJyZXJAZ214LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KU2VudDogVHVlc2RheSwgT2N0 b2JlciAxMywgMjAyMCA5OjE2IEFNPGJyIGNsYXNzPSIiPg0KVG86IE1pY2hhZWwgUmljaGFyZHNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYSIgY2xhc3M9IiI+bWNy K2lldGZAc2FuZGVsbWFuLmNhPC9hPiZndDs7IEplbiBMaW5rb3ZhICZsdDs8YSBocmVmPSJtYWls dG86ZnVycnkxM0BnbWFpbC5jb20iIGNsYXNzPSIiPmZ1cnJ5MTNAZ21haWwuY29tPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQpDYzogQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86 dm9sekBjaXNjby5jb20iIGNsYXNzPSIiPnZvbHpAY2lzY28uY29tPC9hPiZndDs7IGRoY3dnICZs dDs8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIGNsYXNzPSIiPmRoY3dnQGlldGYub3Jn PC9hPiZndDs7IDZtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiBjbGFzcz0i Ij5pcHY2QGlldGYub3JnPC9hPiZndDs7IHY2b3BzIGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyIgY2xhc3M9IiI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0i Ij4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogUXVlc3Rpb24g dG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhj cHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50czxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhp LDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyBmb3IgYWxsIG9mIHRoZSBkaXNj dXNzaW9uIG9uIHRoaXMuIFdl4oCZdmUgcmV3b3JrZWQgdGhlIHJlcXVpcmVtZW50IGFzIGZvbGxv d3M6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUi00PGJyIGNsYXNzPSIiPg0KVG8gcHJl dmVudCByb3V0aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNvbmZpZ3Vy YWJsZSBwb2xpY3kgdG8gZHJvcCBjbGllbnQgdHJhZmZpYyBhcyBmb2xsb3dzOiAmbmJzcDtGb3Ig cG9pbnQtdG8tcG9pbnQgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzIGluZ3Jlc3MgYW5kIGVncmVz cyBpbnRlcmZhY2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtzLCB3aGVuIHRoZSBwYWNr ZXQncyBpbmdyZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlDQogbWF0Y2gsIGFuZCB0aGUgc291cmNl IE1BQyBhbmQgbmV4dC1ob3AgTUFDIGFkZHJlc3NlcyBtYXRjaC4gQW4gSUNNUHY2IFR5cGUgMSwg Q29kZSA2IChEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvPGJyIGNsYXNz PSIiPg0KZGVzdGluYXRpb24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0aGUg Y2xpZW50LiAmbmJzcDtUaGUgSUNNUCBwb2xpY3kgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KSWFuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ T24gOS4gT2N0IDIwMjAsIGF0IDE3OjQxLCBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2EiIGNsYXNzPSIiPm1jcitpZXRmQHNhbmRlbG1h bi5jYTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkplbiBMaW5rb3ZhICZsdDs8YSBocmVmPSJtYWlsdG86ZnVycnkxM0BnbWFpbC5jb20i IGNsYXNzPSIiPmZ1cnJ5MTNAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SSB0aGluayB0aGVyZSBpcyBjb25mdXNp b24gcmU6IHRoZSBzY2VuYXJpbyB3ZSBhcmUgdGFsa2luZyBhYm91dC48YnIgY2xhc3M9IiI+DQpJ J3ZlIGF0dGFjaGVkIHRoZSBkaWFncmFtIGZvciB0aGUgY2FzZSB3aGljaCBjb25jZXJucyBtZS48 YnIgY2xhc3M9IiI+DQpTbzo8YnIgY2xhc3M9IiI+DQotIFRoZSBSZWxheSBSIGhhcyBhbiBpbnRl cmZhY2UgZXRoMCBjb25uZWN0ZWQgdG8gYSBzd2l0Y2ggUy48YnIgY2xhc3M9IiI+DQotIERldmlj ZXMgQSBhbmQgQiBhcmUgY29ubmVjdGVkIHRvIHRoZSBzYW1lIHN3aXRjaCBhbmQgdXNpbmcgUiBh cyBhPGJyIGNsYXNzPSIiPg0KZGVmYXVsdCBnYXRld2F5LjxiciBjbGFzcz0iIj4NCi0gVGhlIHBy ZWZpeCAyMDAxOmRiODo6LzU2IHdhcyBkZWxlZ2F0ZWQgdG8gYSBjbGllbnQgQSB2aWEgdGhlIHJl bGF5IFIuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KYSBmcmll bmRseSBhbWVuZG1lbnQgdG8geW91ciBleGFtcGxlIHRvIGFpZCBpbiBodW1hbiBjb21wcmVoZW5z aW9uOjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO30gLSBUaGUgcHJlZml4IDIwMDE6 ZGI4OjAwMDA6MDEyMzovNjQgd2FzIGRlbGVnYXRlZCB0byBhIGNsaWVudCBBIHZpYSB0aGUgcmVs YXkgUi48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDt9ICZuYnNwOy0gUiBpbnN0YWxs cyBhIHJvdXRlIGZvciAyMDAxOmRiODowMDAwOjAxMjM6LzY0IHRvd2FyZHMgQSB2aWEgZXRoMC48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4tIFRoZSBkZXZpY2UgQiAod2hpY2ggaGFzIGFuIGFkZHJlc3MgTk9UIGZyb20gdGhlIGRl bGVnYXRlZCBwcmVmaXgsPGJyIGNsYXNzPSIiPg0KYnV0IGZyb20gYW5vdGhlciAvNjQgYXNzaWdu ZWQgdG8gdGhhdCBjb21tb24gbGluaywgbGV0J3Mgc2F0PGJyIGNsYXNzPSIiPg0KMjAwMTpkYjg6 Y2FmZTo6LzY0KSBzZW5kcyBhIHBhY2tldCB0byBhbiBhZGRyZXNzIGZyb20gdGhlIGRlbGVnYXRl ZDxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCm5vdywgbXkgYnJh aW4gY2FuIG1vcmUgY2xlYXJseSBzZWUgdGhhdCAyMDAxOmRiODpjYWZlOjovNjQgaXMgbm90PGJy IGNsYXNzPSIiPg0Kd2l0aGluIDIwMDE6ZGI4OjAwMDA6MDEyMzovNjQsIHdoaWxlIEkgaGFkIHRv IHVzZSBhIGZldyBleHRyYSBicmFpbjxiciBjbGFzcz0iIj4NCmNlbGxzIHRvIHNlZSB0aGF0IGl0 IHdhc24ndCBpbiB0aGF0IDo6LzU2IDotKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPldoYXQgSSdkIGV4cGVjdCB0byBoYXBwZW4g KHdpdGggREhDUC1QRCBvciB3aXRob3V0IC0gZS5nLiBpZiBSIGhhcyBhPGJyIGNsYXNzPSIiPg0K c3RhdGljIHJvdXRlIHRvd2FyZHMgQSwgbm90IGEgZHluYW1pYyByb3V0ZSBwcm9kdWNlZCBieSBQ RCk6PGJyIGNsYXNzPSIiPg0KLSB0aGUgcGFja2V0IGlzIHNlbnQgdG8gQS4gV2VsbCwgaWYgQSBk b2VzIG5vdCBoYXZlIGEgcm91dGUgdG88YnIgY2xhc3M9IiI+DQoyMDAxOmRiODo6NDIgdGhlbiBp bmRlZWQgYSByb3V0aW5nIGxvb3AgbWlnaHQgaGFwcGVuLiBCdXQgaWYgQSBkb2VzPGJyIGNsYXNz PSIiPg0KaGF2ZSBhIHJvdXRlLCB0aGUgcGFja2V0IHdpbGwgYmUgZGVsaXZlcmVkLjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPldoYXQgc2VlbXMgdG8gYmUgcmVxdWlyZWQgYnkgUjQ6PGJyIGNsYXNzPSIi Pg0KLSBSIGRldGVjdHMgdGhhdCB0aGUgcGFja2V0IGlzIHJlY2VpdmVkIHZpYSBldGgwIGFuZCBu ZWVkcyB0byBiZSBzZW50PGJyIGNsYXNzPSIiPg0KYmFjayB0byBldGgwLiBSNCBzZWVtcyB0byBy ZXF1aXJlIHN1Y2ggcGFja2V0cyB0byBiZSBkcm9wcGVkLjxiciBjbGFzcz0iIj4NClNvIGlmIEIg d291bGQgbmV2ZXIgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0byBhbnkgYWRkcmVzcyBpbiB0aGU8 YnIgY2xhc3M9IiI+DQpkZWxlZ2F0ZWQgcHJlZml4LCByaWdodD88YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij5BbSBJIG1pc3NpbmcgYW55dGhpbmc/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy IGNsYXNzPSIiPg0KSSB0aGluayB0aGF0IHlvdSBnb3QgaXQgcmlnaHQuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5QZXJoYXBzIHRoZSBtaXNzaW5nIHBpZWNlIG9mIHRo ZSBydWxlIGlzIGRvbuKAmXQgc2VuZCBpdCBiYWNrIHRvIHdoZXJlIGl0IGNhbWUgZnJvbSwgYmFz ZWQgb24gbGluayBsYXllciBhZGRyZXNzZXMgKG9yIGxpbmsgaWYgcG9pbnQtdG8tcG9pbnQpLjxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlllcy4gSWYgUjQgd2FzIHNheWluZyAn ZHJvcCB0aGUgcGFja2V0IGlmIGl0IGNvbWVzIGZyb20gdGhlIHNhbWU8YnIgY2xhc3M9IiI+DQps aW5rLWxheWVyIGFkZHJlc3MgeW91IGFyZSBnb2luZyB0byBzZW5kIGl0IGJhY2snIC0gaXQgd291 bGQgbWFrZTxiciBjbGFzcz0iIj4NCnRvdGFsIHNlbnNlLiBCdXQgSSBkb24ndCB0aGluayByb3V0 ZXJzIGRvICp0aGF0Ki48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQpZZXMsIGlmIHdlIG1hZGUgdGhlIGNoZWNrIG9uIEwyIGFkZHJlc3MsIHRoZW4gaXQgd291bGQg d29yay48YnIgY2xhc3M9IiI+DQpBbmQgSSBhZ3JlZSB0aGF0IHJvdXRlcnMgYXJlIGV4YWN0bHkg ZG9pbmcgdGhhdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRoaW5rIHRoYXQgaXQg YWxzbyB3b3JrcyBpZiBCIGlzIGEgcm91dGVyIHdpdGggYWRkaXRpb25hbCBpbnRlcmZhY2VzPGJy IGNsYXNzPSIiPg0KZG93bnN0cmVhbSwgdW5sZXNzIHRoZXJlIGFyZSBtdWx0aXBsZSBwYXRocy48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLTxiciBjbGFzcz0iIj4NCk1pY2hhZWwgUmlj aGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jcitJRVRGQHNhbmRlbG1hbi5jYSIgY2xhc3M9 IiI+bWNyK0lFVEZAc2FuZGVsbWFuLmNhPC9hPiZndDsgJm5ic3A7Jm5ic3A7LiBvIE8gKCBJUHY2 IEnDuFQgY29uc3VsdGluZyApPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIElu YywgT3R0YXdhIGFuZCBXb3JsZHdpZGU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxiciBjbGFzcz0iIj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiBjbGFzcz0iIj5p cHY2QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnIgY2xhc3M9IiI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tIDxiciBjbGFzcz0i Ij4NClNZLCBKZW4gTGlua292YSBha2EgRnVycnk8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BDA018BA70A64DC392FA21506C72F6D9ciscocom_-- From nobody Wed Nov 4 05:02:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867EC3A1139 for ; Wed, 4 Nov 2020 05:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-Qb338KV8qe for ; Wed, 4 Nov 2020 05:02:03 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BC63A1164 for ; Wed, 4 Nov 2020 05:02:02 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id m16so22872269ljo.6 for ; Wed, 04 Nov 2020 05:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MLGgdDnG2RwKA9NfosbwNjJx2J6EIJ9bMvnRB/dujDU=; b=cPi2Omkn4CDUP+9ArnLe2962rSBsmpaV+VR2Neu3xQdlR5uRndY/585TCR0gSnXGku vrcDGc2mudT8ueWscKa4zCkJma/OlCRoAwxq24z0xcvIRSBnQkDFNu5zIgQwJ9sqbLCy oAxAa5nyWA/RFtpb4o3HcuZ4HEMbOlWi8ub5U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MLGgdDnG2RwKA9NfosbwNjJx2J6EIJ9bMvnRB/dujDU=; b=f2nd2Q1S75wINd5/mTbmwlXEYaeBUGvO/W2UnbVSOdGbFyGitndktHRUnKqF4LgNzx YCBFKU8vsJh+ZBNSypofRVaBJ3FiUt6iX3xCTwFzfUvqNiLbloo3Vd73tidne98f/4bK MKK9y+YcMIG2rhRd4JcBfhlPbUnSoBDXlEjAQ7Yo4X+qtJXR/4JrdmC766sg7v9vs+L7 f6w1yvc4jQPW37gqAL5y6t2WC/nkrE1qYiyVya50/DIfLV+L56/aZwdneqx4z6JmoKUY ba1zLZQCsf4z8qEp3iPd4v0Ljm86XKMDrRd6AMO/IGrbJbFTMCVCMst+g/fQ88jjFh2l jeVw== X-Gm-Message-State: AOAM530icvdIS+G7GnS35DwcUrXfS3Eoz/6tOYaSmKGvEp2dVF6AoNj5 YfvsjHXvAjjkrV3YeEDZpUb3GCwT+wPjyjBJSboX5w== X-Google-Smtp-Source: ABdhPJwrCEmwJ1z000HkaUfQTEDOXCdv8qhT/N1y/IvayC5z2yFlTAfiwreYWHGDlWeA5MlecFRHiaBkl+UNu7zHxHo= X-Received: by 2002:a2e:a0d4:: with SMTP id f20mr9926735ljm.350.1604494920252; Wed, 04 Nov 2020 05:02:00 -0800 (PST) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> In-Reply-To: From: Timothy Winters Date: Wed, 4 Nov 2020 08:01:48 -0500 Message-ID: To: "Bernie Volz (volz)" Cc: "ianfarrer@gmx.com" , Michael Richardson , v6ops list , dhcwg Content-Type: multipart/alternative; boundary="000000000000c41aeb05b34795ff" Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 13:02:07 -0000 --000000000000c41aeb05b34795ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Bernie, link-layer address would be an improvement to the Mac Address. ~Tim On Wed, Nov 4, 2020 at 7:15 AM Bernie Volz (volz) wrote: > Hi ... looks good but perhaps MAC address is too Ethernet specific and > just link-layer address would be better? > > - Bernie > > On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com" > wrote: > > =EF=BB=BF > Hi, > > Sorry for the delay in reply, I=E2=80=99ve been out of the office for the= last few > weeks for various reasons. > > Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2=80=99= s suggestions: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y > to drop packets > received on a DHCP-PD client facing interface with a destination address > in a prefix delegated > to a client connected to that interface, as follows: For point-to-point > links, when the packet=E2=80=99s > ingress and egress interfaces match. For multi-access links, when the > packet=E2=80=99s ingress and > egress interface match, and the source MAC and next-hop MAC addresses > match. An > ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY > be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be > configurable. > > Thanks, > Ian > > On 15. Oct 2020, at 03:51, Jen Linkova wrote: > > On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) > wrote: > > If not, perhaps we just say: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y > to drop traffic received from an uplink interface as follows: > > > I'm not sure 'from an uplink interface' makes sense. In the case of a > routing loop caused by an amnesiac DHCP-PD client it would be a > downstream interface. > The scenario when such traffic arrives from an uplink interface is > 'the uplink router believes the prefix is delegated to the client but > the relay does not have a route pointing to the client so it sends > traffic back' - so more likely 'an amnesiac relay' case. > > For point-to-point links, when the packet's ingress and egress interfaces > match. For multi-access links, when the packet's ingress and egress > interface match, and the source MAC and next-hop MAC addresses match. An > ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent as per [RFC4443], section 3.1. Th= e > ICMP policy SHOULD be configurable. > > - Bernie > > -----Original Message----- > From: ianfarrer@gmx.com > Sent: Tuesday, October 13, 2020 9:16 AM > To: Michael Richardson ; Jen Linkova < > furry13@gmail.com> > Cc: Bernie Volz (volz) ; dhcwg ; 6man < > ipv6@ietf.org>; v6ops list > Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > > Hi, > > Thanks for all of the discussion on this. We=E2=80=99ve reworked the requ= irement > as follows: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y > to drop client traffic as follows: For point-to-point links, when the > packet's ingress and egress interfaces match. For multi-access links, whe= n > the packet's ingress and egress interface match, and the source MAC and > next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination > Unreachable, reject route to > destination) error message MAY be sent back to the client. The ICMP > policy SHOULD be configurable. > > Thanks, > Ian > > On 9. Oct 2020, at 17:41, Michael Richardson > wrote: > > > Jen Linkova wrote: > > I think there is confusion re: the scenario we are talking about. > I've attached the diagram for the case which concerns me. > So: > - The Relay R has an interface eth0 connected to a switch S. > - Devices A and B are connected to the same switch and using R as a > default gateway. > - The prefix 2001:db8::/56 was delegated to a client A via the relay R. > > > a friendly amendment to your example to aid in human comprehension: > } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via > the relay R. > } - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0. > > - The device B (which has an address NOT from the delegated prefix, > but from another /64 assigned to that common link, let's sat > 2001:db8:cafe::/64) sends a packet to an address from the delegated > > > now, my brain can more clearly see that 2001:db8:cafe::/64 is not > within 2001:db8:0000:0123:/64, while I had to use a few extra brain > cells to see that it wasn't in that ::/56 :-) > > What I'd expect to happen (with DHCP-PD or without - e.g. if R has a > static route towards A, not a dynamic route produced by PD): > - the packet is sent to A. Well, if A does not have a route to > 2001:db8::42 then indeed a routing loop might happen. But if A does > have a route, the packet will be delivered. > > > What seems to be required by R4: > - R detects that the packet is received via eth0 and needs to be sent > back to eth0. R4 seems to require such packets to be dropped. > So if B would never be able to communicate to any address in the > delegated prefix, right? > > > Am I missing anything? > > > I think that you got it right. > > Perhaps the missing piece of the rule is don=E2=80=99t send it back to wh= ere it > came from, based on link layer addresses (or link if point-to-point). > > > Yes. If R4 was saying 'drop the packet if it comes from the same > link-layer address you are going to send it back' - it would make > total sense. But I don't think routers do *that*. > > > Yes, if we made the check on L2 address, then it would work. > And I agree that routers are exactly doing that. > > I think that it also works if B is a router with additional interfaces > downstream, unless there are multiple paths. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -- > SY, Jen Linkova aka Furry > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000c41aeb05b34795ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree with Bernie, = link-layer address would be an improvement to the Mac=C2=A0Address.

~Tim

On Wed, Nov 4, 2020 at 7:15 AM B= ernie Volz (volz) <volz=3D= 40cisco.com@dmarc.ietf.org> wrote:
Hi ... looks good but perhaps MAC address is too Ethernet specific and just= link-layer address would be better?

- Bernie

On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com" <<= a href=3D"mailto:ianfarrer@gmx.com" target=3D"_blank">ianfarrer@gmx.com= > wrote:

=EF=BB=BF
Hi,

Sorry for the delay in reply, I=E2=80=99= ve been out of the office for the last few weeks for various reasons.

Here=E2=80=99s a new wording proposal in= corporating=C2=A0Jen & Bernie=E2=80=99s suggestions:

R-4
To prevent routing loops, the relay SHOULD implement a configurable po= licy to drop packets
received on a DHCP-PD client facing interface with a destination address in= a prefix delegated
to a client connected to that interface, as follows: =C2=A0For point-to-poi= nt links,=C2=A0when the packet=E2=80=99s
ingress and egress interfaces match. For multi-access links, when the = packet=E2=80=99s=C2=A0ingress and
egress interface match, and the source MAC and next-hop MAC addresses = match. An
ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination= ) error message MAY
be sent as per [RFC4443], section 3.1.=C2=A0 The ICMP policy SHOULD be conf= igurable.

Thanks,
Ian

On 15. Oct 2020, at 03:51, Jen Linkova <furry13@gmail.com> wrote:

On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <volz@cisco.com> wrote:
If not, perhaps we just say:

R-4
To prevent routing loops, the relay SHOULD implement a configurable policy = to drop traffic received from an uplink interface as follows:

I'm not sure 'from an uplink interface' makes sense. In the cas= e of a
routing loop caused by an amnesiac DHCP-PD client it would be a
downstream interface.
The scenario when such traffic arrives from an uplink interface is
'the uplink router believes the prefix is delegated to the client but the relay does not have a route pointing to the client so it sends
traffic back' - so more likely 'an amnesiac relay' case.

For point-to-point links, when the packet's i= ngress and egress interfaces match. For multi-access links, when the packet= 's ingress and egress interface match, and the source MAC and next-hop = MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to
destination) error message MAY be sent as per [RFC4443], section 3.1.=C2=A0= The ICMP policy SHOULD be configurable.

- Bernie

-----Original Message-----
From: ianfarrer@gmx.= com <ianfarre= r@gmx.com>
Sent: Tuesday, October 13, 2020 9:16 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova <furry13@gmail.com>
Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg <dhcwg@ietf.org>; 6man <ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implem= entors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi,

Thanks for all of the discussion on this. We=E2=80=99ve reworked the requir= ement as follows:

R-4
To prevent routing loops, the relay SHOULD implement a configurable policy = to drop client traffic as follows: =C2=A0For point-to-point links, when the= packet's ingress and egress interfaces match. For multi-access links, = when the packet's ingress and egress interface match, and the source MAC and next-hop MAC addresses match. An ICMPv6 Type= 1, Code 6 (Destination Unreachable, reject route to
destination) error message MAY be sent back to the client.=C2=A0 The ICMP p= olicy SHOULD be configurable.

Thanks,
Ian

On 9. Oct 2020, at 17:41, Michael Richardson <= mcr+ietf@sandelm= an.ca> wrote:


Jen Linkova <furr= y13@gmail.com> wrote:
I think there is confusion re: the scenario we ar= e talking about.
I've attached the diagram for the case which concerns me.
So:
- The Relay R has an interface eth0 connected to a switch S.
- Devices A and B are connected to the same switch and using R as a
default gateway.
- The prefix 2001:db8::/56 was delegated to a client A via the relay R.

a friendly amendment to your example to aid in human comprehension:
=C2=A0=C2=A0=C2=A0} - The prefix 2001:db8:0000:0123:/64 was delegated to a = client A via the relay R.
=C2=A0=C2=A0=C2=A0} =C2=A0- R installs a route for 2001:db8:0000:0123:/64 t= owards A via eth0.

- The device B (which has an address NOT from the= delegated prefix,
but from another /64 assigned to that common link, let's sat
2001:db8:cafe::/64) sends a packet to an address from the delegated

now, my brain can more clearly see that 2001:db8:cafe::/64 is not
within 2001:db8:0000:0123:/64, while I had to use a few extra brain
cells to see that it wasn't in that ::/56 :-)

What I'd expect to happen (with DHCP-PD or wi= thout - e.g. if R has a
static route towards A, not a dynamic route produced by PD):
- the packet is sent to A. Well, if A does not have a route to
2001:db8::42 then indeed a routing loop might happen. But if A does
have a route, the packet will be delivered.

What seems to be required by R4:
- R detects that the packet is received via eth0 and needs to be sent
back to eth0. R4 seems to require such packets to be dropped.
So if B would never be able to communicate to any address in the
delegated prefix, right?

Am I missing anything?

I think that you got it right.

Perhaps the missing piece of the rule is don=E2= =80=99t send it back to where it came from, based on link layer addresses (= or link if point-to-point).

Yes. If R4 was saying 'drop the packet if it = comes from the same
link-layer address you are going to send it back' - it would make
total sense. But I don't think routers do *that*.

Yes, if we made the check on L2 address, then it would work.
And I agree that routers are exactly doing that.

I think that it also works if B is a router with additional interfaces
downstream, unless there are multiple paths.

--
Michael Richardson <mcr+IETF@sandelman.ca> =C2=A0=C2=A0. o O ( IPv6 I=C3=B8T cons= ulting )
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Sandelman Software Wo= rks Inc, Ottawa and Worldwide

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--
SY, Jen Linkova aka Furry

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000c41aeb05b34795ff-- From nobody Wed Nov 4 11:09:28 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01723A0E56 for ; Wed, 4 Nov 2020 11:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfY5ZY8ogP9W for ; Wed, 4 Nov 2020 11:09:25 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE193A0D44 for ; Wed, 4 Nov 2020 11:09:25 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id z3so2668059pfb.10 for ; Wed, 04 Nov 2020 11:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:reply-to:mime-version:subject :message-id:date:to; bh=wPhx/V3dUL6q0Iu0wZCKquR4oyxrumAPpkpdmgRkb6Y=; b=IiY0bCGfw1mV/wENgw8eXaMkgl/zgjiOKy7lYUHsM6ffpXOCD/Aj3zJp6P20cphTWu WRHKNYw8e71JppW0iu+Q4jtvMz1Lfbvbw/tbrnOb6oStAO00cpx7FXjI/8sC/M6d6eJd DhQGuuYkWz3d2/z6DaENPY39WNM1+G/Uo4rB7q/2SSo6N2x1ozejzFOUDif1Y7WeYJvc L9qqsgxmWoFvJ1gcACx93a+mBpxM7taWLZneRXM8i5qZFmrJnBFNu4gxacjh1QgKhBLQ 070Tt3wbr0zzIEtcC0dwt7qmsmo3dl93TSCS4BRut+yvFDVaXFQPrW5BIUK8xkDyqV0v S0rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:reply-to :mime-version:subject:message-id:date:to; bh=wPhx/V3dUL6q0Iu0wZCKquR4oyxrumAPpkpdmgRkb6Y=; b=V4qE7a8QCUkG2wFMiyPj+BC/XiWQQ7QxIIcZJ0DrTyWKEJmJqBaRZ79kA7s8j7TB+f +K6PLKgmmqznc7PGYF1idGKF61jeeijwt+i1G3dC0jXPiCCD9llfstDdeU+sw9+NusqS HtgxOwDo275wIp3Znsbl2t+paz2YaHKPEI+NgF/pkCOWhXugXmf4OuCJwVDxGECF9dE+ 32AcoIJjwhe0C/KBO/9BfG6vOOyPxWWEfcbZIgIwQUkXD8iNDqrzP7SL0bVanmpHzKI3 YvXaqvwRhApVDNmj0OxK7UJtp7H0CYcP1WLtENBdXZ3x5zp44OeZpIvZQiDR8mN5tNsL hjhg== X-Gm-Message-State: AOAM533fOIAxxVzc9FQYzngnIrwFNTxolkC54gJAgqATv2UUwu7usrmj GvIM31L4NVJmi4kPDrr5AUuaO5urysGZQg== X-Google-Smtp-Source: ABdhPJxNxiQEtrorDby54uYE0MvsxRCzfnUeXorQVGN7Hv6vyNsHWzBTSDW1DEupCjQUXEL4pSdwqQ== X-Received: by 2002:a17:90a:6683:: with SMTP id m3mr5868227pjj.225.1604516964772; Wed, 04 Nov 2020 11:09:24 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id ck21sm2933679pjb.56.2020.11.04.11.09.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2020 11:09:24 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: V6Ops-Chairs Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Message-Id: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> Date: Wed, 4 Nov 2020 11:09:23 -0800 To: IPv6 Operations X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: [v6ops] draft-peng-v6ops-hbh X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:09:27 -0000 Folks: The authors have asked Ron and I for time on the v6ops agenda for = https://tools.ietf.org/html/draft-peng-v6ops-hbh-01. I can find time if = you want it; my question is, with a grand total of three emails on the = topic, two from the authors and one from the secretariat announcing the = draft, is there interest? Let me ask you, once, to glance through the draft and let us know. Do = you want it on the agenda? Fred= From nobody Wed Nov 4 14:29:03 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B643A1092 for ; Wed, 4 Nov 2020 14:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyf7X42uY9IG for ; Wed, 4 Nov 2020 14:29:00 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8BF3A108F for ; Wed, 4 Nov 2020 14:29:00 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id t6so10958412plq.11 for ; Wed, 04 Nov 2020 14:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Qlj2nxAHUt+KZOX6OcMCcSYCb4YqqjokjBEc2vNnsHo=; b=mErbFLKSxZAhwQmsdj8ChWiiosXyT94mmIvLEvHuB/5jda3o+1pWuBMLQJBrjP0zkA F26his1bs05MMdIkJlz/5Z/VTCfYijg1a9/Wibj+ebYgXcaJ0/BJNSqjLqegZ/LAOuL3 OT3M9H3Cg90/LZLzGK2SAhtaTBVFDk2UJ0pDUV1qVU8c6GT9KQ7L59VU9UutUsgSjuLx w5eAWQmP86y/4t1Vrm0jG/4vulckdMCfDnaNQtUIRxjKYEqOnXCwRzXwxs/nHRSu4kAb U+X7b7D9A4SgLchTOyd6k5z8hqYuCFoHAhaO4NGFkrmBdrKua15lOSp12Qj0nUt7R3IA C38w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Qlj2nxAHUt+KZOX6OcMCcSYCb4YqqjokjBEc2vNnsHo=; b=BwT0rUe310pN4aRIheuz/X+KzGUstgKqsqJFubd71EQ80OC0w+gfbFZj1pR/uIlEid BpMhGO7P2F+6FJyIcFDsGbHA078ds3LD4e/eVFS76Omvfh9nZxw4BzGYTekbi3wwAumH GNaCHgzeqbpV3mFkKJADaorVn1KRzmD1R+H68DFBl1AdB3qPYy49jvVGj7wyVVFztcV+ DXoKMfnQY5d2DySWhNwzG7Qmloxu26tYeKjivlc63Nye+NdauLn/OoD9n8n7O8G9J9ng 2IE5TG+XQjcPeADK7hLlK5OCBAnlfiH1r46Ihonc4FRJwVygjQSStjib7QfdHaKFSDCj 6EJA== X-Gm-Message-State: AOAM533za5Ab2H+YYoEC8lxNZQpqQgP4PhSuIU5EhgbXbXIEVpLZl9I8 SXLG3nGVsIMt08e3cL6pT/8= X-Google-Smtp-Source: ABdhPJwGCKns/961Go4C1QcT3xrdhHxPxWGhZTtVDw0n2kui0WatQSqTHyQiEuksKIueMzytZf4lNw== X-Received: by 2002:a17:902:a9c9:b029:d6:2d8f:f7b4 with SMTP id b9-20020a170902a9c9b02900d62d8ff7b4mr175372plr.2.1604528940119; Wed, 04 Nov 2020 14:29:00 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id t26sm3659001pfl.72.2020.11.04.14.28.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2020 14:28:58 -0800 (PST) To: Lorenzo Colitti Cc: Gyan Mishra , Fred Baker , Dmytro Shytyi , Naveen Kottapalli , IPv6 Operations , Alexandre Petrescu , Gyan Mishra References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> From: Brian E Carpenter Message-ID: <33fd62eb-79d7-6560-f859-55724a1435e9@gmail.com> Date: Thu, 5 Nov 2020 11:28:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 22:29:02 -0000 On 04-Nov-20 22:20, Lorenzo Colitti wrote: > On Tue, Nov 3, 2020 at 5:09 AM Brian E Carpenter > wrote: >=20 > So let's have a discussion whether there is a new operational probl= em here first: >=20 > =C2=A0 "The main problem is that SLAAC RA or PD allocates a /64 by = the > =C2=A0 =C2=A0wireless carrier 4G, 5G, 3GPP to mobile handset or hot= spot, however > =C2=A0 =C2=A0segmentation of the /64 via SLAAC is required so that = downstream > =C2=A0 =C2=A0interfaces can be further sub-netted." >=20 > Why isn't that in v6ops scope? >=20 >=20 > I'd say that is not in scope anywhere because there already exists a pr= otocol that solves this problem. It's called DHCPv6 PD. I meant that if 5G doesn't already define how to support an IPv6 "hotspot= " solution, then there is an operational gap that could usefully be docum= ented. The current draft doesn't do that, because it assumes a class of s= olution (SLAAC-based instead of PD-based) rather than stating the underly= ing problem. Assuming that PD is the preferred solution, a description of how to do th= at in a 5G (or any 3GPP) deployment would be very desirable. If such a do= cument already exists outside the IETF, that would be fine too. =20 > If there is an operational problem with DHCPv6 PD, then that might inde= ed be in scope for v6ops. That's not what the draft is about though. As f= ar as I can see it doesn't mention DHCPv6 PD at all. The draft is about p= roposing a change to SLAAC, and as such is a protocol change that is not = in scope for v6ops. I agree that the draft as it stands is out of scope. I had to find the te= xt quoted above to understand what the underlying problem migh be. Brian From nobody Wed Nov 4 15:57:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13193A117F; Wed, 4 Nov 2020 15:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SqjQo5Qq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QZWgKlTs Received: 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-NCRQbWX_63; Wed, 4 Nov 2020 15:57:11 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841923A117D; Wed, 4 Nov 2020 15:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43578; q=dns/txt; s=iport; t=1604534231; x=1605743831; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9Xg/f55Bvy8C4biQMnkeR9bOijTwfgi88ugF7mGdfp4=; b=SqjQo5Qq3MCBqWwSEJCwUZwzpYZAOdvq9EWDriLOLQKzOSoGh4M9Y7kz vBAUmRNJ3FVshVwD9H4jQb1boKtem3wiPBZmbHTFUFto/8d1QLXQNm+Bj cd4bzuFB2Eax47sBhfkVF2vHn3a+9w+2/YCOTkb4/ypX+pjb6rsGlDWgu k=; IronPort-PHdr: =?us-ascii?q?9a23=3APfWU4hFzYmmRId5HHnvz9Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QWbXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgBYP6Nf/4ENJK1iHQEBAQEJARI?= =?us-ascii?q?BBQUBgX4FAQsBgSIvIy4HcFkvLgqEM4NJA41PihOObIJTA08FCwEBAQ0BARg?= =?us-ascii?q?BDAgCBAEBgVWCdQIXgXUCJTcGDgIDAQELAQEFAQEBAgEGBHGFYQELhXIBAQE?= =?us-ascii?q?BAwEBEBEKEwEBLAsBCwQCAQgRBAEBIQECBAMCAgIfBgsUCQgCBA4FCBqDBYF?= =?us-ascii?q?+TQMuAQ6lPQKBO4hodoEygwQBAQWBMwETQYJ9DQuCEAMGgTgBgnGDcYEGhVE?= =?us-ascii?q?bggCBEAFDgk8+ghtCAQECAQGBXRUPBwmCYTOCLJA8gR6CCocajAyQR1QKgm2?= =?us-ascii?q?JCoxshTWDGJ5Vk02Bfoh6gm6SXgIEAgQFAg4BAQWBaiQqgS1wFTuCNQEzCUc?= =?us-ascii?q?XAg2OHwwXFIM6hRSFRHQCNgIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,451,1596499200"; d="scan'208,217";a="581073670" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2020 23:57:10 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A4NvAOj005550 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2020 23:57:10 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 4 Nov 2020 17:57:09 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 4 Nov 2020 18:57:09 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 4 Nov 2020 17:57:08 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F7OPNSkTYyeZxvt+fl31WcZPWVkYzAS0eNkbYL/37LxbsbKVTnTs+PIWKLKhumQDvV42+nWlicdXw0hD5mdvOpbo3GGeAKTtjnnM5MDbB8Uuj77/mOqiBXm5S3EyRgt0ksu7b0EP7si0HMdlyv3UB7+ZUOn8B1txyF5Nm566oobnwQA5wgIWvTXcN5Yeq7GKOa3ehc2Pr4L9QYSi44d3mFbx7PJfv/MuPeC1LBBFXN4NiKq5co3xttLlbXr1DOnRw4/qkyUr5XGFb5f/uHNbgz5iwWjqUaqvVpbQl4tVbu3gpKyKJGk9tIDag7NUP+R6LXAZVBCRsB2zDevT1yFcrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Xg/f55Bvy8C4biQMnkeR9bOijTwfgi88ugF7mGdfp4=; b=KmjWi3JH8q4HLHpnp04C+l4CnxdGRsEsnJc1eSXTzAPXXTHr0yevyovMZkyMZWqaC4co0tWCBCAcQnfVPr1ishUadB9Nm7zkEXev6VOF+b1OvrrABdvW1ubz8gS/2BJRCFursAcO9G8kvHSfVn7YYT6Iwy5cefgUaS3mjWh7pK5hLHIfJNXukSgBDlfnFV0sCihvJuq9x5Jor5wxKU4yxKkSP2Jdb5b+7iZf+r2CteODyAK6SDo7G16Rg/dv7utA0CevNqgnxfhQlmaXumMR1b4QY1IF2I2WGbW24oUfEIU/l7CQrITHfD9VwCLL4hsZZEJ+sRx2/iqmzXyBwjsppA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Xg/f55Bvy8C4biQMnkeR9bOijTwfgi88ugF7mGdfp4=; b=QZWgKlTsysbYrkkEVuCYpie4z5lUvO4QdI732ArZ0Xi9HBTqySInftfAav4lTIFz4AOhg8f3ytRFVy8JoCiy5XAXpucC5amr3Uda3UMFOfyrXgo7VuEwXdfzsJKPLIF9v/+9lMppPbZOYkP/3eW8OAcnBmhmnDyFB9weFjbXqkE= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2785.namprd11.prod.outlook.com (2603:10b6:406:ac::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Wed, 4 Nov 2020 23:57:07 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::1dc1:e7f4:84ef:3711]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::1dc1:e7f4:84ef:3711%6]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 23:57:07 +0000 From: "Bernie Volz (volz)" To: "draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org" CC: v6ops list , dhcwg , "Eric Vyncke (evyncke)" Thread-Topic: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWoWMb7h/SuZNgk0iBKtkQ2d57eamVg+CAgAJkrICAFvSAAIAJKGCXgAANHACAALRpUA== Date: Wed, 4 Nov 2020 23:57:06 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 99666c57-f868-43e8-9059-08d8811d5611 x-ms-traffictypediagnostic: BN7PR11MB2785: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cOKZnaa7BVnx8PGq4youuxpIdhtnHwVPuR+aDJR6WhoUbyQEMAl2jBgBE59gb7KgDz7g8mr0X+MZJRiCaEJsc9WYI2XJ/cfLdf2yNK+vlpYKDspCjYDTOSXA7gnhBYZznEjwD4Y7kTV7kP1yrRWJ8QrlxlOz6dcWkncm+UiFGbc3EYJkX3l7jJzKyvPrGacYrmAgOtXlJsoEQ01h33SxZEh+xaR/VRXVrg1FM7KM0EkTpomucUv2I98LZiSFIoV28U4sXWQNNrV0KkqY1KizB5fSsG/5lecNff/Nfq65J1DW78BEh72PvvvmckZcIEbfVYz7Bct+b5TxcZM9R5X9VdZai5WMrgpueiys0gEnofdE4//TS/t8WNND1Nw0YK851MdZW2tprgKAkr6nLkGU6HNDS1WC0si1ybksE8PzaFJWnc1crzixcF0z3d5bdYOQnqlJDksNepNb0ZpkULy0Fw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(366004)(39860400002)(66476007)(64756008)(966005)(66556008)(9686003)(55016002)(166002)(66446008)(66946007)(54906003)(76116006)(8936002)(5660300002)(83380400001)(26005)(8676002)(7696005)(6506007)(107886003)(53546011)(2906002)(4326008)(6916009)(52536014)(450100002)(33656002)(86362001)(71200400001)(478600001)(66574015)(316002)(186003)(518174003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +AzyPAQdzJMSQsAXFC8fOjxuqylp/6GKIGMjY2OYiocpt5kIUmpj0PejjlA7/gpfxSCUGF+Opr06b4UqDLK62LZ8iB87wbKE04Ah7T6CPypMS2Rfd3x+Axs9tuVRrrbrD41whas8m/0AyZaNHolXLgiosIKewhop5Kf/cpLlmClkUaZvEFWxSj92zIwqbLPJ6rji6u4Qd7q/XqGV6g4Hh82USr5bh7msrQ2KA3Qu5stl7jAdnZMY/Rk0YhjOR8BRAxLgYnf7MCBZazFuhlS0CvIrd4WNj3Oz0r1u4PgwOxFFT0+T9H7vnI2wJiV7ntjIqeIS81/NbzrgKthcnqZFlpcSYLylqVGs5taodJ2bIDTosEZkAMrGC8DsyxLQsT3nmSoCZ1X4Qivife1RXmM5BZHtnfyMasWyCgAWOa1a4nQ4CbNONUvnAANF9KDdHF9Nc/84EZa3Bf43xBZeFsx9PtEL9lIDqEvtb2yc4qfeaKSWxhFf/DJjA+j+dtDT9A4IyGbbtqIi5o7OFKiGOIfPAAvkCittc3P8angxy6ooioLXnbUIDcl4ZLDBk3+vStqnrW8ehgxK8p78K50mQtn60E9i009sM375XQ2yhcFvsJJoEaLZ0VNmWl1kT06ceiLRo8Ry6FKdBobfjgpI+HYjNg== Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547DD143D784940F5524DA5CFEF0BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99666c57-f868-43e8-9059-08d8811d5611 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 23:57:06.9782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AmgIb9PNbhnNaLXTFnMWLmSW0ZNdatm9uJmX0Xmdp1s1Hr1jfDjL7HYcOpc+tImZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2785 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 23:57:15 -0000 --_000_BN7PR11MB2547DD143D784940F5524DA5CFEF0BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWxzbyB3b25kZXJpbmcgZ2l2ZW4gaXNzdWVzIHRoZSBJRVNHIHJhaXNlZCBmb3IgdGhl IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1y ZW51bSBkb2N1bWVudCByZWdhcmRpbmcgdGhlIHRleHTigKYNCjI8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtLTA1I3NlY3Rpb24tMj4u ICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UNCg0KICAgVGFrZSBjYXJlZnVsIG5vdGU6IFVubGlrZSBv dGhlciBJRVRGIGRvY3VtZW50cywgdGhlIGtleSB3b3JkcyAiTVVTVCIsDQogICAiTVVTVCBOT1Qi LCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9U IiwNCiAgICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3Vt ZW50IGFyZSBub3QgdXNlZCBhcw0KICAgZGVzY3JpYmVkIGluIFtSRkMyMTE5PGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmMyMTE5Pl0uICBUaGlzIGRvY3VtZW50IHVzZXMgdGhlc2Uga2V5 d29yZHMgbm90DQogICBzdHJpY3RseSBmb3IgdGhlIHB1cnBvc2Ugb2YgaW50ZXJvcGVyYWJpbGl0 eSwgYnV0IHJhdGhlciBmb3IgdGhlDQogICBwdXJwb3NlIG9mIGVzdGFibGlzaGluZyBpbmR1c3Ry eS1jb21tb24gYmFzZWxpbmUgZnVuY3Rpb25hbGl0eS4gIEFzDQogICBzdWNoLCB0aGUgZG9jdW1l bnQgcG9pbnRzIHRvIHNldmVyYWwgb3RoZXIgc3BlY2lmaWNhdGlvbnMgKHByZWZlcmFibGUNCiAg IGluIFJGQyBvciBzdGFibGUgZm9ybSkgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGd1aWRhbmNlIHRv IGltcGxlbWVudGVycw0KICAgcmVnYXJkaW5nIGFueSBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiBy ZXF1aXJlZCB0byBwcm9kdWNlIGENCiAgIHN1Y2Nlc3NmdWwgQ0Ugcm91dGVyIHRoYXQgaW50ZXJv cGVyYXRlcyBzdWNjZXNzZnVsbHkgd2l0aCBhDQogICBwYXJ0aWN1bGFyIHN1YnNldCBvZiBjdXJy ZW50bHkgZGVwbG95aW5nIGFuZCBwbGFubmVkIGNvbW1vbiBJUHY2DQogICBhY2Nlc3MgbmV0d29y a3MuDQoNCiAgIE5vdGU6IHRoZSBhZm9yZW1lbnRpb25lZCB0ZXJtcyBhcmUgdXNlZCBpbiBleGFj dGx5IHRoZSBzYW1lIHdheSBhcyBpbg0KICAgW1JGQzcwODQ8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzcwODQ+XSwgd2l0aCB0aGUgYWJvdmUgZXhwbGFuYXRpb24gY29waWVkIHZlcmJh dGltIGZyb20NCiAgIFNlY3Rpb24gMS4xIG9mIFtSRkM3MDg0XTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzA4NCNzZWN0aW9uLTEuMT4uDQoNClNlZSBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bS9iYWxsb3QvLg0K DQrigKYgd2hldGhlciBpdCB3b3VsZCBiZSB3aXNlIHRvIGZvbGxvdyB0aGUgSUVTRyBndWlkYW5j ZSBhbmQgZHJvcCB0aGUgc3BlY2lhbCB1c2UgKGluIHNlY3Rpb24gMi4zKT8gT3RoZXJ3aXNlLCB5 b3UgbWF5IHJ1biBpbnRvIHRoZSBzYW1lIGlzc3VlcyB0aGUgY3BlLXNsYWFjLXJlbnVtIGRvY3Vt ZW50IGRpZC4NCg0KSXQgbWF5IGJlIHdpc2UgdG8gd2FpdCB1bnRpbCB0aGUgZHVzdCBzZXR0bGVz IHdpdGggdGhhdCBkb2N1bWVudCBhbmQgdGhlIHRleHQgdGhhdCBpdCBlbmRzIHVwIHVzaW5nIChw ZXJoYXBzIGp1c3QgdGhlIGRlZmF1bHQgYm9pbGVycGxhdGUgZm9yIHRoZSBrZXl3b3JkcykuIEFu ZCBhcHBseSB0aGF0Lg0KDQpJIFdJTEwgYXNzdW1lIHlvdSB3aWxsIGRvIHRoYXQgKGFzIEkgYW0g Y3VycmVudGx5IHRoZSBvbmUgaG9sZGluZyB0aGUgZG9jdW1lbnQpIHVubGVzcyBJIGhlYXIgb3Ro ZXJ3aXNlIGZyb20geW91LiBPciwgeW91IGNvdWxkIGRlY2lkZSB0byBqdXN0IHVwZGF0ZSBpdCB0 byBmb2xsb3cgdGhlIHN0YW5kYXJkIGJvaWxlcnBsYXRlIGZvciB0aGVzZSBrZXl3b3JkcyDigJMg aWYgc28sIGJlIHN1cmUgdG8gdXNlIHRoZSBsYXRlc3QgdmVyc2lvbiwgc3VjaCBhcyB3aGF0IHdh cyB1c2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4OTI1IChzZWN0aW9uIDEu MSkuDQoNClRoYW5rcyENCg0KDQogICogICBCZXJuaWUNCg0KRnJvbTogZGhjd2cgPGRoY3dnLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUaW1vdGh5IFdpbnRlcnMNClNlbnQ6IFdlZG5l c2RheSwgTm92ZW1iZXIgNCwgMjAyMCA4OjAyIEFNDQpUbzogQmVybmllIFZvbHogKHZvbHopIDx2 b2x6PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IHY2b3BzIGxpc3QgPHY2b3BzQGll dGYub3JnPjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkaGN3Z10gW3Y2 b3BzXSBbRVhURVJOQUxdIFJlOiBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3Jz IHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzDQoN Cg0KSSBhZ3JlZSB3aXRoIEJlcm5pZSwgbGluay1sYXllciBhZGRyZXNzIHdvdWxkIGJlIGFuIGlt cHJvdmVtZW50IHRvIHRoZSBNYWMgQWRkcmVzcy4NCg0KflRpbQ0KDQpPbiBXZWQsIE5vdiA0LCAy MDIwIGF0IDc6MTUgQU0gQmVybmllIFZvbHogKHZvbHopIDx2b2x6PTQwY2lzY28uY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSGkg Li4uIGxvb2tzIGdvb2QgYnV0IHBlcmhhcHMgTUFDIGFkZHJlc3MgaXMgdG9vIEV0aGVybmV0IHNw ZWNpZmljIGFuZCBqdXN0IGxpbmstbGF5ZXIgYWRkcmVzcyB3b3VsZCBiZSBiZXR0ZXI/DQotIEJl cm5pZQ0KDQoNCk9uIE9jdCAyOSwgMjAyMCwgYXQgMTI6MjQgUE0sICJpYW5mYXJyZXJAZ214LmNv bTxtYWlsdG86aWFuZmFycmVyQGdteC5jb20+IiA8aWFuZmFycmVyQGdteC5jb208bWFpbHRvOmlh bmZhcnJlckBnbXguY29tPj4gd3JvdGU6DQrvu78NCkhpLA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5 IGluIHJlcGx5LCBJ4oCZdmUgYmVlbiBvdXQgb2YgdGhlIG9mZmljZSBmb3IgdGhlIGxhc3QgZmV3 IHdlZWtzIGZvciB2YXJpb3VzIHJlYXNvbnMuDQoNCkhlcmXigJlzIGEgbmV3IHdvcmRpbmcgcHJv cG9zYWwgaW5jb3Jwb3JhdGluZyBKZW4gJiBCZXJuaWXigJlzIHN1Z2dlc3Rpb25zOg0KDQpSLTQN ClRvIHByZXZlbnQgcm91dGluZyBsb29wcywgdGhlIHJlbGF5IFNIT1VMRCBpbXBsZW1lbnQgYSBj b25maWd1cmFibGUgcG9saWN5IHRvIGRyb3AgcGFja2V0cw0KcmVjZWl2ZWQgb24gYSBESENQLVBE IGNsaWVudCBmYWNpbmcgaW50ZXJmYWNlIHdpdGggYSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIGEg cHJlZml4IGRlbGVnYXRlZA0KdG8gYSBjbGllbnQgY29ubmVjdGVkIHRvIHRoYXQgaW50ZXJmYWNl LCBhcyBmb2xsb3dzOiAgRm9yIHBvaW50LXRvLXBvaW50IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXTi gJlzDQppbmdyZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlcyBtYXRjaC4gRm9yIG11bHRpLWFjY2Vz cyBsaW5rcywgd2hlbiB0aGUgcGFja2V04oCZcyBpbmdyZXNzIGFuZA0KZWdyZXNzIGludGVyZmFj ZSBtYXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1h dGNoLiBBbg0KSUNNUHY2IFR5cGUgMSwgQ29kZSA2IChEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwg cmVqZWN0IHJvdXRlIHRvIGRlc3RpbmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWQ0KYmUgc2VudCBh cyBwZXIgW1JGQzQ0NDNdLCBzZWN0aW9uIDMuMS4gIFRoZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUg Y29uZmlndXJhYmxlLg0KDQpUaGFua3MsDQpJYW4NCg0KT24gMTUuIE9jdCAyMDIwLCBhdCAwMzo1 MSwgSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNv bT4+IHdyb3RlOg0KDQpPbiBXZWQsIE9jdCAxNCwgMjAyMCBhdCAxMjo0NCBBTSBCZXJuaWUgVm9s eiAodm9seikgPHZvbHpAY2lzY28uY29tPG1haWx0bzp2b2x6QGNpc2NvLmNvbT4+IHdyb3RlOg0K DQpJZiBub3QsIHBlcmhhcHMgd2UganVzdCBzYXk6DQoNClItNA0KVG8gcHJldmVudCByb3V0aW5n IGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNvbmZpZ3VyYWJsZSBwb2xpY3kg dG8gZHJvcCB0cmFmZmljIHJlY2VpdmVkIGZyb20gYW4gdXBsaW5rIGludGVyZmFjZSBhcyBmb2xs b3dzOg0KDQpJJ20gbm90IHN1cmUgJ2Zyb20gYW4gdXBsaW5rIGludGVyZmFjZScgbWFrZXMgc2Vu c2UuIEluIHRoZSBjYXNlIG9mIGENCnJvdXRpbmcgbG9vcCBjYXVzZWQgYnkgYW4gYW1uZXNpYWMg REhDUC1QRCBjbGllbnQgaXQgd291bGQgYmUgYQ0KZG93bnN0cmVhbSBpbnRlcmZhY2UuDQpUaGUg c2NlbmFyaW8gd2hlbiBzdWNoIHRyYWZmaWMgYXJyaXZlcyBmcm9tIGFuIHVwbGluayBpbnRlcmZh Y2UgaXMNCid0aGUgdXBsaW5rIHJvdXRlciBiZWxpZXZlcyB0aGUgcHJlZml4IGlzIGRlbGVnYXRl ZCB0byB0aGUgY2xpZW50IGJ1dA0KdGhlIHJlbGF5IGRvZXMgbm90IGhhdmUgYSByb3V0ZSBwb2lu dGluZyB0byB0aGUgY2xpZW50IHNvIGl0IHNlbmRzDQp0cmFmZmljIGJhY2snIC0gc28gbW9yZSBs aWtlbHkgJ2FuIGFtbmVzaWFjIHJlbGF5JyBjYXNlLg0KDQoNCkZvciBwb2ludC10by1wb2ludCBs aW5rcywgd2hlbiB0aGUgcGFja2V0J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZXMgbWF0 Y2guIEZvciBtdWx0aS1hY2Nlc3MgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzIGluZ3Jlc3MgYW5k IGVncmVzcyBpbnRlcmZhY2UgbWF0Y2gsIGFuZCB0aGUgc291cmNlIE1BQyBhbmQgbmV4dC1ob3Ag TUFDIGFkZHJlc3NlcyBtYXRjaC4gQW4gSUNNUHY2IFR5cGUgMSwgQ29kZSA2IChEZXN0aW5hdGlv biBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvDQpkZXN0aW5hdGlvbikgZXJyb3IgbWVzc2Fn ZSBNQVkgYmUgc2VudCBhcyBwZXIgW1JGQzQ0NDNdLCBzZWN0aW9uIDMuMS4gIFRoZSBJQ01QIHBv bGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWFuZmFycmVyQGdteC5jb208bWFpbHRvOmlhbmZhcnJlckBn bXguY29tPiA8aWFuZmFycmVyQGdteC5jb208bWFpbHRvOmlhbmZhcnJlckBnbXguY29tPj4NClNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTMsIDIwMjAgOToxNiBBTQ0KVG86IE1pY2hhZWwgUmljaGFy ZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+ PjsgSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNv bT4+DQpDYzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBj aXNjby5jb20+PjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4+ OyA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj47IHY2b3BzIGxpc3Qg PHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2Ro Y3dnXSBbdjZvcHNdIFtFWFRFUk5BTF0gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBs ZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJl bWVudHMNCg0KSGksDQoNClRoYW5rcyBmb3IgYWxsIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMu IFdl4oCZdmUgcmV3b3JrZWQgdGhlIHJlcXVpcmVtZW50IGFzIGZvbGxvd3M6DQoNClItNA0KVG8g cHJldmVudCByb3V0aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNvbmZp Z3VyYWJsZSBwb2xpY3kgdG8gZHJvcCBjbGllbnQgdHJhZmZpYyBhcyBmb2xsb3dzOiAgRm9yIHBv aW50LXRvLXBvaW50IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdyZXNzIGFuZCBlZ3Jlc3Mg aW50ZXJmYWNlcyBtYXRjaC4gRm9yIG11bHRpLWFjY2VzcyBsaW5rcywgd2hlbiB0aGUgcGFja2V0 J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBtYXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFD IGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1hdGNoLiBBbiBJQ01QdjYgVHlwZSAxLCBDb2Rl IDYgKERlc3RpbmF0aW9uIFVucmVhY2hhYmxlLCByZWplY3Qgcm91dGUgdG8NCmRlc3RpbmF0aW9u KSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gIFRoZSBJQ01Q IHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0KDQpUaGFua3MsDQpJYW4NCg0KDQpPbiA5 LiBPY3QgMjAyMCwgYXQgMTc6NDEsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVs bWFuLmNhPG1haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+PiB3cm90ZToNCg0KDQpKZW4gTGlu a292YSA8ZnVycnkxM0BnbWFpbC5jb208bWFpbHRvOmZ1cnJ5MTNAZ21haWwuY29tPj4gd3JvdGU6 DQoNCkkgdGhpbmsgdGhlcmUgaXMgY29uZnVzaW9uIHJlOiB0aGUgc2NlbmFyaW8gd2UgYXJlIHRh bGtpbmcgYWJvdXQuDQpJJ3ZlIGF0dGFjaGVkIHRoZSBkaWFncmFtIGZvciB0aGUgY2FzZSB3aGlj aCBjb25jZXJucyBtZS4NClNvOg0KLSBUaGUgUmVsYXkgUiBoYXMgYW4gaW50ZXJmYWNlIGV0aDAg Y29ubmVjdGVkIHRvIGEgc3dpdGNoIFMuDQotIERldmljZXMgQSBhbmQgQiBhcmUgY29ubmVjdGVk IHRvIHRoZSBzYW1lIHN3aXRjaCBhbmQgdXNpbmcgUiBhcyBhDQpkZWZhdWx0IGdhdGV3YXkuDQot IFRoZSBwcmVmaXggMjAwMTpkYjg6Oi81NiB3YXMgZGVsZWdhdGVkIHRvIGEgY2xpZW50IEEgdmlh IHRoZSByZWxheSBSLg0KDQphIGZyaWVuZGx5IGFtZW5kbWVudCB0byB5b3VyIGV4YW1wbGUgdG8g YWlkIGluIGh1bWFuIGNvbXByZWhlbnNpb246DQogICB9IC0gVGhlIHByZWZpeCAyMDAxOmRiODow MDAwOjAxMjM6LzY0IHdhcyBkZWxlZ2F0ZWQgdG8gYSBjbGllbnQgQSB2aWEgdGhlIHJlbGF5IFIu DQogICB9ICAtIFIgaW5zdGFsbHMgYSByb3V0ZSBmb3IgMjAwMTpkYjg6MDAwMDowMTIzOi82NCB0 b3dhcmRzIEEgdmlhIGV0aDAuDQoNCg0KLSBUaGUgZGV2aWNlIEIgKHdoaWNoIGhhcyBhbiBhZGRy ZXNzIE5PVCBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LA0KYnV0IGZyb20gYW5vdGhlciAvNjQg YXNzaWduZWQgdG8gdGhhdCBjb21tb24gbGluaywgbGV0J3Mgc2F0DQoyMDAxOmRiODpjYWZlOjov NjQpIHNlbmRzIGEgcGFja2V0IHRvIGFuIGFkZHJlc3MgZnJvbSB0aGUgZGVsZWdhdGVkDQoNCm5v dywgbXkgYnJhaW4gY2FuIG1vcmUgY2xlYXJseSBzZWUgdGhhdCAyMDAxOmRiODpjYWZlOjovNjQg aXMgbm90DQp3aXRoaW4gMjAwMTpkYjg6MDAwMDowMTIzOi82NCwgd2hpbGUgSSBoYWQgdG8gdXNl IGEgZmV3IGV4dHJhIGJyYWluDQpjZWxscyB0byBzZWUgdGhhdCBpdCB3YXNuJ3QgaW4gdGhhdCA6 Oi81NiA6LSkNCg0KDQpXaGF0IEknZCBleHBlY3QgdG8gaGFwcGVuICh3aXRoIERIQ1AtUEQgb3Ig d2l0aG91dCAtIGUuZy4gaWYgUiBoYXMgYQ0Kc3RhdGljIHJvdXRlIHRvd2FyZHMgQSwgbm90IGEg ZHluYW1pYyByb3V0ZSBwcm9kdWNlZCBieSBQRCk6DQotIHRoZSBwYWNrZXQgaXMgc2VudCB0byBB LiBXZWxsLCBpZiBBIGRvZXMgbm90IGhhdmUgYSByb3V0ZSB0bw0KMjAwMTpkYjg6OjQyIHRoZW4g aW5kZWVkIGEgcm91dGluZyBsb29wIG1pZ2h0IGhhcHBlbi4gQnV0IGlmIEEgZG9lcw0KaGF2ZSBh IHJvdXRlLCB0aGUgcGFja2V0IHdpbGwgYmUgZGVsaXZlcmVkLg0KDQoNCldoYXQgc2VlbXMgdG8g YmUgcmVxdWlyZWQgYnkgUjQ6DQotIFIgZGV0ZWN0cyB0aGF0IHRoZSBwYWNrZXQgaXMgcmVjZWl2 ZWQgdmlhIGV0aDAgYW5kIG5lZWRzIHRvIGJlIHNlbnQNCmJhY2sgdG8gZXRoMC4gUjQgc2VlbXMg dG8gcmVxdWlyZSBzdWNoIHBhY2tldHMgdG8gYmUgZHJvcHBlZC4NClNvIGlmIEIgd291bGQgbmV2 ZXIgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0byBhbnkgYWRkcmVzcyBpbiB0aGUNCmRlbGVnYXRl ZCBwcmVmaXgsIHJpZ2h0Pw0KDQoNCkFtIEkgbWlzc2luZyBhbnl0aGluZz8NCg0KSSB0aGluayB0 aGF0IHlvdSBnb3QgaXQgcmlnaHQuDQoNCg0KUGVyaGFwcyB0aGUgbWlzc2luZyBwaWVjZSBvZiB0 aGUgcnVsZSBpcyBkb27igJl0IHNlbmQgaXQgYmFjayB0byB3aGVyZSBpdCBjYW1lIGZyb20sIGJh c2VkIG9uIGxpbmsgbGF5ZXIgYWRkcmVzc2VzIChvciBsaW5rIGlmIHBvaW50LXRvLXBvaW50KS4N Cg0KDQpZZXMuIElmIFI0IHdhcyBzYXlpbmcgJ2Ryb3AgdGhlIHBhY2tldCBpZiBpdCBjb21lcyBm cm9tIHRoZSBzYW1lDQpsaW5rLWxheWVyIGFkZHJlc3MgeW91IGFyZSBnb2luZyB0byBzZW5kIGl0 IGJhY2snIC0gaXQgd291bGQgbWFrZQ0KdG90YWwgc2Vuc2UuIEJ1dCBJIGRvbid0IHRoaW5rIHJv dXRlcnMgZG8gKnRoYXQqLg0KDQpZZXMsIGlmIHdlIG1hZGUgdGhlIGNoZWNrIG9uIEwyIGFkZHJl c3MsIHRoZW4gaXQgd291bGQgd29yay4NCkFuZCBJIGFncmVlIHRoYXQgcm91dGVycyBhcmUgZXhh Y3RseSBkb2luZyB0aGF0Lg0KDQpJIHRoaW5rIHRoYXQgaXQgYWxzbyB3b3JrcyBpZiBCIGlzIGEg cm91dGVyIHdpdGggYWRkaXRpb25hbCBpbnRlcmZhY2VzDQpkb3duc3RyZWFtLCB1bmxlc3MgdGhl cmUgYXJlIG11bHRpcGxlIHBhdGhzLg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVU RkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitJRVRGQHNhbmRlbG1hbi5jYT4+ICAgLiBvIE8gKCBJ UHY2IEnDuFQgY29uc3VsdGluZyApDQogICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3Mg SW5jLCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3Jn Pg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0tDQpTWSwgSmVuIExpbmtvdmEgYWth IEZ1cnJ5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== --_000_BN7PR11MB2547DD143D784940F5524DA5CFEF0BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTkxNTk1ODE4Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzc3ODM0NTIgLTI2ODYwNTY4 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIGFs c28gd29uZGVyaW5nIGdpdmVuIGlzc3VlcyB0aGUgSUVTRyByYWlzZWQgZm9yIHRoZSA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMt cmVudW0iPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtY3Bl LXNsYWFjLXJlbnVtPC9hPiBkb2N1bWVudCByZWdhcmRpbmcgdGhlIHRleHTigKY8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ic2VjdGlvbi0yIj48L2E+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtY3BlLXNs YWFjLXJlbnVtLTA1I3NlY3Rpb24tMiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpzZWN0aW9u LTIiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4yPC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpzZWN0aW9uLTIiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpzZWN0aW9uLTIiPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LiZuYnNw Ow0KIFJlcXVpcmVtZW50cyBMYW5ndWFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBUYWtlIGNhcmVmdWwgbm90ZTogVW5saWtlIG90aGVyIElFVEYgZG9jdW1lbnRz LCB0aGUga2V5IHdvcmRzICZxdW90O01VU1QmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAm cXVvdDtNVVNUIE5PVCZxdW90OywgJnF1b3Q7UkVRVUlSRUQmcXVvdDssICZxdW90O1NIQUxMJnF1 b3Q7LCAmcXVvdDtTSEFMTCBOT1QmcXVvdDssICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hP VUxEIE5PVCZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZxdW90O1JFQ09NTUVOREVEJnF1 b3Q7LCAmcXVvdDtNQVkmcXVvdDssIGFuZCAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlzIGRv Y3VtZW50IGFyZSBub3QgdXNlZCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZGVzY3JpYmVkIGlu IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjExOSIgdGl0bGU9IiZx dW90O0tleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2 ZWxzJnF1b3Q7Ij5SRkMyMTE5PC9hPl0uJm5ic3A7IFRoaXMgZG9jdW1lbnQgdXNlcyB0aGVzZQ0K IGtleXdvcmRzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc3RyaWN0bHkgZm9yIHRoZSBwdXJw b3NlIG9mIGludGVyb3BlcmFiaWxpdHksIGJ1dCByYXRoZXIgZm9yIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgcHVycG9zZSBvZiBlc3RhYmxpc2hpbmcgaW5kdXN0cnktY29tbW9uIGJhc2VsaW5l IGZ1bmN0aW9uYWxpdHkuJm5ic3A7IEFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzdWNoLCB0aGUg ZG9jdW1lbnQgcG9pbnRzIHRvIHNldmVyYWwgb3RoZXIgc3BlY2lmaWNhdGlvbnMgKHByZWZlcmFi bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluIFJGQyBvciBzdGFibGUgZm9ybSkgdG8gcHJvdmlk ZSBhZGRpdGlvbmFsIGd1aWRhbmNlIHRvIGltcGxlbWVudGVyczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgcmVnYXJkaW5nIGFueSBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiByZXF1aXJlZCB0byBwcm9k dWNlIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN1Y2Nlc3NmdWwgQ0Ugcm91dGVyIHRoYXQgaW50 ZXJvcGVyYXRlcyBzdWNjZXNzZnVsbHkgd2l0aCBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXJ0 aWN1bGFyIHN1YnNldCBvZiBjdXJyZW50bHkgZGVwbG95aW5nIGFuZCBwbGFubmVkIGNvbW1vbiBJ UHY2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY2Nlc3MgbmV0d29ya3MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgTm90ZTogdGhlIGFmb3JlbWVudGlvbmVkIHRlcm1zIGFy ZSB1c2VkIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5IGFzIGluPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwODQiIHRpdGxlPSIm cXVvdDtCYXNpYyBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJzJnF1 b3Q7Ij5SRkM3MDg0PC9hPl0sIHdpdGggdGhlIGFib3ZlIGV4cGxhbmF0aW9uIGNvcGllZCB2ZXJi YXRpbQ0KIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzA4NCNzZWN0aW9uLTEuMSI+U2VjdGlvbiZuYnNwOzEuMSBvZiBb UkZDNzA4NF08L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlIDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtY3BlLXNs YWFjLXJlbnVtL2JhbGxvdC8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW0vYmFsbG90LzwvYT4uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKApiB3aGV0aGVyIGl0IHdvdWxkIGJlIHdpc2UgdG8gZm9sbG93IHRoZSBJRVNH IGd1aWRhbmNlIGFuZCBkcm9wIHRoZSBzcGVjaWFsIHVzZSAoaW4gc2VjdGlvbiAyLjMpPyBPdGhl cndpc2UsIHlvdSBtYXkgcnVuIGludG8gdGhlIHNhbWUgaXNzdWVzIHRoZSBjcGUtc2xhYWMtcmVu dW0gZG9jdW1lbnQgZGlkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtYXkgYmUgd2lzZSB0 byB3YWl0IHVudGlsIHRoZSBkdXN0IHNldHRsZXMgd2l0aCB0aGF0IGRvY3VtZW50IGFuZCB0aGUg dGV4dCB0aGF0IGl0IGVuZHMgdXAgdXNpbmcgKHBlcmhhcHMganVzdCB0aGUgZGVmYXVsdCBib2ls ZXJwbGF0ZSBmb3IgdGhlIGtleXdvcmRzKS4gQW5kIGFwcGx5IHRoYXQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgV0lMTCBhc3N1bWUgeW91IHdpbGwgZG8gdGhhdCAoYXMgSSBhbSBjdXJyZW50 bHkgdGhlIG9uZSBob2xkaW5nIHRoZSBkb2N1bWVudCkgdW5sZXNzIEkgaGVhciBvdGhlcndpc2Ug ZnJvbSB5b3UuIE9yLCB5b3UgY291bGQgZGVjaWRlIHRvIGp1c3QgdXBkYXRlIGl0IHRvIGZvbGxv dyB0aGUgc3RhbmRhcmQgYm9pbGVycGxhdGUgZm9yIHRoZXNlIGtleXdvcmRzIOKAkyBpZiBzbywg YmUgc3VyZSB0byB1c2UgdGhlIGxhdGVzdA0KIHZlcnNpb24sIHN1Y2ggYXMgd2hhdCB3YXMgdXNl ZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODkyNSI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODkyNTwvYT4gKHNlY3Rpb24gMS4xKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+QmVybmllPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBkaGN3 ZyAmbHQ7ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NClRp bW90aHkgV2ludGVyczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDQsIDIw MjAgODowMiBBTTxicj4NCjxiPlRvOjwvYj4gQmVybmllIFZvbHogKHZvbHopICZsdDt2b2x6PTQw Y2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gdjZvcHMgbGlzdCAm bHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyBkaGN3ZyAmbHQ7ZGhjd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbZGhjd2ddIFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogUXVlc3Rp b24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMt ZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIEJlcm5pZSwgbGluay1sYXll ciBhZGRyZXNzIHdvdWxkIGJlIGFuIGltcHJvdmVtZW50IHRvIHRoZSBNYWMmbmJzcDtBZGRyZXNz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+flRpbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92IDQsIDIwMjAgYXQgNzoxNSBBTSBCZXJuaWUgVm9s eiAodm9seikgJmx0O3ZvbHo9PGEgaHJlZj0ibWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYu b3JnIj40MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgLi4uIGxvb2tzIGdvb2QgYnV0IHBlcmhhcHMg TUFDIGFkZHJlc3MgaXMgdG9vIEV0aGVybmV0IHNwZWNpZmljIGFuZCBqdXN0IGxpbmstbGF5ZXIg YWRkcmVzcyB3b3VsZCBiZSBiZXR0ZXI/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSBCZXJuaWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIE9jdCAyOSwgMjAyMCwg YXQgMTI6MjQgUE0sICZxdW90OzxhIGhyZWY9Im1haWx0bzppYW5mYXJyZXJAZ214LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmlhbmZhcnJlckBnbXguY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlhbmZhcnJlckBnbXguY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuZmFycmVyQGdteC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+77u/IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvcnJ5IGZvciB0 aGUgZGVsYXkgaW4gcmVwbHksIEnigJl2ZSBiZWVuIG91dCBvZiB0aGUgb2ZmaWNlIGZvciB0aGUg bGFzdCBmZXcgd2Vla3MgZm9yIHZhcmlvdXMgcmVhc29ucy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+SGVyZeKAmXMgYSBuZXcgd29yZGluZyBwcm9wb3NhbCBpbmNvcnBvcmF0aW5nPC9z cGFuPiZuYnNwO0plbiAmYW1wOyBCZXJuaWXigJlzIHN1Z2dlc3Rpb25zOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ui00PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBwcmV2ZW50 IHJvdXRpbmcgbG9vcHMsIHRoZSByZWxheSBTSE9VTEQgaW1wbGVtZW50IGEgY29uZmlndXJhYmxl IHBvbGljeSB0byBkcm9wIHBhY2tldHM8YnI+DQpyZWNlaXZlZCBvbiBhIERIQ1AtUEQgY2xpZW50 IGZhY2luZyBpbnRlcmZhY2Ugd2l0aCBhIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gYSBwcmVmaXgg ZGVsZWdhdGVkPGJyPg0KdG8gYSBjbGllbnQgY29ubmVjdGVkIHRvIHRoYXQgaW50ZXJmYWNlLCBh cyBmb2xsb3dzOiAmbmJzcDtGb3IgcG9pbnQtdG8tcG9pbnQgbGlua3MsJm5ic3A7d2hlbiB0aGUg cGFja2V04oCZczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+aW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZXMgbWF0Y2guIEZvciBtdWx0aS1hY2Nl c3MgbGlua3MsIHdoZW4gdGhlIHBhY2tldOKAmXMmbmJzcDtpbmdyZXNzIGFuZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZWdyZXNzIGludGVyZmFj ZSBtYXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1h dGNoLiBBbjxicj4NCklDTVB2NiBUeXBlIDEsIENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFi bGUsIHJlamVjdCByb3V0ZSB0byBkZXN0aW5hdGlvbikgZXJyb3IgbWVzc2FnZSBNQVk8YnI+DQpi ZSBzZW50IGFzIHBlciBbUkZDNDQ0M10sIHNlY3Rpb24gMy4xLiZuYnNwOyBUaGUgSUNNUCBwb2xp Y3kgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE1 LiBPY3QgMjAyMCwgYXQgMDM6NTEsIEplbiBMaW5rb3ZhICZsdDs8YSBocmVmPSJtYWlsdG86ZnVy cnkxM0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mdXJyeTEzQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBPY3QgMTQsIDIwMjAgYXQgMTI6NDQgQU0gQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBo cmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj52b2x6QGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiBub3QsIHBlcmhhcHMgd2UganVzdCBzYXk6PGJyPg0KPGJyPg0KUi00PGJy Pg0KVG8gcHJldmVudCByb3V0aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBh IGNvbmZpZ3VyYWJsZSBwb2xpY3kgdG8gZHJvcCB0cmFmZmljIHJlY2VpdmVkIGZyb20gYW4gdXBs aW5rIGludGVyZmFjZSBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSdtIG5vdCBzdXJlICdmcm9tIGFuIHVwbGluayBp bnRlcmZhY2UnIG1ha2VzIHNlbnNlLiBJbiB0aGUgY2FzZSBvZiBhPGJyPg0Kcm91dGluZyBsb29w IGNhdXNlZCBieSBhbiBhbW5lc2lhYyBESENQLVBEIGNsaWVudCBpdCB3b3VsZCBiZSBhPGJyPg0K ZG93bnN0cmVhbSBpbnRlcmZhY2UuPGJyPg0KVGhlIHNjZW5hcmlvIHdoZW4gc3VjaCB0cmFmZmlj IGFycml2ZXMgZnJvbSBhbiB1cGxpbmsgaW50ZXJmYWNlIGlzPGJyPg0KJ3RoZSB1cGxpbmsgcm91 dGVyIGJlbGlldmVzIHRoZSBwcmVmaXggaXMgZGVsZWdhdGVkIHRvIHRoZSBjbGllbnQgYnV0PGJy Pg0KdGhlIHJlbGF5IGRvZXMgbm90IGhhdmUgYSByb3V0ZSBwb2ludGluZyB0byB0aGUgY2xpZW50 IHNvIGl0IHNlbmRzPGJyPg0KdHJhZmZpYyBiYWNrJyAtIHNvIG1vcmUgbGlrZWx5ICdhbiBhbW5l c2lhYyByZWxheScgY2FzZS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHBvaW50LXRvLXBvaW50IGxpbmtzLCB3aGVuIHRoZSBwYWNr ZXQncyBpbmdyZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlcyBtYXRjaC4gRm9yIG11bHRpLWFjY2Vz cyBsaW5rcywgd2hlbiB0aGUgcGFja2V0J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBt YXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1hdGNo LiBBbiBJQ01QdjYgVHlwZSAxLCBDb2RlIDYNCiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJl amVjdCByb3V0ZSB0bzxicj4NCmRlc3RpbmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50 IGFzIHBlciBbUkZDNDQ0M10sIHNlY3Rpb24gMy4xLiZuYnNwOyBUaGUgSUNNUCBwb2xpY3kgU0hP VUxEIGJlIGNvbmZpZ3VyYWJsZS48YnI+DQo8YnI+DQotIEJlcm5pZTxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmlhbmZhcnJl ckBnbXguY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuZmFycmVyQGdteC5jb208L2E+ICZsdDs8YSBo cmVmPSJtYWlsdG86aWFuZmFycmVyQGdteC5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5mYXJyZXJA Z214LmNvbTwvYT4mZ3Q7PGJyPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMywgMjAyMCA5OjE2 IEFNPGJyPg0KVG86IE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jcitp ZXRmQHNhbmRlbG1hbi5jYSIgdGFyZ2V0PSJfYmxhbmsiPm1jcitpZXRmQHNhbmRlbG1hbi5jYTwv YT4mZ3Q7OyBKZW4gTGlua292YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZ1cnJ5MTNAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZnVycnkxM0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCkNjOiBCZXJu aWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1haWx0bzp2b2x6QGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnZvbHpAY2lzY28uY29tPC9hPiZndDs7IGRoY3dnICZsdDs8YSBocmVmPSJtYWls dG86ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kaGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7 OyA2bWFuICZsdDs8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlwdjZAaWV0Zi5vcmc8L2E+Jmd0OzsgdjZvcHMgbGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N ClN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogUXVlc3Rpb24gdG8g REhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2 LXBkLXJlbGF5LXJlcXVpcmVtZW50czxicj4NCjxicj4NCkhpLDxicj4NCjxicj4NClRoYW5rcyBm b3IgYWxsIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMuIFdl4oCZdmUgcmV3b3JrZWQgdGhlIHJl cXVpcmVtZW50IGFzIGZvbGxvd3M6PGJyPg0KPGJyPg0KUi00PGJyPg0KVG8gcHJldmVudCByb3V0 aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNvbmZpZ3VyYWJsZSBwb2xp Y3kgdG8gZHJvcCBjbGllbnQgdHJhZmZpYyBhcyBmb2xsb3dzOiAmbmJzcDtGb3IgcG9pbnQtdG8t cG9pbnQgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzIGluZ3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZh Y2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdy ZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlDQogbWF0Y2gsIGFuZCB0aGUgc291cmNlIE1BQyBhbmQg bmV4dC1ob3AgTUFDIGFkZHJlc3NlcyBtYXRjaC4gQW4gSUNNUHY2IFR5cGUgMSwgQ29kZSA2IChE ZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvPGJyPg0KZGVzdGluYXRpb24p IGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0aGUgY2xpZW50LiZuYnNwOyBUaGUg SUNNUCBwb2xpY3kgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KSWFuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDkuIE9jdCAyMDIwLCBhdCAxNzo0MSwgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8 YSBocmVmPSJtYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhIiB0YXJnZXQ9Il9ibGFuayI+bWNy K2lldGZAc2FuZGVsbWFuLmNhPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KSmVuIExp bmtvdmEgJmx0OzxhIGhyZWY9Im1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmZ1cnJ5MTNAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlcmUgaXMgY29uZnVzaW9u IHJlOiB0aGUgc2NlbmFyaW8gd2UgYXJlIHRhbGtpbmcgYWJvdXQuPGJyPg0KSSd2ZSBhdHRhY2hl ZCB0aGUgZGlhZ3JhbSBmb3IgdGhlIGNhc2Ugd2hpY2ggY29uY2VybnMgbWUuPGJyPg0KU286PGJy Pg0KLSBUaGUgUmVsYXkgUiBoYXMgYW4gaW50ZXJmYWNlIGV0aDAgY29ubmVjdGVkIHRvIGEgc3dp dGNoIFMuPGJyPg0KLSBEZXZpY2VzIEEgYW5kIEIgYXJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZSBz d2l0Y2ggYW5kIHVzaW5nIFIgYXMgYTxicj4NCmRlZmF1bHQgZ2F0ZXdheS48YnI+DQotIFRoZSBw cmVmaXggMjAwMTpkYjg6Oi81NiB3YXMgZGVsZWdhdGVkIHRvIGEgY2xpZW50IEEgdmlhIHRoZSBy ZWxheSBSLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KYSBmcmllbmRseSBhbWVuZG1lbnQgdG8geW91ciBleGFtcGxlIHRvIGFpZCBpbiBo dW1hbiBjb21wcmVoZW5zaW9uOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO30gLSBUaGUgcHJlZml4 IDIwMDE6ZGI4OjAwMDA6MDEyMzovNjQgd2FzIGRlbGVnYXRlZCB0byBhIGNsaWVudCBBIHZpYSB0 aGUgcmVsYXkgUi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDt9ICZuYnNwOy0gUiBpbnN0YWxscyBh IHJvdXRlIGZvciAyMDAxOmRiODowMDAwOjAxMjM6LzY0IHRvd2FyZHMgQSB2aWEgZXRoMC48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBU aGUgZGV2aWNlIEIgKHdoaWNoIGhhcyBhbiBhZGRyZXNzIE5PVCBmcm9tIHRoZSBkZWxlZ2F0ZWQg cHJlZml4LDxicj4NCmJ1dCBmcm9tIGFub3RoZXIgLzY0IGFzc2lnbmVkIHRvIHRoYXQgY29tbW9u IGxpbmssIGxldCdzIHNhdDxicj4NCjIwMDE6ZGI4OmNhZmU6Oi82NCkgc2VuZHMgYSBwYWNrZXQg dG8gYW4gYWRkcmVzcyBmcm9tIHRoZSBkZWxlZ2F0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCm5vdywgbXkgYnJhaW4gY2FuIG1vcmUg Y2xlYXJseSBzZWUgdGhhdCAyMDAxOmRiODpjYWZlOjovNjQgaXMgbm90PGJyPg0Kd2l0aGluIDIw MDE6ZGI4OjAwMDA6MDEyMzovNjQsIHdoaWxlIEkgaGFkIHRvIHVzZSBhIGZldyBleHRyYSBicmFp bjxicj4NCmNlbGxzIHRvIHNlZSB0aGF0IGl0IHdhc24ndCBpbiB0aGF0IDo6LzU2IDotKTxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0 IEknZCBleHBlY3QgdG8gaGFwcGVuICh3aXRoIERIQ1AtUEQgb3Igd2l0aG91dCAtIGUuZy4gaWYg UiBoYXMgYTxicj4NCnN0YXRpYyByb3V0ZSB0b3dhcmRzIEEsIG5vdCBhIGR5bmFtaWMgcm91dGUg cHJvZHVjZWQgYnkgUEQpOjxicj4NCi0gdGhlIHBhY2tldCBpcyBzZW50IHRvIEEuIFdlbGwsIGlm IEEgZG9lcyBub3QgaGF2ZSBhIHJvdXRlIHRvPGJyPg0KMjAwMTpkYjg6OjQyIHRoZW4gaW5kZWVk IGEgcm91dGluZyBsb29wIG1pZ2h0IGhhcHBlbi4gQnV0IGlmIEEgZG9lczxicj4NCmhhdmUgYSBy b3V0ZSwgdGhlIHBhY2tldCB3aWxsIGJlIGRlbGl2ZXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHNlZW1zIHRvIGJlIHJlcXVpcmVkIGJ5IFI0 Ojxicj4NCi0gUiBkZXRlY3RzIHRoYXQgdGhlIHBhY2tldCBpcyByZWNlaXZlZCB2aWEgZXRoMCBh bmQgbmVlZHMgdG8gYmUgc2VudDxicj4NCmJhY2sgdG8gZXRoMC4gUjQgc2VlbXMgdG8gcmVxdWly ZSBzdWNoIHBhY2tldHMgdG8gYmUgZHJvcHBlZC48YnI+DQpTbyBpZiBCIHdvdWxkIG5ldmVyIGJl IGFibGUgdG8gY29tbXVuaWNhdGUgdG8gYW55IGFkZHJlc3MgaW4gdGhlPGJyPg0KZGVsZWdhdGVk IHByZWZpeCwgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW0gSSBtaXNzaW5nIGFueXRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSB0aGluayB0aGF0IHlvdSBnb3QgaXQgcmln aHQuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGVyaGFwcyB0aGUgbWlzc2luZyBwaWVjZSBvZiB0aGUgcnVsZSBpcyBkb27igJl0IHNl bmQgaXQgYmFjayB0byB3aGVyZSBpdCBjYW1lIGZyb20sIGJhc2VkIG9uIGxpbmsgbGF5ZXIgYWRk cmVzc2VzIChvciBsaW5rIGlmIHBvaW50LXRvLXBvaW50KS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIElmIFI0IHdhcyBz YXlpbmcgJ2Ryb3AgdGhlIHBhY2tldCBpZiBpdCBjb21lcyBmcm9tIHRoZSBzYW1lPGJyPg0KbGlu ay1sYXllciBhZGRyZXNzIHlvdSBhcmUgZ29pbmcgdG8gc2VuZCBpdCBiYWNrJyAtIGl0IHdvdWxk IG1ha2U8YnI+DQp0b3RhbCBzZW5zZS4gQnV0IEkgZG9uJ3QgdGhpbmsgcm91dGVycyBkbyAqdGhh dCouPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpZZXMsIGlmIHdlIG1hZGUgdGhlIGNoZWNrIG9uIEwyIGFkZHJlc3MsIHRoZW4gaXQgd291 bGQgd29yay48YnI+DQpBbmQgSSBhZ3JlZSB0aGF0IHJvdXRlcnMgYXJlIGV4YWN0bHkgZG9pbmcg dGhhdC48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgaXQgYWxzbyB3b3JrcyBpZiBCIGlzIGEgcm91 dGVyIHdpdGggYWRkaXRpb25hbCBpbnRlcmZhY2VzPGJyPg0KZG93bnN0cmVhbSwgdW5sZXNzIHRo ZXJlIGFyZSBtdWx0aXBsZSBwYXRocy48YnI+DQo8YnI+DQotLTxicj4NCk1pY2hhZWwgUmljaGFy ZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jcitJRVRGQHNhbmRlbG1hbi5jYSIgdGFyZ2V0PSJf YmxhbmsiPm1jcitJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7ICZuYnNwOyZuYnNwOy4gbyBPICgg SVB2NiBJw7hUIGNvbnN1bHRpbmcgKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90 dGF3YSBhbmQgV29ybGR3aWRlPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCi0tIDxicj4NClNZLCBK ZW4gTGlua292YSBha2EgRnVycnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BN7PR11MB2547DD143D784940F5524DA5CFEF0BN7PR11MB2547namp_-- From nobody Wed Nov 4 18:10:14 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D2A3A12A5 for ; Wed, 4 Nov 2020 18:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzirm78cyX07 for ; Wed, 4 Nov 2020 18:10:11 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0B73A12A3 for ; Wed, 4 Nov 2020 18:10:11 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id m3so23807vki.12 for ; Wed, 04 Nov 2020 18:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o6JBz2RObIhl/VGWYlVDG6DWm8MTfYJYeBWu/tS9R3Y=; b=emMPE0vgv0pI6mBf+9Doeo+PeAswBsK28LPT5d/bbxD5D3HkxUrusUjT+GBgCk+E4H vrCFHy9worFMh7UCm++ww4oIPSTiwmaLk2Hce4iKIN+vqRhBFzmBrdqZxWtXh6Yg7KTe UZStyFYWWCeS0cIg0I2znHdS2nK4aVJYnqbHk3UNxwAVUqbvusx1xI4rD4G3MXIdJ9qN ZGOf8SosO051K7tHcxw9Zv1FPYiJb5T8dv+DxsmwFrwNN0awOmBN0GTei+k+B4yMWX9+ bvg/BxMGunGT0IPwUyU4QvAiREVilm4Wo1IolJHHz9k4EkBV9shSSreRvDiIIQNZtxPT y86w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o6JBz2RObIhl/VGWYlVDG6DWm8MTfYJYeBWu/tS9R3Y=; b=J9vc30lLRlLBk5nBWTQpUNS2crEgLr/7GbsqEQZTiUyz0wDA1Tw0l06yAtgYUx6Qbc DMoJDNqBKn72KXAANO7Kuu6VjpSBxZYs3LdfTmPVnY8G6YFNtvgV1iZKfgZLMPmBzjPr elN7yxUoNPCW8ZyGN7vX1JKWhRZ+uTYnEgFgGSn712x5DjV7og78az3pXkxFdEjqyTga tkujV4SBH5p8kNknU91iSJoCTOUsAU+MJDyURsEAcvw0ViKlRIdetEI0MDA2K/KZ21nL 1Iul9jHSGh5+wR8IN0qfUS99bKxK9QB5Pz1ma/h07/9PYGmD0ZAipHpBQDFrv0Vw5eiA tNmA== X-Gm-Message-State: AOAM533SIGC1kUwx1FOLyYmZfOxuNYA7q9ELpLyER8Qxog4OqBefWkCV 24KNVs7stMuWiaNB4cdLPKmDjhN7uvm86jVht1E= X-Google-Smtp-Source: ABdhPJxaG1bwFqCi/cidAQHD2iOal8bk9XG2ixt0E20DIe7hmnjLVEtMU9B8lTOctHpqGs09mvKlBsWKCJonJEml0P8= X-Received: by 2002:a05:6122:12a7:: with SMTP id j7mr136735vkp.15.1604542210466; Wed, 04 Nov 2020 18:10:10 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <33fd62eb-79d7-6560-f859-55724a1435e9@gmail.com> In-Reply-To: <33fd62eb-79d7-6560-f859-55724a1435e9@gmail.com> From: Gyan Mishra Date: Wed, 4 Nov 2020 21:09:59 -0500 Message-ID: To: Brian E Carpenter Cc: Alexandre Petrescu , Dmytro Shytyi , Fred Baker , Gyan Mishra , IPv6 Operations , Lorenzo Colitti , Naveen Kottapalli Content-Type: multipart/alternative; boundary="0000000000007b652605b3529863" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 02:10:13 -0000 --0000000000007b652605b3529863 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 4, 2020 at 5:29 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 04-Nov-20 22:20, Lorenzo Colitti wrote: > > On Tue, Nov 3, 2020 at 5:09 AM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > So let's have a discussion whether there is a new operational > problem here first: > > > > "The main problem is that SLAAC RA or PD allocates a /64 by the > > wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, > however > > segmentation of the /64 via SLAAC is required so that downstream > > interfaces can be further sub-netted." > > > > Why isn't that in v6ops scope? > > > > > > I'd say that is not in scope anywhere because there already exists a > protocol that solves this problem. It's called DHCPv6 PD. > > I meant that if 5G doesn't already define how to support an IPv6 "hotspot= " > solution, then there is an operational gap that could usefully be > documented. The current draft doesn't do that, because it assumes a class > of solution (SLAAC-based instead of PD-based) rather than stating the > underlying problem. > > Assuming that PD is the preferred solution, a description of how to do > that in a 5G (or any 3GPP) deployment would be very desirable. If such a > document already exists outside the IETF, that would be fine too. > > > If there is an operational problem with DHCPv6 PD, then that might > indeed be in scope for v6ops. That's not what the draft is about though. = As > far as I can see it doesn't mention DHCPv6 PD at all. The draft is about > proposing a change to SLAAC, and as such is a protocol change that is not > in scope for v6ops. > > I agree that the draft as it stands is out of scope. I had to find the > text quoted above to understand what the underlying problem migh be. Gyan> Agreed. As pointed out the problem statement draft states the problem with slaac and proposed change to slaac and does not mention anything about dhcpv6 PD. There are two drafts below that complement each other. ! v6ops slaac issue =E2=80=94> so this should move to 6man https://tools.ietf.org/html/draft-mishra-v6ops-variable-slaac-problem-stmt-= 01 ! 6MAN Proposes slaac change https://tools.ietf.org/html/draft-mishra-6man-variable-slaac-01 > > Brian > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000007b652605b3529863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 4, 2020 at 5:29 PM Brian E Carpenter <brian.e.carpenter@gmail.com>= ; wrote:
On 04-Nov-20 22:20, Lorenzo Colitti wrot= e:
> On Tue, Nov 3, 2020 at 5:09 AM Brian E Carpenter <brian.e.carpenter@gmail.com= <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0So let's have a discussion whether there is a n= ew operational problem here first:
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 "The main problem is that SLAAC RA or P= D allocates a /64 by the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0wireless carrier 4G, 5G, 3GPP to mobil= e handset or hotspot, however
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0segmentation of the /64 via SLAAC is r= equired so that downstream
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0interfaces can be further sub-netted.&= quot;
>
>=C2=A0 =C2=A0 =C2=A0Why isn't that in v6ops scope?
>
>
> I'd say that is not in scope anywhere because there already exists= a protocol that solves this problem. It's called DHCPv6 PD.

I meant that if 5G doesn't already define how to support an IPv6 "= hotspot" solution, then there is an operational gap that could usefull= y be documented. The current draft doesn't do that, because it assumes = a class of solution (SLAAC-based instead of PD-based) rather than stating t= he underlying problem.

Assuming that PD is the preferred solution, a description of how to do that= in a 5G (or any 3GPP) deployment would be very desirable. If such a docume= nt already exists outside the IETF, that would be fine too.

> If there is an operational problem with DHCPv6 PD, then that might ind= eed be in scope for v6ops. That's not what the draft is about though. A= s far as I can see it doesn't mention DHCPv6 PD at all. The draft is ab= out proposing a change to SLAAC, and as such is a protocol change that is n= ot in scope for v6ops.

I agree that the draft as it stands is out of scope. I had to find the text= quoted above to understand what the underlying problem migh be.

=C2=A0 =C2=A0 Gyan> Agre= ed.=C2=A0 As pointed out the problem statement draft states the problem wit= h slaac and proposed change to slaac and does not mention anything about dh= cpv6 =C2=A0PD. =C2=A0

Th= ere are two drafts below that complement each other.

! v6ops slaac issue =E2=80=94> so this shou= ld move to 6man
! 6MAN Proposes slaac c= hange=C2=A0
--
--0000000000007b652605b3529863-- From nobody Thu Nov 5 00:39:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82CF3A15AB; Thu, 5 Nov 2020 00:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ffx2TScK_V6M; Thu, 5 Nov 2020 00:39:22 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FB23A151F; Thu, 5 Nov 2020 00:39:22 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CRcNS75XTz67KJG; Thu, 5 Nov 2020 16:38:00 +0800 (CST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 5 Nov 2020 09:39:15 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 5 Nov 2020 16:39:13 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 5 Nov 2020 16:39:13 +0800 From: "Xiejingrong (Jingrong)" To: V6Ops-Chairs , IPv6 Operations Thread-Topic: [v6ops] draft-peng-v6ops-hbh Thread-Index: AQHWst4Vq6Goleve3EaXUQWO82+Diam5Nzjg Date: Thu, 5 Nov 2020 08:39:13 +0000 Message-ID: <52d23acc0bf746e4baeddf83a302b4b1@huawei.com> References: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> In-Reply-To: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.201.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-peng-v6ops-hbh X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 08:39:24 -0000 Hi! Yes, I would like to see discussions about HBH. Thanks Jingrong -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Thursday, November 5, 2020 3:09 AM To: IPv6 Operations Subject: [v6ops] draft-peng-v6ops-hbh Folks: The authors have asked Ron and I for time on the v6ops agenda for https://t= ools.ietf.org/html/draft-peng-v6ops-hbh-01. I can find time if you want it;= my question is, with a grand total of three emails on the topic, two from = the authors and one from the secretariat announcing the draft, is there int= erest? Let me ask you, once, to glance through the draft and let us know. Do you w= ant it on the agenda? Fred _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 5 01:46:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70F3A171D for ; Thu, 5 Nov 2020 01:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=previdi-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srV6xlwzCRqB for ; Thu, 5 Nov 2020 01:46:28 -0800 (PST) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8143A0DEB for ; Thu, 5 Nov 2020 01:46:27 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id dk16so1642123ejb.12 for ; Thu, 05 Nov 2020 01:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6g4WUENroI9+ckxCGIEHsdf6S6mmgMtM/8wqNmjkVe8=; b=wEjK70TiiZyLSUMiAkV8HHPfdoWv2PG5E5vwNPpre62ONd4PFWzUZgI6Dr3wBrxpSk VAh+cfeb0P7gBOxavVBexPQzTq3mN3uVJTlitHY7no+u+90gCk8AeL/smcRRLjoMAhKM NX7gYRpvtq++bpvuCWz9bswhops4nYUDC/nWnTdN31+Kmj1DY8e4jRQWPl/9FVUzaia8 SsKzYHOtVRrstRDhOTMZpMswHOwbEy5UltpREJCBcpWqtqGxiLn5t8OBx/84iWyWZ5d8 MUMqrGBo1Ehfn6ntr9/onu/ONPZga6CglY6CsK6+cwmuiSQBqmVeI9YtuwPXsnw7uPwd Evfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6g4WUENroI9+ckxCGIEHsdf6S6mmgMtM/8wqNmjkVe8=; b=VZ7si+80i+QLzO7IIthlAmvXjbspcCY6IZacnPBRBRXg2tNqMvnR/1815kMJ8FO/cg ke8Jy80FbJqmP3oDDY46z7zYSFdSgytmRmZ0BOQbQsQrNxbipM9Rwlg8s0uA0fEm2kM2 msBuFk/TNFyY1ubZEeMGJ/x9Ye+ll7hL5DQV8w2fvsvEapGzaQRtNDZciqfzbwiylb98 5iX/dm+hEQB0EegH3J8UX4G5MO8FC159Mv1vQ17wTxEHbPKhbOM6jCI4HkHRtaMIa4qv Xi4H19dOuXtKQf9YnbqPE/xiCAMOPIMkkDi0CiGmfUYUC7Y5YMlaFNXJJOjrA9qoxUYZ noMw== X-Gm-Message-State: AOAM5339KsUAWRqekfDjUhmKeLYli4W9Ukr+AkN3uI7NMes2yANAUkir BH9EH+eBkszxNpUuTejUBvFzMQ== X-Google-Smtp-Source: ABdhPJylEjMGHNOFuTaq6OAm41RIBhcW61twkysWsxuKiZL9p3p6KdemGlHS7UaHUiQNrScbNtlrBA== X-Received: by 2002:a17:906:a43:: with SMTP id x3mr1463229ejf.197.1604569586211; Thu, 05 Nov 2020 01:46:26 -0800 (PST) Received: from pc.home (host-79-47-210-53.retail.telecomitalia.it. [79.47.210.53]) by smtp.gmail.com with ESMTPSA id bn25sm605874ejb.76.2020.11.05.01.46.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2020 01:46:25 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: stefano previdi In-Reply-To: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> Date: Thu, 5 Nov 2020 10:46:31 +0100 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <52CA310C-FED3-418C-8367-C9F93D3D3898@previdi.net> References: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> To: V6Ops-Chairs X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] draft-peng-v6ops-hbh X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 09:46:30 -0000 Hi, this draft proposes an improvement on how HBH is handled and processed = and this proposal is related to the APN work. I think it=E2=80=99s a = good idea to have it in the agenda so I support it. Thanks. s. > On Nov 4, 2020, at 8:09 PM, Fred Baker = wrote: >=20 > Folks: >=20 > The authors have asked Ron and I for time on the v6ops agenda for = https://tools.ietf.org/html/draft-peng-v6ops-hbh-01. I can find time if = you want it; my question is, with a grand total of three emails on the = topic, two from the authors and one from the secretariat announcing the = draft, is there interest? >=20 > Let me ask you, once, to glance through the draft and let us know. Do = you want it on the agenda? >=20 > Fred > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 5 02:12:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8A63A0E3F; Thu, 5 Nov 2020 02:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ml3zMfG6UBbh; Thu, 5 Nov 2020 02:12:37 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA653A0E0E; Thu, 5 Nov 2020 02:12:37 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CRfRx2dlDz67D5t; Thu, 5 Nov 2020 18:11:09 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 5 Nov 2020 11:12:31 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Thu, 5 Nov 2020 11:12:31 +0100 From: Giuseppe Fioccola To: V6Ops-Chairs , IPv6 Operations Thread-Topic: [v6ops] draft-peng-v6ops-hbh Thread-Index: AQHWst4W3rtLjuw8Y02SuYrx/6LGIKm5T4bA Date: Thu, 5 Nov 2020 10:12:31 +0000 Message-ID: <02f52561225749008685403c09d1c421@huawei.com> References: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> In-Reply-To: <29BE9996-BC6A-4BB4-A246-3B0A51A38D25@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.222.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-peng-v6ops-hbh X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 10:12:39 -0000 Hi All, I think that a discussion about the processing of the HBH Options Header ca= n be meaningful for the IETF109 agenda. There are techniques, for example IOAM (draft-ietf-ippm-ioam-ipv6-options-0= 2) and Alternate Marking (draft-ietf-6man-ipv6-alt-mark), that are applied = to IPv6 by using also HBH Options to carry the telemetry information. For t= his reason the analysis of the deployment of HBH Options Header is an inter= esting topic. Regards, Giuseppe -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker Sent: Wednesday, November 4, 2020 8:09 PM To: IPv6 Operations Subject: [v6ops] draft-peng-v6ops-hbh Folks: The authors have asked Ron and I for time on the v6ops agenda for https://t= ools.ietf.org/html/draft-peng-v6ops-hbh-01. I can find time if you want it;= my question is, with a grand total of three emails on the topic, two from = the authors and one from the secretariat announcing the draft, is there int= erest? Let me ask you, once, to glance through the draft and let us know. Do you w= ant it on the agenda? Fred _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 5 06:48:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB33A12EB; Thu, 5 Nov 2020 06:48:00 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5Ci69039_vH; Thu, 5 Nov 2020 06:47:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 B81EF3A12CD; Thu, 5 Nov 2020 06:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604587669; bh=MFT7p3yzAJ216jAyzAQnryzjRluze8es8R9QXbFCcpM=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=FmQi3vjdeMOT+EPQLtOfBhIRriQWSYNWObds3PV4EoLm07PvlkyyxqUrqEbFX+EjC y4OoCJZGUZRh2nWgFqu2XSVSk5ezxuJBUkldcoWdW316vfYov4Wo0yoViGPVpaCp86 j/ZhhCuGmhtJa2NgewV+RaGzDgiTRmS1Ey0Sk2GA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([89.1.62.143]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MGQnF-1kXgwz3WaT-00GpWE; Thu, 05 Nov 2020 15:47:48 +0100 From: ianfarrer@gmx.com Message-Id: <819FC1BA-948F-4A35-9BF0-B5DAFD78057F@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B592B40A-FE16-4D6C-BBB3-96D37E752903" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 5 Nov 2020 15:47:46 +0100 In-Reply-To: Cc: Michael Richardson , v6ops list , dhcwg To: Timothy Winters , "Bernie Volz (volz)" , Jen Linkova References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:eQ6DWErdmPfPS2P9vfH7GnPmRcbCLCCxKFrGS9ooVk91WZEGOa3 mPxr+x64J+Imqxk4rxSiIa1lbPEOEKT0qCCeemw0HW+1QpWXC++wzISuUJ9TjvhEhSpGANj +rydRNCO39pQ/E8D86bTfDgpPZh8v+07uZoDVUlA0GHQxPEgjwWIckwumYJtgecjrV2135X UbjtARHK6Fu6hC+QwImQg== X-UI-Out-Filterresults: notjunk:1;V03:K0:zDKcHWqatO8=:u/BQwa0iy+nSqH9OqWiOQo GCyisRgrqJPYnJ2I85Kgr4PmjMRAieyb3PQ2js3qwRcR8e9rMAJjEHfYIo3mqC9UqEagmRChv sM/IPJ8M3WdnEhU8SCWRJMqkkVR28giY2CFQ07DzDttNXnXtJCyMUClwwn3y5UDSwM7eFbib+ e8z7IGU6C76XH/FWTib+M337Fp3Lw84U3LRHqWhRgxaeXPDx6gfINKh8LbLkiPFknmzJVgPMf RvhjSvO6L8mr9swt2nQY/vKC7HUHEI3WEi9lXwEO5nYjmFgYVpKfcpkgvK6pRTqJeOqJDqczK AAqo0Z/uljyh9wlh2i2/nGXHoAw6igGKbKGdwqiXm2JQDEhwXB6h92GB0N9fHIIZMEhQfKHtq N/1KXDiltROt2S0LsU2g/aREyg2kRvrxqny8bdrZ4pEuYoOF+PkedNNPfImDYTf6obv41sGHs 2Fvylszktr3p2m+U53EVTjLBGOyL4XQLHWSmDbnlwK2wAuniB9mnalFmE5peqyflzX0Ddtlla zDROy3P3eom+TdK7BJV7na4f6rVFCvj+pxAjhia3S3ZQcBQA4vKy8vtHNHHhgYra7ffCTgAPa uLS8ToJU0YUsf3SVKg7D4q35FJngbdwFeu8al3Z3OR5QGeC/y5IUJEmGXbvy4/OrTUVPftVT2 qTowgEOtg186NT+eGmiEIpV+3bVZZRPSpA3PgAXU1HeWoSdCT2VJYayoRKxpnO9nEZGiCs72r fJJHENSNBYWN9FiWX7P4ZsWVB+KZ0x7zzApjTs319SG6+8mkN2iRxifeb5qY/WTLxbBoRG6pV R6KxLchvURQ3E2TdlweVg0JI/JTXMITM7kw02YvKLZ4aE+U1kR+PDafTN/Zro9cK4+mRAnikJ nL7JBvh4aje1RlZmayrg== Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:48:01 -0000 --Apple-Mail=_B592B40A-FE16-4D6C-BBB3-96D37E752903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Just to be clear, are we talking about Michael=E2=80=99s proposed = rewording/restructuring of the requirement text (here with Bernie=E2=80=99= s link-layer wording change): R-4 To prevent routing loops, the relay SHOULD implement a configurable policy to drop potential looping packets received on any DHCP-PD = client facing interfaces. The policy SHOULD be configurable on a per-client or per-destination = basis. Looping packets are those with a destination address in a prefix delegated to a client connected to that interface, as follows: 1) For point-to-point links (e.g., PPPoE), when the packet=E2=80=99= s ingress and egress interfaces match. 2) For multi-access links (e.g., ethernet), when the packet=E2=80=99= s ingress and egress interface match, and the source link-layer = and next-hop=20 link-layer addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be = configurable. Thanks, Ian > On 4. Nov 2020, at 14:01, Timothy Winters wrote: >=20 >=20 > I agree with Bernie, link-layer address would be an improvement to the = Mac Address. >=20 > ~Tim >=20 > On Wed, Nov 4, 2020 at 7:15 AM Bernie Volz (volz) = > = wrote: > Hi ... looks good but perhaps MAC address is too Ethernet specific and = just link-layer address would be better? >=20 > - Bernie >=20 >> On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com = " > wrote: >>=20 >> =EF=BB=BF >> Hi, >>=20 >> Sorry for the delay in reply, I=E2=80=99ve been out of the office for = the last few weeks for various reasons. >>=20 >> Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2=80=99= s suggestions: >>=20 >> R-4 >> To prevent routing loops, the relay SHOULD implement a configurable = policy to drop packets >> received on a DHCP-PD client facing interface with a destination = address in a prefix delegated >> to a client connected to that interface, as follows: For = point-to-point links, when the packet=E2=80=99s >> ingress and egress interfaces match. For multi-access links, when the = packet=E2=80=99s ingress and >> egress interface match, and the source MAC and next-hop MAC addresses = match. An >> ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY >> be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be = configurable. >>=20 >> Thanks, >> Ian >>=20 >>> On 15. Oct 2020, at 03:51, Jen Linkova > wrote: >>>=20 >>> On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) > wrote: >>>> If not, perhaps we just say: >>>>=20 >>>> R-4 >>>> To prevent routing loops, the relay SHOULD implement a configurable = policy to drop traffic received from an uplink interface as follows: >>>=20 >>> I'm not sure 'from an uplink interface' makes sense. In the case of = a >>> routing loop caused by an amnesiac DHCP-PD client it would be a >>> downstream interface. >>> The scenario when such traffic arrives from an uplink interface is >>> 'the uplink router believes the prefix is delegated to the client = but >>> the relay does not have a route pointing to the client so it sends >>> traffic back' - so more likely 'an amnesiac relay' case. >>>=20 >>>> For point-to-point links, when the packet's ingress and egress = interfaces match. For multi-access links, when the packet's ingress and = egress interface match, and the source MAC and next-hop MAC addresses = match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route = to >>>> destination) error message MAY be sent as per [RFC4443], section = 3.1. The ICMP policy SHOULD be configurable. >>>>=20 >>>> - Bernie >>>>=20 >>>> -----Original Message----- >>>> From: ianfarrer@gmx.com = > >>>> Sent: Tuesday, October 13, 2020 9:16 AM >>>> To: Michael Richardson >; Jen Linkova > >>>> Cc: Bernie Volz (volz) >; = dhcwg >; 6man >; v6ops list > >>>> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 = Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements >>>>=20 >>>> Hi, >>>>=20 >>>> Thanks for all of the discussion on this. We=E2=80=99ve reworked = the requirement as follows: >>>>=20 >>>> R-4 >>>> To prevent routing loops, the relay SHOULD implement a configurable = policy to drop client traffic as follows: For point-to-point links, = when the packet's ingress and egress interfaces match. For multi-access = links, when the packet's ingress and egress interface match, and the = source MAC and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 = (Destination Unreachable, reject route to >>>> destination) error message MAY be sent back to the client. The = ICMP policy SHOULD be configurable. >>>>=20 >>>> Thanks, >>>> Ian >>>>=20 >>>>> On 9. Oct 2020, at 17:41, Michael Richardson = > wrote: >>>>>=20 >>>>>=20 >>>>> Jen Linkova > wrote: >>>>>> I think there is confusion re: the scenario we are talking about. >>>>>> I've attached the diagram for the case which concerns me. >>>>>> So: >>>>>> - The Relay R has an interface eth0 connected to a switch S. >>>>>> - Devices A and B are connected to the same switch and using R as = a >>>>>> default gateway. >>>>>> - The prefix 2001:db8::/56 was delegated to a client A via the = relay R. >>>>>=20 >>>>> a friendly amendment to your example to aid in human = comprehension: >>>>> } - The prefix 2001:db8:0000:0123:/64 was delegated to a client = A via the relay R. >>>>> } - R installs a route for 2001:db8:0000:0123:/64 towards A = via eth0. >>>>>=20 >>>>>> - The device B (which has an address NOT from the delegated = prefix, >>>>>> but from another /64 assigned to that common link, let's sat >>>>>> 2001:db8:cafe::/64) sends a packet to an address from the = delegated >>>>>=20 >>>>> now, my brain can more clearly see that 2001:db8:cafe::/64 is not >>>>> within 2001:db8:0000:0123:/64, while I had to use a few extra = brain >>>>> cells to see that it wasn't in that ::/56 :-) >>>>>=20 >>>>>> What I'd expect to happen (with DHCP-PD or without - e.g. if R = has a >>>>>> static route towards A, not a dynamic route produced by PD): >>>>>> - the packet is sent to A. Well, if A does not have a route to >>>>>> 2001:db8::42 then indeed a routing loop might happen. But if A = does >>>>>> have a route, the packet will be delivered. >>>>>=20 >>>>>> What seems to be required by R4: >>>>>> - R detects that the packet is received via eth0 and needs to be = sent >>>>>> back to eth0. R4 seems to require such packets to be dropped. >>>>>> So if B would never be able to communicate to any address in the >>>>>> delegated prefix, right? >>>>>=20 >>>>>> Am I missing anything? >>>>>=20 >>>>> I think that you got it right. >>>>>=20 >>>>>>> Perhaps the missing piece of the rule is don=E2=80=99t send it = back to where it came from, based on link layer addresses (or link if = point-to-point). >>>>>=20 >>>>>> Yes. If R4 was saying 'drop the packet if it comes from the same >>>>>> link-layer address you are going to send it back' - it would make >>>>>> total sense. But I don't think routers do *that*. >>>>>=20 >>>>> Yes, if we made the check on L2 address, then it would work. >>>>> And I agree that routers are exactly doing that. >>>>>=20 >>>>> I think that it also works if B is a router with additional = interfaces >>>>> downstream, unless there are multiple paths. >>>>>=20 >>>>> -- >>>>> Michael Richardson > . o O ( IPv6 I=C3=B8T consulting ) >>>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 = >>>>> = -------------------------------------------------------------------- >>>>=20 >>>=20 >>>=20 >>> --=20 >>> SY, Jen Linkova aka Furry >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_B592B40A-FE16-4D6C-BBB3-96D37E752903 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

Just to be clear, are we talking about Michael=E2=80=99s = proposed rewording/restructuring of the requirement text (here with = Bernie=E2=80=99s link-layer wording change):

   R-4
   To = prevent routing loops, the relay SHOULD implement a = configurable
   policy to drop potential = looping packets received on any DHCP-PD client
   facing interfaces.
   The policy SHOULD be configurable on a = per-client or per-destination basis.

   Looping = packets are those with a destination address in a prefix
   delegated to a client connected to that = interface, as follows:

        1) For = point-to-point links (e.g., PPPoE), when the packet=E2=80=99s ingress = and egress
          &nb= sp;interfaces match.

        2) For = multi-access links (e.g., ethernet), when the packet=E2=80=99s
          &nb= sp;ingress and egress interface match, and the source link-layer and = next-hop = --Apple-Mail=_B592B40A-FE16-4D6C-BBB3-96D37E752903-- From nobody Thu Nov 5 07:05:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512C3A12AC; Thu, 5 Nov 2020 07:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fpgT54JCFGe; Thu, 5 Nov 2020 07:05:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 1BDBD3A129A; Thu, 5 Nov 2020 07:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604588704; bh=W4qKeuXP5leY7idxpByfkUyZ9iZ57S6UZkTlvBnh08E=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=CNftGoS95SME12Kw1Z7CfBP8VRU6PMJcmYsxi4qPaptC14RjmPLd9El8v0DVfNglh t8fdrw7lGGE6Ker0CrMLZFVCCOFn2PzbuJaxcZSvHNituKw72JR2JTOenn/D3rcwWv DoCQGk/jVZILpowP/svAJwUhTwe3MZdddmpW811g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([89.1.62.143]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1M7sDq-1kfclR3dZK-004yhu; Thu, 05 Nov 2020 16:05:03 +0100 From: ianfarrer@gmx.com Message-Id: <1F66C58E-720B-4D2A-8832-BBDC67D521EF@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_674673F2-67E3-4E5A-AA6B-FEBA04556372" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 5 Nov 2020 16:05:01 +0100 In-Reply-To: Cc: "draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org" , dhcwg , v6ops list To: "Bernie Volz (volz)" References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> X-Mailer: Apple Mail (2.3445.104.17) X-Provags-ID: V03:K1:kHk7TLvABK6L6RKoDS3J+OBtEgmRgazwLLr0C8yI7Ckl6lnt6bL JZooJsMQzLtN3NqdJlaKFcKvISrpvWHmB8HoqzJqQwQoEH6wUUstazhXP1ohyddbae0x/JK bP+thz1ETcLD7E4PDINwifo07aswTuHkomEulVhcOQJvgve5mm0Pduzt0izoNeNZWLBia32 SFmP9gXdie3uFVNC22sMg== X-UI-Out-Filterresults: notjunk:1;V03:K0:9g7r07eVkSg=:Xqyi9rf3lUgnSpCpkmYFSp 4PoTOL09F/CASk6sZTuqYySiX/Jj1boAdp5gIxuc3yGU2Vof0p19K5qzo+OF3DpKAcEh4Pe6R TXqtDyESPIVNTys2UpyzXlvVlGRN6Bbyat+JZgukCAibF6olO6hWoTf0uAazdcw0oR44fiYkM O9pTLpbfIqBhv4u7OeBYc9IgsNkmM1jDY6A5M38F3f7P92JNDp10eMD3RszsdNMKLNMfHTd4H 21mHtshyA3ov6z+0QRqinQJ5+vdI24mIq3lJXwSogfqyCsKyebnLRyWf2SvOpAj8LYswcs249 d5OlbtGZ+32cTgePVpjL72hRswvB35lDsvitry04W6a1Fg+gUGT8+CSCGo7KYMq/P9ln6IQXc xPpjxIteqvf7SzrbZJLGkX+Y8qR3XYaF6/k+Ge8oxjcsbOWjSuZGLTcWOuJt0na3m6thc95dt PGiLiJDdEjz1EdCYUoWXZmL99OD7HqYr/Qy354XH3Pz3qM8DykSVYYuk9lIfLBdpv98Juskq1 tesWH6ZWRrfcKcUX/gI0gKsfWSn3g3x2xDPYX0y7O6zfouKutbucxlv6+tQxBi28UDMnppxBV tB63l8AI2hVtHwP7KWgWvgZYFUmycOu1l/vBOANr0IXGCgPlH+u1f/ayHW0tWmNIQ1cPcJGm7 v8J5Pn96rEoK/LNGGOSfeDg8Pc3qppCnmSXQ3MwgVdN90Hz5j3yvlx6o3IlvP5nKqcjSRhN8x 7ngM5POBy5ICH0VPTWcexZJ27ga9LFi2NDhJZDlypCdf0aRXpAv8jZlyWu9y+76y2zNFRtQ9M kU3Ndmu2p0BZ3a1+XkvTJTdJLgAFc6/qTq3N+Zf3KKBzCapZlrN+slZU720sazS9Uk4ivy8bl DMAjc754JDIwXxAMZphg== Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 15:05:11 -0000 --Apple-Mail=_674673F2-67E3-4E5A-AA6B-FEBA04556372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bernie, The Requirements text for this was taken from RFC7084 as originally it = was expected that this draft would be similar in its format and = approach. However, as the draft has developed, I don=E2=80=99t think = that is still true. The main difference is that RFC7084 requirements are = largely a list of =E2=80=99these are the RFC=E2=80=99s that you need to = implement' (hence the Requirements text). The delegating relay draft=E2=80=99s requirements are mostly = =E2=80=98standalone=E2=80=99 functional requirements, with only a small = number referencing other RFCs, so I think the best approach here would = just be to move to using the standard boilerplate. I=E2=80=99ll update. Thanks, Ian > On 5. Nov 2020, at 00:57, Bernie Volz (volz) = wrote: >=20 > I=E2=80=99m also wondering given issues the IESG raised for the = https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum = document = regarding the text=E2=80=A6 > <>2 = . Requirements Language > =20 > Take careful note: Unlike other IETF documents, the key words = "MUST", > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD = NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used = as > described in [RFC2119 ]. This = document uses these keywords not > strictly for the purpose of interoperability, but rather for the > purpose of establishing industry-common baseline functionality. As > such, the document points to several other specifications = (preferable > in RFC or stable form) to provide additional guidance to = implementers > regarding any protocol implementation required to produce a > successful CE router that interoperates successfully with a > particular subset of currently deploying and planned common IPv6 > access networks. > =20 > Note: the aforementioned terms are used in exactly the same way as = in > [RFC7084 ], with the above = explanation copied verbatim from > Section=C2=A01.1 of [RFC7084] = . > =20 > See = https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ballot/ = . > =20 > =E2=80=A6 whether it would be wise to follow the IESG guidance and = drop the special use (in section 2.3)? Otherwise, you may run into the = same issues the cpe-slaac-renum document did. > =20 > It may be wise to wait until the dust settles with that document and = the text that it ends up using (perhaps just the default boilerplate for = the keywords). And apply that. > =20 > I WILL assume you will do that (as I am currently the one holding the = document) unless I hear otherwise from you. Or, you could decide to just = update it to follow the standard boilerplate for these keywords =E2=80=93 = if so, be sure to use the latest version, such as what was used in = https://tools.ietf.org/html/rfc8925 = (section 1.1). > =20 > Thanks! > =20 > Bernie > =20 > From: dhcwg On Behalf Of Timothy Winters > Sent: Wednesday, November 4, 2020 8:02 AM > To: Bernie Volz (volz) > Cc: v6ops list ; dhcwg > Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > =20 > =20 > I agree with Bernie, link-layer address would be an improvement to the = Mac Address. > =20 > ~Tim > =20 > On Wed, Nov 4, 2020 at 7:15 AM Bernie Volz (volz) = > = wrote: > Hi ... looks good but perhaps MAC address is too Ethernet specific and = just link-layer address would be better? >=20 > - Bernie >=20 >=20 > On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com = " > wrote: >=20 > =EF=BB=BF=20 > Hi, > =20 > Sorry for the delay in reply, I=E2=80=99ve been out of the office for = the last few weeks for various reasons. > =20 > Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2=80=99= s suggestions: > =20 > R-4 > To prevent routing loops, the relay SHOULD implement a configurable = policy to drop packets > received on a DHCP-PD client facing interface with a destination = address in a prefix delegated > to a client connected to that interface, as follows: For = point-to-point links, when the packet=E2=80=99s > ingress and egress interfaces match. For multi-access links, when the = packet=E2=80=99s ingress and > egress interface match, and the source MAC and next-hop MAC addresses = match. An > ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY > be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be = configurable. > =20 > Thanks, > Ian > =20 > On 15. Oct 2020, at 03:51, Jen Linkova > wrote: > =20 > On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) > wrote: >=20 > If not, perhaps we just say: >=20 > R-4 > To prevent routing loops, the relay SHOULD implement a configurable = policy to drop traffic received from an uplink interface as follows: >=20 > I'm not sure 'from an uplink interface' makes sense. In the case of a > routing loop caused by an amnesiac DHCP-PD client it would be a > downstream interface. > The scenario when such traffic arrives from an uplink interface is > 'the uplink router believes the prefix is delegated to the client but > the relay does not have a route pointing to the client so it sends > traffic back' - so more likely 'an amnesiac relay' case. >=20 >=20 > For point-to-point links, when the packet's ingress and egress = interfaces match. For multi-access links, when the packet's ingress and = egress interface match, and the source MAC and next-hop MAC addresses = match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route = to > destination) error message MAY be sent as per [RFC4443], section 3.1. = The ICMP policy SHOULD be configurable. >=20 > - Bernie >=20 > -----Original Message----- > From: ianfarrer@gmx.com > > Sent: Tuesday, October 13, 2020 9:16 AM > To: Michael Richardson >; Jen Linkova > > Cc: Bernie Volz (volz) >; dhcwg = >; 6man >; v6ops list > > Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements >=20 > Hi, >=20 > Thanks for all of the discussion on this. We=E2=80=99ve reworked the = requirement as follows: >=20 > R-4 > To prevent routing loops, the relay SHOULD implement a configurable = policy to drop client traffic as follows: For point-to-point links, = when the packet's ingress and egress interfaces match. For multi-access = links, when the packet's ingress and egress interface match, and the = source MAC and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 = (Destination Unreachable, reject route to > destination) error message MAY be sent back to the client. The ICMP = policy SHOULD be configurable. >=20 > Thanks, > Ian >=20 >=20 > On 9. Oct 2020, at 17:41, Michael Richardson > wrote: >=20 >=20 > Jen Linkova > wrote: >=20 > I think there is confusion re: the scenario we are talking about. > I've attached the diagram for the case which concerns me. > So: > - The Relay R has an interface eth0 connected to a switch S. > - Devices A and B are connected to the same switch and using R as a > default gateway. > - The prefix 2001:db8::/56 was delegated to a client A via the relay = R. >=20 > a friendly amendment to your example to aid in human comprehension: > } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A = via the relay R. > } - R installs a route for 2001:db8:0000:0123:/64 towards A via = eth0. >=20 >=20 > - The device B (which has an address NOT from the delegated prefix, > but from another /64 assigned to that common link, let's sat > 2001:db8:cafe::/64) sends a packet to an address from the delegated >=20 > now, my brain can more clearly see that 2001:db8:cafe::/64 is not > within 2001:db8:0000:0123:/64, while I had to use a few extra brain > cells to see that it wasn't in that ::/56 :-) >=20 >=20 > What I'd expect to happen (with DHCP-PD or without - e.g. if R has a > static route towards A, not a dynamic route produced by PD): > - the packet is sent to A. Well, if A does not have a route to > 2001:db8::42 then indeed a routing loop might happen. But if A does > have a route, the packet will be delivered. >=20 >=20 > What seems to be required by R4: > - R detects that the packet is received via eth0 and needs to be sent > back to eth0. R4 seems to require such packets to be dropped. > So if B would never be able to communicate to any address in the > delegated prefix, right? >=20 >=20 > Am I missing anything? >=20 > I think that you got it right. >=20 >=20 > Perhaps the missing piece of the rule is don=E2=80=99t send it back to = where it came from, based on link layer addresses (or link if = point-to-point). >=20 >=20 > Yes. If R4 was saying 'drop the packet if it comes from the same > link-layer address you are going to send it back' - it would make > total sense. But I don't think routers do *that*. >=20 > Yes, if we made the check on L2 address, then it would work. > And I agree that routers are exactly doing that. >=20 > I think that it also works if B is a router with additional interfaces > downstream, unless there are multiple paths. >=20 > -- > Michael Richardson > . o O ( IPv6 I=C3=B8T consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 = > -------------------------------------------------------------------- > =20 >=20 >=20 > --=20 > SY, Jen Linkova aka Furry > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = _____________________________= __________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_674673F2-67E3-4E5A-AA6B-FEBA04556372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Bernie,

The = Requirements text for this was taken from RFC7084 as originally it was = expected that this draft would be similar in its format and approach. = However, as the draft has developed, I don=E2=80=99t think that is still = true. The main difference is that RFC7084 requirements are largely a = list of =E2=80=99these are the RFC=E2=80=99s that you need to implement' = (hence the Requirements text).

The delegating relay draft=E2=80=99s = requirements are mostly =E2=80=98standalone=E2=80=99 functional = requirements, with only a small number referencing other RFCs, so I = think the best approach here would just be to move to using the standard = boilerplate. I=E2=80=99ll update.

Thanks,
Ian

On 5. Nov 2020, at 00:57, Bernie Volz (volz) <volz=3D40cisco.com@dmarc.ietf.org> wrote:

I=E2=80=99m also wondering = given issues the IESG raised for the https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum document regarding = the text=E2=80=A6
2.  Requirements = Language
 
   Take careful note: Unlike other IETF documents, = the key words "MUST",
   "MUST NOT", = "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are not used as
   described in [RFC2119].  This = document uses these keywords not
   strictly for the = purpose of interoperability, but rather for the
   purpose of establishing industry-common baseline = functionality.  As
   such, the document = points to several other specifications (preferable
   in RFC or stable form) to provide additional = guidance to implementers
   regarding any protocol = implementation required to produce a
   successful CE router that interoperates = successfully with a
   particular subset of = currently deploying and planned common IPv6
   access networks.
 
   Note: the aforementioned terms are used in = exactly the same way as in
   [RFC7084], with the above = explanation copied verbatim from
   Section 1.1 of = [RFC7084].
 
See https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-ren= um/ballot/.
 
=E2=80=A6 whether it would = be wise to follow the IESG guidance and drop the special use (in section = 2.3)? Otherwise, you may run into the same issues the cpe-slaac-renum = document did.
 
It may be wise to wait = until the dust settles with that document and the text that it ends up = using (perhaps just the default boilerplate for the keywords). And apply = that.
 
I WILL assume you will do = that (as I am currently the one holding the document) unless I hear = otherwise from you. Or, you could decide to just update it to follow the = standard boilerplate for these keywords =E2=80=93 if so, be sure to use = the latest version, such as what was used in https://tools.ietf.org/html/rfc8925 (section 1.1).
 
Thanks!
 
  • Bernie
 
From: dhcwg <dhcwg-bounces@ietf.org> On Behalf = Of Timothy = Winters
Sent: Wednesday, November 4, 2020 = 8:02 AM
To: Bernie Volz (volz) <volz=3D40cisco.com@dmarc.ietf.org>
Cc: v6ops= list <v6ops@ietf.org>; dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] [v6ops] = [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding = draft-ietf-dhc-dhcpv6-pd-relay-requirements
 
 
I = agree with Bernie, link-layer address would be an improvement to the = Mac Address.
 
~Tim
 
On Wed, Nov 4, 2020 at = 7:15 AM Bernie Volz (volz) <volz=3D40cisco.com@dmarc.ietf.org>= wrote:

Hi ... looks good but perhaps MAC = address is too Ethernet specific and just link-layer address would be = better?

- = Bernie


On Oct = 29, 2020, at 12:24 PM, "ianfarrer@gmx.com" <ianfarrer@gmx.com> wrote:

=EF=BB=BF 
Hi,
 
Sorry for the delay in reply, I=E2=80=99ve been = out of the office for the last few weeks for various reasons.
 
Here=E2=80=99s a new wording proposal = incorporating Jen & Bernie=E2=80=99s suggestions:
 
R-4
To prevent routing loops, the relay = SHOULD implement a configurable policy to drop packets
received on a DHCP-PD client facing interface with a = destination address in a prefix delegated
to a client = connected to that interface, as follows:  For point-to-point = links, when the packet=E2=80=99s
ingress = and egress interfaces match. For multi-access links, when the = packet=E2=80=99s ingress and
egress interface match, and the source = MAC and next-hop MAC addresses match. An
ICMPv6 Type 1, = Code 6 (Destination Unreachable, reject route to destination) error = message MAY
be sent as per [RFC4443], section 3.1.  = The ICMP policy SHOULD be configurable.
 
Thanks,
Ian
 
On 15. Oct 2020, at 03:51, = Jen Linkova <furry13@gmail.com> wrote:
 
On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz = (volz) <volz@cisco.com> wrote:

If not, perhaps we = just say:

R-4
To prevent = routing loops, the relay SHOULD implement a configurable policy to drop = traffic received from an uplink interface as follows:

I'm not sure 'from an uplink interface' makes sense. In the = case of a
routing loop caused by an amnesiac DHCP-PD = client it would be a
downstream interface.
The= scenario when such traffic arrives from an uplink interface is
'the uplink router believes the prefix is delegated to the = client but
the relay does not have a route pointing to the = client so it sends
traffic back' - so more likely 'an = amnesiac relay' case.


For point-to-point = links, when the packet's ingress and egress interfaces match. For = multi-access links, when the packet's ingress and egress interface = match, and the source MAC and next-hop MAC addresses match. An ICMPv6 = Type 1, Code 6 (Destination Unreachable, reject route to
destination) error message MAY be sent as per [RFC4443], = section 3.1.  The ICMP policy SHOULD be configurable.

- Bernie

-----Original Message-----
From: ianfarrer@gmx.com <ianfarrer@gmx.com>Sent: Tuesday, October 13, 2020 9:16 AM
To: = Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova <furry13@gmail.com>Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg <dhcwg@ietf.org>; 6man = <ipv6@ietf.org>; = v6ops list <v6ops@ietf.org>
Subject: Re: [dhcwg] = [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding = draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi,

Thanks for all of the = discussion on this. We=E2=80=99ve reworked the requirement as = follows:

R-4
To prevent = routing loops, the relay SHOULD implement a configurable policy to drop = client traffic as follows:  For point-to-point links, when the = packet's ingress and egress interfaces match. For multi-access links, = when the packet's ingress and egress interface match, and the source MAC = and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination = Unreachable, reject route to
destination) error message = MAY be sent back to the client.  The ICMP policy SHOULD be = configurable.

Thanks,
Ian


On 9. Oct 2020, at = 17:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Jen Linkova <furry13@gmail.com> = wrote:

I think there is = confusion re: the scenario we are talking about.
I've = attached the diagram for the case which concerns me.
So:
- The Relay R has an interface eth0 connected to a switch = S.
- Devices A and B are connected to the same switch and = using R as a
default gateway.
- The prefix = 2001:db8::/56 was delegated to a client A via the relay R.

a friendly amendment to your example to aid in human = comprehension:
   } - The prefix = 2001:db8:0000:0123:/64 was delegated to a client A via the relay R.
   }  - R installs a route for = 2001:db8:0000:0123:/64 towards A via eth0.


- The device B (which has an address NOT from = the delegated prefix,
but from another /64 assigned to = that common link, let's sat
2001:db8:cafe::/64) sends a = packet to an address from the delegated

now, my brain can more clearly see that 2001:db8:cafe::/64 is = not
within 2001:db8:0000:0123:/64, while I had to use a = few extra brain
cells to see that it wasn't in that ::/56 = :-)


What I'd expect to = happen (with DHCP-PD or without - e.g. if R has a
static = route towards A, not a dynamic route produced by PD):
- = the packet is sent to A. Well, if A does not have a route to
2001:db8::42 then indeed a routing loop might happen. But if = A does
have a route, the packet will be delivered.


What seems to be required by R4:
- = R detects that the packet is received via eth0 and needs to be sent
back to eth0. R4 seems to require such packets to be = dropped.
So if B would never be able to communicate to any = address in the
delegated prefix, right?


Am I missing anything?

I think that you got it right.

Perhaps = the missing piece of the rule is don=E2=80=99t send it back to where it = came from, based on link layer addresses (or link if = point-to-point).


Yes. If R4 was = saying 'drop the packet if it comes from the same
link-layer= address you are going to send it back' - it would make
total sense. But I don't think routers do *that*.

Yes, if we made the check on L2 address, then it would = work.
And I agree that routers are exactly doing that.

I think that it also works if B is a router = with additional interfaces
downstream, unless there are = multiple paths.

--
Michael = Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T= consulting )
         Sandelman= Software Works Inc, Ottawa and Worldwide

---------------------------------------------------------------= -----
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------------= -----
 


-- 
SY, Jen = Linkova aka Furry
 
           link-layer  addresses = match.

   An ICMPv6 Type 1, Code 6 = (Destination Unreachable, reject route to destination) error message = MAY
   be sent as per [RFC4443], section 3.1. =  The ICMP policy SHOULD be configurable.


Thanks,
Ian


On 4. Nov 2020, at 14:01, Timothy Winters = <tim@qacafe.com> = wrote:


I agree with Bernie, link-layer address = would be an improvement to the Mac Address.

~Tim

On Wed, Nov = 4, 2020 at 7:15 AM Bernie Volz (volz) <volz=3D40cisco.com@dmarc.ietf.org> wrote:
Hi ... looks good but perhaps MAC address is too Ethernet specific and = just link-layer address would be better?

- Bernie

On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com" <ianfarrer@gmx.com> wrote:

=EF=BB=BF
Hi,

Sorry for the delay in = reply, I=E2=80=99ve been out of the office for the last few weeks for = various reasons.

Here=E2=80=99s a new = wording proposal incorporating Jen & Bernie=E2=80=99= s suggestions:

R-4
To prevent routing loops, the relay SHOULD implement a = configurable policy to drop packets
received on a DHCP-PD client facing interface with a destination address = in a prefix delegated
to a client connected to that interface, as follows:  For = point-to-point links, when the packet=E2=80=99s
ingress and egress interfaces match. For multi-access = links, when the packet=E2=80=99s ingress and
egress interface match, and the source MAC and next-hop = MAC addresses match. An
ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY
be sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be = configurable.

Thanks,
Ian

On 15. Oct 2020, at 03:51, Jen Linkova <furry13@gmail.com> wrote:

On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) = <volz@cisco.com> wrote:
If not, perhaps we just say:

R-4
To prevent routing loops, the relay SHOULD implement a configurable = policy to drop traffic received from an uplink interface as follows:

I'm not sure 'from an uplink interface' makes sense. In the case of a
routing loop caused by an amnesiac DHCP-PD client it would be a
downstream interface.
The scenario when such traffic arrives from an uplink interface is
'the uplink router believes the prefix is delegated to the client but
the relay does not have a route pointing to the client so it sends
traffic back' - so more likely 'an amnesiac relay' case.

For point-to-point links, when the = packet's ingress and egress interfaces match. For multi-access links, = when the packet's ingress and egress interface match, and the source MAC = and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to
destination) error message MAY be sent as per [RFC4443], section = 3.1.  The ICMP policy SHOULD be configurable.

- Bernie

-----Original Message-----
From: ianfarrer@gmx.com <ianfarrer@gmx.com>
Sent: Tuesday, October 13, 2020 9:16 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova = <furry13@gmail.com>
Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg <dhcwg@ietf.org>; 6man <ipv6@ietf.org>; v6ops list <v6ops@ietf.org>
Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi,

Thanks for all of the discussion on this. We=E2=80=99ve reworked the = requirement as follows:

R-4
To prevent routing loops, the relay SHOULD implement a configurable = policy to drop client traffic as follows:  For point-to-point = links, when the packet's ingress and egress interfaces match. For = multi-access links, when the packet's ingress and egress interface match, and the source MAC and next-hop MAC addresses match. An ICMPv6 = Type 1, Code 6 (Destination Unreachable, reject route to
destination) error message MAY be sent back to the client.  The = ICMP policy SHOULD be configurable.

Thanks,
Ian

On 9. Oct 2020, at 17:41, Michael = Richardson <mcr+ietf@sandelman.ca> wrote:


Jen Linkova <furry13@gmail.com> wrote:
I think there is confusion re: the = scenario we are talking about.
I've attached the diagram for the case which concerns me.
So:
- The Relay R has an interface eth0 connected to a switch S.
- Devices A and B are connected to the same switch and using R as a
default gateway.
- The prefix 2001:db8::/56 was delegated to a client A via the relay = R.

a friendly amendment to your example to aid in human comprehension:
   } - The prefix 2001:db8:0000:0123:/64 was delegated to = a client A via the relay R.
   }  - R installs a route for = 2001:db8:0000:0123:/64 towards A via eth0.

- The device B (which has an = address NOT from the delegated prefix,
but from another /64 assigned to that common link, let's sat
2001:db8:cafe::/64) sends a packet to an address from the delegated

now, my brain can more clearly see that 2001:db8:cafe::/64 is not
within 2001:db8:0000:0123:/64, while I had to use a few extra brain
cells to see that it wasn't in that ::/56 :-)

What I'd expect to happen (with = DHCP-PD or without - e.g. if R has a
static route towards A, not a dynamic route produced by PD):
- the packet is sent to A. Well, if A does not have a route to
2001:db8::42 then indeed a routing loop might happen. But if A does
have a route, the packet will be delivered.

What seems to be required by R4:
- R detects that the packet is received via eth0 and needs to be sent
back to eth0. R4 seems to require such packets to be dropped.
So if B would never be able to communicate to any address in the
delegated prefix, right?

Am I missing anything?
=

I think that you got it right.

Perhaps the missing piece of the = rule is don=E2=80=99t send it back to where it came from, based on link = layer addresses (or link if point-to-point).

Yes. If R4 was saying 'drop the = packet if it comes from the same
link-layer address you are going to send it back' - it would make
total sense. But I don't think routers do *that*.

Yes, if we made the check on L2 address, then it would work.
And I agree that routers are exactly doing that.

I think that it also works if B is a router with additional = interfaces
downstream, unless there are multiple paths.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . = o O ( IPv6 I=C3=B8T consulting )
         Sandelman Software = Works Inc, Ottawa and Worldwide

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--
SY, Jen Linkova aka Furry

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

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

On Mon, Nov 2, 2020 at 8:25 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
<= /div>
Let me ask a question of the operators.= This draft, as of today, is in discussion in 6man and will probably be dis= cussed in the 6man meeting. I have not offered the authors a slot in v6ops,= as it is not being discussed here. That said, it is presumably a solution = to an operational problem, in that the prefix that SLAAC is being used to g= enerate an address in is not exactly 64 bits.
=C2=A0 =C2=A0
=C2=A0 = =C2=A0 Gyan> Agreed on 6MAN slot.=C2=A0 Yes, solution to operational pro= blem.=C2=A0 We would discuss both problem and solution during the time slot= so I think 6MAN would be the right spot.=C2=A0 Correct.

Soliciting opinions on the problem: is this something that needs a solution= ? On the solution: what do you think of it? Does it have holes?
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0= Gyan> Yes soliciting opinions on the problem is the first step and poki= ng holes on v6ops before we get to solution - so v6ops ML is perfect spot f= or that.


> On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>=C2=A0 =C2=A0Dear v6OPS,
>
> This draft addresses the problem statement to change SLAAC's histo= rical fixed 64 bit boundary to variable PIO so that VLSM masking is support= ed just as it is today with static & DHCPv6 & DHCPv6 PD.=C2=A0
>
> This change to SLAAC to variable, ensures that parity is maintained be= tween the three address deployment mechanisms that exist today with IPv6.= =C2=A0 This draft as well addresses the MAJOR gap that exists today with la= ck of parity and the historical framework of the impact of this lack of par= tify that has existed since the IPv6 specification was published 20+ years = ago.
>
> We have a solutions draft below that is referenced in this draft that = goes over in detail the solution on 6MAN.
>
> ! Variable SLAAC
> https://datatracker.ietf.org/= doc/draft-mishra-6man-variable-slaac/
>
> Bob & Ole,
>
> Please review.=C2=A0 Based on the feedback received from 6MAN, I would= like to request a time slot on IETF 109.
>
> Kind Regards
>
> Gyan
>
>
>
> ---------- Forwarded message ---------
> From: Mishra, Gyan S <gyan.s.mishra@verizon.com>
> Date: Fri, Oct 30, 2020 at 6:50 PM
> Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-vari= able-slaac-problem-stmt-01.txt
> To: Hayabusanew <hayabusagsm@gmail.com>
>
>
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Oct 30, 2020 at 6:46 PM
> Subject: [E] New Version Notification for draft-mishra-v6ops-variable-= slaac-problem-stmt-01.txt
> To: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petrescu@= cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petrescu &= lt;Alexandre= .Petrescu@cea.fr>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.com>
>
>
>
> A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-stmt-0= 1.txt
> has been successfully submitted by Gyan Mishra and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-varia= ble-slaac-problem-stmt
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of arbitr= ary length in PIO (Variable SLAAC) - A Problem Statement
> Document date:=C2=A0 2020-10-30
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dh= ttps-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-= 2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3m= Z3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m= =3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-cXn0FCho9ZftXjO= -TuTH19Nr6MO5spHMPP0xR4&e=3D
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__d= atatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem= -2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ= &r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYR= nxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8= Q9kHxc&e=3D
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__data= tracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dprobl= em-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBT= Q&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oY= RnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3= KwlktF8&e=3D
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625= Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI= &e=3D
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariabl= e-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJ= lPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU= &m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQw7BqnqoVfmk= BjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D
>
> Abstract:
>=C2=A0 =C2=A0 In the past, various IPv6 addressing models have been pro= posed based
>=C2=A0 =C2=A0 on a subnet hierarchy embedding a 64-bit prefix.=C2=A0 Th= e last remnant of
>=C2=A0 =C2=A0 IPv6 classful addressing is a inflexible interface identi= fier
>=C2=A0 =C2=A0 boundary at /64.=C2=A0 This document details the 64-bit b= oundary problem
>=C2=A0 =C2=A0 statement.
>
>
>
>
> 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. >
> The IETF Secretariat
>
>
>
>
> --
>
>
> Gyan Mishra
> Network Solutions Architect & SME
> Data Center Planning | Common Core | Development & Engineering Lab= Services
> Global Technology Services | ITNUC
> O 240 970-6287
> M 301 502-1347
> 13101 Columbia Pike Rm 304-D
> Silver Spring, MD 20904
>
> IETF=C2=A0 & ISOC Member since 2015
> https://www.ietf.org/
> https://www.internetsociety.org/
>
>
>
>
> --
>
>
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

--
--000000000000c0e32e05b322dfce-- From nobody Mon Nov 2 09:29:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10CB3A0D93 for ; Mon, 2 Nov 2020 09:29:16 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK13uowcb2gq for ; Mon, 2 Nov 2020 09:29:14 -0800 (PST) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5896B3A0D91 for ; Mon, 2 Nov 2020 09:29:14 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id w3so1060213uau.2 for ; Mon, 02 Nov 2020 09:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k15UwgXtB823zKA7Wbw5RulM+eSlLPAUXvYePMgnc8o=; b=X1obaMJ2Q/vz3AYROe3qbaweDGOElGsbUEpvyshvz+JnwDhP92igvBZA3CH/EzqGiX rrx1BsOLr2dzpl5aj6wl5JeGT9Nq2ZoYVKnSt40dhyBC2qCxP0RG6JHbAJI3zZ0F4/v6 d5uTMJwBCmJYQS3qYJSFJqTry+OxyymFX68Pw+5s/LaCQuDDmYpydSVHQmpMx4AIqwrK YFUgR7yNIyWmILjQrQqVuFv/rLptN5RJMPyvkA4rhjCJIflvzRJ52il0Dqit7wL9bRgs 1gX1pZy8wp7YBLQWmh9xHS14mOdA1nR46999e92cGY5AlU5HXjShcIROqxE3t7om4VL7 ak/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k15UwgXtB823zKA7Wbw5RulM+eSlLPAUXvYePMgnc8o=; b=RwTgtb0HUT/JKhwz3gqv2u60T0H6d2BTt+acgvG4KPq6qY6e7mOztRVITqlUdEwflY NTWCGPwutPL+k59i4rUBPeugodRApXs70Kbw6jmkg3+6GKOCzV7NCNTRl02LOPoHBCfl JdTiSgxaFC8uzyF3sYXyW2GTnvgj/kw/xwN6ep8pa+Pga2RHXbIcOMvXjFmnO/Y80Lq7 sW+PvkGJESq1hce6MgCTJeYTi4uMkYF5px3gL1V+gXuqoYAAFHNlD0NYQfGKJfIxssP+ 4fbNvpvAtFLW8+jXyv4P3l1rkSS2OUlFAjJa++GxMCdlY7ulJvEcCDmV65QbQC/VGReG s0zA== X-Gm-Message-State: AOAM533Z1Ro6qafiYQRsMf4F301I10VO8M8phqHTeDubXNqHptm7odBG wSNteyaULD6Eg/EkGQJLSGYhxe8mIDUNG9siyQE= X-Google-Smtp-Source: ABdhPJwqYPLV0nxdBCsq80zwAyJwKOb56qQMMzy928ESzfYUMzwru9ljUgd8o5R+inUSAeJRSwW5dIxB1SpVgqDmYU8= X-Received: by 2002:ab0:48ae:: with SMTP id x43mr8156256uac.114.1604338153331; Mon, 02 Nov 2020 09:29:13 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> In-Reply-To: From: Gyan Mishra Date: Mon, 2 Nov 2020 12:29:02 -0500 Message-ID: To: Lorenzo Colitti Cc: Alexandre Petrescu , Dmytro Shytyi , Fred Baker , Gyan Mishra , IPv6 Operations , Naveen Kottapalli Content-Type: multipart/alternative; boundary="000000000000ba9e7f05b32315e1" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:29:17 -0000 --000000000000ba9e7f05b32315e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 2, 2020 at 8:33 AM Lorenzo Colitti wrote: > AFAICS this is a straight violation of the text in RFC 4291 which says > that interface IDs are 64 bits long. As such, I don't see the point in > discussing it unless there is reason to believe that that text will chang= e. > Gyan> Yes this is a violation as this draft updates RFC 4861 removing the 64 bit boundary and providing a solution that is backwards compatible so that there is not any impact to any existing deployments which is a must for this solution to be even viable in the least. > > There was a very long and very heated discussion about that text a few > years ago when the 6man tried to take 4291 to full standard. That consume= d > a lot of WG time and ultimately resulted in no changes. I expect there ar= e > still going to be very strong opinions on both sides. If we are to reopen > that discussion now, it should happen in 6man, not v6ops. That way those > discussions will at least only happen in one place. > Gyan> Yes I remember being on some of those heated debates. This development was spawned from those debates but it took quite some time to build a concrete problem statement to move the ball forward. So my thoughts are to kickoff the initial discuss on v6ops on the problem what is broke, and then at some point shift over to 6MAN on the discussion of the problem and road to the solution. > > On Mon, Nov 2, 2020 at 10:25 PM Fred Baker > wrote: > >> Let me ask a question of the operators. This draft, as of today, is in >> discussion in 6man and will probably be discussed in the 6man meeting. I >> have not offered the authors a slot in v6ops, as it is not being discuss= ed >> here. That said, it is presumably a solution to an operational problem, = in >> that the prefix that SLAAC is being used to generate an address in is no= t >> exactly 64 bits. >> >> Soliciting opinions on the problem: is this something that needs a >> solution? On the solution: what do you think of it? Does it have holes? >> >> > On Nov 2, 2020, at 12:14 AM, Gyan Mishra wrote= : >> > >> > Dear v6OPS, >> > >> > This draft addresses the problem statement to change SLAAC's historica= l >> fixed 64 bit boundary to variable PIO so that VLSM masking is supported >> just as it is today with static & DHCPv6 & DHCPv6 PD. >> > >> > This change to SLAAC to variable, ensures that parity is maintained >> between the three address deployment mechanisms that exist today with >> IPv6. This draft as well addresses the MAJOR gap that exists today with >> lack of parity and the historical framework of the impact of this lack o= f >> partify that has existed since the IPv6 specification was published 20+ >> years ago. >> > >> > We have a solutions draft below that is referenced in this draft that >> goes over in detail the solution on 6MAN. >> > >> > ! Variable SLAAC >> > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >> > >> > Bob & Ole, >> > >> > Please review. Based on the feedback received from 6MAN, I would like >> to request a time slot on IETF 109. >> > >> > Kind Regards >> > >> > Gyan >> > >> > >> > >> > ---------- Forwarded message --------- >> > From: Mishra, Gyan S >> > Date: Fri, Oct 30, 2020 at 6:50 PM >> > Subject: Fwd: [E] New Version Notification for >> draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt >> > To: Hayabusanew >> > >> > >> > >> > >> > ---------- Forwarded message --------- >> > From: >> > Date: Fri, Oct 30, 2020 at 6:46 PM >> > Subject: [E] New Version Notification for >> draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt >> > To: Naveen Kottapalli , Alexandre Petrescu < >> alexandre.petrescu@cea.fr>, Gyan Mishra , >> Alexandre Petrescu , Dusan Mudric < >> dmudric@ciena.com>, Dmytro Shytyi >> > >> > >> > >> > A new version of I-D, >> draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt >> > has been successfully submitted by Gyan Mishra and posted to the >> > IETF repository. >> > >> > Name: draft-mishra-v6ops-variable-slaac-problem-stmt >> > Revision: 01 >> > Title: SLAAC with prefixes of arbitrary length in PIO >> (Variable SLAAC) - A Problem Statement >> > Document date: 2020-10-30 >> > Group: Individual Submission >> > Pages: 12 >> > URL: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_arch= ive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&= d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mq= q0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27= MAoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D >> > Status: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwI= CaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn= 2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D >> > Htmlized: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D >> > Htmlized: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ht= ml_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D >> > Diff: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcd= iff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D0= 1&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4= mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx= 27MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D >> > >> > Abstract: >> > In the past, various IPv6 addressing models have been proposed base= d >> > on a subnet hierarchy embedding a 64-bit prefix. The last remnant = of >> > IPv6 classful addressing is a inflexible interface identifier >> > boundary at /64. This document details the 64-bit boundary problem >> > statement. >> > >> > >> > >> > >> > 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 >> > >> > >> > >> > >> > -- >> > >> > >> > Gyan Mishra >> > Network Solutions Architect & SME >> > Data Center Planning | Common Core | Development & Engineering Lab >> Services >> > Global Technology Services | ITNUC >> > O 240 970-6287 >> > M 301 502-1347 >> > 13101 Columbia Pike Rm 304-D >> >> >> > >> Silver Spring, MD 20904 >> >> > >> > IETF & ISOC Member since 2015 >> > https://www.ietf.org/ >> > https://www.internetsociety.org/ >> > >> > >> > >> > >> > -- >> > >> > >> > Gyan Mishra >> > Network Solutions Architect >> > M 301 502-1347 >> > 13101 Columbia Pike >> >> >> > >> Silver Spring, MD >> >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000ba9e7f05b32315e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

--
--000000000000ba9e7f05b32315e1-- From nobody Mon Nov 2 11:10:13 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37663A0B3C for ; Mon, 2 Nov 2020 11:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUZhKF25Pnmi for ; Mon, 2 Nov 2020 11:10:09 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFE33A0B08 for ; Mon, 2 Nov 2020 11:10:08 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id n15so15932090wrq.2 for ; Mon, 02 Nov 2020 11:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4jd6C7EvR4cYwJrVHwLSbxpo98GUSsUD7kObg+q9NzQ=; b=LARBznEcqKhDtCtCCYW2I7R7A7TmdKvy089xKEMd2wYg9DTZfpUvhTrkkxpIrWpFrO wUSvMNsyIluq1ePvwqrnT6mX07ePr7ODJLGJm6Eei04P8CEz4jbhFKBUvNnhxRXsi98f NkAM8ws3fw5VSrSvThPZoPYTmwWpU+8fd77ds9LK4TA46buZDqvpux7mXdXiFdyqKBxn /awYm+3B5q3pFHGxGlzHTpc91wlS870VMEdWdql0epO1stzg8LUoliUPPcCYqTvdr/Om 6VdQ+wA6qYcaEgYeM7nQEtMNA+YfKON7CbzUxpRS1xvcHLaYegS0pxHobHG6S7UFg0fN iuJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4jd6C7EvR4cYwJrVHwLSbxpo98GUSsUD7kObg+q9NzQ=; b=c12N1CQbpbc+Nf0CQlxYrcCfSykXn0ouqaKiWHSR/ngBsNAYtm6m6hcjFVjPhW8KSK LhCO0tFiL7NB396UIcE7EsU3+JKP9fGBTNncOxmKGhlntvidTmizoYr7WztJOqFjoD5b Nj363uj229vN7smQGvxEUL+MKjmWI7+YiajCAO09bPlKDjL0F7Ia7UjeqznjLO4Sto3U iE3Ta2wmPWi5nbuv4YHlln8jJoZO3nvtL9f6Vlq8vv5feRjW9hfWoC2LEfWzzRc01+PK uTrZ0dGE/Rg54U310weytVjCFElxM7PEuqc9wnH1sE2MD2ahm/AEEE5m231WNmTAolDl s6tg== X-Gm-Message-State: AOAM531C+HJeLULjRB56RtvNEhZhfRyGF2FI3RGNaYQZjt77AC+9EImv e1KRbMS96oNWhz1/laShc2o= X-Google-Smtp-Source: ABdhPJzskAe8db8w9b6xU9FrK6ptsbOg5f2GwZ8o8Dg5omWgTE9Mom78P6RjIG78SGt7hj0AszuYew== X-Received: by 2002:a5d:4148:: with SMTP id c8mr21674609wrq.261.1604344207252; Mon, 02 Nov 2020 11:10:07 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:d8a1:de28:c52d:9528? ([2601:647:5a00:ef0b:d8a1:de28:c52d:9528]) by smtp.gmail.com with ESMTPSA id t199sm373143wmt.46.2020.11.02.11.10.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 11:10:06 -0800 (PST) From: Bob Hinden Message-Id: <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_19C3217B-1074-4B77-96C7-FE38C0F562E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Mon, 2 Nov 2020 11:09:57 -0800 In-Reply-To: Cc: Bob Hinden , Fred Baker , IPv6 Operations , Gyan Mishra To: Lorenzo Colitti References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 19:10:11 -0000 --Apple-Mail=_19C3217B-1074-4B77-96C7-FE38C0F562E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, What Lorenzo said. Further, I did quick read and see some immediate issues. First off SLACC works just fine with any size prefix/interface ID. = The protocol supports different sized prefixes/IIDs. The purported = issue relates to interface ID sizes. These drafts appear to be = confused about that. The v6ops draft goes beyond a problem, it it has an IANA section = requesting a new RA flag. Bob > On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti = wrote: >=20 > AFAICS this is a straight violation of the text in RFC 4291 which says = that interface IDs are 64 bits long. As such, I don't see the point in = discussing it unless there is reason to believe that that text will = change. >=20 > There was a very long and very heated discussion about that text a few = years ago when the 6man tried to take 4291 to full standard. That = consumed a lot of WG time and ultimately resulted in no changes. I = expect there are still going to be very strong opinions on both sides. = If we are to reopen that discussion now, it should happen in 6man, not = v6ops. That way those discussions will at least only happen in one = place. >=20 > On Mon, Nov 2, 2020 at 10:25 PM Fred Baker = wrote: > Let me ask a question of the operators. This draft, as of today, is in = discussion in 6man and will probably be discussed in the 6man meeting. I = have not offered the authors a slot in v6ops, as it is not being = discussed here. That said, it is presumably a solution to an operational = problem, in that the prefix that SLAAC is being used to generate an = address in is not exactly 64 bits. >=20 > Soliciting opinions on the problem: is this something that needs a = solution? On the solution: what do you think of it? Does it have holes? >=20 > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra = wrote: > > > > Dear v6OPS, > > > > This draft addresses the problem statement to change SLAAC's = historical fixed 64 bit boundary to variable PIO so that VLSM masking is = supported just as it is today with static & DHCPv6 & DHCPv6 PD. > > > > This change to SLAAC to variable, ensures that parity is maintained = between the three address deployment mechanisms that exist today with = IPv6. This draft as well addresses the MAJOR gap that exists today with = lack of parity and the historical framework of the impact of this lack = of partify that has existed since the IPv6 specification was published = 20+ years ago. > > > > We have a solutions draft below that is referenced in this draft = that goes over in detail the solution on 6MAN. > > > > ! Variable SLAAC > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > Bob & Ole, > > > > Please review. Based on the feedback received from 6MAN, I would = like to request a time slot on IETF 109. > > > > Kind Regards > > > > Gyan > > > > > > > > ---------- Forwarded message --------- > > From: Mishra, Gyan S > > Date: Fri, Oct 30, 2020 at 6:50 PM > > Subject: Fwd: [E] New Version Notification for = draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > To: Hayabusanew > > > > > > > > > > ---------- Forwarded message --------- > > From: > > Date: Fri, Oct 30, 2020 at 6:46 PM > > Subject: [E] New Version Notification for = draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > To: Naveen Kottapalli , Alexandre Petrescu = , Gyan Mishra , = Alexandre Petrescu , Dusan Mudric = , Dmytro Shytyi > > > > > > > > A new version of I-D, = draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > has been successfully submitted by Gyan Mishra and posted to the > > IETF repository. > > > > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > > Revision: 01 > > Title: SLAAC with prefixes of arbitrary length in PIO = (Variable SLAAC) - A Problem Statement > > Document date: 2020-10-30 > > Group: Individual Submission > > Pages: 12 > > URL: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archiv= e_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mq= q0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > Status: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn= 2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > Htmlized: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0U= Y8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MA= oo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > Htmlized: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D > > Diff: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdif= f-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4= mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oD= x27MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > Abstract: > > In the past, various IPv6 addressing models have been proposed = based > > on a subnet hierarchy embedding a 64-bit prefix. The last = remnant of > > IPv6 classful addressing is a inflexible interface identifier > > boundary at /64. This document details the 64-bit boundary = problem > > statement. > > > > > > > > > > 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 > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect & SME > > Data Center Planning | Common Core | Development & Engineering Lab = Services > > Global Technology Services | ITNUC > > O 240 970-6287 > > M 301 502-1347 > > 13101 Columbia Pike Rm 304-D > > Silver Spring, MD 20904 > > > > IETF & ISOC Member since 2015 > > https://www.ietf.org/ > > https://www.internetsociety.org/ > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_19C3217B-1074-4B77-96C7-FE38C0F562E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+gWYUACgkQrut0EXfn u6iAJgf9HJDrhgn4trCaXVShiTxoRpMz7oLdguwC3n+5a+cqcQvoXA9nY7yu2lMs 5z1ukXZJoRRyA+KLdb2zkHBbWF1WcoQacBLmQ/nSl2OOAKSjI4Gr/+6LYAEf0qYy DdENt5xI2rqi4iYNYKih24GJ5fkuE51ANmDO3tPLuakrIduJIpbp89WPWtNzyD38 wrDezIlHmZJlQ/vlBAQViKodAthgepJ7vWwQE+aP5zDVGjm+JeVBe3XtkjHPJzm4 emiZVWV6w5tK4753+eLFqUFe3mjG4hN3yPUMtoBTLOINKHAYUT9N+TTjLOZeYBsZ opB6kyNSmf1N1F3jBe4wLw5AFnbagw== =GxN8 -----END PGP SIGNATURE----- --Apple-Mail=_19C3217B-1074-4B77-96C7-FE38C0F562E8-- From nobody Mon Nov 2 12:08:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3F3A0FB6 for ; Mon, 2 Nov 2020 12:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7NwCwS4j7ze for ; Mon, 2 Nov 2020 12:08:55 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8603A12E6 for ; Mon, 2 Nov 2020 12:08:35 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id h6so11736011pgk.4 for ; Mon, 02 Nov 2020 12:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KdpEm11WAaglRFis7Vr3r6xNEnGrF2jOwsomTJd9hRg=; b=PljC+XEW7lCM8XwleCnWjCsDU5zcqiLfyRdUg9F8OqH5dkQRzWtNYVe2oCJjjeABt0 xaDBGZz/wLXx4r62IJyuICUzSxSR9qmiQAJkRFT5Uz9jzh/LbBvi1FIvHA3o+y4FXhUP pC+UWvauUg9Vt32VXyAM2xLWPC5YzWq2ewRgOwX7Xlk/bepoNecspfwsFD1CCboph7A0 bUFDsdVOP5xISP0HIe91xZAQozu+8qzt96VFLdRbnWGqIXFctEwDL9JkV9It19zE2VIO kzpBzvksYBeWSGfweNASoJTh3VIACZeCcA4BQmCrqOnC4SnDufbT8PFZHnwmrQSgXVpd vEmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KdpEm11WAaglRFis7Vr3r6xNEnGrF2jOwsomTJd9hRg=; b=ThAHEfMLn8izmTR9XhRZzkwE/ZDLA630QDnJWBmGaSmkbUjiWQsaxQ/tZYv3VZnb2x eStINf63d57gHBPi+TttMCt9GHD/ydY6l9OpoidP0wpQz5IkNggZJr8V/GqWOi1CRfov C9nDe4boMRSY6WRjBZcuBK4KkGb6hk3+yw6n7+FmOm7apk+vwsmcb/CaZ5tXaSq4BnMd oqi1ZmEAX56fgFq2HuAZjXJ+K8qBVVWS+ZHXNc9TtJii7AlnD8G4y/wVmyxjcySyiUT1 M6ViAkKZuPZdMXpDYewxzZY09/WIOvd4T3g9D9Gf+q4d1xNRHYU92F2NpcQYSBDGKQ21 UYOg== X-Gm-Message-State: AOAM533pLa46dkteh06Yu27DvzVbgMAV1dAk90r4NU7inAoktng22krU Rvgg/PMgnpA02UCeB55hIjk= X-Google-Smtp-Source: ABdhPJyNxbAmIcrc5MnBjEDzJxwV6ORk8IMvXwcukJdZ2KnYBLTw0pMYUfSWRPnvBoEltWKaYQr6FA== X-Received: by 2002:a17:90a:d182:: with SMTP id fu2mr8054604pjb.145.1604347715076; Mon, 02 Nov 2020 12:08:35 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id o15sm15756694pfp.91.2020.11.02.12.08.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 12:08:34 -0800 (PST) To: Gyan Mishra , Fred Baker Cc: Dmytro Shytyi , Naveen Kottapalli , IPv6 Operations , Gyan Mishra , Alexandre Petrescu References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 3 Nov 2020 09:08:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 20:08:58 -0000 On 03-Nov-20 06:13, Gyan Mishra wrote: >=20 >=20 > On Mon, Nov 2, 2020 at 8:25 AM Fred Baker > wrote: >=20 > Let me ask a question of the operators. This draft, as of today, is= in discussion in 6man and will probably be discussed in the 6man meeting= =2E I have not offered the authors a slot in v6ops, as it is not being di= scussed here. That said, it is presumably a solution to an operational pr= oblem, in that the prefix that SLAAC is being used to generate an address= in is not exactly 64 bits. >=20 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 Gyan> Agreed on 6MAN slot.=C2=A0 Yes, solution to operati= onal problem.=C2=A0 We would discuss both problem and solution during the= time slot so I think 6MAN would be the right spot.=C2=A0 Correct. Why would 6man spend time on solving a problem before the operational com= munity agreees that there is a problem? My understanding is that the principal operational requirement is already= stated in BCP198 (RFC7608). There was a previous attempt to change the s= tatus quo in https://tools.ietf.org/html/draft-bourbaki-6man-classless-ip= v6 but that didn't advance. So let's have a discussion whether there is a new operational problem her= e first: "The main problem is that SLAAC RA or PD allocates a /64 by the wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however segmentation of the /64 via SLAAC is required so that downstream interfaces can be further sub-netted." Why isn't that in v6ops scope? > Soliciting opinions on the problem: is this something that needs a = solution? Is there any reason why the mobile devices can't be given a /56 or /48, w= hich solves the problem immediately? Brian On the solution: what do you think of it? Does it have holes? >=20 > =C2=A0 =C2=A0=C2=A0 > =C2=A0 =C2=A0 Gyan> Yes soliciting opinions on the problem is the first= step and poking holes on v6ops before we get to solution - so v6ops ML i= s perfect spot for that. >=20 >=20 >=20 > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra > wrote: > > > >=C2=A0 =C2=A0Dear v6OPS, > > > > This draft addresses the problem statement to change SLAAC's hist= orical fixed 64 bit boundary to variable PIO so that VLSM masking is supp= orted just as it is today with static & DHCPv6 & DHCPv6 PD.=C2=A0 > > > > This change to SLAAC to variable, ensures that parity is maintain= ed between the three address deployment mechanisms that exist today with = IPv6.=C2=A0 This draft as well addresses the MAJOR gap that exists today = with lack of parity and the historical framework of the impact of this la= ck of partify that has existed since the IPv6 specification was published= 20+ years ago. > > > > We have a solutions draft below that is referenced in this draft = that goes over in detail the solution on 6MAN. > > > > ! Variable SLAAC > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac= / > > > > Bob & Ole, > > > > Please review.=C2=A0 Based on the feedback received from 6MAN, I = would like to request a time slot on IETF 109. > > > > Kind Regards > > > > Gyan > > > > > > > > ---------- Forwarded message --------- > > From: Mishra, Gyan S > > > Date: Fri, Oct 30, 2020 at 6:50 PM > > Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops= -variable-slaac-problem-stmt-01.txt > > To: Hayabusanew > > > > > > > > > > > ---------- Forwarded message --------- > > From: = > > > Date: Fri, Oct 30, 2020 at 6:46 PM > > Subject: [E] New Version Notification for draft-mishra-v6ops-vari= able-slaac-problem-stmt-01.txt > > To: Naveen Kottapalli >, Alexandre Petrescu >, Gyan Mishra >, Alexandre Petrescu >, Dusan Mudric >, Dmytro Shytyi > > > > > > > > > A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-s= tmt-01.txt > > has been successfully submitted by Gyan Mishra and posted to the > > IETF repository. > > > > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-= variable-slaac-problem-stmt > > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001 > > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of a= rbitrary length in PIO (Variable SLAAC) - A Problem Statement > > Document date:=C2=A0 2020-10-30 > > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission > > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12 > > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.= proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archive_id_draft-2Dmishr= a-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudB= TRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qO= W_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-= cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proof= point.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dmishra-2D= v6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg= 7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML2= 8ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIi= w5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint= =2Ecom/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-= 2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhq= g7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML= 28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOc= qSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint= =2Ecom/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dmishra-2Dv6ops-2D= variable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHp= JlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&= m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwG= X54ODGu0gmDToc_EweEdtI&e=3D > > Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.= proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2= Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3Du= dBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7= qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQ= w7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > Abstract: > >=C2=A0 =C2=A0 In the past, various IPv6 addressing models have bee= n proposed based > >=C2=A0 =C2=A0 on a subnet hierarchy embedding a 64-bit prefix.=C2=A0= The last remnant of > >=C2=A0 =C2=A0 IPv6 classful addressing is a inflexible interface i= dentifier > >=C2=A0 =C2=A0 boundary at /64.=C2=A0 This document details the 64-= bit boundary problem > >=C2=A0 =C2=A0 statement. > > > > > > > > > > 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.o= rg . > > > > The IETF Secretariat > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect & SME > > Data Center Planning | Common Core | Development & Engineering La= b Services > > Global Technology Services | ITNUC > > O 240 970-6287 > > M 301 502-1347 > > 13101 Columbia Pike Rm 304-D > > Silver Spring, MD 20904 > > > > IETF=C2=A0 & ISOC Member since 2015 > > https://www.ietf.org/ > > https://www.internetsociety.org/ > > > > > > > > > > -- > > > > > > Gyan Mishra > > Network Solutions Architect > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > --=20 >=20 > >=20 > *Gyan Mishra* >=20 > /Network Solutions A//rchitect=C2=A0/ >=20 > /M 301 502-1347 > 13101 Columbia Pike=C2=A0 > /Silver Spring, MD >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Nov 2 15:19:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF953A128F for ; Mon, 2 Nov 2020 15:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 rQZqiELlcs5p for ; Mon, 2 Nov 2020 15:19:29 -0800 (PST) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645EC3A03FC for ; Mon, 2 Nov 2020 15:19:29 -0800 (PST) Received: by mail-vs1-f43.google.com with SMTP id b3so8444029vsc.5 for ; Mon, 02 Nov 2020 15:19:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pqfAdok3Y9AvteGwWgzymsYiDNL0gVoRCHBBSrMriAg=; b=nMshKytw0fXmj9FkFcodlJFEvULTtvgy4562/7/xfHvj8DPM6VjDz5j7P/FTgjf1R4 69nP7dxcEQI2zfN6UWYKiURfGdL5keSqTgLaGMP5s3r2elLM5XX9Q+7914GpNZfoPFxF qNbXBdMpx7oA9WDHh2mmKXsqtA626l8CCr+db8/n8apqSz6VKn79oRNHRg/W43ikIfbf zM8OyAaqeWCAEyzHPCEysFL2xLgWFCRCRqxLbiTOEYMhPDXDQ6fVfRHrJhHWdkETye3Y Vc5WrL5fDJc6hCsNVI1RLfuEhsnJVTMJA2I5w5fESxt5XgXXqF97ia+L4ixuKtItci1i N9RQ== X-Gm-Message-State: AOAM531blxSYl8QK2T/5WEW7gW8px5sjzKWim60JLjhmns3Br3fjUO3d tbpzZ+pDFidHFAzSeV82Hj7IYjnlYd4EbjS2Ab8= X-Google-Smtp-Source: ABdhPJzyDFfIFBdykqN55LM1Dm+dtHfft099xGWqAKDVRlkdZNAlOfDROd1I6t5GzZjw4J6U8/kYZtVLPSGgzyZH7q8= X-Received: by 2002:a67:f453:: with SMTP id r19mr16086750vsn.43.1604359168400; Mon, 02 Nov 2020 15:19:28 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> In-Reply-To: <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 2 Nov 2020 15:19:17 -0800 Message-ID: To: Bob Hinden Cc: Lorenzo Colitti , IPv6 Operations , Gyan Mishra Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:19:31 -0000 At Mon, 2 Nov 2020 11:09:57 -0800, Bob Hinden wrote: > First off SLACC works just fine with any size prefix/interface ID. > The protocol supports different sized prefixes/IIDs. The purported > issue relates to interface ID sizes. These drafts appear to be > confused about that. +1. Even the draft title has the confusion: "SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Statement". The SLAAC protocol itself as defined in RFC4862 already works with an arbitrary prefix length. Today's limitation, i.e., the interface identifier (and therefore the prefix also) length used in SLAAC is always 64 bits in practice, just comes from the addressing architecture (RFC4291) and IPv6-over-foo standards (that are supposed to be consistent with the addressing architecture). If the "problem(s)" the authors see are this limitation, the draft should target at the addressing architecture and/or IPv6-over-foo specs, not SLAAC. So, for example, the title would have to be: "IPv6 subnet prefixes of arbitrary length - A Problem Statement" or "Arbitrary Length Interface Identifiers - A Problem Statement" (both "subnet prefix" and "interface identifier" are a concept defined in the address architecture). -- JINMEI, Tatuya From nobody Mon Nov 2 15:56:57 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 108C63A14EC; Mon, 2 Nov 2020 15:56:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <160436140502.19738.5638510722481791464@ietfa.amsl.com> Date: Mon, 02 Nov 2020 15:56:45 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-slaac-renum-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:56: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 WG of the IETF. Title : Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events Authors : Fernando Gont Jan Zorz Richard Patterson Filename : draft-ietf-v6ops-slaac-renum-05.txt Pages : 13 Date : 2020-11-02 Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-05 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-slaac-renum-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-slaac-renum-05 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 Nov 2 15:57:00 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 302933A1397; Mon, 2 Nov 2020 15:56:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , "Owen DeLong" , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160436140517.19738.10093050465283244959@ietfa.amsl.com> Date: Mon, 02 Nov 2020 15:56:45 -0800 Archived-At: Subject: [v6ops] New Version Notification - draft-ietf-v6ops-slaac-renum-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:56:52 -0000 A new version (-05) has been submitted for draft-ietf-v6ops-slaac-renum: https://www.ietf.org/archive/id/draft-ietf-v6ops-slaac-renum-05.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-slaac-renum-05 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Mon Nov 2 19:01:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87C3A1392 for ; Mon, 2 Nov 2020 19:01:48 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5RgdP7I_4_s for ; Mon, 2 Nov 2020 19:01:45 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02F53A1393 for ; Mon, 2 Nov 2020 19:01:44 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id u7so8654908vsq.11 for ; Mon, 02 Nov 2020 19:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nz9qpxtDVcIy7u2VIcSewqGuD2HFUAl5mRdbwyIXVOw=; b=Yiwji7D6obr0u8ZO/oGK/99WVWkboTPYUYohHtbiIjLqRjakah8CJj9ZhIEkYEViHm GL/+QYGWUjB7ZLb3COb1NyaOLfpPd+eNdru52QlyNb/xDz9FEpUDb3nJ2UGftLkiU61h M2/fUUxBZBRXqNP0BDYt7CdPP6kur5KOlf+p8p/ULl5xOejh3FcRnBWGaNyj8U9yf3Jf jr4NzJYMdfnAYNnFaAS5KrD6wzT0a5FRt5+mpwtcEnNOpLu7JV+dFdg+r9fy/GoBMIDQ QHF26qDP4POAy+BO4tEJwE/yTjKbEq8P8oqc87HgkiZXp2Nq22OWvS/42dwEvCDorNWO A1ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nz9qpxtDVcIy7u2VIcSewqGuD2HFUAl5mRdbwyIXVOw=; b=RRnZhr/VxnUNVOZ/1NRvAsrltQOlN6c5TmsVWsZddOiDDarhZWVewbKC64iOpAK0sh dGzMDVOodmqq7uwu6i+sSL6NpzyymCm4vBm1jG00gC7Ko2DqLUN1W8OtXRsJ/Gbpv8xy q6cYfnEHMn5aVMYSnDt8a9V9ucyGQhAGsNOFqujhpcbVu7wLAi5k/sfY9Gf58Y7BJxye GM++wS95g0sdmSur9k6itBQB2ZXPyoZ/KOPFGwC3Sp/l+qFcAcXn7sbzL+ZJQiRy8Cbz i3QxMkY/9anNyxvDQCL8O9SEpHzgLZMLBUtk+WXy3EycU6ZxC6kWdxNc5l1Z8tGUd8cI 8U6Q== X-Gm-Message-State: AOAM531tLqJmTN9zWBlr0A6WFRSO0GQ1Zb7IHNT0A+Hner3R3amTlqsb o/0x8GXw3miuyAaCfRAReDfxmdT8/QgHkvOcjfA= X-Google-Smtp-Source: ABdhPJziZpPVa3W+ajA1AGHxJCqPT2vJmN1Lq9Oeq6+VFhDXZIBTisersV67YCcuz74j44B+oEnMcFuTz/ftxs/ESDw= X-Received: by 2002:a67:e9c5:: with SMTP id q5mr6257462vso.5.1604372503864; Mon, 02 Nov 2020 19:01:43 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> In-Reply-To: <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> From: Gyan Mishra Date: Mon, 2 Nov 2020 21:55:39 -0500 Message-ID: To: Bob Hinden Cc: Lorenzo Colitti , IPv6 Operations , Gyan Mishra Content-Type: multipart/alternative; boundary="0000000000002e2a4205b32b15e7" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 03:01:48 -0000 --0000000000002e2a4205b32b15e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden wrote: > Hi, > > What Lorenzo said. > > Further, I did quick read and see some immediate issues. > > First off SLACC works just fine with any size prefix/interface ID. The > protocol supports different sized prefixes/IIDs. The purported issue > relates to interface ID sizes. These drafts appear to be confused about > that. > > The v6ops draft goes beyond a problem, it it has an IANA section > requesting a new RA flag. > Gyan> The v6ops draft is about defining the problem statement not solution so no IANA requests in that draft - that was in error - fixed in next revision > > Bob > > > > On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti 40google.com@dmarc.ietf.org> wrote: > > > > AFAICS this is a straight violation of the text in RFC 4291 which says > that interface IDs are 64 bits long. As such, I don't see the point in > discussing it unless there is reason to believe that that text will chang= e. > > > > There was a very long and very heated discussion about that text a few > years ago when the 6man tried to take 4291 to full standard. That consume= d > a lot of WG time and ultimately resulted in no changes. I expect there ar= e > still going to be very strong opinions on both sides. If we are to reopen > that discussion now, it should happen in 6man, not v6ops. That way those > discussions will at least only happen in one place. > > > > On Mon, Nov 2, 2020 at 10:25 PM Fred Baker > wrote: > > Let me ask a question of the operators. This draft, as of today, is in > discussion in 6man and will probably be discussed in the 6man meeting. I > have not offered the authors a slot in v6ops, as it is not being discusse= d > here. That said, it is presumably a solution to an operational problem, i= n > that the prefix that SLAAC is being used to generate an address in is not > exactly 64 bits. > > > > Soliciting opinions on the problem: is this something that needs a > solution? On the solution: what do you think of it? Does it have holes? > > > > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra > wrote: > > > > > > Dear v6OPS, > > > > > > This draft addresses the problem statement to change SLAAC's > historical fixed 64 bit boundary to variable PIO so that VLSM masking is > supported just as it is today with static & DHCPv6 & DHCPv6 PD. > > > > > > This change to SLAAC to variable, ensures that parity is maintained > between the three address deployment mechanisms that exist today with > IPv6. This draft as well addresses the MAJOR gap that exists today with > lack of parity and the historical framework of the impact of this lack of > partify that has existed since the IPv6 specification was published 20+ > years ago. > > > > > > We have a solutions draft below that is referenced in this draft that > goes over in detail the solution on 6MAN. > > > > > > ! Variable SLAAC > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > > > Bob & Ole, > > > > > > Please review. Based on the feedback received from 6MAN, I would lik= e > to request a time slot on IETF 109. > > > > > > Kind Regards > > > > > > Gyan > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: Mishra, Gyan S > > > Date: Fri, Oct 30, 2020 at 6:50 PM > > > Subject: Fwd: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > To: Hayabusanew > > > > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: > > > Date: Fri, Oct 30, 2020 at 6:46 PM > > > Subject: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > To: Naveen Kottapalli , Alexandre Petrescu < > alexandre.petrescu@cea.fr>, Gyan Mishra , > Alexandre Petrescu , Dusan Mudric < > dmudric@ciena.com>, Dmytro Shytyi > > > > > > > > > > > > A new version of I-D, > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > has been successfully submitted by Gyan Mishra and posted to the > > > IETF repository. > > > > > > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > > > Revision: 01 > > > Title: SLAAC with prefixes of arbitrary length in PIO > (Variable SLAAC) - A Problem Statement > > > Document date: 2020-10-30 > > > Group: Individual Submission > > > Pages: 12 > > > URL: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archi= ve_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > > Status: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY= 8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo= &s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2r= xBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D > > > Diff: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdi= ff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4m= qq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > > > Abstract: > > > In the past, various IPv6 addressing models have been proposed bas= ed > > > on a subnet hierarchy embedding a 64-bit prefix. The last remnant > of > > > IPv6 classful addressing is a inflexible interface identifier > > > boundary at /64. This document details the 64-bit boundary proble= m > > > statement. > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > -- > > > > > > > > > Gyan Mishra > > > Network Solutions Architect & SME > > > Data Center Planning | Common Core | Development & Engineering Lab > Services > > > Global Technology Services | ITNUC > > > O 240 970-6287 > > > M 301 502-1347 > > > 13101 Columbia Pike Rm 304-D > > > Silver Spring, MD 20904 > > > > > > IETF & ISOC Member since 2015 > > > https://www.ietf.org/ > > > https://www.internetsociety.org/ > > > > > > > > > > > > > > > -- > > > > > > > > > Gyan Mishra > > > Network Solutions Architect > > > M 301 502-1347 > > > 13101 Columbia Pike > > > Silver Spring, MD > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002e2a4205b32b15e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000002e2a4205b32b15e7-- From nobody Mon Nov 2 22:18:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA403A14AB for ; Mon, 2 Nov 2020 22:18:36 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpUB3IdqL-IO for ; Mon, 2 Nov 2020 22:18:32 -0800 (PST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A862C3A1504 for ; Mon, 2 Nov 2020 22:18:10 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id z123so4137524vsb.0 for ; Mon, 02 Nov 2020 22:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tx2syzDu4cVv3PNZNL9BWUPRWlXt486sDscIaEhBWko=; b=ThYvgmesAsHxhY+ZK4ExOBe6Cmnox+8Em3rTiJrsk4OFjjPbtN1zFpgzw5PAHuasHH 4UuEzQBPu51drILhGdlhQZybSpcP6EMM7aDxqG1CH/g8ycobHd/jZDE+Ci4puVy0JAlw QIlx9XabRoLc6L2H2W1loNp+BCkFqxOMqH7QurL5eypDfg4I9FgMIDL9cW6XEOU5CPAL 5jSepAv7wWKF4PvMZIubilnb1G6Cr/BOARXct8OA1acHsYU/DAQrub4J+SlCygYhSLNf OAw1De7LykVymu9kP6IM0DQHirVCitFprTsURkBXiEY0Svkfvc6nrnD5JpWRQVqXX8gm Ghpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tx2syzDu4cVv3PNZNL9BWUPRWlXt486sDscIaEhBWko=; b=W5TLYvVX79Oyp4Hjd45bJdfThRkrEJm8hybSlKDi7RnCmVvTPSlLeTIVTXRNENkgP7 3YukgX1LcXutcvkJHR5ZoQLQtF+K9oacFEXG6quZ/PaeBoDqWPBKKEsHY965+MGvDQMI BtjO/9BgwTkR/npmNrrJyMBmfC/s5AbLXaSWfHrim5cWiNVtP8d/UTB07LgId1KTZl7y +oaLUVqGzrTwWzapZ+W9//dD+cNG4sG6Ma9xYLxpv4E+Fd6HSzF6TKVy2DKqiJ5dxiTl OVOuEKM6DwaFa/vhLj5JucjDnqPjGvfOiDU2Ez3R8qF8WyIPv21xxjEJgVEfvMO8nifH sIOQ== X-Gm-Message-State: AOAM531Az92DvEE0YDo6336laQN2eS9+RuZa7VMjj0zwpKfu7Qd67WA2 71l7WFqYdNT9dsVGhslJ4gZu6YGLaoLtRfw9L4I= X-Google-Smtp-Source: ABdhPJxtiKpgU5YtMv+b1P3BbRxHaJRfRV08hNDKhu25Is92+/ZzXxVW68Nx0s68BYpuIt7ifbFT7GwYLFvdyeJgGcc= X-Received: by 2002:a67:6f06:: with SMTP id k6mr16855391vsc.20.1604384289469; Mon, 02 Nov 2020 22:18:09 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> In-Reply-To: From: Gyan Mishra Date: Tue, 3 Nov 2020 01:12:05 -0500 Message-ID: To: Brian E Carpenter Cc: Fred Baker , Dmytro Shytyi , Naveen Kottapalli , IPv6 Operations , Gyan Mishra , Alexandre Petrescu Content-Type: multipart/alternative; boundary="000000000000a837e605b32dd3ff" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 06:18:37 -0000 --000000000000a837e605b32dd3ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 2, 2020 at 3:08 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 03-Nov-20 06:13, Gyan Mishra wrote: > > > > > > On Mon, Nov 2, 2020 at 8:25 AM Fred Baker > wrote: > > > > Let me ask a question of the operators. This draft, as of today, is > in discussion in 6man and will probably be discussed in the 6man meeting.= I > have not offered the authors a slot in v6ops, as it is not being discusse= d > here. That said, it is presumably a solution to an operational problem, i= n > that the prefix that SLAAC is being used to generate an address in is not > exactly 64 bits. > > > > > > Gyan> Agreed on 6MAN slot. Yes, solution to operational problem. > We would discuss both problem and solution during the time slot so I thin= k > 6MAN would be the right spot. Correct. > > Why would 6man spend time on solving a problem before the operational > community agreees that there is a problem? > > My understanding is that the principal operational requirement is already > stated in BCP198 (RFC7608). There was a previous attempt to change the > status quo in > https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6 but that > didn't advance. > > So let's have a discussion whether there is a new operational problem her= e > first: > > "The main problem is that SLAAC RA or PD allocates a /64 by the > wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however > segmentation of the /64 via SLAAC is required so that downstream > interfaces can be further sub-netted." > Gyan> Correct. That is the issue. > > Why isn't that in v6ops scope? > I think the problem would be I would think in scope to v6ops however as Fred & Lorenzo pointed out that it maybe better to keep the entire discussion in 6MAN as it pertains to operations problem but then also solutions to the problem that updates slaac which is in a separate 6man draft. So having the entire discussion in 6man makes sense. I see you already started the thread there so I will join in. > > > Soliciting opinions on the problem: is this something that needs a > solution? > > Is there any reason why the mobile devices can't be given a /56 or /48, > which solves the problem immediately? > 4G & 5G carrier standard is /64 per handset for both IPv6 only and dual stack deployments. Even though there is a way tremendous amount of space in IPv6 I believe last count worldwide is 14 billion handsets. This issue with /64 segmentation does become more pronounced with 5G as it competes with broadband use case and in many cases SOHO customers may eliminate their broadband and rely solely on 5G and need the segmentation. > > Brian > > On the solution: what do you think of it? Does it have holes? > > > > > > Gyan> Yes soliciting opinions on the problem is the first step and > poking holes on v6ops before we get to solution - so v6ops ML is perfect > spot for that. > > > > > > > > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra > wrote: > > > > > > Dear v6OPS, > > > > > > This draft addresses the problem statement to change SLAAC's > historical fixed 64 bit boundary to variable PIO so that VLSM masking is > supported just as it is today with static & DHCPv6 & DHCPv6 PD. > > > > > > This change to SLAAC to variable, ensures that parity is > maintained between the three address deployment mechanisms that exist tod= ay > with IPv6. This draft as well addresses the MAJOR gap that exists today > with lack of parity and the historical framework of the impact of this la= ck > of partify that has existed since the IPv6 specification was published 20= + > years ago. > > > > > > We have a solutions draft below that is referenced in this draft > that goes over in detail the solution on 6MAN. > > > > > > ! Variable SLAAC > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac= / > > > > > > Bob & Ole, > > > > > > Please review. Based on the feedback received from 6MAN, I would > like to request a time slot on IETF 109. > > > > > > Kind Regards > > > > > > Gyan > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: Mishra, Gyan S gyan.s.mishra@verizon.com>> > > > Date: Fri, Oct 30, 2020 at 6:50 PM > > > Subject: Fwd: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > To: Hayabusanew hayabusagsm@gmail.com>> > > > > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: = > > > > Date: Fri, Oct 30, 2020 at 6:46 PM > > > Subject: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > To: Naveen Kottapalli nkottapalli@benu.net>>, Alexandre Petrescu >, Gyan Mishra < > gyan.s.mishra@verizon.com >, Alexandre > Petrescu >, > Dusan Mudric >, Dmytro > Shytyi > > > > > > > > > > > > > A new version of I-D, > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > has been successfully submitted by Gyan Mishra and posted to the > > > IETF repository. > > > > > > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > > > Revision: 01 > > > Title: SLAAC with prefixes of arbitrary length in PIO > (Variable SLAAC) - A Problem Statement > > > Document date: 2020-10-30 > > > Group: Individual Submission > > > Pages: 12 > > > URL: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archi= ve_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > > Status: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY= 8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo= &s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2r= xBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D > > > Diff: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdi= ff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4m= qq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > > > Abstract: > > > In the past, various IPv6 addressing models have been proposed > based > > > on a subnet hierarchy embedding a 64-bit prefix. The last > remnant of > > > IPv6 classful addressing is a inflexible interface identifier > > > boundary at /64. This document details the 64-bit boundary > problem > > > statement. > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > -- > > > > > > > > > Gyan Mishra > > > Network Solutions Architect & SME > > > Data Center Planning | Common Core | Development & Engineering La= b > Services > > > Global Technology Services | ITNUC > > > O 240 970-6287 > > > M 301 502-1347 > > > 13101 Columbia Pike Rm 304-D > > > Silver Spring, MD 20904 > > > > > > IETF & ISOC Member since 2015 > > > https://www.ietf.org/ > > > https://www.internetsociety.org/ > > > > > > > > > > > > > > > -- > > > > > > > > > Gyan Mishra > > > Network Solutions Architect > > > M 301 502-1347 > > > 13101 Columbia Pike > > > Silver Spring, MD > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a837e605b32dd3ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 2, 2020 at 3:08 PM Brian = E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 03-Nov-20 06:13, Gyan Mishra wrote:
>
>
> On Mon, Nov 2, 2020 at 8:25 AM Fred Baker <fredbaker.ietf@gmail.com <mail= to:fredbaker.= ietf@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Let me ask a question of the operators. This draft,= as of today, is in discussion in 6man and will probably be discussed in th= e 6man meeting. I have not offered the authors a slot in v6ops, as it is no= t being discussed here. That said, it is presumably a solution to an operat= ional problem, in that the prefix that SLAAC is being used to generate an a= ddress in is not exactly 64 bits.
>
> =C2=A0 =C2=A0
> =C2=A0 =C2=A0 Gyan> Agreed on 6MAN slot.=C2=A0 Yes, solution to ope= rational problem.=C2=A0 We would discuss both problem and solution during t= he time slot so I think 6MAN would be the right spot.=C2=A0 Correct.

Why would 6man spend time on solving a problem before the operational commu= nity agreees that there is a problem?

My understanding is that the principal operational requirement is already s= tated in BCP198 (RFC7608). There was a previous attempt to change the statu= s quo in https://tools.ietf.org/html/d= raft-bourbaki-6man-classless-ipv6 but that didn't advance.

So let's have a discussion whether there is a new operational problem h= ere first:

=C2=A0 "The main problem is that SLAAC RA or PD allocates a /64 by the=
=C2=A0 =C2=A0wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, ho= wever
=C2=A0 =C2=A0segmentation of the /64 via SLAAC is required so that downstre= am
=C2=A0 =C2=A0interfaces can be further sub-netted."

=C2=A0 =C2=A0 =C2=A0 Gyan> Correct.=C2=A0 That is the = issue.=C2=A0 =C2=A0

Why isn't that in v6ops scope?
=C2=A0 =C2=A0=C2=A0=
=C2=A0 =C2=A0 I think the problem would be I would think in scop= e to v6ops however as Fred & Lorenzo pointed out that it maybe better t= o keep the entire discussion in 6MAN as it pertains to operations problem b= ut then also solutions to the problem that updates slaac which is in a sepa= rate 6man draft.=C2=A0 So having the entire discussion in 6man makes sense.= =C2=A0 I see you already started the thread there so I will join in.
<= div>=C2=A0

>=C2=A0 =C2=A0 =C2=A0Soliciting opinions on the problem: is this somethi= ng that needs a solution?

Is there any reason why the mobile devices can't be given a /56 or /48,= which solves the problem immediately?

= =C2=A0 4G & 5G carrier standard is /64 per handset for both IPv6 only a= nd dual stack deployments.=C2=A0 Even though there is a way tremendous amou= nt of space in IPv6 I believe last count worldwide is 14 billion handsets.= =C2=A0
=C2=A0 This issue with /64 segmentation does become more p= ronounced with 5G=C2=A0 as it competes with broadband use case and in many = cases SOHO customers may eliminate their broadband and rely solely on 5G an= d need the segmentation.=C2=A0 =C2=A0

=C2=A0 =C2=A0 Brian

On the solution: what do you think of it? Does it have holes?
>
> =C2=A0 =C2=A0=C2=A0
> =C2=A0 =C2=A0 Gyan> Yes soliciting opinions on the problem is the f= irst step and poking holes on v6ops before we get to solution - so v6ops ML= is perfect spot for that.
>
>
>
>=C2=A0 =C2=A0 =C2=A0> On Nov 2, 2020, at 12:14 AM, Gyan Mishra <<= a href=3D"mailto:hayabusagsm@gmail.com" target=3D"_blank">hayabusagsm@gmail= .com <mailto:hayabusagsm@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Dear v6OPS,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This draft addresses the problem statement to = change SLAAC's historical fixed 64 bit boundary to variable PIO so that= VLSM masking is supported just as it is today with static & DHCPv6 &am= p; DHCPv6 PD.=C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This change to SLAAC to variable, ensures that= parity is maintained between the three address deployment mechanisms that = exist today with IPv6.=C2=A0 This draft as well addresses the MAJOR gap tha= t exists today with lack of parity and the historical framework of the impa= ct of this lack of partify that has existed since the IPv6 specification wa= s published 20+ years ago.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> We have a solutions draft below that is refere= nced in this draft that goes over in detail the solution on 6MAN.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ! Variable SLAAC
>=C2=A0 =C2=A0 =C2=A0> https= ://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Bob & Ole,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Please review.=C2=A0 Based on the feedback rec= eived from 6MAN, I would like to request a time slot on IETF 109.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Kind Regards
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Gyan
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ---------- Forwarded message ---------
>=C2=A0 =C2=A0 =C2=A0> From: Mishra, Gyan S <gyan.s.mishra@verizon.com <= ;mailto:gyan= .s.mishra@verizon.com>>
>=C2=A0 =C2=A0 =C2=A0> Date: Fri, Oct 30, 2020 at 6:50 PM
>=C2=A0 =C2=A0 =C2=A0> Subject: Fwd: [E] New Version Notification for= draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
>=C2=A0 =C2=A0 =C2=A0> To: Hayabusanew <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com= >>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ---------- Forwarded message ---------
>=C2=A0 =C2=A0 =C2=A0> From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf= .org>>
>=C2=A0 =C2=A0 =C2=A0> Date: Fri, Oct 30, 2020 at 6:46 PM
>=C2=A0 =C2=A0 =C2=A0> Subject: [E] New Version Notification for draf= t-mishra-v6ops-variable-slaac-problem-stmt-01.txt
>=C2=A0 =C2=A0 =C2=A0> To: Naveen Kottapalli <nkottapalli@benu.net <mailto:<= a href=3D"mailto:nkottapalli@benu.net" target=3D"_blank">nkottapalli@benu.n= et>>, Alexandre Petrescu <alexandre.petrescu@cea.fr <mailto:alexandre.petrescu@= cea.fr>>, Gyan Mishra <gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.= com>>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr <mailto:Alexandre.Petrescu= @cea.fr>>, Dusan Mudric <dmudric@ciena.com <mailto:dmudric@ciena.com>>, Dmytro Shytyi= <dmytro.shyt= yi@sfr.com <mailto:dmytro.shytyi@sfr.com>>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> A new version of I-D, draft-mishra-v6ops-varia= ble-slaac-problem-stmt-01.txt
>=C2=A0 =C2=A0 =C2=A0> has been successfully submitted by Gyan Mishra= and posted to the
>=C2=A0 =C2=A0 =C2=A0> IETF repository.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= draft-mishra-v6ops-variable-slaac-problem-stmt
>=C2=A0 =C2=A0 =C2=A0> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
>=C2=A0 =C2=A0 =C2=A0> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC= with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Stat= ement
>=C2=A0 =C2=A0 =C2=A0> Document date:=C2=A0 2020-10-30
>=C2=A0 =C2=A0 =C2=A0> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indiv= idual Submission
>=C2=A0 =C2=A0 =C2=A0> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12 >=C2=A0 =C2=A0 =C2=A0> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = https://urldefense.pro= ofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv= 6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3Dud= BTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO= 7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&= s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D
>=C2=A0 =C2=A0 =C2=A0> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvar= iable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJ= lPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU= &m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFj= yIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D
>=C2=A0 =C2=A0 =C2=A0> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-= 2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7= UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML= 28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFa= i1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D
>=C2=A0 =C2=A0 =C2=A0> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url= ?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaa= c-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3= LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m= =3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojw= GX54ODGu0gmDToc_EweEdtI&e=3D
>=C2=A0 =C2=A0 =C2=A0> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmi= shra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c= =3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo= &s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Abstract:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 In the past, various IPv6 address= ing models have been proposed based
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 on a subnet hierarchy embedding a= 64-bit prefix.=C2=A0 The last remnant of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 IPv6 classful addressing is a inf= lexible interface identifier
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 boundary at /64.=C2=A0 This docum= ent details the 64-bit boundary problem
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 statement.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Please note that it may take a couple of minut= es from the time of submission
>=C2=A0 =C2=A0 =C2=A0> until the htmlized version and diff are availa= ble at tools.ietf.org <http://tools.ietf.org>.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The IETF Secretariat
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> --
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0> Network Solutions Architect & SME
>=C2=A0 =C2=A0 =C2=A0> Data Center Planning | Common Core | Developme= nt & Engineering Lab Services
>=C2=A0 =C2=A0 =C2=A0> Global Technology Services | ITNUC
>=C2=A0 =C2=A0 =C2=A0> O 240 970-6287
>=C2=A0 =C2=A0 =C2=A0> M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0> 13101 Columbia Pike Rm 304-D
>=C2=A0 =C2=A0 =C2=A0> Silver Spring, MD 20904
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> IETF=C2=A0 & ISOC Member since 2015
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/
>=C2=A0 =C2=A0 =C2=A0> https://www.internetsociety.org/ >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> --
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0> Network Solutions Architect
>=C2=A0 =C2=A0 =C2=A0> M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0> 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0> Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0> v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0> v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman= /listinfo/v6ops
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect=C2=A0/
>
> /M 301 502-1347
> 13101 Columbia Pike=C2=A0
> /Silver Spring, MD
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>



=
On Mon, Nov 2, 2020 at 2:10 PM Bob Hi= nden <bob.hinden@gmail.com&g= t; wrote:
Hi,
What Lorenzo said.

Further, I did quick read and see some immediate issues.

First off SLACC works just fine with any size prefix/interface ID.=C2=A0 = =C2=A0 The protocol supports different sized prefixes/IIDs.=C2=A0 =C2=A0The= purported issue relates to interface ID sizes.=C2=A0 =C2=A0These drafts ap= pear to be confused about that.

The v6ops draft goes beyond a problem, it it has an IANA section requesting= a new RA flag.

=C2=A0 =C2=A0Gyan> T= he v6ops draft is about defining the problem statement not solution so no I= ANA requests in that draft - that was in error - fixed in next revision=C2= =A0

Bob


> On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti <lorenzo=3D40google.com@dmarc.iet= f.org> wrote:
>
> AFAICS this is a straight violation of the text in RFC 4291 which says= that interface IDs are 64 bits long. As such, I don't see the point in= discussing it unless there is reason to believe that that text will change= .
>
> There was a very long and very heated discussion about that text a few= years ago when the 6man tried to take 4291 to full standard. That consumed= a lot of WG time and ultimately resulted in no changes. I expect there are= still going to be very strong opinions on both sides. If we are to reopen = that discussion now, it should happen in 6man, not v6ops. That way those di= scussions will at least only happen in one place.
>
> On Mon, Nov 2, 2020 at 10:25 PM Fred Baker <fredbaker.ietf@gmail.com> wro= te:
> Let me ask a question of the operators. This draft, as of today, is in= discussion in 6man and will probably be discussed in the 6man meeting. I h= ave not offered the authors a slot in v6ops, as it is not being discussed h= ere. That said, it is presumably a solution to an operational problem, in t= hat the prefix that SLAAC is being used to generate an address in is not ex= actly 64 bits.
>
> Soliciting opinions on the problem: is this something that needs a sol= ution? On the solution: what do you think of it? Does it have holes?
>
> > On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:=
> >
> >=C2=A0 =C2=A0Dear v6OPS,
> >
> > This draft addresses the problem statement to change SLAAC's = historical fixed 64 bit boundary to variable PIO so that VLSM masking is su= pported just as it is today with static & DHCPv6 & DHCPv6 PD.
> >
> > This change to SLAAC to variable, ensures that parity is maintain= ed between the three address deployment mechanisms that exist today with IP= v6.=C2=A0 This draft as well addresses the MAJOR gap that exists today with= lack of parity and the historical framework of the impact of this lack of = partify that has existed since the IPv6 specification was published 20+ yea= rs ago.
> >
> > We have a solutions draft below that is referenced in this draft = that goes over in detail the solution on 6MAN.
> >
> > ! Variable SLAAC
> > https://datatracker.ietf= .org/doc/draft-mishra-6man-variable-slaac/
> >
> > Bob & Ole,
> >
> > Please review.=C2=A0 Based on the feedback received from 6MAN, I = would like to request a time slot on IETF 109.
> >
> > Kind Regards
> >
> > Gyan
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: Mishra, Gyan S <gyan.s.mishra@verizon.com>
> > Date: Fri, Oct 30, 2020 at 6:50 PM
> > Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops= -variable-slaac-problem-stmt-01.txt
> > To: Hayabusanew <hayabusagsm@gmail.com>
> >
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Fri, Oct 30, 2020 at 6:46 PM
> > Subject: [E] New Version Notification for draft-mishra-v6ops-vari= able-slaac-problem-stmt-01.txt
> > To: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petre= scu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petres= cu <Alexa= ndre.Petrescu@cea.fr>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.c= om>
> >
> >
> >
> > A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-s= tmt-01.txt
> > has been successfully submitted by Gyan Mishra and posted to the<= br> > > IETF repository.
> >
> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-= variable-slaac-problem-stmt
> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of a= rbitrary length in PIO (Variable SLAAC) - A Problem Statement
> > Document date:=C2=A0 2020-10-30
> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission > > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
> > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Ds= laac-2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJl= Pps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&= amp;m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-cXn0FCho9Z= ftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D
> > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= __datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dprob= lem-2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0Pom= BTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8= oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBf= iR8Q9kHxc&e=3D
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2D= problem-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0= PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hF= oz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTk= H1qE3KwlktF8&e=3D
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tool= s.ietf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-= 2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&= ;r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB6= 25Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEd= tI&e=3D
> > Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/ur= l?u=3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvari= able-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7U= HpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML2= 8ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQw7BqnqoV= fmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D
> >
> > Abstract:
> >=C2=A0 =C2=A0 In the past, various IPv6 addressing models have bee= n proposed based
> >=C2=A0 =C2=A0 on a subnet hierarchy embedding a 64-bit prefix.=C2= =A0 The last remnant of
> >=C2=A0 =C2=A0 IPv6 classful addressing is a inflexible interface i= dentifier
> >=C2=A0 =C2=A0 boundary at /64.=C2=A0 This document details the 64-= bit boundary problem
> >=C2=A0 =C2=A0 statement.
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> > --
> >
> >
> > Gyan Mishra
> > Network Solutions Architect & SME
> > Data Center Planning | Common Core | Development & Engineerin= g Lab Services
> > Global Technology Services | ITNUC
> > O 240 970-6287
> > M 301 502-1347
> > 13101 Columbia Pike Rm 304-D
> > Silver Spring, MD 20904
> >
> > IETF=C2=A0 & ISOC Member since 2015
> > https://www.ietf.org/
> > https://www.internetsociety.org/
> >
> >
> >
> >
> > --
> >
> >
> > Gyan Mishra
> > Network Solutions Architect
> > M 301 502-1347
> > 13101 Columbia Pike
> > Silver Spring, MD
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/v6ops=
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

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


--

Gyan Mishra

Network Solutions A= rchitect=C2= =A0

M 301 502-1347
13101 Columbia= Pike=C2=A0
Silver Spring, MD


<= /div>


--

Gyan Mishra

Network Solutions A= rchitect=C2= =A0

M 301 502-1347
13101 Columbia= Pike=C2=A0
Silver Spring, MD


<= /div>

On Mon, Nov 2, 2020 at 8:33 AM Lorenzo Colitti <lorenzo= =3D40google.com@dmarc.ietf.o= rg> wrote:
= AFAICS this is a straight violation of the text in RFC 4291 which says that= interface IDs are 64 bits long. As such, I don't see the point in disc= ussing it unless there is reason to believe that that text will change.

=C2= =A0 =C2=A0 Gyan> Yes this is a violation as this draft updates RFC 4861 = removing the 64 bit boundary and providing a solution that is backwards com= patible so that there is not any impact to any existing deployments which i= s a must for this solution to be even viable in the least.

There was a very l= ong and very heated discussion about that text a few years ago when the 6ma= n tried to take 4291 to full standard. That consumed a lot of WG time and u= ltimately resulted in no changes. I expect there are still going to be very= strong opinions on both sides. If we are to reopen that discussion now, it= should happen in 6man, not v6ops. That way those discussions will at least= only happen in one place.

=C2=A0 =C2=A0Gyan> Yes I remember being on some of= those heated debates.=C2=A0 This development was spawned from those debate= s but it took quite some time to build a concrete problem statement to move= the ball forward.=C2=A0 So my thoughts are to kickoff the initial discuss = on v6ops on the problem what is broke, and then at some point shift over to= 6MAN on the discussion of the problem and road to the solution.
On Mon, = Nov 2, 2020 at 10:25 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
=
Let me ask a question of = the operators. This draft, as of today, is in discussion in 6man and will p= robably be discussed in the 6man meeting. I have not offered the authors a = slot in v6ops, as it is not being discussed here. That said, it is presumab= ly a solution to an operational problem, in that the prefix that SLAAC is b= eing used to generate an address in is not exactly 64 bits.

Soliciting opinions on the problem: is this something that needs a solution= ? On the solution: what do you think of it? Does it have holes?

> On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>=C2=A0 =C2=A0Dear v6OPS,
>
> This draft addresses the problem statement to change SLAAC's histo= rical fixed 64 bit boundary to variable PIO so that VLSM masking is support= ed just as it is today with static & DHCPv6 & DHCPv6 PD.=C2=A0
>
> This change to SLAAC to variable, ensures that parity is maintained be= tween the three address deployment mechanisms that exist today with IPv6.= =C2=A0 This draft as well addresses the MAJOR gap that exists today with la= ck of parity and the historical framework of the impact of this lack of par= tify that has existed since the IPv6 specification was published 20+ years = ago.
>
> We have a solutions draft below that is referenced in this draft that = goes over in detail the solution on 6MAN.
>
> ! Variable SLAAC
> https://datatracker.ietf.org/= doc/draft-mishra-6man-variable-slaac/
>
> Bob & Ole,
>
> Please review.=C2=A0 Based on the feedback received from 6MAN, I would= like to request a time slot on IETF 109.
>
> Kind Regards
>
> Gyan
>
>
>
> ---------- Forwarded message ---------
> From: Mishra, Gyan S <gyan.s.mishra@verizon.com>
> Date: Fri, Oct 30, 2020 at 6:50 PM
> Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-vari= able-slaac-problem-stmt-01.txt
> To: Hayabusanew <hayabusagsm@gmail.com>
>
>
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Oct 30, 2020 at 6:46 PM
> Subject: [E] New Version Notification for draft-mishra-v6ops-variable-= slaac-problem-stmt-01.txt
> To: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petrescu@= cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petrescu &= lt;Alexandre= .Petrescu@cea.fr>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.com>
>
>
>
> A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-stmt-0= 1.txt
> has been successfully submitted by Gyan Mishra and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-varia= ble-slaac-problem-stmt
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of arbitr= ary length in PIO (Variable SLAAC) - A Problem Statement
> Document date:=C2=A0 2020-10-30
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?u=3Dh= ttps-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-= 2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3m= Z3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m= =3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-cXn0FCho9ZftXjO= -TuTH19Nr6MO5spHMPP0xR4&e=3D
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__d= atatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem= -2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ= &r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYR= nxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8= Q9kHxc&e=3D
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__data= tracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dprobl= em-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBT= Q&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oY= RnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3= KwlktF8&e=3D
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r= =3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625= Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI= &e=3D
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariabl= e-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJ= lPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU= &m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQw7BqnqoVfmk= BjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D
>
> Abstract:
>=C2=A0 =C2=A0 In the past, various IPv6 addressing models have been pro= posed based
>=C2=A0 =C2=A0 on a subnet hierarchy embedding a 64-bit prefix.=C2=A0 Th= e last remnant of
>=C2=A0 =C2=A0 IPv6 classful addressing is a inflexible interface identi= fier
>=C2=A0 =C2=A0 boundary at /64.=C2=A0 This document details the 64-bit b= oundary problem
>=C2=A0 =C2=A0 statement.
>
>
>
>
> 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. >
> The IETF Secretariat
>
>
>
>
> --
>
>
> Gyan Mishra
> Network Solutions Architect & SME
> Data Center Planning | Common Core | Development & Engineering Lab= Services
> Global Technology Services | ITNUC
> O 240 970-6287
> M 301 502-1347
> 13101 Col= umbia Pike Rm 304-D
> Silve= r Spring, MD 20904
>
> IETF=C2=A0 & ISOC Member since 2015
> https://www.ietf.org/
> https://www.internetsociety.org/
>
>
>
>
> --
>
>
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000a837e605b32dd3ff-- From nobody Mon Nov 2 22:34:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98113A14DA for ; Mon, 2 Nov 2020 22:34:17 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEk_tt09kmQH for ; Mon, 2 Nov 2020 22:34:15 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4703A14D7 for ; Mon, 2 Nov 2020 22:34:15 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id n189so3486780vkb.3 for ; Mon, 02 Nov 2020 22:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9cTtVekMQQWLfpSqKCI1RBpqzfI0XqnQrWHK69j6GPk=; b=lPl5KlOouYFYZD5jeBus1JHgNpS+92FT/vJKKdreE124weJDjr1W8v6BVwZap8UMuP 879TPPHzxI0Lwpb9YergCB/V3ivXdruIURlGtwZ1dQdRmp1aILTo24X4gwr7tvI4ecn4 8DvFPgYnWjpQ1/Im2s1pmcyCkRQi8QjG8r5zKnk2j3GtNiUgAh8xe6cpHf4CiSZYpm8P 1lppv5+VR4KgQBa1aG3KBG0USpFjbQYhu1+fTcoOpMLyeylLroCn0Dxy5RXYPmOVnqnE R9m7PAflUcyLQnxypnqndPPZRPzW9EdIrKHIkM080+JXN2nhuOZ684EtkJ2oNctfXL6q WDLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9cTtVekMQQWLfpSqKCI1RBpqzfI0XqnQrWHK69j6GPk=; b=I7X/xLDwNZHzsPrx9i/9dBj26JGT27HV5WBs+Kznx+naKqqPZQwt6Dh3s92TyyJ41N qlWvNbDIWffI2KHeL689ebe8icz2l6kvrRgqutztqFfsi8IsvgWeE4ih2sf/29P6S70e me99uLiX60BkKTbGQz6Rx2zz2ffz4kGEqCvCzoKyQgkHDJpk+BrJxbjuP9wFajgtSu4z HGHbP7QBRzFl+G6PUVqhwLDW08wHeF8PDASGK0bW56QcMpV80xA6mo5YbzlmTmnLh7wb y6lQ1qXeBm118z5cbEUELEC168coqqSX6Ir1ioZSUlSO2kAPjSSOTY+X1cR3VEHe/i6N yIYg== X-Gm-Message-State: AOAM531fuAG2CMU6uDYF8GYMCFflwlwGKyZVG7eqpD+LJlW28ua3Zw6g d8Ogh+RbfBtCc8HHo21QyGjLFszh47hTcoAsm/k= X-Google-Smtp-Source: ABdhPJx4VJA8GPlolGrLeh9wHBzVdBOENR1j5uwBo2pk5qIDCHk8DDOgavuDvqLKp0NC+5jFm5suy//YwcuEOBcrU5o= X-Received: by 2002:a05:6122:12a7:: with SMTP id j7mr8987801vkp.15.1604385254028; Mon, 02 Nov 2020 22:34:14 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> In-Reply-To: <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> From: Gyan Mishra Date: Tue, 3 Nov 2020 01:28:10 -0500 Message-ID: To: Bob Hinden Cc: Lorenzo Colitti , IPv6 Operations , Gyan Mishra Content-Type: multipart/alternative; boundary="00000000000026393a05b32e0dd7" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 06:34:18 -0000 --00000000000026393a05b32e0dd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob In-line On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden wrote: > Hi, > > What Lorenzo said. > > Further, I did quick read and see some immediate issues. > > First off SLACC works just fine with any size prefix/interface ID. The > protocol supports different sized prefixes/IIDs. The purported issue > relates to interface ID sizes. These drafts appear to be confused about > that. > > Gyan> Understood that SLAAC in itself does not create the restriction as the 64 bit boundary restriction is due to 64 bit IID fixed length when A flag is set. The 6man draft below identifies the solution and references the last time this topic came up about a year or so ago with this draft " https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05" This draft submitted on 6man discusses the history behind the slaac 64 bit fixed iid and refrences the v6ops draft problem statement and defines the RA flag solution for slaac to support vlsm & eliminating the IID fixed 64 bit boundary. https://tools.ietf.org/html/draft-mishra-6man-variable-slaac-01 > The v6ops draft goes beyond a problem, it it has an IANA section > requesting a new RA flag. Gyan> This was a typo -wll update when draft > submissions opens back up > > Bob > > > > On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti 40google.com@dmarc.ietf.org> wrote: > > > > AFAICS this is a straight violation of the text in RFC 4291 which says > that interface IDs are 64 bits long. As such, I don't see the point in > discussing it unless there is reason to believe that that text will chang= e. > > > > There was a very long and very heated discussion about that text a few > years ago when the 6man tried to take 4291 to full standard. That consume= d > a lot of WG time and ultimately resulted in no changes. I expect there ar= e > still going to be very strong opinions on both sides. If we are to reopen > that discussion now, it should happen in 6man, not v6ops. That way those > discussions will at least only happen in one place. > > > > On Mon, Nov 2, 2020 at 10:25 PM Fred Baker > wrote: > > Let me ask a question of the operators. This draft, as of today, is in > discussion in 6man and will probably be discussed in the 6man meeting. I > have not offered the authors a slot in v6ops, as it is not being discusse= d > here. That said, it is presumably a solution to an operational problem, i= n > that the prefix that SLAAC is being used to generate an address in is not > exactly 64 bits. > > > > Soliciting opinions on the problem: is this something that needs a > solution? On the solution: what do you think of it? Does it have holes? > > > > > On Nov 2, 2020, at 12:14 AM, Gyan Mishra > wrote: > > > > > > Dear v6OPS, > > > > > > This draft addresses the problem statement to change SLAAC's > historical fixed 64 bit boundary to variable PIO so that VLSM masking is > supported just as it is today with static & DHCPv6 & DHCPv6 PD. > > > > > > This change to SLAAC to variable, ensures that parity is maintained > between the three address deployment mechanisms that exist today with > IPv6. This draft as well addresses the MAJOR gap that exists today with > lack of parity and the historical framework of the impact of this lack of > partify that has existed since the IPv6 specification was published 20+ > years ago. > > > > > > We have a solutions draft below that is referenced in this draft that > goes over in detail the solution on 6MAN. > > > > > > ! Variable SLAAC > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > > > Bob & Ole, > > > > > > Please review. Based on the feedback received from 6MAN, I would lik= e > to request a time slot on IETF 109. > > > > > > Kind Regards > > > > > > Gyan > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: Mishra, Gyan S > > > Date: Fri, Oct 30, 2020 at 6:50 PM > > > Subject: Fwd: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > To: Hayabusanew > > > > > > > > > > > > > > > ---------- Forwarded message --------- > > > From: > > > Date: Fri, Oct 30, 2020 at 6:46 PM > > > Subject: [E] New Version Notification for > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > To: Naveen Kottapalli , Alexandre Petrescu < > alexandre.petrescu@cea.fr>, Gyan Mishra , > Alexandre Petrescu , Dusan Mudric < > dmudric@ciena.com>, Dmytro Shytyi > > > > > > > > > > > > A new version of I-D, > draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt > > > has been successfully submitted by Gyan Mishra and posted to the > > > IETF repository. > > > > > > Name: draft-mishra-v6ops-variable-slaac-problem-stmt > > > Revision: 01 > > > Title: SLAAC with prefixes of arbitrary length in PIO > (Variable SLAAC) - A Problem Statement > > > Document date: 2020-10-30 > > > Group: Individual Submission > > > Pages: 12 > > > URL: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_archi= ve_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d= =3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq= 0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27M= Aoo&s=3DdtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D > > > Status: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=3DDwIC= aQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2= rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s= =3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=3D > > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=3D= DwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY= 8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo= &s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=3D > > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICa= Q&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2r= xBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3D= BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=3D > > > Diff: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdi= ff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01= &d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4m= qq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx2= 7MAoo&s=3DZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D > > > > > > Abstract: > > > In the past, various IPv6 addressing models have been proposed bas= ed > > > on a subnet hierarchy embedding a 64-bit prefix. The last remnant > of > > > IPv6 classful addressing is a inflexible interface identifier > > > boundary at /64. This document details the 64-bit boundary proble= m > > > statement. > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > -- > > > > > > > > > Gyan Mishra > > > Network Solutions Architect & SME > > > Data Center Planning | Common Core | Development & Engineering Lab > Services > > > Global Technology Services | ITNUC > > > O 240 970-6287 > > > M 301 502-1347 > > > 13101 Columbia Pike Rm 304-D > > > Silver Spring, MD 20904 > > > > > > IETF & ISOC Member since 2015 > > > https://www.ietf.org/ > > > https://www.internetsociety.org/ > > > > > > > > > > > > > > > -- > > > > > > > > > Gyan Mishra > > > Network Solutions Architect > > > M 301 502-1347 > > > 13101 Columbia Pike > > > Silver Spring, MD > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000026393a05b32e0dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob

In-line

On Mon, Nov 2,= 2020 at 2:10 PM Bob Hinden <bob= .hinden@gmail.com> wrote:
Hi,

What Lorenzo said.

Further, I did quick read and see some immediate issues.

First off SLACC works just fine with any size prefix/interface ID.=C2=A0 = =C2=A0 The protocol supports different sized prefixes/IIDs.=C2=A0 =C2=A0The= purported issue relates to interface ID sizes.=C2=A0 =C2=A0These drafts ap= pear to be confused about that.

=C2=A0 =C2=A0Gyan> Understood that SLAAC in itself= does not create the restriction as the 64 bit boundary restriction is due = to 64 bit IID fixed length when A flag is set.=C2=A0=C2=A0

=C2=A0 =C2=A0The 6man draft below identifies the solution and refe= rences the last time this topic came up about a year or so ago with this dr= aft "https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6= -05"
=C2=A0 =C2=A0This draft submitted on 6man discusses= the history behind the slaac 64 bit fixed iid and refrences the v6ops draf= t problem statement and defines the RA flag solution for slaac to support v= lsm & eliminating the IID fixed 64 bit boundary.=C2=A0

The v6ops draft goes beyond a problem, it it has an IANA section requesting= a new RA flag.=C2=A0 Gyan> This was a typo -wll update when draft submi= ssions opens back up

Bob


> On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti <lorenzo=3D40google.com@dmarc.iet= f.org> wrote:
>
> AFAICS this is a straight violation of the text in RFC 4291 which says= that interface IDs are 64 bits long. As such, I don't see the point in= discussing it unless there is reason to believe that that text will change= .
>
> There was a very long and very heated discussion about that text a few= years ago when the 6man tried to take 4291 to full standard. That consumed= a lot of WG time and ultimately resulted in no changes. I expect there are= still going to be very strong opinions on both sides. If we are to reopen = that discussion now, it should happen in 6man, not v6ops. That way those di= scussions will at least only happen in one place.
>
> On Mon, Nov 2, 2020 at 10:25 PM Fred Baker <fredbaker.ietf@gmail.com> wro= te:
> Let me ask a question of the operators. This draft, as of today, is in= discussion in 6man and will probably be discussed in the 6man meeting. I h= ave not offered the authors a slot in v6ops, as it is not being discussed h= ere. That said, it is presumably a solution to an operational problem, in t= hat the prefix that SLAAC is being used to generate an address in is not ex= actly 64 bits.
>
> Soliciting opinions on the problem: is this something that needs a sol= ution? On the solution: what do you think of it? Does it have holes?
>
> > On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:=
> >
> >=C2=A0 =C2=A0Dear v6OPS,
> >
> > This draft addresses the problem statement to change SLAAC's = historical fixed 64 bit boundary to variable PIO so that VLSM masking is su= pported just as it is today with static & DHCPv6 & DHCPv6 PD.
> >
> > This change to SLAAC to variable, ensures that parity is maintain= ed between the three address deployment mechanisms that exist today with IP= v6.=C2=A0 This draft as well addresses the MAJOR gap that exists today with= lack of parity and the historical framework of the impact of this lack of = partify that has existed since the IPv6 specification was published 20+ yea= rs ago.
> >
> > We have a solutions draft below that is referenced in this draft = that goes over in detail the solution on 6MAN.
> >
> > ! Variable SLAAC
> > https://datatracker.ietf= .org/doc/draft-mishra-6man-variable-slaac/
> >
> > Bob & Ole,
> >
> > Please review.=C2=A0 Based on the feedback received from 6MAN, I = would like to request a time slot on IETF 109.
> >
> > Kind Regards
> >
> > Gyan
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: Mishra, Gyan S <gyan.s.mishra@verizon.com>
> > Date: Fri, Oct 30, 2020 at 6:50 PM
> > Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops= -variable-slaac-problem-stmt-01.txt
> > To: Hayabusanew <hayabusagsm@gmail.com>
> >
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Fri, Oct 30, 2020 at 6:46 PM
> > Subject: [E] New Version Notification for draft-mishra-v6ops-vari= able-slaac-problem-stmt-01.txt
> > To: Naveen Kottapalli <nkottapalli@benu.net>, Alexandre Petrescu <alexandre.petre= scu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petres= cu <Alexa= ndre.Petrescu@cea.fr>, Dusan Mudric <dmudric@ciena.com>, Dmytro Shytyi <dmytro.shytyi@sfr.c= om>
> >
> >
> >
> > A new version of I-D, draft-mishra-v6ops-variable-slaac-problem-s= tmt-01.txt
> > has been successfully submitted by Gyan Mishra and posted to the<= br> > > IETF repository.
> >
> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mishra-v6ops-= variable-slaac-problem-stmt
> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SLAAC with prefixes of a= rbitrary length in PIO (Variable SLAAC) - A Problem Statement
> > Document date:=C2=A0 2020-10-30
> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission > > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
> > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Ds= laac-2Dproblem-2Dstmt-2D01.txt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJl= Pps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&= amp;m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DdtYY-cXn0FCho9Z= ftXjO-TuTH19Nr6MO5spHMPP0xR4&e=3D
> > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= __datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dprob= lem-2Dstmt_&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0Pom= BTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8= oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3Dr_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBf= iR8Q9kHxc&e=3D
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2D= problem-2Dstmt&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0= PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hF= oz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DeKzBB98mFai1psOcqSKEFKAB4ex0TTk= H1qE3KwlktF8&e=3D
> > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tool= s.ietf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-= 2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&= ;r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=3DZpKJS8hFoz8oYRnxB6= 25Sh8r1NsuITN0k-oDx27MAoo&s=3DBWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEd= tI&e=3D
> > Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://urldefense.proofpoint.com/v2/ur= l?u=3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvari= able-2Dslaac-2Dproblem-2Dstmt-2D01&d=3DDwICaQ&c=3DudBTRvFvXC5Dhqg7U= HpJlPps3mZ3LRxpb6__0PomBTQ&r=3DDnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML2= 8ZU&m=3DZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=3DZnQw7BqnqoV= fmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=3D
> >
> > Abstract:
> >=C2=A0 =C2=A0 In the past, various IPv6 addressing models have bee= n proposed based
> >=C2=A0 =C2=A0 on a subnet hierarchy embedding a 64-bit prefix.=C2= =A0 The last remnant of
> >=C2=A0 =C2=A0 IPv6 classful addressing is a inflexible interface i= dentifier
> >=C2=A0 =C2=A0 boundary at /64.=C2=A0 This document details the 64-= bit boundary problem
> >=C2=A0 =C2=A0 statement.
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> > --
> >
> >
> > Gyan Mishra
> > Network Solutions Architect & SME
> > Data Center Planning | Common Core | Development & Engineerin= g Lab Services
> > Global Technology Services | ITNUC
> > O 240 970-6287
> > M 301 502-1347
> > 13101 Columbia Pike Rm 304-D
> > Silver Spring, MD 20904
> >
> > IETF=C2=A0 & ISOC Member since 2015
> > https://www.ietf.org/
> > https://www.internetsociety.org/
> >
> >
> >
> >
> > --
> >
> >
> > Gyan Mishra
> > Network Solutions Architect
> > M 301 502-1347
> > 13101 Columbia Pike
> > Silver Spring, MD
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/v6ops=
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

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


--

Gyan Mishra

Network Solutions A= rchitect=C2= =A0

M 301 502-1347
13101 Columbia= Pike=C2=A0
Silver Spring, MD


<= /div>
--00000000000026393a05b32e0dd7-- From nobody Mon Nov 2 22:47:10 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D053F3A14F0 for ; Mon, 2 Nov 2020 22:47:08 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZdKHdvgv7vV for ; Mon, 2 Nov 2020 22:47:07 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D003A0DE9 for ; Mon, 2 Nov 2020 22:47:07 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id b3so8886747vsc.5 for ; Mon, 02 Nov 2020 22:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kife3FhLEnqc/P6REFB0/PWALzuMuxWGHlNRJK3BiVM=; b=ZPpWZM+7iQXVv//+FMUosbpuG7NEALee2geRbwve1qCzLu//NzU/idhjXolZ61khcB ZcF3Ozo8ZQzibb7Qqz7BUexqeMd5ixHtUlXzPfZB+Xdxf9t8EufEQR8LtwLz6AenE/y8 RChdpq/HXDxPUTN4urjPehb5zh1KVMv5pIPpuwmc1CmNC3uvsIoZAfVYY38cCl2kaZAX wPJPlRf7u2JQKr+sMXd6LdDDprl0FtgRlXHVf/Z+gq/0JjkVFDKDlqIRlLyW0rW9htXm a0Pjkx29aq/E3h+Phs//XAeCbTmjOZyDpr3AQExsDp/AItR7x5UR41H+RgaKGJvX5Jng 3mCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kife3FhLEnqc/P6REFB0/PWALzuMuxWGHlNRJK3BiVM=; b=YZwnjSo89w8vx3ZiGHoEaqmFUJ7QsF/y6LFWHjheHsyYSEFhpnKOzjRJFGt7hEM+Ev 7ESVo+ocs1jykqecWYYwG2OPY3W8Jd4LF5MErDARNVJugQUChXJERlknrwV1oOuQpMI7 Wqjx/QSu+ezBCmOojHtq6lULWIOjKcBWq7zjk5t7v+kYbUuHHXVQykh27+FPP9j0uMq0 bJTrMsci54z/ntEGTpODSso+B0gB7gurxKqhj5Btaj1tPJP9fvVSKW1O0/3W8vRJE5nf LpSMqGDMHtDzcoPFZlwRjnf6tMts4Rtxh9X/YPUVLvIq275vJdf3CDifdqEps0qqbh2E rfJw== X-Gm-Message-State: AOAM530++z7CBlb2MJLIzSmrOwDpp+sXZVD7/b4PES/x3kk+RxFg72bo ykY9YqTfWE0T2Qa78OgEQj/ICVDHYav7RSNgFTY= X-Google-Smtp-Source: ABdhPJze0hRsCBu5Str5cExbVGWN+6UlpfzxvCcyZkYS1Vh6pLSoy9OmWQq7Ob1+cZcycDwPRjl/zvHD+EBD5iKgtwE= X-Received: by 2002:a67:e9c5:: with SMTP id q5mr6514436vso.5.1604386026068; Mon, 02 Nov 2020 22:47:06 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> In-Reply-To: From: Gyan Mishra Date: Tue, 3 Nov 2020 01:41:02 -0500 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Bob Hinden , IPv6 Operations , Lorenzo Colitti , Gyan Mishra Content-Type: multipart/alternative; boundary="0000000000002a9c7c05b32e3bc0" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 06:47:09 -0000 --0000000000002a9c7c05b32e3bc0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jinmei In-line On Mon, Nov 2, 2020 at 6:20 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Mon, 2 Nov 2020 11:09:57 -0800, > Bob Hinden wrote: > > > First off SLACC works just fine with any size prefix/interface ID. > > The protocol supports different sized prefixes/IIDs. The purported > > issue relates to interface ID sizes. These drafts appear to be > > confused about that. > > +1. Even the draft title has the confusion: "SLAAC with prefixes of > arbitrary length in PIO (Variable SLAAC) - A Problem Statement". > The SLAAC protocol itself as defined in RFC4862 already works with an > arbitrary prefix length. > Gyan> I will fix the title to make it clear. > > Today's limitation, i.e., the interface identifier (and therefore the > prefix also) length used in SLAAC is always 64 bits in practice, just > comes from the addressing architecture (RFC4291) and IPv6-over-foo > standards (that are supposed to be consistent with the addressing > architecture). If the "problem(s)" the authors see are this > limitation, the draft should target at the addressing architecture > and/or IPv6-over-foo specs, not SLAAC. So, for example, the title > would have to be: "IPv6 subnet prefixes of arbitrary length - A > Problem Statement" or "Arbitrary Length Interface Identifiers - A > Problem Statement" (both "subnet prefix" and "interface identifier" > are a concept defined in the address architecture). > > Gyan> Many Thanks for your feedback on the title description to make i= t clearer. I agree that RFC 4862 does not state anywhere that SLAAC itself does not support variable prefix length. RFC 4291 IPv6 Addressing architecture states the 64 bit IID requirement. Agreed. I will clarify that in the draft. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. > -- > JINMEI, Tatuya > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002a9c7c05b32e3bc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jinmei

In-line

On Mon, Nov 2, 2020 at 6:20 PM =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89 <jinmei@wide.ad.jp>= ; wrote:
At Mon,= 2 Nov 2020 11:09:57 -0800,
Bob Hinden <bo= b.hinden@gmail.com> wrote:

> First off SLACC works just fine with any size prefix/interface ID.
> The protocol supports different sized prefixes/IIDs.=C2=A0 =C2=A0The p= urported
> issue relates to interface ID sizes.=C2=A0 =C2=A0These drafts appear t= o be
> confused about that.

+1.=C2=A0 Even the draft title has the confusion: "SLAAC with prefixes= of
arbitrary length in PIO (Variable SLAAC) - A Problem Statement".
The SLAAC protocol itself as defined in RFC4862 already works with an
arbitrary prefix length.

=C2=A0 =C2=A0 = Gyan> I will fix the title to make it clear.=C2=A0
=C2=A0 =C2= =A0=C2=A0

Today's limitation, i.e., the interface identifier (and therefore the prefix also) length used in SLAAC is always 64 bits in practice, just
comes from the addressing architecture (RFC4291) and IPv6-over-foo
standards (that are supposed to be consistent with the addressing
architecture).=C2=A0 If the "problem(s)" the authors see are this=
limitation, the draft should target at the addressing architecture
and/or IPv6-over-foo specs, not SLAAC.=C2=A0 So, for example, the title
would have to be: "IPv6 subnet prefixes of arbitrary length - A
Problem Statement" or "Arbitrary Length Interface Identifiers - A=
Problem Statement" (both "subnet prefix" and "interface= identifier"
are a concept defined in the address architecture).

=C2=A0 =C2=A0Gyan> Many Thanks for your feedback o= n the title description to make it clearer.=C2=A0 I agree that RFC 4862 doe= s not state anywhere that SLAAC itself does not support variable prefix len= gth.
=C2=A0 =C2=A0RFC 4291 IPv6 Addressing architecture states th= e 64 bit IID requirement.=C2=A0 Agreed.=C2=A0 =C2=A0I will clarify that in = the draft.

   For all unicast addresses, except those that start with the=
 binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.
=C2=A0 =C2=A0=C2= =A0
--
JINMEI, Tatuya

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


--

Gyan Mishra

Network Solutions A= rchitect=C2= =A0

M 301 502-1347
13101 Columbia= Pike=C2=A0
Silver Spring, MD


<= /div>
--0000000000002a9c7c05b32e3bc0-- From nobody Tue Nov 3 04:02:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB63A08AB for ; Tue, 3 Nov 2020 04:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 P91r_kmNmtKP for ; Tue, 3 Nov 2020 04:02:37 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC693A083F for ; Tue, 3 Nov 2020 04:02:35 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kZv1E-0000HJC; Tue, 3 Nov 2020 13:02:32 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <48D68317-0DB0-4FAA-8CB5-D23F7B9245D1@gmail.com> In-reply-to: Your message of "Mon, 2 Nov 2020 14:49:59 +0100 ." Date: Tue, 03 Nov 2020 13:02:31 +0100 Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 12:02:38 -0000 >While the draft has a particular solution in mind, I wouldn't mind discussing >the problems the draft enumerates. I'm curious why existing mechanisms for distributing prefixes are not enough. On landlines we have a very successful deployment of DHCPv6 IA_PD. We have homenet for distributing prefixes within a site (and for simple cases, nested DHCPv6 IUA_PD works as well). We have RIR policies that allow sites to get a /48, also for individual consumers. So why then have people problems giving each subnet its own /64? - Is this a protocol issue? - Is a technical issue? (equipment that doesn't support prefix delegation) - Is it economical and if so where? RIR fees, cost of equipment, support, etc. For example, if customers of 5G mobile need to have multiple subnets behind the mobile link, why do the mobile telcos only provide a /64? Why does the draft list a home network as a problem (Section 4.4)? Is this for the rare case that the upstream ISP doesn't support DHCPv6 IA_PD? Somehow the draft completely fails to mention DHCP prefix delegation. Which is weird because it is the main mechanism for provides sites with enough space to number the sites' subnets. From nobody Tue Nov 3 11:08:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577DD3A0D3A for ; Tue, 3 Nov 2020 11:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbJfa61qTdTd for ; Tue, 3 Nov 2020 11:08:11 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79403A0DC1 for ; Tue, 3 Nov 2020 11:08:10 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id c17so279498wrc.11 for ; Tue, 03 Nov 2020 11:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tKwfgzB4T1jybJY1jYAHNlds+h/+pCN0wVK8/hVF4ag=; b=gpnCchddQSHZs+PTYa63hQJvvkr3YHiKoO7/0UnwWr7NzuK7xR2tTo+JMTzx40A7Tn yIlWkYi/ztXDEOnpsMepe3yU5P0JTXi0z29frDwhTw/2T2/yuYLONYTng5ZQfM+oD6BI I7yTUiJRbMpsOvmeGY3t8YQ0dMcWwjrMGM2EUeEodGIcfkk8ddSUcr8A5IwiVokDoCI8 4UsOqjqXwF6mpWTpHTVSG5evmuRG2L2WxRn3H7S22WRjlBiPkbU6NAau6AmvStcd0wXE 3J8W2fOWihT+kmw8n+2y49mB/BLB859G++MMqvcXKYWqKu/j7gJkAXvDuJLvGOgBgVzT 9zlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tKwfgzB4T1jybJY1jYAHNlds+h/+pCN0wVK8/hVF4ag=; b=VsRc9xM7AZNqRtzEGzOaYif+bvnM2Z+KIb0U750PMyYJKc+5Ej1FMcfsw7vxCJNV9A rWo5t7L3boJxH1S+rTQ3RWPR0PVMQQ9/uF2nRyt05XJEJtDn19bmxpgiLiV1Zv5IEMkb uC5S2B02Wt5ADJ134o76eCiBd19OuTvyjRES2T4IpRkrmZTOWjEB2yBbmkHbQUr2x9/8 oeGRkCZ+0xQpJdoYoYZYgwIEYAs/8l+70Gq7P2wFzourYJSwpQ8FnTpQJ7LTpabDsF44 OyhptDZaPcdkLVS6yPHp/SAvxzcAj4fnAkYkMoRNEWi8obhOqwoM3FzjV7VEhaFoXX1A gxJA== X-Gm-Message-State: AOAM531gAVzFifB6VLlQ4RcmWxJRCo/jZrCwWYLGj1scLl2qQ7F4uTLO 7Cv+8NB9pR72gltPcxKvWr0= X-Google-Smtp-Source: ABdhPJxQ2zTtjkberESnAhAYO8kywaP5PwIwGYFcN1ox2v8Fax5aM57qv0mCmEzowyy1PoCWPzoRfg== X-Received: by 2002:adf:f104:: with SMTP id r4mr28098170wro.202.1604430489299; Tue, 03 Nov 2020 11:08:09 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:11f0:9fef:263:fc4b? ([2601:647:5a00:ef0b:11f0:9fef:263:fc4b]) by smtp.gmail.com with ESMTPSA id e2sm28478986wrr.85.2020.11.03.11.08.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 11:08:08 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E56DE2F6-ABEC-4750-B707-E7ACC70D9451"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 3 Nov 2020 11:08:03 -0800 In-Reply-To: Cc: Bob Hinden , Brian Carpenter , IPv6 Operations To: Gyan Mishra References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:08:12 -0000 --Apple-Mail=_E56DE2F6-ABEC-4750-B707-E7ACC70D9451 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gyan, > On Nov 2, 2020, at 10:12 PM, Gyan Mishra = wrote: >=20 >=20 > > Soliciting opinions on the problem: is this something that needs = a solution? >=20 > Is there any reason why the mobile devices can't be given a /56 or = /48, which solves the problem immediately? >=20 > 4G & 5G carrier standard is /64 per handset for both IPv6 only and = dual stack deployments. Even though there is a way tremendous amount of = space in IPv6 I believe last count worldwide is 14 billion handsets. > This issue with /64 segmentation does become more pronounced with 5G = as it competes with broadband use case and in many cases SOHO customers = may eliminate their broadband and rely solely on 5G and need the = segmentation. >=20 Like Brian if multiple subnets are needed, it appears to me that this = can be solved by giving the handset or fixed 5G a shorter prefix. Why = is anything else needed? Bob --Apple-Mail=_E56DE2F6-ABEC-4750-B707-E7ACC70D9451 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+hqpMACgkQrut0EXfn u6jvqgf/ZeQZlzpTNf5lzAQBlWdMRfpg6SJunwljCTi3tK4PM4nfwE5ER+tG20Sh e6BJK5Z3u77gN7Gd1wQcB0WnGt9iCLISfUFKPpvOjBsJuffcekM0V4ePHvQzZxF4 +XXbE7F8Dcxhi0Bf5uPnLefbOKdDFxKhTcZHg/yKvKKlYNGPmg3UtSq26G+cFnhe XZYiKdwSvIh9EnRrD6HzbsW/DnrJ+ykSBXBLRaQIoTi4MCXMzerDNyDt9+n4b80P vXALNRPYL2Qg5Mcfx6qGM9nDkdGi3Xoa5tUdiVOj5Mq40LYjCae4cYEfAToN323h tvFCSQnnTxx4xl7CxtTOIzdr7gYVnA== =oFK9 -----END PGP SIGNATURE----- --Apple-Mail=_E56DE2F6-ABEC-4750-B707-E7ACC70D9451-- From nobody Tue Nov 3 11:14:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841243A010A for ; Tue, 3 Nov 2020 11:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmAJJwCTpnMa for ; Tue, 3 Nov 2020 11:14:46 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16F13A0DC1 for ; Tue, 3 Nov 2020 11:14:46 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id c17so295830wrc.11 for ; Tue, 03 Nov 2020 11:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MJgPusHhGPAcc3T0rC3lHmPyc4WQ4LixTrVd/4XpxxA=; b=I/vyqwA0AFvPSoEkyNWgZh7mk6arAVxzOZNerBsJZ5LXI1ABNVHdwHt5PrQ3RPh4eA jokvrl29A8TxbtIa5+/QkggTlNY9FZv0IkYJYocPen9+5RUK+JeYcvCbgMIcGGsYo2Sc 8A14MbQsmfBNvmUcVOT0cpj9rzx2BANBM3t5IIYaGYOXzbWIxlPtUn4ndUrh5nem53JA QF3alt+uSzai5eIaW18K+dqu3lzCPJ/E/WKqMxH/65WNoIuQlrD7cZGu+evcIfqdkM5F KE0tix1lZUeZJwQ5qsG82em9/ZC6BuTK86SPKjCE5468weL3eXpg+72nbZx7+5mb43TP j/gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MJgPusHhGPAcc3T0rC3lHmPyc4WQ4LixTrVd/4XpxxA=; b=J0l91n8B8N8ynmg2/+LWKet4gQvW1+ums0WE/RqfW/uuP8MHdcQTj7IIAAWX1r1n1y pCDNc0pkCrMSIjgw1TXdB/Vz8ltAwfxQR070SK+v0KPNHKVZg7iCDTiNKj+fOi11aCZn +bzZybenpGF9f/F7ROqPbE5+PU57m4jtDDFSMEho8BR42x+H5umafWCAsiXL/h9zWTHp 0JZZ3iEfatCJiTNHqZRHiJAC0D5SB74Xt0q+nC7k6o+jII3e9VczjbqX467aHjjOH3Py rp/4peFOEkKDOSYWpsPBKlszURVdQ8Pi9yIDUgjxNVEMtN09tp8Kz672D3Ye/IXXNjK7 uSfQ== X-Gm-Message-State: AOAM531rqbtIKLvYeh0w4/FvfpHBHzzAU/q8/3Dn/mvQyNDOyQFYEAYM 0kbmf31dSXIMvjiAr1tYUxE= X-Google-Smtp-Source: ABdhPJwrPjs6DQEvv2G4KudotlaFDz/PD9/nd3aDa724tCtvGBsZ0aWOGFI0NizhAicBefsJKJUUaQ== X-Received: by 2002:a5d:6a86:: with SMTP id s6mr28222956wru.344.1604430885105; Tue, 03 Nov 2020 11:14:45 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:11f0:9fef:263:fc4b? ([2601:647:5a00:ef0b:11f0:9fef:263:fc4b]) by smtp.gmail.com with ESMTPSA id e6sm20067758wrs.7.2020.11.03.11.14.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 11:14:44 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DDE07432-D40D-4386-993F-EF79C28054C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 3 Nov 2020 11:14:40 -0800 In-Reply-To: Cc: Bob Hinden , Lorenzo Colitti , IPv6 Operations , Gyan Mishra To: Gyan Mishra References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:14:50 -0000 --Apple-Mail=_DDE07432-D40D-4386-993F-EF79C28054C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Gyan, > On Nov 2, 2020, at 10:28 PM, Gyan Mishra = wrote: >=20 > Hi Bob >=20 > In-line >=20 > On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden = wrote: > Hi, >=20 > What Lorenzo said. >=20 > Further, I did quick read and see some immediate issues. >=20 > First off SLACC works just fine with any size prefix/interface ID. = The protocol supports different sized prefixes/IIDs. The purported = issue relates to interface ID sizes. These drafts appear to be = confused about that. >=20 > Gyan> Understood that SLAAC in itself does not create the = restriction as the 64 bit boundary restriction is due to 64 bit IID = fixed length when A flag is set. Good, then I suggest you stop calling it a SLAAC problem. > The 6man draft below identifies the solution and references the = last time this topic came up about a year or so ago with this draft = "https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05" > This draft submitted on 6man discusses the history behind the slaac = 64 bit fixed iid and refrences the v6ops draft problem statement and = defines the RA flag solution for slaac to support vlsm & eliminating the = IID fixed 64 bit boundary. I, and I suspect most of the working group, are very aware of the = history and background on this topic. Bob --Apple-Mail=_DDE07432-D40D-4386-993F-EF79C28054C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+hrCAACgkQrut0EXfn u6ivEggArGAV5BTIS35rs9nRHw3eWHk/ePuE7W3xKPZHr8GnR9ol/Q4reMb03h92 VT5dprIw/uoPn+9/C6A0jj/mdSTHsBdWQLhLZDBzVuOtIl8N/HuwRY+f/EoziNMJ uZtiMYadIPCi0/sd7cpxr81eGTfFqvAbEY6gEbfxoRrut3PJb+WNWedJo1Yy3v1A 3g//tNq5eO1kOHm6YFiHxvWDK4Rke+0/bxIz8/sxbXv+YvSJqUhIKhodzdpIWt8D P67qnVoUVJ7m+tfhHAX3BCz0/5CXLNAP+VctY1HZWOYmX+YzJGkLxIUSOS4YTYuz NZ3/r4Pe5Jle/SIwj+ikXxg/VjrCTQ== =U7p8 -----END PGP SIGNATURE----- --Apple-Mail=_DDE07432-D40D-4386-993F-EF79C28054C9-- From nobody Tue Nov 3 11:56:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831D13A110E for ; Tue, 3 Nov 2020 11:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 kv1Rx0KRtekJ for ; Tue, 3 Nov 2020 11:56:35 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 D66963A110C for ; Tue, 3 Nov 2020 11:56:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A3JuW8l041172 for ; Tue, 3 Nov 2020 20:56:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82DCB20952D for ; Tue, 3 Nov 2020 20:56:32 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 78FCE20937B for ; Tue, 3 Nov 2020 20:56:32 +0100 (CET) Received: from [10.11.242.16] ([10.11.242.16]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A3JuWrC001927 for ; Tue, 3 Nov 2020 20:56:32 +0100 To: v6ops@ietf.org References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> From: Alexandre Petrescu Message-ID: <089c05d3-bbf7-35ca-6685-bdfb2cb1e079@gmail.com> Date: Tue, 3 Nov 2020 20:56:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 19:56:37 -0000 Le 03/11/2020 ŕ 20:14, Bob Hinden a écrit : > Gyan, > >> On Nov 2, 2020, at 10:28 PM, Gyan Mishra wrote: >> >> Hi Bob >> >> In-line >> >> On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden wrote: >> Hi, >> >> What Lorenzo said. >> >> Further, I did quick read and see some immediate issues. >> >> First off SLACC works just fine with any size prefix/interface ID. The protocol supports different sized prefixes/IIDs. The purported issue relates to interface ID sizes. These drafts appear to be confused about that. >> >> Gyan> Understood that SLAAC in itself does not create the restriction as the 64 bit boundary restriction is due to 64 bit IID fixed length when A flag is set. > > Good, then I suggest you stop calling it a SLAAC problem.* We struggled during internal discussions about what to call it so that it gets better through. Indeed, the SLAAC spec is independent of the prefix length. However, SLAAC spec needs IP-over-foo specs to give an IID. And these latter are all 64bit len. Indirectly, this makes that SLAAC forms GUAs with only a 64bit plen. Maybe one would be ok to call it and _indirect_ SLAAC-GUA problem? (I formulated yesterday a longer email explaining this in more detail but I hold it in my Drafts folder, and I restrain) Alex > >> The 6man draft below identifies the solution and references the last time this topic came up about a year or so ago with this draft "https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05" >> This draft submitted on 6man discusses the history behind the slaac 64 bit fixed iid and refrences the v6ops draft problem statement and defines the RA flag solution for slaac to support vlsm & eliminating the IID fixed 64 bit boundary. > > I, and I suspect most of the working group, are very aware of the history and background on this topic. > > Bob > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 3 17:36:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42B3A12E3 for ; Tue, 3 Nov 2020 17:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W08mC01Aukq for ; Tue, 3 Nov 2020 17:36:13 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E733A1308 for ; Tue, 3 Nov 2020 17:36:13 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id v5so973162wmh.1 for ; Tue, 03 Nov 2020 17:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QpMFZOL88phdkX1iGrie0lYLmBi18DdMzfbAUFi3Reo=; b=PK3EpJgm+6YskTHcJyGj5pLihNWMpHjOmfrZBRXmxl8qTP/B75o1V4Ccux/znNVKFn ZPW0a92OoiStGNLM7hDv5+wnEM895DmQjhvY97+fWNTWooHT8r58hFIZhGSoBI3ZggGt 3Y4q2bQ5AYsRD63POWOkxXLHb2RC/PIEHMvugAm9+UM6JovaDzxtimc1HdTS3+4n+68v 14zhNROPhp8Tf2qFqxHNMfpzQNYhJInDjs2MwswoMlg7FchnjvQjR3OWfP21r0QWOLgO EsCX0bU82WcGmQuRpZWGo2LpEJY2etc8hZgMO6Pxi/ppDR8902QkYi6kmr7wKjAgYAc6 WjsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QpMFZOL88phdkX1iGrie0lYLmBi18DdMzfbAUFi3Reo=; b=h79cgcYkyjE5CdgLWTz5ZWWW4tbLxBtx8SW4rtY2/9jujBgVsTdWlwIVQ6ldX8skIg nr6aNu/0ztr8aqOYvfTiOfT+yF+DC63X/x+H73jjJ96lp8pN0OiG2SWcp7wrfgI5NAMN iJFnieGpkvHJHf/3Wiue5b9lyQK5Nvy1DgtpM6rMIMgO1uDRf837FALqj/juHklr59FM dq/mOoY7Gjks5J3pnRw7KK1QYug4z6Q2qt15rZJt32KLOkPDzj3rt10WIl5RSTag3Gju k9LQEDbSr07vOeZ7BvvK6NyNYGsFb17wMD1Razwo+ecXEq7IBwT3OXxVjFkKCnnzgFRK 7C5A== X-Gm-Message-State: AOAM531j8BR4u0UigYRxBJkvH339RY5kUDaWXBfW21Yeq8Hkr7C/DeOQ yAnuKbqEwSJuhughHUb0fJY= X-Google-Smtp-Source: ABdhPJz+lM/fdqiYkjL75AejHyXtJ1qXbnZ4vj0Xl8wpKH+/qEmvmvMDEje2SLQjmqi0jbxiFkuFeA== X-Received: by 2002:a7b:c8d3:: with SMTP id f19mr1851369wml.17.1604453771943; Tue, 03 Nov 2020 17:36:11 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:11f0:9fef:263:fc4b? ([2601:647:5a00:ef0b:11f0:9fef:263:fc4b]) by smtp.gmail.com with ESMTPSA id a15sm437023wrn.75.2020.11.03.17.36.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 17:36:11 -0800 (PST) From: Bob Hinden Message-Id: <593D6229-7A73-4DFC-AE87-8F1765093EC9@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CCB130E0-D023-4DFE-9046-13569C483F7F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 3 Nov 2020 17:36:05 -0800 In-Reply-To: <089c05d3-bbf7-35ca-6685-bdfb2cb1e079@gmail.com> Cc: Bob Hinden , v6ops@ietf.org To: Alexandre Petrescu References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <089c05d3-bbf7-35ca-6685-bdfb2cb1e079@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 01:36:16 -0000 --Apple-Mail=_CCB130E0-D023-4DFE-9046-13569C483F7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alexandre, > On Nov 3, 2020, at 11:56 AM, Alexandre Petrescu = wrote: >>>=20 >>> What Lorenzo said. >>>=20 >>> Further, I did quick read and see some immediate issues. >>>=20 >>> First off SLACC works just fine with any size prefix/interface ID. = The protocol supports different sized prefixes/IIDs. The purported = issue relates to interface ID sizes. These drafts appear to be = confused about that. >>>=20 >>> Gyan> Understood that SLAAC in itself does not create the = restriction as the 64 bit boundary restriction is due to 64 bit IID = fixed length when A flag is set. >> Good, then I suggest you stop calling it a SLAAC problem.* >=20 > We struggled during internal discussions about what to call it so that = it gets better through. >=20 > Indeed, the SLAAC spec is independent of the prefix length. Correct. >=20 > However, SLAAC spec needs IP-over-foo specs to give an IID. And these = latter are all 64bit len. Indirectly, this makes that SLAAC forms GUAs = with only a 64bit plen. >=20 > Maybe one would be ok to call it and _indirect_ SLAAC-GUA problem? Again, ND and SLAAC works fine with any combination of prefix and IID = length (as long as they add up to 128 bits, and the IID isn=E2=80=99t = too small to avoid collisions on the link). It=E2=80=99s not a SLAAC-GUA problem. RFC4291 defines how long IIDs = are: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long... Bob >=20 > (I formulated yesterday a longer email explaining this in more detail = butd I hold it in my Drafts folder, and I restrain) >=20 > Alex >=20 >>> The 6man draft below identifies the solution and references the = last time this topic came up about a year or so ago with this draft = "https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05" >>> This draft submitted on 6man discusses the history behind the = slaac 64 bit fixed iid and refrences the v6ops draft problem statement = and defines the RA flag solution for slaac to support vlsm & eliminating = the IID fixed 64 bit boundary. >> I, and I suspect most of the working group, are very aware of the = history and background on this topic. >> Bob >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_CCB130E0-D023-4DFE-9046-13569C483F7F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+iBYUACgkQrut0EXfn u6i3Cgf/TI9iTJN7RECCAvnmHzUn8NGDrmM+mo3sDL9CIqaNkTXw8DUste7MBQeZ kyFCQNFDGdmVprW+ma1qe2tSa/JPHSWFUsOzQ3bBo5/8cnFGZYcxmXbAl0+L7nfX CnGvYPbwaLff8VM4vMbSWL+xwhcQh3q7QRgXdi3WDLsDyjtBLE/unh3rhPU8CE+X ZsxF7HR4kDH3ioZ34MxDJykizE9LO9QbrgesufFmegNra2ghCTRaG7CYJUWRVc/Y HTZIMxQf35MzK5Xio0MlbnxdFO8oZq+YyMM6v+q+ruB/RoKzlFJzcCw+jUboUfbF RwCz8kr8B8zPgU3+/3gq3GcO5uADWQ== =EGMB -----END PGP SIGNATURE----- --Apple-Mail=_CCB130E0-D023-4DFE-9046-13569C483F7F-- From nobody Tue Nov 3 23:28:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC23A0C92; Tue, 3 Nov 2020 23:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjtuFLi6yco8; Tue, 3 Nov 2020 23:28:03 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104413A0C8B; Tue, 3 Nov 2020 23:28:03 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id o205so11428818qke.10; Tue, 03 Nov 2020 23:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hHsblAHg7qt0rr0YgX7HY5VhRGwY1KDDcnRNE927q2c=; b=nDzdcG78Pwd+7H8rF0rjKMjGvE9VvcepwmE/2b9DYtumeou1g+JHYdPGpi9jmx+nv3 1Lx+egc3iw73F9uhY9hKj2Rgi6AYHgcU3wMLsvPlEipY76kAGTA2M5AZNeyzUpH1F7RW iebJb9cBbWXdY7byVV9FyfNb6/q3oJ3MwPaemNx8jCUOeHTldXeN8qmq9VRRmdN0bUWp Wrrz7IBQjqixuH/tmLZDNruPKLAkdp1EQfXeD+r0m0/t1K8AwMinALtm1iW7eF5KLw1x r8PJVMIHgP+a14B/hZgI/zS+S0H1Ke2LJknOWwLs6QlvK3tWBYoVDmKU3B/Q2Vbr1XLk O2NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hHsblAHg7qt0rr0YgX7HY5VhRGwY1KDDcnRNE927q2c=; b=l9vSn2Q0THbBnHqIf56mt6hBzfaY+C8v436oldAtFbVjCCX8y2FgUm23W0VEP5sXPL /He12D1VwtlpRloeYfsW/ge7onmybbGsVp4zarN/a2WtPBGZAAEJloaAE6ta/uw/0swi teP4ViguKSVmA946dqP9RLh8ubNJCBmij9KURIPxURBhFl4QGUJAxu8HoP8F5/iRYfl1 yGEvetkzNTLqC9xWydviAC33y+7lTJeqoyLHQV48MeEwn+RH/D6PZ7+DRybQ0bZwg7DT 1GjkyLS0JW4NDcTXe31694mEj/le8IUlp4HZcvjLteRf3C9WBECYhrI7QHjSxCKCZKqe QmWQ== X-Gm-Message-State: AOAM531ZVYzUHmNLpR/mSEDyue2IUhwQobj6H1iSCEcvKaiZ+4w1/A2M qbRAXN2l0wqnkNRW3K0I8WzLG6je+QIG8iNfTyE= X-Google-Smtp-Source: ABdhPJzVaxYvVyH9/ngpDhr8qUM8oM3krqS+wDzUxUT32soatjeEHRDaxLVtLOIZyXfRk3lghmi430ckeWIdsoXuUAk= X-Received: by 2002:a37:e43:: with SMTP id 64mr24041463qko.466.1604474882135; Tue, 03 Nov 2020 23:28:02 -0800 (PST) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> In-Reply-To: From: Jen Linkova Date: Wed, 4 Nov 2020 18:27:50 +1100 Message-ID: To: ianfarrer@gmx.com Cc: "Bernie Volz (volz)" , Michael Richardson , dhcwg , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 07:28:06 -0000 On Fri, Oct 30, 2020 at 3:24 AM wrote: > Sorry for the delay in reply, I=E2=80=99ve been out of the office for the= last few weeks for various reasons. > > Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2=80=99= s suggestions: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y to drop packets > received on a DHCP-PD client facing interface with a destination address = in a prefix delegated > to a client connected to that interface, as follows: For point-to-point = links, when the packet=E2=80=99s > ingress and egress interfaces match. For multi-access links, when the pac= ket=E2=80=99s ingress and > egress interface match, and the source MAC and next-hop MAC addresses mat= ch. An > ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destinati= on) error message MAY > be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be configu= rable. That looks good, thanks for updating the text! > On 15. Oct 2020, at 03:51, Jen Linkova wrote: > > On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) wrot= e: > > If not, perhaps we just say: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y to drop traffic received from an uplink interface as follows: > > > I'm not sure 'from an uplink interface' makes sense. In the case of a > routing loop caused by an amnesiac DHCP-PD client it would be a > downstream interface. > The scenario when such traffic arrives from an uplink interface is > 'the uplink router believes the prefix is delegated to the client but > the relay does not have a route pointing to the client so it sends > traffic back' - so more likely 'an amnesiac relay' case. > > For point-to-point links, when the packet's ingress and egress interfaces= match. For multi-access links, when the packet's ingress and egress interf= ace match, and the source MAC and next-hop MAC addresses match. An ICMPv6 T= ype 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent as per [RFC4443], section 3.1. Th= e ICMP policy SHOULD be configurable. > > - Bernie > > -----Original Message----- > From: ianfarrer@gmx.com > Sent: Tuesday, October 13, 2020 9:16 AM > To: Michael Richardson ; Jen Linkova > Cc: Bernie Volz (volz) ; dhcwg ; 6man ; v6ops list > Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Impl= ementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > > Hi, > > Thanks for all of the discussion on this. We=E2=80=99ve reworked the requ= irement as follows: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y to drop client traffic as follows: For point-to-point links, when the pa= cket's ingress and egress interfaces match. For multi-access links, when th= e packet's ingress and egress interface match, and the source MAC and next-= hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable,= reject route to > destination) error message MAY be sent back to the client. The ICMP poli= cy SHOULD be configurable. > > Thanks, > Ian > > On 9. Oct 2020, at 17:41, Michael Richardson wrot= e: > > > Jen Linkova wrote: > > I think there is confusion re: the scenario we are talking about. > I've attached the diagram for the case which concerns me. > So: > - The Relay R has an interface eth0 connected to a switch S. > - Devices A and B are connected to the same switch and using R as a > default gateway. > - The prefix 2001:db8::/56 was delegated to a client A via the relay R. > > > a friendly amendment to your example to aid in human comprehension: > } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via = the relay R. > } - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0. > > - The device B (which has an address NOT from the delegated prefix, > but from another /64 assigned to that common link, let's sat > 2001:db8:cafe::/64) sends a packet to an address from the delegated > > > now, my brain can more clearly see that 2001:db8:cafe::/64 is not > within 2001:db8:0000:0123:/64, while I had to use a few extra brain > cells to see that it wasn't in that ::/56 :-) > > What I'd expect to happen (with DHCP-PD or without - e.g. if R has a > static route towards A, not a dynamic route produced by PD): > - the packet is sent to A. Well, if A does not have a route to > 2001:db8::42 then indeed a routing loop might happen. But if A does > have a route, the packet will be delivered. > > > What seems to be required by R4: > - R detects that the packet is received via eth0 and needs to be sent > back to eth0. R4 seems to require such packets to be dropped. > So if B would never be able to communicate to any address in the > delegated prefix, right? > > > Am I missing anything? > > > I think that you got it right. > > Perhaps the missing piece of the rule is don=E2=80=99t send it back to wh= ere it came from, based on link layer addresses (or link if point-to-point)= . > > > Yes. If R4 was saying 'drop the packet if it comes from the same > link-layer address you are going to send it back' - it would make > total sense. But I don't think routers do *that*. > > > Yes, if we made the check on L2 address, then it would work. > And I agree that routers are exactly doing that. > > I think that it also works if B is a router with additional interfaces > downstream, unless there are multiple paths. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -- > SY, Jen Linkova aka Furry > > --=20 SY, Jen Linkova aka Furry From nobody Wed Nov 4 01:20:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921503A0DFF for ; Wed, 4 Nov 2020 01:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urt3TbCoFMcV for ; Wed, 4 Nov 2020 01:20:32 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727273A0DFE for ; Wed, 4 Nov 2020 01:20:32 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id t13so10793942ilp.2 for ; Wed, 04 Nov 2020 01:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3f60cSin3NXwzWwARSkBoXPtpTGoxJkzKCjqc3ytbbk=; b=aYS3HurnEF/Yk8dtNYDX0Rc74EG1LUGhfrenRulqKlApMD+5qWiED1Phy2JXbqI+1B EbFfKaN7Zq859kHbdKClC9hPL0liqVi+3212JN6Vr77UHWZFKhyYkV/th9aC5lSWMriC gkK9iqXa+XjW4jlAsUwBBziTa4DJpB3nl2UiefpXaTV7kSc/eW4FGEmF0RzrOONNXnmY Pbr/RrKamqGbRyEt3WFfi5M0fKsR2Y7xDCWuKliqJ4epEwdi2vzgLSVXErk2/eHPBkUP oP6NaS8+hbFjYukd8gHf+eBcyAqPSh+gCm13OufBNLSrLZaBlrbuTQzz1kp4LN3K0xC1 Emhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3f60cSin3NXwzWwARSkBoXPtpTGoxJkzKCjqc3ytbbk=; b=ibkdiHqj5/w95xxXLI5h1wMGaHsGEO4mCTxdQFIaml5LYTUBrddeQrFQTOCfY8IE8D eQSdL8UFjllDt4xmT+DM+8mJfy1JmeoW3dYLwu7BKHtRQv89mQ71YRv0KUsPH7yT65SO fzuoh9zoy6iwTQcSrY80kr9jCtg1cESuTrA97V9CH/pdZP16TdnDyoZLubaT+/kkE2Nz tbtzl/uYZGuI7eXT/A7zr6mzzSKJ4cTs2yT8iBHYGmw9bjQNc/kxVYhy1lsKeLi5P9Ih od80gZpdursEYFwzVJVvXIIesVoLA0PluITuK7+AH1SdSMgPAgnK13v+Pe/+IKsf6fiU mH8w== X-Gm-Message-State: AOAM533RjVNKYNJ+ejjlhTshWS4TWwJJY3i1Ady86ETidXViWP7LAxBr pG4Hxn+d0Fy5YyeGOfVhqzCkOhjgHZig/Zoumc6PhA== X-Google-Smtp-Source: ABdhPJyyMALlGUaxzuBhx12N7AyOEFwU/lfSLyJRx7ctLpmt+HQFPpz4d7yHHy6vLJjaA08Yvg0u3A5pl1J6KzoRS/E= X-Received: by 2002:a92:690f:: with SMTP id e15mr13608389ilc.269.1604481631562; Wed, 04 Nov 2020 01:20:31 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> In-Reply-To: From: Lorenzo Colitti Date: Wed, 4 Nov 2020 18:20:19 +0900 Message-ID: To: Brian E Carpenter Cc: Gyan Mishra , Fred Baker , Dmytro Shytyi , Naveen Kottapalli , IPv6 Operations , Alexandre Petrescu , Gyan Mishra Content-Type: multipart/alternative; boundary="000000000000b32ea305b3447d91" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 09:20:34 -0000 --000000000000b32ea305b3447d91 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 3, 2020 at 5:09 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > So let's have a discussion whether there is a new operational problem here > first: > > "The main problem is that SLAAC RA or PD allocates a /64 by the > wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however > segmentation of the /64 via SLAAC is required so that downstream > interfaces can be further sub-netted." > > Why isn't that in v6ops scope? I'd say that is not in scope anywhere because there already exists a protocol that solves this problem. It's called DHCPv6 PD. If there is an operational problem with DHCPv6 PD, then that might indeed be in scope for v6ops. That's not what the draft is about though. As far as I can see it doesn't mention DHCPv6 PD at all. The draft is about proposing a change to SLAAC, and as such is a protocol change that is not in scope for v6ops. --000000000000b32ea305b3447d91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 3, 2020 at 5:09 AM Brian E Ca= rpenter <brian.e.carpente= r@gmail.com> wrote:
So let's have a discussion whethe= r there is a new operational problem here first:

=C2=A0 "The main problem is that SLAAC RA or PD allocates a /64 by the=
=C2=A0 =C2=A0wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, ho= wever
=C2=A0 =C2=A0segmentation of the /64 via SLAAC is required so that downstre= am
=C2=A0 =C2=A0interfaces can be further sub-netted."

Why isn't that in v6ops scope?

I'd = say that is not in scope anywhere because there already exists a protocol t= hat solves this problem. It's called DHCPv6 PD.

If there is an operational problem with DHCPv6 PD, then that might indeed= be in scope for v6ops. That's not what the draft is about though. As f= ar as I can see it doesn't mention DHCPv6 PD at all. The draft is about= proposing a change to SLAAC, and as such is a protocol change that is not = in scope for v6ops.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

On Mon, Nov 2, 2020 at 1:35 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
<= /div>


> On Oct 29, 2020, at 1:42 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
>
> I've thought that the use of Anycast would increase, and have thou= ght that it would be useful to have a specially designated anycast prefix. = It has also occurred to me that anycast has some of the properties of unica= st as well as some of the properties of multicast, so could be seen to fit = in between unicast and multicast (1:1 -> 1:Any -> 1:Many)

That's a reasonable description of anycast as deployed.

=C2=A0 =C2=A0Gyan> Agreed


My question in that would be exactly what you might want to change. We have= some pretty widespread use of anycast today (https://www.i= ana.org/domains/root/servers https://root-servers.org), and to my = knowledge it seems to work just fine. If we're going to replace existin= g anycast with some sort of anycast prefix, the first big change we have to= make is in BGP; it can advertise a unicast prefix or address, but can'= t, today at least, advertise an anycast prefix.Then we have to tell hosts t= hat they can send traffic to such addresses and should. I think we should h= ave a good reason if we're going to boil the ocean.

=C2=A0 =C2=A0Gyan> Good point and= as you mention services such as DNS, NTP predominantly but even Syslog, sn= mp, netflow have gone the way of Anycast VIP advertisement via a lb for pro= ximity routing to unicast address for a just about any service can be done = the ASM way and works very well. =C2=A0

I think with IPv6 a lot of thought was put into the address= ing schema I am guessing like the built in Anycast range out of the GUI ran= ge without a use case but hopes for if you build they will come which I gue= ss never happened.=C2=A0 So then I guess it never took of as it would requi= re some changes to BGP.=C2=A0 Working with BGP on parameters and codepoint = development in some of the other WGs, if there is a real gain or use case f= or an Anycast BGP SAFI =C2=A0I could author a draft to make it happen but I= would need to figure out the why and what gap is not being filled by the e= xisting Anycast capability via unicast today which has been widely =C2=A0pr= oliferated.
<= /div>
--


Gyan Mishra

Network Solutions Architect=C2=A0

<= i>M 301 502-1347
13101 Columbia Pike=C2=A0=
Silver Spring, MD


=

= --Apple-Mail=_674673F2-67E3-4E5A-AA6B-FEBA04556372-- From nobody Thu Nov 5 10:15:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A0D3A1944 for ; Thu, 5 Nov 2020 10:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 kn1MP_AO0c2r for ; Thu, 5 Nov 2020 10:15:56 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 8C7363A1947 for ; Thu, 5 Nov 2020 10:15:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A5IFtCC030265 for ; Thu, 5 Nov 2020 19:15:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 055A620992A for ; Thu, 5 Nov 2020 19:15:55 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EF8892098DE for ; Thu, 5 Nov 2020 19:15:54 +0100 (CET) Received: from [10.11.242.214] ([10.11.242.214]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A5IFsvT015806 for ; Thu, 5 Nov 2020 19:15:54 +0100 To: v6ops@ietf.org References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> From: Alexandre Petrescu Message-ID: <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> Date: Thu, 5 Nov 2020 19:15:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 18:15:58 -0000 Tatuya, Le 03/11/2020 Ă  00:19, 神ćŽé”哉 a Ă©crit : > At Mon, 2 Nov 2020 11:09:57 -0800, Bob Hinden > wrote: > >> First off SLACC works just fine with any size prefix/interface ID. >> The protocol supports different sized prefixes/IIDs. The >> purported issue relates to interface ID sizes. These drafts >> appear to be confused about that. > > +1. Even the draft title has the confusion: "SLAAC with prefixes of > arbitrary length in PIO (Variable SLAAC) - A Problem Statement". The > SLAAC protocol itself as defined in RFC4862 already works with an > arbitrary prefix length. I think it is an indirect SLAAC-GUA problem. The IID len problem taints SLAAC. Yes, SLAAC spec works with 65bit plens. No, IIDs defined in IPv6-over-foo are not used anywhere else than in SLAAC. SLAAC is the only protocol that uses the IIDs defined in IPv6-over-foo. Because of that, if we formulate a problem that is only about IID, then nobody will want to solve that problem, because nobody uses the IIDs defined by IPv6-over-foo. > Today's limitation, i.e., the interface identifier (and therefore > the prefix also) length used in SLAAC is always 64 bits in practice, > just comes from the addressing architecture (RFC4291) and > IPv6-over-foo standards (that are supposed to be consistent with the > addressing architecture). If the "problem(s)" the authors see are > this limitation, the draft should target at the addressing > architecture and/or IPv6-over-foo specs, not SLAAC. If we target the problem at the IPv6 Addr Archi, then that RFC might (lets say) get improved and define IIDs that could be of different length than 64. But, at that point, shall we also update _all_ IPv6-over-foo documents to refer to the new IPv6 Address Archi document? Or maybe should we just write an implementation of variable len SLAAC-GUA? > So, for example, the title would have to be: "IPv6 subnet prefixes of > arbitrary length - A Problem Statement" But subnet prefixes like 65bit length do work ok with ND nowadays. > or "Arbitrary Length > Interface Identifiers - A Problem Statement" (both "subnet prefix" > and "interface identifier" are a concept defined in the address > architecture). But who uses Interface Identifiers? Only SLAAC, I think. Alex > > -- JINMEI, Tatuya > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 5 11:54:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248343A19F7 for ; Thu, 5 Nov 2020 11:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z5wBO7HYtFo for ; Thu, 5 Nov 2020 11:54:44 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 B5ABF3A19F5 for ; Thu, 5 Nov 2020 11:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1604606083; x=1636142083; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IjnjBIz2BoCNuiaR4fBfE4dX8pQ7ArB4o7gXgfQZuwk=; b=RUWvInrjlu9W6VY1GvEiU0dAvk/yLyLBbAsJgjOwi1Y3Lf65GiUCO1Es RPM0P+woSDyYvvV5Ywca12TS9T+T/aYASZrd0MzKxWmOuiKy9DGKzgE07 TU3XYKYlIq3k/1A15r9UGwUR2DZbCgIDRcqRi3PJYVsoHXME+Gvbqe9n7 ozM0f196QOLW2qvQpzCDtRhT4fnRw/tGiPrQFnSXDNhalAXvHn7M7mLGa I8p7sN3D5yjFcUUXBgfBIcKxelm2FxUXd4nhQZb97YzchO6HvLyNlbnn0 8bMJRDBqRZxTvmwc4yVDTp5sYC624qPa5LXtBmB194iGoMi0YQrAR+EuG A==; IronPort-SDR: a8eAd39UNvz4gsX5iRrkTQG9iIFmj5L/f0IDWDx/bSaBBVLHAOdAa+tcVfu7Lm5UJzOiYR/373 j6avMreLhjeQyDzrvkX27eTO3QJrGbv0We1AbBhRtdaiskwMwnDjmpC2ltQV57sDg5V0sZYVoR TZXD4dPKFhBtPLy6J+YX6e6S6ki4K+q5FHQRRMTIrBotIWJWYVi7q+cfOOGA27gEyHMVB5FXYq 7kljNgtz0VEmwHYaCKHKWy38t5NfSdzwmuV6pATtDaYUGutGpAQ7mNu8K6x5V3Q2EDxEu6uuL9 /FM= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2020 20:54:40 +0100 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9E44941041 for ; Thu, 5 Nov 2020 20:54:40 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 5BE5D40EC5; Thu, 5 Nov 2020 20:54:40 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 54F72AB645; Thu, 5 Nov 2020 20:54:40 +0100 (CET) Date: Thu, 5 Nov 2020 20:54:40 +0100 From: Gert Doering To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20201105195440.GL14279@Space.Net> References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 19:54:46 -0000 Hi, On Thu, Nov 05, 2020 at 07:15:54PM +0100, Alexandre Petrescu wrote: > But subnet prefixes like 65bit length do work ok with ND nowadays. Subnet prefixes of any length work perfectly fine with ND nowadays. Just "SLAAC" doesn't, on most platforms. I've heard that OpenBSD can do SLAAC with non-/64 prefix lengths just fine these days, though I have not tried it. > But who uses Interface Identifiers? Only SLAAC, I think. Using MAC-based EUI-64 for IIDs seems to be a relic from the past anyway. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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 Nov 5 12:43:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9203A1A41 for ; Thu, 5 Nov 2020 12:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGKEQ8qH_zyB for ; Thu, 5 Nov 2020 12:43:26 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5713A1A3F for ; Thu, 5 Nov 2020 12:43:25 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id i7so2164589pgh.6 for ; Thu, 05 Nov 2020 12:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=peWzleWxJiuYzKz62EiY2SLeq8YluNla/6M04CCSzsA=; b=e7NLuNz5YN2xZ+V1EPU/XbQYiz8r0upDW9GRvzKnhjYqxHu6mPgvge2SeUKT9Z4wOD XNWsjva3wjlEX6c1UN8f/rIpSM3RrZ38/ogRzWMIm2jHI/Wo78Gcicdo1r89q8DXJv1I aTAhtFUKrCGWdKB5OWu4MiCTbsfNFYmG1wXzZ7eu1TtbBXkWQxtakm8iVzo3H4LI7/F3 TGExKl2GxoDjLNIVw1XYRv0MtmMbZsa94j7P4xgtzD5/ElDYRhUsmFGrIfEJM3TFiu75 sRm+P1vdg945uJkzzctzEIlBLd6kPMCW4jrF2UViZJ6TuGTV1kdKNEGp1CiKyXlb1rqU vW2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=peWzleWxJiuYzKz62EiY2SLeq8YluNla/6M04CCSzsA=; b=O9qgL8RLwzCKD9YBOvfcC5/P5YX0DfwbdQ1FUTCXWxciynwYj1UdUkkBxUjrADepzm 69aR26LV+7fbbOq3O4Qf5wEv2q4hT6gcvm6tvsmabrBod5R4QOPr1Brnecfv4K4dFaZV Te+3M5PimLfHVXSRQfTYS7KpJM/2vjkmbk5W4iIDj36H9Gru2K/w2Ka7QC/AukWR/EHz FIAPkiynYFWmgIB+4tOO3YPm5T/xFjwP4Si31FjYi8eR5dDZJ5TDaHk/5xWkGyc0FjEZ HnammBeSpuQsDftB3jdVou8xwQrkj3uhrqTdDvo/ziYkoYT0w+FplqMDOrHUIOx64iIB z5IA== X-Gm-Message-State: AOAM533BhnSbXoq9DvIHyvGpn+JLjOcZIaCcRpCUQbt01XmdFQ8KAxHv YRhDJQPQh+ySiokJBNHQbabIq2nyWmVGfw== X-Google-Smtp-Source: ABdhPJw26YZi67XLgn4rFfEFJ6E1WWlsgYfvwX3Qfkh4HG9oKd54pu2quYSeZXjvOC+xOxo2Qpfa1w== X-Received: by 2002:a17:90a:f195:: with SMTP id bv21mr4264456pjb.8.1604609004327; Thu, 05 Nov 2020 12:43:24 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id b13sm3156056pfi.185.2020.11.05.12.43.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 12:43:23 -0800 (PST) To: Gert Doering , Alexandre Petrescu Cc: v6ops@ietf.org References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> <20201105195440.GL14279@Space.Net> From: Brian E Carpenter Message-ID: Date: Fri, 6 Nov 2020 09:43:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20201105195440.GL14279@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 20:43:33 -0000 On 06-Nov-20 08:54, Gert Doering wrote: > Hi, > > On Thu, Nov 05, 2020 at 07:15:54PM +0100, Alexandre Petrescu wrote: >> But subnet prefixes like 65bit length do work ok with ND nowadays. > > Subnet prefixes of any length work perfectly fine with ND nowadays. > > Just "SLAAC" doesn't, on most platforms. > > I've heard that OpenBSD can do SLAAC with non-/64 prefix lengths > just fine these days, though I have not tried it. > >> But who uses Interface Identifiers? Only SLAAC, I think. Since SLAAC is mandatory to implement on IPv6 nodes [BCP220, RFC8504], that means that all IPv6 nodes use IIDs (and most of them have /64 baked in [RFC4291]). > Using MAC-based EUI-64 for IIDs seems to be a relic from the past anyway. True; that aspect is a complete distraction. Brian From nobody Thu Nov 5 13:06:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472C83A1A50 for ; Thu, 5 Nov 2020 13:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 qFg38MEsXkIb for ; Thu, 5 Nov 2020 13:06:16 -0800 (PST) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86A23A1A4E for ; Thu, 5 Nov 2020 13:06:16 -0800 (PST) Received: by mail-vs1-f51.google.com with SMTP id u7so1567953vsq.11 for ; Thu, 05 Nov 2020 13:06:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=24voRGn9nVUW07DGtXc6eyKDsmv6WTIiDQhWGK/yYvE=; b=GToVTawydYWGI5n/LjY21qej3RH3CBNVvMaryQPVPZQcVrwSfsnJFC9VeBjOVlUZRE 9LAplgazfXOgHvcqeV0YW/mDzsjqnG0NwLOQl9qhD2jqyJoPxUCTzd5J5rrHRTe2fjT1 tf01VDrDCndEL7HoId3ODlLFOSVt//cg+g7lofN65c0DOV/vV9CJL++aV650+Mk+lBKO z+Co371lMC4nnGTsuyCXirAc0P0YHvxM1N5VDoFwVSa6vuayXczQaucYRZ3pEUjP5afW k8YZunR+Is943O7571Jun7/XpuODoCmP9IIaVO8olEds3g9qyH4nb3gdaeCIqMk+hOe9 Ykjg== X-Gm-Message-State: AOAM533KqKgZUB4B/OIICP6ZAXvAUXOZNffQu+XuoxmTvQzS+7QoW8ZC jJ2A1Sr4vFpBH46927OHzBomtiWYfYOrO7va9O0= X-Google-Smtp-Source: ABdhPJwmEJWs0eLL7RxqS1Ni79yb1IUS+ydQNmpto2XM8Y6RAjqPcCslCa7EvFIXoeyxnZ5bvNNrlILNVicE4uIoMio= X-Received: by 2002:a67:f453:: with SMTP id r19mr3002030vsn.43.1604610375605; Thu, 05 Nov 2020 13:06:15 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> In-Reply-To: <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 5 Nov 2020 13:06:04 -0800 Message-ID: To: Alexandre Petrescu Cc: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 21:06:18 -0000 At Thu, 5 Nov 2020 19:15:54 +0100, Alexandre Petrescu wrote: > >> First off SLACC works just fine with any size prefix/interface ID. > >> The protocol supports different sized prefixes/IIDs. The > >> purported issue relates to interface ID sizes. These drafts > >> appear to be confused about that. > > > > +1. Even the draft title has the confusion: "SLAAC with prefixes of > > arbitrary length in PIO (Variable SLAAC) - A Problem Statement". The > > SLAAC protocol itself as defined in RFC4862 already works with an > > arbitrary prefix length. > > I think it is an indirect SLAAC-GUA problem. The IID len problem taints > SLAAC. > > Yes, SLAAC spec works with 65bit plens. > > No, IIDs defined in IPv6-over-foo are not used anywhere else than in > SLAAC. SLAAC is the only protocol that uses the IIDs defined in > IPv6-over-foo. For IPv6-over-foo, that's correct. For example, RFC2464 Section 4 specifically states it's for SLAAC. But that's only a part of the whole picture; IPv6-over-foo and addr arch (RFC4291) must be consistent, and the latter is not specific to SLAAC. In fact, if the spec for IID length in the addr arch were also only about SLAAC, I suspect the Bourbaki author(s) wouldn't care too much about it. The authors of draft-mishra-v6ops-variable-slaac-problem-stmt might only be interested in SLAAC related use cases, but we can't pretend it's an SLAAC specific problem (and provide a tweak to SLAAC as a "solution") without resolving the implication on the addr arch (and on manually configured addresses, etc). That's what I tried to point out. -- JINMEI, Tatuya From nobody Thu Nov 5 13:49:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039423A1A72 for ; Thu, 5 Nov 2020 13:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61YHydEWn2Sz for ; Thu, 5 Nov 2020 13:49:16 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E273A1A70 for ; Thu, 5 Nov 2020 13:49:15 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id 79so2862358otc.7 for ; Thu, 05 Nov 2020 13:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vr5oFFbG5wuVxPhlrLiEoOGIaSbJGBvBU1IMEqQ1IGs=; b=HgjPZEUkDvfLml0ka1DGJV5t6prjMjhtPF6Bu/mkdq0wIu0MFAFTXSlrBJORmgXUP+ gSDZj7KH3jo9KtFV9BLXNnH45Fbzw7IRtP4m/sXsGo36ax28APbgyQ8DDbqEiGpY3N0X JzY/daIuVL/kJYzRegrU2JIWXPXf5fmVRZ9AreItxRFMcaD6hNH+0jZv5nEGWn2mVoNA snoeqoKb5jfQo3QMf8BZdcjDglgiPU6oTL0DdajZfsBSV6OtZpu32sdfsblnkubWTJNZ S0Fjl2AT0c/v/d2pxOP3kwmXeJ76e5FQnV3H5SHCkcFSn8GUM/Xi7JbPnIu0cQUdmGXn R4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vr5oFFbG5wuVxPhlrLiEoOGIaSbJGBvBU1IMEqQ1IGs=; b=ahDceztpjchmSAwx+wRQukv2XvfQB4ugyMUU8ufCYrzP5cOFamgcjKJI3jrvYZIPXW CFfbLqJqx+roOAqaGmijjH4W4cAZ2DYRzPzTJTvNTf4w8Vf3UYqtU5ykHC7KcrAzgg83 eDDckjmcwMd7TkA8E1SkFxjCMQNHPwy6LqYgu1M3nR/Tmy7W8rM32wg1MizX8j/1ANgD RtZwdEfO1vqhOUEgeavqsC+3Ig52WcP08yN6nSZoAoqWkFrOr7BMncia7Jdf9USAjE9S XZG40frpybCrTDlncRS1sXtNC3ck0Wnwqy77NeSyqKNnqzxK5FarICWMPAvchaOa62YJ k8aw== X-Gm-Message-State: AOAM530sjImu5ZT2WVI0xlyT71AVIdCGC0azey1LjQv65+jhT0eniYs1 SLaOwpWYE4qd6lZi0OcHMwxhKk+68v4lIMuMGi4= X-Google-Smtp-Source: ABdhPJyCA29dKcEXPzh4J6GKmp2Fmn9hIj9pd12/UgNxKzIs2qcxXS6qmRNqXJ1glxnrx36HPJ7/J5hXiAduBTvOm44= X-Received: by 2002:a9d:a0d:: with SMTP id 13mr2900688otg.348.1604612955191; Thu, 05 Nov 2020 13:49:15 -0800 (PST) MIME-Version: 1.0 References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> In-Reply-To: From: Mark Smith Date: Fri, 6 Nov 2020 08:49:04 +1100 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Alexandre Petrescu , IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000323b9c05b3631120" Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 21:49:18 -0000 --000000000000323b9c05b3631120 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 6 Nov 2020, 08:06 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89, wrote: > At Thu, 5 Nov 2020 19:15:54 +0100, > Alexandre Petrescu wrote: > > > >> First off SLACC works just fine with any size prefix/interface ID. > > >> The protocol supports different sized prefixes/IIDs. The > > >> purported issue relates to interface ID sizes. These drafts > > >> appear to be confused about that. > > > > > > +1. Even the draft title has the confusion: "SLAAC with prefixes of > > > arbitrary length in PIO (Variable SLAAC) - A Problem Statement". The > > > SLAAC protocol itself as defined in RFC4862 already works with an > > > arbitrary prefix length. > > > > I think it is an indirect SLAAC-GUA problem. The IID len problem taint= s > > SLAAC. > > > > Yes, SLAAC spec works with 65bit plens. > > > > No, IIDs defined in IPv6-over-foo are not used anywhere else than in > > SLAAC. SLAAC is the only protocol that uses the IIDs defined in > > IPv6-over-foo. > > For IPv6-over-foo, that's correct. For example, RFC2464 Section 4 > specifically states it's for SLAAC. But that's only a part of the > whole picture; IPv6-over-foo and addr arch (RFC4291) must be > consistent, and the latter is not specific to SLAAC. In fact, if the > spec for IID length in the addr arch were also only about SLAAC, I > suspect the Bourbaki author(s) wouldn't care too much about it. > > The authors of draft-mishra-v6ops-variable-slaac-problem-stmt might > only be interested in SLAAC related use cases, but we can't pretend > it's an SLAAC specific problem (and provide a tweak to SLAAC as a > "solution") without resolving the implication on the addr arch (and > on manually configured addresses, etc). > There's also privacy and security implications, as if prefix lengths become arbitrary, then at a certain length, privacy addreses become ineffective, and measures to prevent discovery by unsolicited packet probing become ineffective. There's also implications to BCP204, host addressing recommendations, because I expect people will choose prefix lengths to only give each host a single address, as that is what they're familiar with from IPv4. 64 bits itself isn't magic, it is that it is a default, "plug-and-play" size that very effectively accommodates all of these other things that couldn't exist in IPv4. A provider giving out a single /64, when the provider has at least 4 billion /64s (i.e., min RIR allocation of a /32) is implicitly and strongly saying they don't want the receiver to be running a routed network. The IETF shouldn't come up with technical work arounds to operator policies, when there are already solutions for operators that don't have those policies (in this specific case, if customers are allowed to run routed networks, the operator can provide multiple /64s via PD). Regards, Mark. > That's what I tried to point out. > > -- > JINMEI, Tatuya > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000323b9c05b3631120 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 6 Nov 2020, 08:06 =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89, <jinmei@wide.ad.jp> wrote:
At Thu, 5 Nov 2020 19:15:54 +0100,
Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

> >> First off SLACC works just fine with any size prefix/interfac= e ID.
> >> The protocol supports different sized prefixes/IIDs.=C2=A0 = =C2=A0The
> >> purported issue relates to interface ID sizes.=C2=A0 =C2=A0Th= ese drafts
> >> appear to be confused about that.
> >
> > +1.=C2=A0 Even the draft title has the confusion: "SLAAC wit= h prefixes of
> > arbitrary length in PIO (Variable SLAAC) - A Problem Statement&qu= ot;. The
> > SLAAC protocol itself as defined in RFC4862 already works with an=
> > arbitrary prefix length.
>
> I think it is an indirect SLAAC-GUA problem.=C2=A0 The IID len problem= taints
> SLAAC.
>
> Yes, SLAAC spec works with 65bit plens.
>
> No, IIDs defined in IPv6-over-foo are not used anywhere else than in > SLAAC.=C2=A0 SLAAC is the only protocol that uses the IIDs defined in<= br> > IPv6-over-foo.

For IPv6-over-foo, that's correct.=C2=A0 For example, RFC2464 Section 4=
specifically states it's for SLAAC.=C2=A0 But that's only a part of= the
whole picture; IPv6-over-foo and addr arch (RFC4291) must be
consistent, and the latter is not specific to SLAAC.=C2=A0 In fact, if the<= br> spec for IID length in the addr arch were also only about SLAAC, I
suspect the Bourbaki author(s) wouldn't care too much about it.

The authors of draft-mishra-v6ops-variable-slaac-problem-stmt might
only be interested in SLAAC related use cases, but we can't pretend
it's an SLAAC specific problem (and provide a tweak to SLAAC as a
"solution") without resolving the implication on the addr arch (a= nd
on manually configured addresses, etc).









--000000000000323b9c05b3631120-- From nobody Thu Nov 5 13:49:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968793A1AE8 for ; Thu, 5 Nov 2020 13:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMEk3uOECxJM for ; Thu, 5 Nov 2020 13:49:48 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7FB3A1AE9 for ; Thu, 5 Nov 2020 13:49:41 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id v5so3039494wmh.1 for ; Thu, 05 Nov 2020 13:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LI/cnGYVaJbyF7T0NIhaj1Lxm0/LNd8cyp54ImRGY9A=; b=M3raS3JhWS8W5/4cOyoJPhXg7FqDI4Z6ph6iodvhh25YO1UubZLp5FbD/ypjJOAeZX rFCo8Zefgx+b9xAMzkr7W7rlac4numT4pQPsbWiOw6JwDdjpwUdU/xErZPwchHi7eURH 3xpB1lZIzY0P0cAaYvdicFDZEDdNJQEuIHz8OWO2quoPQ2LCrwfP7dLPzw8l24T28wjA b6NSIylKCXyndDrJZ7EFkCsHXLO6UuDRRKY1cFKDJPyv4WNEd9o8uxGQY8IY0TSdTiN+ ngPuzqZRrPoU4zMPc3n4jpMtDFreeDgGbXcC3dy4dxzvL4HKM3Z8wq8EAQ2Ii97CFFei YcRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LI/cnGYVaJbyF7T0NIhaj1Lxm0/LNd8cyp54ImRGY9A=; b=QVw9VmWbwJbvDaBTo8hIlH13C4ULgTsdShCus0gsuT3caJhnUm+/ElfoT/dSKE84kK 6KxUWEqUlnUHfx6cwzGOBsm0MZxOuI20bSKHudyVIazgADHpAFWZIeY7g5mFmM+U+40B LpinX8rDH4PPq+QTJZpBXudhIWjzeQ1iKUag5rGZJtvMcnbBATk79wjTmczrO4esaHBx qGOC1izss54frS5yBDCLg2w9XJRykRqjzcls6uUk8pyfghRkuWnpcZpiRyv74ZBJQoN9 qTzEy+Wrii/CB+bW5dxNvtFNP2Hda5Uz7vYhr1DWOoFWvEy556xBuklD6br4zZP1SRQO fbHw== X-Gm-Message-State: AOAM533yu9btOzzaIPf91DGbaN/W2yJMg1Ru/yUxINLLuTEu9D5QOkvO aTEDYkP01anW/ovxxi0ZPjEzevb9w9A= X-Google-Smtp-Source: ABdhPJz+Tp9qsevSnxW8iaUPUbis8XXwIKA7qlQqFc1ywRLEnrV1r3MMziP5slNrdLYhIQ867bTVKQ== X-Received: by 2002:a1c:4e1a:: with SMTP id g26mr4812667wmh.98.1604612980006; Thu, 05 Nov 2020 13:49:40 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:3157:b79c:3999:169e? ([2601:647:5a00:ef0b:3157:b79c:3999:169e]) by smtp.gmail.com with ESMTPSA id a185sm4124999wmf.24.2020.11.05.13.49.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 13:49:38 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F424B148-B3CF-406F-8DE2-AE98BB9F075F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 5 Nov 2020 13:49:33 -0800 In-Reply-To: <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> Cc: Bob Hinden , v6ops@ietf.org To: Alexandre Petrescu References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 21:49:56 -0000 --Apple-Mail=_F424B148-B3CF-406F-8DE2-AE98BB9F075F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alexandre, > On Nov 5, 2020, at 10:15 AM, Alexandre Petrescu = wrote: >=20 >=20 >> or "Arbitrary Length >> Interface Identifiers - A Problem Statement" (both "subnet prefix" >> and "interface identifier" are a concept defined in the address >> architecture). >=20 > But who uses Interface Identifiers? Only SLAAC, I think. >=20 That is not correct. All IPv6 unicast addresses have Interface IDs. = For example from RFC4291: 2.5.4. Global Unicast Addresses The general format for IPv6 Global Unicast addresses is as follows: | n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+ This is independent of how they are allocated (SLAAC, DHCP, manual). Please reread RFC4291. Bob --Apple-Mail=_F424B148-B3CF-406F-8DE2-AE98BB9F075F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+kc20ACgkQrut0EXfn u6ggggf8Cpfo+9Q2UejmPSSoDpETKALYDdhcw4njZH5wy8mLb7SrewedsrX9QHmS Xnn5ufiJa44VVWFnC5/UV/kR6sEie2aKl1EHa0MPUlyF2n75GXN++RdiNCsnyaCx R3+gukg11KbCfvp4p45DdepnGO/huGN1Wn2CPpspgRyQdzb7zWCzha+5U/12ILn3 erXLo4UNxzKBUGl4eTJxfk1UNooE673sn28vYnu3rg+KcYFYQwDPPXFLfqE5uiXM gqLzp+0RpIDhK0a5iEDRiHbBKKqUpeR+5M3hakYAgXLQvleHmCdq6gJOvQqIhjvx 5/ZG2eSrlaSyzcTePddw4l0tr/jcSA== =Xh+Z -----END PGP SIGNATURE----- --Apple-Mail=_F424B148-B3CF-406F-8DE2-AE98BB9F075F-- From nobody Thu Nov 5 14:18:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE03A1A9A for ; Thu, 5 Nov 2020 14:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TIm-x3o4m4M for ; Thu, 5 Nov 2020 14:18:16 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E1F3A1A99 for ; Thu, 5 Nov 2020 14:18:16 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id 62so2313496pgg.12 for ; Thu, 05 Nov 2020 14:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=P6Hd0JcbMpLbMtroj8kwtuM7wAJM/W0EGot2fAwU4+Y=; b=PtlHbHS9YI6gfW0IbP2ITIGumG3GEIDVP7xJc8PArg4ZVt2B+dgsWoZkwihAj0VojD omfdM3f5PiojW9Az6gJLBQPgOCC0+0zRoCWKFO+9+nYn0SYIEVVlP0Umum11NL8jnQAL iGL7fU9HdvCRs/s1k+Clqq4kKxNyy/e7UgQAS4wQ8t+vYWUHfzkXTe86EHTLtKyG7Hcf Mpj4tc2Wo/Vz0ZeY3RqwYk5a0BOoKtOagtTlp6eeqY1vaqSDPsWbBUzJScK96MGnIh8R L7tRmeTbiXa2r8dj1fane+P5jlkebbNVL4bNGkcUrl+gATIu0eGCXwkZy5utJkut0pU0 q5Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=P6Hd0JcbMpLbMtroj8kwtuM7wAJM/W0EGot2fAwU4+Y=; b=YHbSi7/SP73AXLDbhJi5MqYdof0mdZZFHukKxRfMOgoiQ8TVxPeNNzlPvnU/mq3IQC d9AC18I2vIE4UlCjCqF7J99Ju7Mrv8q1wkV6rCvR0eva3FXkW72B7C2R4MwIv4WRxX10 rqJJv+3qp/3LljC6ARIpcJHOhjY8zOQVxC9Nc/C/dRcg/e+93Cs6RxJ8xnyG6oKJ/uA1 BsJb+LLPgWKsy9MJd9kvX+h8j4+x84d4pl5ERhZTwynTib2L7PgvYfsR56qoyUMFdNjO p5oy5nhBBQy29JKVqtcKHDUV0/XcD07I7x3CJC1Pj/oqAhM0GetpoHT2Kw+a7TFYWdIM gYXw== X-Gm-Message-State: AOAM533ZOvNV3/sVaA4wpnQIVnxIPKGJCzyxLBOgBknT2jQn+kr2vtvf lKfP9WZ9Vq+oOW5QmZ3E0F8kAnLY10a+kQ== X-Google-Smtp-Source: ABdhPJxqeag0dz8NTHb0CQSqHd3jBYXjeIKiXnUN665w3TJ4zH+IvirNchXplpRVHtp2HGtkHKo1DA== X-Received: by 2002:a17:90a:a008:: with SMTP id q8mr4446513pjp.211.1604614695505; Thu, 05 Nov 2020 14:18:15 -0800 (PST) Received: from freds-mbp.lan (ip68-111-231-227.sd.sd.cox.net. [68.111.231.227]) by smtp.gmail.com with ESMTPSA id c24sm3429590pgk.34.2020.11.05.14.18.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 14:18:15 -0800 (PST) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_95A1D40A-581B-43C9-8F0F-912BAF64C943" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Date: Thu, 5 Nov 2020 14:18:13 -0800 References: <7AB74314-E35B-4868-ACF9-A20DBDEF6CA1@gmail.com> To: IPv6 Operations Message-Id: X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: [v6ops] Adding two drafts to the agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 22:18:18 -0000 --Apple-Mail=_95A1D40A-581B-43C9-8F0F-912BAF64C943 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ron and I have added two drafts to the agenda: draft-peng-v6ops-hbh and = draft-mishra-v6ops-variable-slaac-problem-stmt. The agenda is now as = stated at = https://www.ietf.org/proceedings/109/agenda/agenda-109-v6ops-04 = .=20 The argument, in the case of the SLAAC problem statement, is that the = 6man chairs requested operational discussion and an operational = viewpoint. So, voila, we can have that discussion. The argument in the = HBH case is that we have the time, and while Ron and I don't expect a = lot of support (and as stated it would have to be a 6man draft anyway), = it doesn't hurt to let it be discussed.=20 That means, authors, that each discussion has about 24 minutes total. = You get 10-15 minutes to present your thoughts, and about as much time = for online discussion. Please upload your slides to the meeting = materials page (https://datatracker.ietf.org/meeting/materials/ = ) or mail them to me by = the 2020-11-14 so I can upload them. > Begin forwarded message: >=20 > From: Bob Hinden > Subject: SLAAC with prefixes of arbitrary length in PIO (Variable = SLAAC) drafts > Date: November 5, 2020 at 12:36:55 PM PST > To: Fred Baker , Ron Bonica = > Cc: Bob Hinden , Ole Tr=C3=B8an = >=20 > Fred, Ron, >=20 > Ole and I planning the 6man agenda. We have been discussing the Gyan = drafts (SLAAC with prefixes of arbitrary length). >=20 > We wanted to get your thoughts. Our take is that it might be good if = V6OPS had a presentation on the problem that this is trying to solve. = Specifically the operational issues. >=20 > The solution proposed makes little sense to us since SLAAC already = supports variable length prefixes/IIDs, so we aren=E2=80=99t sure it = make sense to give him a slot in 6MAN. >=20 > Your thoughts? >=20 > Bob >=20 --Apple-Mail=_95A1D40A-581B-43C9-8F0F-912BAF64C943 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ron = and I have added two drafts to the agenda: draft-peng-v6ops-hbh and draft-mishra-v6ops-variable-slaac-problem-stmt. The agenda is = now as stated at https://www.ietf.org/proceedings/109/agenda/agenda-109-v6ops-04= . 

The argument, = in the case of the SLAAC problem statement, is that the 6man chairs = requested operational discussion and an operational viewpoint. So, = voila, we can have that discussion. The argument in the HBH case is that = we have the time, and while Ron and I don't expect a lot of support = (and as stated it would have to be a 6man draft anyway), it doesn't hurt = to let it be discussed. 

That means, = authors, that each discussion has about 24 minutes total. You get = 10-15 minutes to present your thoughts, and about as much time for = online discussion. Please upload your slides to the meeting materials = page (https://datatracker.ietf.org/meeting/materials/) or mail them to me by the 2020-11-14 so I can upload = them.

Begin forwarded = message:

From: = Bob Hinden <bob.hinden@gmail.com>
Subject: = SLAAC with = prefixes of arbitrary length in PIO (Variable SLAAC) drafts
Date: = November 5, 2020 at 12:36:55 PM = PST
To: = Fred Baker <fredbaker.ietf@gmail.com>, Ron Bonica <rbonica@juniper.net>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ole Tr=C3=B8an <otroan@employees.org>

Fred, Ron,

Ole and I planning the 6man agenda.  We have been = discussing the Gyan drafts (SLAAC with prefixes of arbitrary length).

We wanted to get your thoughts. =   Our take is that it might be good if V6OPS had a = presentation on the problem that this is trying to solve. =  Specifically the operational issues.

The solution proposed makes little sense to us since SLAAC = already supports variable length prefixes/IIDs, so we aren=E2=80=99t = sure it make sense to give him a slot in 6MAN.

Your thoughts?

Bob


= --Apple-Mail=_95A1D40A-581B-43C9-8F0F-912BAF64C943-- From nobody Fri Nov 6 01:54:22 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276323A1011 for ; Fri, 6 Nov 2020 01:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 Yt_xta8sB71n for ; Fri, 6 Nov 2020 01:54:19 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 1E1D43A0D5A for ; Fri, 6 Nov 2020 01:54:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A69sEZT014292; Fri, 6 Nov 2020 10:54:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DD06420422F; Fri, 6 Nov 2020 10:54:14 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CC4B520437A; Fri, 6 Nov 2020 10:54:14 +0100 (CET) Received: from [10.11.245.11] ([10.11.245.11]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A69sErC024941; Fri, 6 Nov 2020 10:54:14 +0100 To: Mark Smith , =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: IPv6 Operations References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 6 Nov 2020 10:54:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 09:54:21 -0000 Le 05/11/2020 Ă  22:49, Mark Smith a Ă©crit : > > > On Fri, 6 Nov 2020, 08:06 神ćŽé”哉, > wrote: > > At Thu, 5 Nov 2020 19:15:54 +0100, > Alexandre Petrescu > wrote: > > > >> First off SLACC works just fine with any size prefix/interface ID. > > >> The protocol supports different sized prefixes/IIDs.   The > > >> purported issue relates to interface ID sizes.   These drafts > > >> appear to be confused about that. > > > > > > +1.  Even the draft title has the confusion: "SLAAC with > prefixes of > > > arbitrary length in PIO (Variable SLAAC) - A Problem > Statement". The > > > SLAAC protocol itself as defined in RFC4862 already works with an > > > arbitrary prefix length. > > > > I think it is an indirect SLAAC-GUA problem.  The IID len problem > taints > > SLAAC. > > > > Yes, SLAAC spec works with 65bit plens. > > > > No, IIDs defined in IPv6-over-foo are not used anywhere else than in > > SLAAC.  SLAAC is the only protocol that uses the IIDs defined in > > IPv6-over-foo. > > For IPv6-over-foo, that's correct.  For example, RFC2464 Section 4 > specifically states it's for SLAAC.  But that's only a part of the > whole picture; IPv6-over-foo and addr arch (RFC4291) must be > consistent, and the latter is not specific to SLAAC.  In fact, if the > spec for IID length in the addr arch were also only about SLAAC, I > suspect the Bourbaki author(s) wouldn't care too much about it. > > The authors of draft-mishra-v6ops-variable-slaac-problem-stmt might > only be interested in SLAAC related use cases, but we can't pretend > it's an SLAAC specific problem (and provide a tweak to SLAAC as a > "solution") without resolving the implication on the addr arch (and > on manually configured addresses, etc). > > > There's also privacy and security implications, as if prefix lengths > become arbitrary, then at a certain length, privacy addreses become > ineffective, and measures to prevent discovery by unsolicited packet > probing become ineffective. > > There's also implications to BCP204, host addressing recommendations, > because I expect people will choose prefix lengths to only give each > host a single address, as that is what they're familiar with from IPv4. > > 64 bits itself isn't magic, it is that it is a default, "plug-and-play" > size that very effectively accommodates all of these other things that > couldn't exist in IPv4. > > A provider giving out a single /64, when the provider has at least 4 > billion /64s (i.e., min RIR allocation of a /32) is implicitly and > strongly saying they don't want the receiver to be running a routed network. > > The IETF shouldn't come up with technical work arounds to operator > policies, when there are already solutions for operators that don't have > those policies (in this specific case, if customers are allowed to run > routed networks, the operator can provide multiple /64s via PD). MArk, There are operators and operators. And, within operators, we use a generic term 'operator' to mean many things. But there are humans and computers at our each mention of 'operator'. We should not misunderstand each other at IETF. Operators depend on hardware manufacturers. At this time, the conclusion of all these dependencies, is that it's not possible to do a /56 for a smartphone. Some people and some computers and some policies at some operators do not mind if an IETF solution does 65+63 on the Ethernet or WiFi interface. They dont mind that any more than doing 64share or NAT for IPv4. Doing 65+63 on the WiFi interface of a smartphone might even be seen as an advantage, by certain people on some computers at some operators with some policies. This 65+63 is not a workaround operators interests. Alex > > Regards, > Mark. > > > > > > > That's what I tried to point out. > > -- > JINMEI, Tatuya > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Nov 6 04:01:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FB13A10FD for ; Fri, 6 Nov 2020 04:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.423 X-Spam-Level: X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 cqzvZteWqtGD for ; Fri, 6 Nov 2020 04:01:14 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 726043A10FC for ; Fri, 6 Nov 2020 04:01:14 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A6C1BWu013962; Fri, 6 Nov 2020 13:01:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8F396207289; Fri, 6 Nov 2020 13:01:11 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 81684204DE6; Fri, 6 Nov 2020 13:01:11 +0100 (CET) Received: from [10.11.245.11] ([10.11.245.11]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0A6C1B47013549; Fri, 6 Nov 2020 13:01:11 +0100 To: Bob Hinden Cc: v6ops@ietf.org References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <3FF78364-0435-4BF5-9027-B4E330FBB49A@gmail.com> <04992575-65a7-c719-b862-0b77e56a510b@gmail.com> From: Alexandre Petrescu Message-ID: <4b49fcb4-eb46-a2c3-a0f9-4c0d1bff4f3f@gmail.com> Date: Fri, 6 Nov 2020 13:01:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 12:01:16 -0000 Le 05/11/2020 ŕ 22:49, Bob Hinden a écrit : > Alexandre, > >> On Nov 5, 2020, at 10:15 AM, Alexandre Petrescu >> wrote: >> >> >>> or "Arbitrary Length Interface Identifiers - A Problem Statement" >>> (both "subnet prefix" and "interface identifier" are a concept >>> defined in the address architecture). >> >> But who uses Interface Identifiers? Only SLAAC, I think. >> > > That is not correct. All IPv6 unicast addresses have Interface > IDs. Maybe I can try to say that an 64bit IID is made of a sub-IID1 and a sub-IID2? In this way, an IID would still be 64bit length, but the Variable SLAAC would form an address in a different way: it would use a super-prefix constructed of the prefix received in RA to which the sub-IID1 would be appended. This Variable SLAAC would finally append the sub-IID1 to the super-prefix to form a 128bit IPv6 address. This be in agreement with IID 64bit of RFC4291, I think? Alex For example from RFC4291: > > 2.5.4. Global Unicast Addresses > > The general format for IPv6 Global Unicast addresses is as follows: > > | n bits | m bits | 128-n-m bits | > +------------------------+-----------+----------------------------+ | > global routing prefix | subnet ID | interface ID | > +------------------------+-----------+----------------------------+ > > This is independent of how they are allocated (SLAAC, DHCP, manual). > > Please reread RFC4291. > > Bob > > > From nobody Sun Nov 8 12:02:12 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB03A09D8; Sun, 8 Nov 2020 12:02:08 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg3Si4EBHAQ1; Sun, 8 Nov 2020 12:02:06 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3A33A09EC; Sun, 8 Nov 2020 12:02:05 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id t15so2149883ual.6; Sun, 08 Nov 2020 12:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=St4v9Mr28DYNmdkefoZnz0iSCLfSU/1TpZRmQWivJVM=; b=Wpa8UzgEguxvh9rk/JwApsFIyoAYmpcoIe1h3oqNnwt+D40zaR0zYOaw1DHTe7CJzJ 3mysgZzpQdWDHjkCRmhEA+GnCODaEM9BZ1sF8MZ7F81Uw9Qrg++UfWaXhmhzM1wKHjXV tAxdc5/T3mQY0ghLHTaLqgahSjAEfAuFRe02vFJ9SzFpf8SSwt/URPp21m7AF8aC8tOt QYn3HmO0gGeE6oeESnYQtlYas3gAfG64sBT7gTjg/Ep08+zxH0/qDg9eB5ymTkmTbd36 15lqvp41mbG6P5iU0r/M0aTQI49Zf6Vg5WiIe+WQFz3RZMo43V+gQAXzrKVEOuXv3ynP dn+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=St4v9Mr28DYNmdkefoZnz0iSCLfSU/1TpZRmQWivJVM=; b=lxxy/Ajf5HoKoDC2k38mc23b1ODUKhQcy4ydG6vJVRff7XbEF1fpwk5L9E53tnftQX uEaXIdHTPG3/NwVMd6GkfVDTNL9ftsxV77fCgD5MZc++sJoFKQgsrNmM88nWqvPbu3My L9ivpx6USClWZCh4zFKDS2QIPcEe0Su3UGAP2fOJRmUPiERsmRC+SU+Gz8UK91XHoRbU 1PqSVPi69Ta68ymvpiq3ZhsrZHzoxUVDJ2QZlGeRuKXng53kgnsG3XeFpB493kP7n8H9 u1wGQPaCYr8S5PXpoay98EIM54FSFTujacphy0e6Yguf5E2Re6nfmrAmGmbNUbiJyDHE Ed7A== X-Gm-Message-State: AOAM530GaSqskIaUPs1zlzVnbsLpF1aE6zmlW24Y/m16xek6fPvLIET/ xcYX/JIVw8EmubwVRNG3bavn9M56X94tEE81+JDuJY9Jgyj07A== X-Google-Smtp-Source: ABdhPJxKTNPSooTH3aiUO6cv1Kb6Ci0Qvc3rGxH6McaZdCKWLg4uuCK+mdk+ewCCKLmK4f68xun8S0XQWF8k//D+P4A= X-Received: by 2002:ab0:48ae:: with SMTP id x43mr5250639uac.114.1604865724753; Sun, 08 Nov 2020 12:02:04 -0800 (PST) MIME-Version: 1.0 References: <1A06280C-97EE-4B0A-9E71-ACAAFEA37399@employees.org> <32b092f1-cb36-a3cc-ca47-ae8edf45e780@gmail.com> In-Reply-To: <32b092f1-cb36-a3cc-ca47-ae8edf45e780@gmail.com> From: Gyan Mishra Date: Sun, 8 Nov 2020 15:01:54 -0500 Message-ID: To: Alexandre Petrescu , IPv6 Operations Cc: ipv6@ietf.org Content-Type: multipart/alternative; boundary="0000000000006fa99105b39debd4" Archived-At: Subject: Re: [v6ops] 6MAN Agenda for IETF 109 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 20:02:08 -0000 --0000000000006fa99105b39debd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So we are already on the agenda for v6ops. Great! Gyan On Sun, Nov 8, 2020 at 2:21 PM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > (for my part, I think v6ops WG already has the problem statement draft > in the agenda; it was posted > https://www.ietf.org/proceedings/109/agenda/agenda-109-v6ops-04) > > For more precision, the title in the agenda would add '... - A Problem > Statement'. > > So I think it's fine there. > > Alex > > Le 08/11/2020 =C3=A0 20:06, Gyan Mishra a =C3=A9crit : > > > > Fred & Ron > > > > See thread below. Should I put together a presentation for v6ops per > > below to review the problem. > > > > Gyan > > > > On Sun, Nov 8, 2020 at 1:16 PM Ole Troan > > wrote: > > > > I would expect the v6ops chairs would like a presentation, but let > > me not presuppose how they want to run that session. > > > > Cheers > > Ole > > > >> On 8 Nov 2020, at 19:00, Gyan Mishra >> > wrote: > >> > >> =EF=BB=BF > >> > >> > >> On Sun, Nov 8, 2020 at 12:58 PM Gyan Mishra >> > wrote: > >> > >> > >> > >> On Sun, Nov 8, 2020 at 12:35 PM >> > wrote: > >> > >> Hi Gyan, > >> > >> > As we have had thus far and ongoing quite a bit of > >> discussion on variable slaac can we add this to the > >> agenda. We can also expand the scope of discussion as to > >> all use cases related to slaac longer prefix lengths and > >> how it can be beneficial per the =E2=80=9CExtending a /64= =E2=80=9D new > >> thread. I can start the discussion and we can take it > >> from there. > >> > >> The "Extending a /64" thread (which I in hindsight see is > >> poorly named) is not about longer prefix lengths. > >> It is about exploring solutions to the problem of > >> extending a network assigned with a single /64 with > >> multiple links. > >> > >> > >> Gyan> Agreed but G-Extend the 64 bit boundary > >> > >> > >> > >> Bob and I had a discussion with the chairs of > >> v6ops, where we agreed to have the "what is the > >> operational problem" discussion over in v6ops.= . > >> > >> > >> Gyan> Sounds good. Will have the draft authors join in on > >> the discussion. > >> > >> > >> Should I put together a presentation for the discussion or > >> will it be ad-hoc. > >> > >> > >> > >> Best regards, > >> Ole > >> > >> -- > >> > >> > >> > >> *Gyan Mishra* > >> > >> /Network Solutions A//rchitect / > >> > >> /M 301 502-1347 > >> 13101 Columbia Pike > >> < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > > > >> > >> /Silver Spring, MD > >> < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > > > >> > >> > >> -- > >> > >> > >> > >> *Gyan Mishra* > >> > >> /Network Solutions A//rchitect / > >> > >> /M 301 502-1347 > >> 13101 Columbia Pike > >> < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > > > >> > >> /Silver Spring, MD > >> < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > > > >> > >> > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000006fa99105b39debd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So we are already on the agenda for v6ops.= =C2=A0

Great!

Gyan
On Sun, Nov 8, 2020 at= 2:21 PM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
(for my part, I think v6ops WG already has the problem statem= ent draft
in the agenda; it was posted
https://www.ietf.org/proceedings/109/= agenda/agenda-109-v6ops-04)

For more precision, the title in the agenda would add=C2=A0 '... - A Pr= oblem
Statement'.

So I think it's fine there.

Alex

Le 08/11/2020 =C3=A0 20:06, Gyan Mishra a =C3=A9crit=C2=A0:
>
> Fred & Ron
>
> See thread below.=C2=A0 Should I put together a presentation for v6ops= per
> below to review the problem.
>
> Gyan
>
> On Sun, Nov 8, 2020 at 1:16 PM Ole Troan <otroan@employees.org
> <mailto:o= troan@employees.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I would expect the v6ops chairs would like a presen= tation, but let
>=C2=A0 =C2=A0 =C2=A0me not presuppose how they want to run that session= .
>
>=C2=A0 =C2=A0 =C2=A0Cheers
>=C2=A0 =C2=A0 =C2=A0Ole
>
>>=C2=A0 =C2=A0 =C2=A0On 8 Nov 2020, at 19:00, Gyan Mishra <hayabusagsm@gmail.com<= /a>
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0=EF=BB=BF
>>
>>
>>=C2=A0 =C2=A0 =C2=A0On Sun, Nov 8, 2020 at 12:58 PM Gyan Mishra <= ;hayabusagsm@gma= il.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>> wrote:
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sun, Nov 8, 2020 at 12:35 PM &= lt;otroan@employe= es.org
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>> wrote:=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Gyan,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> As we have had= thus far and ongoing quite a bit of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussion on varia= ble slaac can we add this to the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0agenda.=C2=A0 We ca= n also expand the scope of discussion as to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0all use cases relat= ed to slaac longer prefix lengths and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0how it can be benef= icial per the =E2=80=9CExtending a /64=E2=80=9D new
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thread.=C2=A0 I can= start the discussion and we can take it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from there.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The "Extending= a /64" thread (which I in hindsight see is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0poorly named) is no= t about longer prefix lengths.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is about explori= ng solutions to the problem of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extending a network= assigned with a single /64 with
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple links.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Gyan> Agreed but= G-Extend the 64 bit boundary
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<chair-hat>Bo= b and I had a discussion with the chairs of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v6ops, where we agr= eed to have the "what is the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operational problem= " discussion over in v6ops.</chair-hat>.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Gyan> Sounds goo= d.=C2=A0 Will have the draft authors join in on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the discussion.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Should I put together a presentat= ion for the discussion or
>>=C2=A0 =C2=A0 =C2=A0will it be ad-hoc.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best regards,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ole
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/>=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Gyan Mishra*
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Network Solutions A//rchitect /<= br> >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/M 301 502-1347
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013101 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/= search/13101+Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Silver Spring, MD
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/= search/13101+Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0--
>>
>>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/>
>>
>>=C2=A0 =C2=A0 =C2=A0*Gyan Mishra*
>>
>>=C2=A0 =C2=A0 =C2=A0/Network Solutions A//rchitect /
>>
>>=C2=A0 =C2=A0 =C2=A0/M 301 502-1347
>>=C2=A0 =C2=A0 =C2=A013101 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/13101+= Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg>
>>
>>=C2=A0 =C2=A0 =C2=A0/Silver Spring, MD
>>=C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/13101+= Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg>
>>
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--0000000000006fa99105b39debd4-- From nobody Tue Nov 10 10:05:56 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE53A0DDD; Tue, 10 Nov 2020 10:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shytyi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkifnvKdPdEC; Tue, 10 Nov 2020 10:05:50 -0800 (PST) Received: from sender11-of-o53.zoho.eu (sender11-of-o53.zoho.eu [31.186.226.239]) (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 0B5C83A0DDB; Tue, 10 Nov 2020 10:05:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605031536; cv=none; d=zohomail.eu; s=zohoarc; b=ShqZv3hVqriYIdZjjvZ11l0EfYZLCKNW4XwLHCidiUJHqbXEFIRe/GSwbieOpD4qDWwRSPNdE8MXzmSsnYujFqFYNSMWvbXNvJ7cdHBGHCe29mDFoLLBO4N/LRbRFvQduvpurcL0mjeY3dFf3mkYJ2miisDDEuGE3DYGluakbtY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1605031536; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:MIME-Version:Message-ID:Subject:To; bh=PvzRhp63nlDX5tILHKnrwNwxxX3OCpotjNaY1iFGVhw=; b=eXde2pdaCIWyTzerHo0yqOSYeMzm6Idf8ZoNqRh/fOK4wZlpnqMroNMiqFUoLkeQhbNSQQzZTRyiBm5myQnqlRtlhw519YmzhchjkLQ2m9qGPP5rPJXH8jO+GtZd/YtdsCMH9SmsIY26BMusE/MI0kINWSoY9ySiktFaPa6zSxU= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1605031536; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-ID:In-Reply-To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=PvzRhp63nlDX5tILHKnrwNwxxX3OCpotjNaY1iFGVhw=; b=ArfObpNWE6c5l8Gnpw4KzXE/tKwISzhq0KDrtXgR8QBHTN0brVMIcHEs+tvvZiLc LrORt3SIfZV8DZjsegd7TfzMoNzoRiZaS6YnX/r64DXy6I0vdE4BaKzDeKBtWmFCrSX XusPT2jtlOMa4DsTNJs8wrOgTjuqq2yDtY5dLt60= Received: from sender21-mail.zoho.eu (172.26.23.78 [172.26.23.78]) by mx.zoho.eu with SMTPS id 1605031535234138.472768096173; Tue, 10 Nov 2020 19:05:35 +0100 (CET) Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1605031535094786.6182309270245; Tue, 10 Nov 2020 19:05:35 +0100 (CET) Date: Tue, 10 Nov 2020 19:05:35 +0100 From: Dmytro Shytyi To: "v6ops" , "ipv6" Cc: "gyansmishra" , "alexandrepetrescu" , "nkottapalli" , "dmudric" Message-ID: <175b355a1f5.de929a1814179.7234090001378491531@shytyi.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: Subject: [v6ops] Variable SLAAC linux kernel implementation (SLAAC with prefixes of arbitrary length in PIO) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 18:05:52 -0000 Dear participants of v6ops and 6man working groups, I just released the open source implementation of Variable SLAAC (SLAAC wit= h prefixes of arbitrary length in PIO) in the next github repository:=C2=A0= https://github.com/dmytroshytyi/variable-slaac Compatible linux kernels with patches in this repo: net-next branch Linux ferby 5.10.0-rc2-00757-g8be33ecfc1ff-dirty #2 SMP PREEMPT Tue Nov = 10 12:33:35 CET 2020 x86_64 GNU/Linux net branch Linux kernel: Linux ferby 5.10.0-rc1-00133-gfffffda4fefb #1 SMP PREEMPT = Mon Nov 2 21:42:42 CET 2020 x86_64 GNU/Linux Linux kernel: Linux ferby 5.9.0-rc3-00357-gcc8e58f8325c-dirty #1 SMP PRE= EMPT Thu Sep 10 10:50:34 CEST 2020 x86_64 GNU/Linux Feel free to try it and leave your comments :) __________________ Dmytro SHYTYI From nobody Tue Nov 10 16:20:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6C63A123C for ; Tue, 10 Nov 2020 16:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_pjjAj5l6_8 for ; Tue, 10 Nov 2020 16:20:29 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826E33A123E for ; Tue, 10 Nov 2020 16:20:29 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id v12so375007pfm.13 for ; Tue, 10 Nov 2020 16:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=L5reh5W4JqQ+KTqlc//jAPe9XdzK1UQXUdKXPmpWPfU=; b=Aq978vv6sVPOdae0/cUCouI4igOoc7+i6I5dmjdJCMr3PswV2MnbALYWko01yydaZQ 3Y/rWVyHuH6rC4ueHnVRbo1fU0RKWnUmy4a0uakAfl30nx7aXYQ/+mi0OlwV1hWcrmYy t01n9Dkj3nGKzFN7P5JjKSiFgwHEuYwa3aW9WPWQ8pdsLD1GuS4fFP6JslJ1HGu0DKag hQKkZqmmahPBxojFlyLca46iS0qA+r5rIWBrRCx8tJ9C3GgDR7etiNtupuCZS2b/q6wa vFIt9uiFCpZzAbVxa8OYrn9yzzF2MN42UtYpclLx2alTGNoShMGZXMPYoJVXRQFG/mSq 9kZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=L5reh5W4JqQ+KTqlc//jAPe9XdzK1UQXUdKXPmpWPfU=; b=PG3kDLwqNS+9sjhdvMFMFrQypQ+gK9uicr9p4tKJYfHAH+VN1uzHpWm/4tQr7rHrH/ E+AwoPkm6aOdPz7TaSdCL8qpp36hHa8P+688PvYXaETV/maHztZv+j7+DLLwnm00d9k6 AXtmBeQ/a0ykY5mhXVK3N19R2m9FtIxKR72LhcmciTYGE5abjWRps0821aUYqLazjXkM qa4sGrhVvB7qaE1ndikEFEbfKATIlI2ERxE/xwGCXbjWP3gm9+7vE2b4b1cdqqaO15H/ JTCwK/1U4d6+IfQVIg65u8TNsNNiiw2y7XGp8nhcc3Nt0XZ/qLf+N2OYuEzRMKaTT568 oFeA== X-Gm-Message-State: AOAM531riMOn6nISBA8NBfvKB5Ov6ZZU7fA/ZZnKrFqC0oGY5/trV0F4 tMYZA8q8qU5X6O/qatuuJMo5zntlO68gWA== X-Google-Smtp-Source: ABdhPJxi0t0WCKyx/jpoHdA9njAFuGRzzHqzlXCqcgqK4Q1PoLJmuO+zcFryFnkVRL2Lv7FspFSLGw== X-Received: by 2002:a63:c94c:: with SMTP id y12mr19073258pgg.303.1605054028807; Tue, 10 Nov 2020 16:20:28 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::102d? ([2600:8802:5800:1963::102d]) by smtp.gmail.com with ESMTPSA id g1sm144924pjl.33.2020.11.10.16.20.27 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2020 16:20:28 -0800 (PST) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_E918E73B-1B5E-4D40-9DF5-96DDD7D3B017" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Message-Id: <63B71AAB-82FD-4C0B-83AD-953EE093FC02@gmail.com> References: To: IPv6 Operations Date: Tue, 10 Nov 2020 16:20:26 -0800 X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: [v6ops] Fwd: Requesting NomCom feedback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 00:20:31 -0000 --Apple-Mail=_E918E73B-1B5E-4D40-9DF5-96DDD7D3B017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nomcom chair is seeking your commentary > Begin forwarded message: >=20 > From: "STARK, BARBARA H" > Subject: Requesting NomCom feedback > Date: November 10, 2020 at 4:12:06 PM PST > To: "'WG Chairs'" >=20 > Hi WG Chairs, > First: Thanks for your help in getting volunteers for NomCom and = getting nominees. Your emails to your WGs have been priceless for making = the NomCom process work. My last request of you is for help with getting = feedback. We've heard from the usual suspects. I really want to hear = from more of the community, and the ietf and Announcement lists just = don't seem to reach enough people. >=20 > Below is the text I just sent out to the Announcement and ietf lists. = Feel free to use this or invent your own shorter version. > Thx, > Barbara > ---------------------------- > NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC = Board, and IETF Trust. We need more input from the community both on = specific nominees and on over-arching topics regarding what the = community wants from these specific groups and wants from its leadership = in general. We need *your* input. >=20 > ** Deadline for community feedback is Friday November 20. ** >=20 > We've paid attention to discussions on the ietf list. Issues raised = there have been brought up in interviews. >=20 > We've also asked questions of nominees based on feedback received, and = based on the "Topics" that people said were important. > We're listening to you.=20 >=20 > But most of the input to date has come from a few consistently vocal = people. We need to hear from more of you. >=20 > I scheduled our office hours during the 2 weeks before next week's = IETF, because IETF week is so busy. We have one more left (18:00-19:00 = UTC November 11). No-one but NomCom members showed up for our first 3. = =E2=98=B9 If there is demand for more office hours, I'll schedule them; = but this really doesn't seem to be the preferred format for input. >=20 > Most input is coming in as either=20 > - email to nomcom20@ietf.org > - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/ > On the feedback page, the specific nominees are all listed at the top. = General Topics are at the bottom. > We pay attention to all the comments we get through these channels. >=20 > I'll also try to hang out in Gather.Town during IETF breaks next week.=20= > I'm not going to have a specific NomCom area in Gather.Town, because = it was really lonely hanging out there during IETF 108. > But please feel free to hunt me down and bend my ear -- on NomCom = issues or just to chat. > I miss seeing all of y'all! > Barbara >=20 > Barbara Stark > NomCom 2020 Chair >=20 >=20 >=20 >=20 --Apple-Mail=_E918E73B-1B5E-4D40-9DF5-96DDD7D3B017 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Nomcom chair is seeking your commentary

= --Apple-Mail=_E918E73B-1B5E-4D40-9DF5-96DDD7D3B017-- From nobody Mon Nov 16 15:08:28 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCF13A163D; Mon, 16 Nov 2020 15:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.67 X-Spam-Level: * X-Spam-Status: No, score=1.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 37ejKDtYNeSZ; Mon, 16 Nov 2020 15:08:21 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 2138B3A13EF; Mon, 16 Nov 2020 15:08:20 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AGN8Ihw049125; Tue, 17 Nov 2020 00:08:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6A763207AAF; Tue, 17 Nov 2020 00:08:18 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5A79B2063BA; Tue, 17 Nov 2020 00:08:18 +0100 (CET) Received: from [10.11.240.254] ([10.11.240.254]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AGN8Hio023664; Tue, 17 Nov 2020 00:08:18 +0100 To: Gyan Mishra , IPv6 Operations Cc: ipv6@ietf.org References: <1A06280C-97EE-4B0A-9E71-ACAAFEA37399@employees.org> <32b092f1-cb36-a3cc-ca47-ae8edf45e780@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 17 Nov 2020 00:08:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] 6MAN Agenda for IETF 109 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 23:08:23 -0000 Just to make sure, The v6ops WG meeting will be on Thursday, the 19th, starting at 10am Paris time. I dont know what is your large city nearby, Gyan. I am saying this because I noticed 'IST' in the agenda, and I suppose that is not right. Alex Le 08/11/2020 à 21:01, Gyan Mishra a écrit : > > So we are already on the agenda for v6ops. > > Great! > > Gyan > On Sun, Nov 8, 2020 at 2:21 PM Alexandre Petrescu > > wrote: > > (for my part, I think v6ops WG already has the problem statement draft > in the agenda; it was posted > https://www.ietf.org/proceedings/109/agenda/agenda-109-v6ops-04 > ) > > For more precision, the title in the agenda would add  '... - A Problem > Statement'. > > So I think it's fine there. > > Alex > > Le 08/11/2020 à 20:06, Gyan Mishra a écrit : > > > > Fred & Ron > > > > See thread below.  Should I put together a presentation for v6ops > per > > below to review the problem. > > > > Gyan > > > > On Sun, Nov 8, 2020 at 1:16 PM Ole Troan > > >> wrote: > > > >     I would expect the v6ops chairs would like a presentation, > but let > >     me not presuppose how they want to run that session. > > > >     Cheers > >     Ole > > > >>     On 8 Nov 2020, at 19:00, Gyan Mishra > >>      >> wrote: > >> > >>      > >> > >> > >>     On Sun, Nov 8, 2020 at 12:58 PM Gyan Mishra > > >>      >> wrote: > >> > >> > >> > >>         On Sun, Nov 8, 2020 at 12:35 PM > >>          >> wrote: > >> > >>             Hi Gyan, > >> > >>             > As we have had thus far and ongoing quite a bit of > >>             discussion on variable slaac can we add this to the > >>             agenda.  We can also expand the scope of discussion > as to > >>             all use cases related to slaac longer prefix lengths and > >>             how it can be beneficial per the “Extending a /64” new > >>             thread.  I can start the discussion and we can take it > >>             from there. > >> > >>             The "Extending a /64" thread (which I in hindsight > see is > >>             poorly named) is not about longer prefix lengths. > >>             It is about exploring solutions to the problem of > >>             extending a network assigned with a single /64 with > >>             multiple links. > >> > >> > >>             Gyan> Agreed but G-Extend the 64 bit boundary > >> > >> > >> > >>             Bob and I had a discussion with the chairs of > >>             v6ops, where we agreed to have the "what is the > >>             operational problem" discussion over in > v6ops.. > >> > >> > >>             Gyan> Sounds good.  Will have the draft authors join > in on > >>         the discussion. > >> > >> > >>         Should I put together a presentation for the discussion or > >>     will it be ad-hoc. > >> > >> > >> > >>             Best regards, > >>             Ole > >> > >>         -- > >> > >>         > > >> > >>         *Gyan Mishra* > >> > >>         /Network Solutions A//rchitect / > >> > >>         /M 301 502-1347 > >>         13101 Columbia Pike > >> >  > > >> > >>         /Silver Spring, MD > >> >  > > >> > >> > >>     -- > >> > >>     > > >> > >>     *Gyan Mishra* > >> > >>     /Network Solutions A//rchitect / > >> > >>     /M 301 502-1347 > >>     13101 Columbia Pike > >> >  > > >> > >>     /Silver Spring, MD > >> >  > > >> > >> > > -- > > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > From nobody Mon Nov 16 16:21:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE53A1749; Mon, 16 Nov 2020 16:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f6q4LOy5rWD; Mon, 16 Nov 2020 16:21:26 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E8D3A1747; Mon, 16 Nov 2020 16:21:25 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id q10so15786045pfn.0; Mon, 16 Nov 2020 16:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z4KovcIEQTLrKv09pVkzC9gjNHNOuhLtjsXs1bJedRY=; b=kSsJMPpXWqfiOttDYuv88Gx9czY6uCrvy5p3C9SFPFB6gH9oQLIYxPMrwtkWP429ty aPyYIWSHrx7I4eWHR6GWILZwV6aS7ihOsXYIKPTDRN6PUDNisBI0W16jUg6fyJxNt30F 5JRghhfmgCnumJGV66uYdTebKQFNe5zlXMnYE/jErbD6ora/fq1pTektj3/3J1m2LP5r 3rxm5WiKMkQR4bUNDXbkjYFd7zTzVa7UqYSDGJwWjwFLfVPAThk6Dq9MCprMUZC9cTue RwkPLbHowxoE9F00cxTsa8vvfoUQSBowubtVYmfASuh3gx9IibxOQwpks7wzQi5vSt3B 7uwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z4KovcIEQTLrKv09pVkzC9gjNHNOuhLtjsXs1bJedRY=; b=C3hlg8XhTdD0YdC2dCoejcp08cocZ45EFxWm5nfsm6uwXnX+5czvoqQLILhflLfPJX 3LLeGjM8vlDSA5S4+6p49Lghbc2BWAWbGosbM8gnyGQRQCCHok5+XIh+6d3qWSXgciVZ 5nk4mXztjeW6fTgj9KT45eYbZU0C4+1bBo90ao32QFFycLF31EQPv+5h5nyPT2sdmryc aRACsdermreOQH30EjG7bkgXQ+itkv4g9NwuM9qr3Rk3qfIDzWK9DmT+H+JH/ofUJkPP xnGaCnzqoGl8Yj3YKqoDf52y8YkuDGgjb12KIarVQUXnuvxCvVdgm9Pd8TCo0PJ0+mKH EW1A== X-Gm-Message-State: AOAM532X45vGS/63KME+PZ9MblfKNoRZ1pw5XKRrsEePm02Ycc3+u1ym 7FKG9Pkic3xecpS316+cUDwCxEeJ9Agb9rJdPLtS1wW8aX7Hvw== X-Google-Smtp-Source: ABdhPJw26rOJ5f+FVJceFu2onALQv7RC6072bs80nfuHC7TxwTqqdZHH+uZnnK+3ngj+myPZrHQ0l8Oi0gUtkH/14jo= X-Received: by 2002:a63:fd0b:: with SMTP id d11mr1383860pgh.50.1605572485286; Mon, 16 Nov 2020 16:21:25 -0800 (PST) MIME-Version: 1.0 References: <1A06280C-97EE-4B0A-9E71-ACAAFEA37399@employees.org> <32b092f1-cb36-a3cc-ca47-ae8edf45e780@gmail.com> In-Reply-To: From: Gyan Mishra Date: Mon, 16 Nov 2020 19:21:14 -0500 Message-ID: To: Alexandre Petrescu Cc: IPv6 Operations , ipv6@ietf.org Content-Type: multipart/alternative; boundary="000000000000a58da605b442797b" Archived-At: Subject: Re: [v6ops] 6MAN Agenda for IETF 109 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 00:21:28 -0000 --000000000000a58da605b442797b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alex I will be on. I was up all last night as being on ET it=E2=80=99s been a b= it brutal working graveyard shift but that=E2=80=99s ok. I do have a conflict with BESS where I am presenting at the same timeframe window, but I was able to work it out with BESS moved my presentation to the top of the window. Gyan On Mon, Nov 16, 2020 at 6:08 PM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Just to make sure, > The v6ops WG meeting will be on Thursday, the 19th, > starting at 10am Paris time. I dont know what is your large city > nearby, Gyan. > > I am saying this because I noticed 'IST' in the agenda, and I suppose > that is not right. > > Alex > > Le 08/11/2020 =C3=A0 21:01, Gyan Mishra a =C3=A9crit : > > > > So we are already on the agenda for v6ops. > > > > Great! > > > > Gyan > > On Sun, Nov 8, 2020 at 2:21 PM Alexandre Petrescu > > > > wrote: > > > > (for my part, I think v6ops WG already has the problem statement > draft > > in the agenda; it was posted > > https://www.ietf.org/proceedings/109/agenda/agenda-109-v6ops-04 > > ) > > > > For more precision, the title in the agenda would add '... - A > Problem > > Statement'. > > > > So I think it's fine there. > > > > Alex > > > > Le 08/11/2020 =C3=A0 20:06, Gyan Mishra a =C3=A9crit : > > > > > > Fred & Ron > > > > > > See thread below. Should I put together a presentation for v6op= s > > per > > > below to review the problem. > > > > > > Gyan > > > > > > On Sun, Nov 8, 2020 at 1:16 PM Ole Troan > > > > >> > wrote: > > > > > > I would expect the v6ops chairs would like a presentation, > > but let > > > me not presuppose how they want to run that session. > > > > > > Cheers > > > Ole > > > > > >> On 8 Nov 2020, at 19:00, Gyan Mishra > > > >> > >> wrote: > > >> > > >> =EF=BB=BF > > >> > > >> > > >> On Sun, Nov 8, 2020 at 12:58 PM Gyan Mishra > > > > >> > >> wrote: > > >> > > >> > > >> > > >> On Sun, Nov 8, 2020 at 12:35 PM > > > >> > >> wrote: > > >> > > >> Hi Gyan, > > >> > > >> > As we have had thus far and ongoing quite a bit o= f > > >> discussion on variable slaac can we add this to the > > >> agenda. We can also expand the scope of discussion > > as to > > >> all use cases related to slaac longer prefix length= s > and > > >> how it can be beneficial per the =E2=80=9CExtending= a /64=E2=80=9D > new > > >> thread. I can start the discussion and we can take > it > > >> from there. > > >> > > >> The "Extending a /64" thread (which I in hindsight > > see is > > >> poorly named) is not about longer prefix lengths. > > >> It is about exploring solutions to the problem of > > >> extending a network assigned with a single /64 with > > >> multiple links. > > >> > > >> > > >> Gyan> Agreed but G-Extend the 64 bit boundary > > >> > > >> > > >> > > >> Bob and I had a discussion with the > chairs of > > >> v6ops, where we agreed to have the "what is the > > >> operational problem" discussion over in > > v6ops.. > > >> > > >> > > >> Gyan> Sounds good. Will have the draft authors joi= n > > in on > > >> the discussion. > > >> > > >> > > >> Should I put together a presentation for the discussion > or > > >> will it be ad-hoc. > > >> > > >> > > >> > > >> Best regards, > > >> Ole > > >> > > >> -- > > >> > > >> > > > >> > > >> *Gyan Mishra* > > >> > > >> /Network Solutions A//rchitect / > > >> > > >> /M 301 502-1347 > > >> 13101 Columbia Pike > > >> > > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > >> > > >> > > >> /Silver Spring, MD > > >> > > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > >> > > >> > > >> > > >> -- > > >> > > >> > > > >> > > >> *Gyan Mishra* > > >> > > >> /Network Solutions A//rchitect / > > >> > > >> /M 301 502-1347 > > >> 13101 Columbia Pike > > >> > > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > >> > > >> > > >> /Silver Spring, MD > > >> > > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?= entry=3Dgmail&source=3Dg > >> > > >> > > >> > > > -- > > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: > > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------= - > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a58da605b442797b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alex=C2=A0

I will be on.=C2=A0 I was up all last night as being on ET it=E2=80=99= s been a bit brutal working graveyard shift but that=E2=80=99s ok.


Begin = forwarded message:

From: = "STARK, BARBARA H" <bs7652@att.com>
Subject: = Requesting NomCom = feedback
Date: = November 10, 2020 at 4:12:06 PM = PST
To: = "'WG Chairs'" <wgchairs@ietf.org>

Hi = WG Chairs,
First: Thanks for your help in getting = volunteers for NomCom and getting nominees. Your emails to your WGs have = been priceless for making the NomCom process work. My last request of = you is for help with getting feedback. We've heard from the usual = suspects. I really want to hear from more of the community, and the ietf = and Announcement lists just don't seem to reach enough people.

Below is the text I just sent out to the = Announcement and ietf lists. Feel free to use this or invent your own = shorter version.
Thx,
Barbara
----------------------------
NomCom is = considering nominees for AD positions, IETF Chair, IAB, LLC Board, and = IETF Trust. We need more input from the community both on specific = nominees and on over-arching topics regarding what the community wants = from these specific groups and wants from its leadership in general. We = need *your* input.

** Deadline for = community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues = raised there have been brought up in interviews.

We've also asked questions of nominees based on feedback = received, and based on the "Topics" that people said were important.
We're listening to you.

But = most of the input to date has come from a few consistently vocal people. = We need to hear from more of you.

I = scheduled our office hours during the 2 weeks before next week's IETF, = because IETF week is so busy. We have one more left (18:00-19:00 UTC = November 11). No-one but NomCom members showed up for our first 3. =E2=98=B9= If there is demand for more office hours, I'll schedule them; but this = really doesn't seem to be the preferred format for input.

Most input is coming in as either
- email to nomcom20@ietf.org
- feedback on https://datatracker.ietf.org/nomcom/2020/feedback/
On the feedback page, the specific nominees are all listed at = the top. General Topics are at the bottom.
We pay = attention to all the comments we get through these channels.

I'll also try to hang out in Gather.Town = during IETF breaks next week.
I'm not going to have a = specific NomCom area in Gather.Town, because it was really lonely = hanging out there during IETF 108.
But please feel free to = hunt me down and bend my ear -- on NomCom issues or just to chat.
I miss seeing all of y'all!
Barbara

Barbara Stark
NomCom 2020 = Chair




I do have a conflict with BESS w= here I am presenting at the same timeframe window, but I was able to work i= t out with BESS moved my presentation to the top of the window.

Gyan

On Mon, Nov 16, 2020 at 6:= 08 PM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Jus= t to make sure,
The v6ops WG meeting will be on Thursday, the 19th,
starting at 10am Paris time.=C2=A0 I dont know what is your large city
nearby, Gyan.

I am saying this because I noticed 'IST' in the agenda, and I suppo= se
that is not right.

Alex

Le 08/11/2020 =C3=A0 21:01, Gyan Mishra a =C3=A9crit=C2=A0:
>
> So we are already on the agenda for v6ops.
>
> Great!
>
> Gyan
> On Sun, Nov 8, 2020 at 2:21 PM Alexandre Petrescu
> <= alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0(for my part, I think v6ops WG already has the prob= lem statement draft
>=C2=A0 =C2=A0 =C2=A0in the agenda; it was posted
>=C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/proceedings/109/agenda/agenda-109-v6ops-04
>=C2=A0 =C2=A0 =C2=A0<https://w= ww.ietf.org/proceedings/109/agenda/agenda-109-v6ops-04>)
>
>=C2=A0 =C2=A0 =C2=A0For more precision, the title in the agenda would a= dd=C2=A0 '... - A Problem
>=C2=A0 =C2=A0 =C2=A0Statement'.
>
>=C2=A0 =C2=A0 =C2=A0So I think it's fine there.
>
>=C2=A0 =C2=A0 =C2=A0Alex
>
>=C2=A0 =C2=A0 =C2=A0Le 08/11/2020 =C3=A0 20:06, Gyan Mishra a =C3=A9cri= t=C2=A0:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Fred & Ron
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > See thread below.=C2=A0 Should I put together= a presentation for v6ops
>=C2=A0 =C2=A0 =C2=A0per
>=C2=A0 =C2=A0 =C2=A0 > below to review the problem.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Gyan
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Sun, Nov 8, 2020 at 1:16 PM Ole Troan <= otroan@employees.= org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:otroan@employees.org <mailto:otroan@employees.org>>= > wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I would expect the v6ops c= hairs would like a presentation,
>=C2=A0 =C2=A0 =C2=A0but let
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0me not presuppose how they= want to run that session.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Cheers
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Ole
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0On 8 Nov 2020, at 19:0= 0, Gyan Mishra <hayabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0=EF=BB=BF
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0On Sun, Nov 8, 2020 at= 12:58 PM Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0<hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sun, = Nov 8, 2020 at 12:35 PM <otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mail= to:otroan@employe= es.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Hi Gyan,
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0> As we have had thus far and ongoing quite a bit of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0discussion on variable slaac can we add this to the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0agenda.=C2=A0 We can also expand the scope of discussion
>=C2=A0 =C2=A0 =C2=A0as to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0all use cases related to slaac longer prefix lengths and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0how it can be beneficial per the =E2=80=9CExtending a /64=E2=80=9D ne= w
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0thread.=C2=A0 I can start the discussion and we can take it
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0from there.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The "Extending a /64" thread (which I in hindsight
>=C2=A0 =C2=A0 =C2=A0see is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0poorly named) is not about longer prefix lengths.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0It is about exploring solutions to the problem of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0extending a network assigned with a single /64 with
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0multiple links.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 = =C2=A0 Gyan> Agreed but G-Extend the 64 bit boundary
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<chair-hat>Bob and I had a discussion with the chairs of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0v6ops, where we agreed to have the "what is the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0operational problem" discussion over in
>=C2=A0 =C2=A0 =C2=A0v6ops.</chair-hat>.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 = =C2=A0 Gyan> Sounds good.=C2=A0 Will have the draft authors join
>=C2=A0 =C2=A0 =C2=A0in on
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the disc= ussion.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Should I= put together a presentation for the discussion or
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0will it be ad-hoc.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Best regards,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Ole
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http:/= /www.verizon.com/ <http://www.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Gyan Mi= shra*
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Network= Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/M 301 5= 02-1347
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013101 Co= lumbia Pike
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/1310= 1+Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg <htt= ps://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry= =3Dgmail&source=3Dg>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/Silver = Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/1310= 1+Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg <htt= ps://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry= =3Dgmail&source=3Dg>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.c= om/ <http://www.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0*Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/Network Solutions A//= rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A013101 Columbia Pike >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/1310= 1+Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg <htt= ps://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry= =3Dgmail&source=3Dg>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/1310= 1+Columbia+Pike+Silver+Spring,+MD?entry=3Dgmail&source=3Dg <htt= ps://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry= =3Dgmail&source=3Dg>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ <http://ww= w.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > ---------------------------------------------= -----------------------
>=C2=A0 =C2=A0 =C2=A0 > IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0 > ipv6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > Administrative Requests:
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/l= istinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0 > ---------------------------------------------= -----------------------
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0= ipv6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://w= ww.ietf.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/l= istinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>
--
--000000000000a58da605b442797b-- From nobody Thu Nov 19 02:48:27 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590133A005D; Thu, 19 Nov 2020 02:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJMLFOME9dyz; Thu, 19 Nov 2020 02:48:18 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14F03A0045; Thu, 19 Nov 2020 02:48:18 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id m143so5801877oig.7; Thu, 19 Nov 2020 02:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pGNWkFYae1qTiPyvVV66IAP5WPPEXhwnMjgPELWIyxU=; b=jI4F4oWJkorYmqrT8uPwp3PKwQ8ZyTl2TY3B8QPfFYFgBweiFvnB/jHmBZ5V375gbD bP7ALwPsLA7fAmcYmwWjDSTkMs3ajiWxa/ZjPRg4w5q5Q4dD9S+eFzwyWEMDxkJWcpS+ cc16b2E2D3px+zuZMBJlpsAzpZ+IcTaOmqgFdQBE7eo7r3m3y/4A7L1BCBJ1bNYrkf2N bprDjGsrMezBOodTq0J1Buuya+2/V0SKEYt/lgik4Rz/L1iSyQo7YQdfvCPq2qu5dA3R lymely3XuqUsa9fdIlz3WE7bhu4FUNoSX0hYEJgTQfd5lOUoTsWmSVysiexET78543ns XrnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pGNWkFYae1qTiPyvVV66IAP5WPPEXhwnMjgPELWIyxU=; b=Wa7FMgQQ306A0B9NEpfILPpBYGHmEjosfNjQZ8w5ueh7vpJvG3+myou6671k4Kn5Mj Dm/hMF5vjsP0BFq5k6zhA6Rq1NKNFYm5TWMGrtuNDwnmqLQUqqhBnx9o71oZ0kY/QsTt 0KVYY4b+RKuO5KepX2vTDRVEj2vIcOJxfIjPI4IMyqfOTKCzBROi9Uw/ay5A4wS+u3Ae VgLrhgmyeloggsQxRZdlGgMp3tvIziYO3q+FgUELuef2jldLQPwpxxzfcpHJthA8tVN5 +zIMEzGHek9exCp6fdEwaIw/mwTI2FbEOdW1TIsdiBUs7EguXxMvAYgWqvStEegxuYmK KPOQ== X-Gm-Message-State: AOAM532edMDJdnaJ+ZNN1N/YoTNf31PdDUpTI7zQfqctb7aU7UftykN1 n2vNiTZfdc0C9Eu6BhHMeOIMP1LDSiG/B6lt1YP5D86nYdw= X-Google-Smtp-Source: ABdhPJyWdlgBLChqsWqrunfmFa6JmjU6LpUGzV6Nlm9W8mC2QJppj6qr1QHyAwufGHjbdf5p/Ma92g2SRY5OinzKjzQ= X-Received: by 2002:aca:c4c3:: with SMTP id u186mr2476326oif.4.1605782897451; Thu, 19 Nov 2020 02:48:17 -0800 (PST) MIME-Version: 1.0 From: Alexander Azimov Date: Thu, 19 Nov 2020 13:48:06 +0300 Message-ID: To: tcpm , v6ops@ietf.org Content-Type: multipart/alternative; boundary="00000000000030651505b473773b" Archived-At: Subject: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 10:48:20 -0000 --00000000000030651505b473773b Content-Type: text/plain; charset="UTF-8" Dear colleagues, I have added in the cc both v6op and tcpm for a reason and let me explain why. It's clear that we are moving forward with load balancing that uses flow label (FL). And the pressure will increase with SRv6 adoption. But at the moment wide adoption of FL-based load-balancing may create significant issues for TCP Anycast services. RFC6437 suggests putting hash from 5-tuple into FL value. And as far as I know, there is no document that updates this behavior. This description is perfectly fine, but what is implemented in the Linux kernel is different: FL is carrying hash from 5-tuple with an additional seed, and this seed is randomly changed after each RTO/SYN_RTO event. Here are related patches: - https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.mtv.corp.google.com/ - https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@herbertland.com/ - https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/ This is a great thing by the way because in the data center environment with multiple equal paths it gives a way to have pseudo-multipath TCP which jumps between paths in case of an outage. There might be interest to write down an informational document for this. But the problem happens when TCP flows start jumping between anycast points. If anycast service provides connection tracking (L7/TCP proxy, stateful L4 balancer) the 'jump' may redirect traffic to another point, and with the adoption of FL load balancing by the transit providers - to another location, where no TCP state is available. In other words, an established TCP session breaks after RTO event. And it's not just a theory - we already faced this kind of issue in our network, and it is really hard to debug. I wonder what you think is a proper solution: - Making FL related RTO change as knob instead of default behavior; - Adding negotiation behavior in TCP; - Something else? I'm looking forward to your advice. If there is a document that describes the above problem - please give me a reference. -- Best regards, Alexander Azimov --00000000000030651505b473773b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

I have added in t= he cc both v6op and tcpm for a reason and let me explain why.
It's clear that we are moving forward with load balancing t= hat uses flow label (FL). And the pressure will increase with SRv6 adoption= . But at the moment wide adoption of FL-based load-balancing may create sig= nificant issues for TCP Anycast services.

RFC6437 = suggests putting hash from=C2=A05-tuple into FL value. And as far as I know, there is no document= that updates this behavior. This description is perfectly fine, but what i= s implemented in the Linux kernel is different: FL is carrying=C2=A0hash=C2= =A0from 5-tuple with an additional seed, and this seed is randomly changed= =C2=A0after each RTO/SYN_RTO event. Here are related patches:
<= div>

This is a great thing by the way because in the data ce= nter=C2=A0environment=C2=A0with multiple equal paths=C2=A0it gives a way to have pseudo-mu= ltipath=C2=A0TCP which jumps between paths in case of an outage. There migh= t be interest to write down an informational document for this.

But th= e problem happens when TCP flows start jumping between anycast points. If a= nycast service provides connection tracking (L7/TCP proxy, stateful L4 bala= ncer) the 'jump' may redirect traffic to another point, and with th= e adoption of FL load balancing by the transit providers - to another locat= ion, where no TCP state is available. In other words, an established TCP se= ssion breaks after RTO event. And it's not just a theory - we already f= aced this kind of issue in our network, and it is really hard to debug.

I wonder what you think is a proper solution:
  • Making FL related RTO change as knob instead of default behavior;
  • A= dding negotiation=C2=A0behavior in TCP;
  • Something else?
I'm l= ooking forward to your advice. If there is a document that describes the ab= ove problem - please give me a reference.

= --
Best regards,
Alexander Azimov
--00000000000030651505b473773b-- From nobody Thu Nov 19 04:25:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202423A0CE0; Thu, 19 Nov 2020 04:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24XeAmZQR6id; Thu, 19 Nov 2020 04:25:11 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BA93A0CD4; Thu, 19 Nov 2020 04:25:11 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id 34so4062219pgp.10; Thu, 19 Nov 2020 04:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YYFFTfygXQbItDvFXeoGKf9VrZmim53goekYHvAlF6E=; b=kYXlm62gONjZPYLyqX646R7kl60qRacTK8Ds6srfcRC0Mt2GWAm7dL4D9TeJkc9Gey gjyYIH0NWVnJNxywBwsGakaS4a0s5uGF+RV3QvKVE45qgbOYXLXncQgugMv2Arq++ulm vNXdVpH0omyLsLKgPaqYWrwu95R3o8dXKiTHu9dTFw8h2SrgfK1nBDz6hh/y/sldRGqq Ac3iSWi4sRRD8c5vH8x/LH/uVs6I6yfMpkZBbVnCKBBQWgNFnGazYoQHUhMoi2HMC0O4 suQ50y1PT043r28Lbv4zPJ/V1VDGv9Q6TjTvdyYVVyreFGC8Zcx9LCK9Nl8PY13dwpYV TjsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YYFFTfygXQbItDvFXeoGKf9VrZmim53goekYHvAlF6E=; b=ubZhmIs/YXbfAdoZ7hLDQl/a/DnXLj7cN1RBY9Szmv9oWN8YzEPrM9e+q5BZTE34A8 oe81+RLWXhET0y8aHDDqq8T+oMfhtJXZWa+8M7aXiNqXJ5bLGPRF4oqXnTOROqUIK+Gy LF56fwzyfRRoUbRXTzB9n7kj+j7X4RBn8yftNlRAf/UbEomMeJrAD/ezjqo/xzCnb2Yv 1MEldZ3OeO2B0ZkCYk3UMNMZRRbmYNzrOJ0rgjX+G6fR4nhzIqBdopmc4KVlLPiyi3cI duhb14KZ9ARVxjRpf0e+DHmplLt3vmCsu6QFYB/l0NMArK2FtGmKNq7HsA7NKSMRlsJn cA7w== X-Gm-Message-State: AOAM532gzEoNpRQIBLjdRRrNgygXlvSkSeyAxSxPEBXqP8ekbbmr+dTQ 8ED/ldZtLbqzdvPcnw2CJCpUg2GvlGPoYsAaP44l2afVCsFxRw== X-Google-Smtp-Source: ABdhPJxSEMPU7g7GRwah2ATWuJNJIR2Ops2EvHQF2Zv1oWZ9rUqHHVrOV9AvsHFmfMUL8jcHNz4YmtKG48bzPGeb/U0= X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr4280846pjx.112.1605788710047; Thu, 19 Nov 2020 04:25:10 -0800 (PST) MIME-Version: 1.0 From: Gyan Mishra Date: Thu, 19 Nov 2020 07:18:35 -0500 Message-ID: To: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000a590dd05b474d1eb" Archived-At: Subject: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 12:25:21 -0000 --000000000000a590dd05b474d1eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable v6ops preso - "race to bottom slide" slightly modified - new proposal for new /80 bottom so that we could actually make multiple /48s I mean /64s actually wearable. A /64 would be the new /48 as we shifted the IID by 16 bits shorter & making the prefix 16 bits longer. /64 =3D current Bottom fixed based on 64 bit IID. /48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot do= le out shorter prefixes via 64share v2 even that Cameron proposed. Also with the RA PD style trickery w/o A bit set as Lorenzo mentioned the host would not accept the shorter prefix as it is expecting a 64 bit prefix from the 3GPP gateway. Why /48's wearable is not possible today for 2 reasons: 1. Large providers such as Verizon subscribers =3D 150M not including broadband and /24 equates to 16M /48 way short and /20 even 160M but large providers as Verizon's of the world need to scale to 1B or 7B. 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, RFC 4291 would have to change the 64 bit fixed boundary requirement for any handset to accept shorter prefix. So we are stuck and 64 share v2 is not possible w/o RFC 4291 changing. What if we made the new fixed bottom a /80 meaning. So that would essentially be the new bottom that ISPs cannot race any further since the standard would be fixed at the new /80 bottom just as its fixed at the /64 bottom. We just gave ourselves 16 bits to play with. 64 share v2 - Allocate /64 as it does today and that would basically be equivalent to a /48 allocation. Nice! */80 =3D New bottom =3D> Problem solved * */64 =3D 64k /80s - wearable - so now both 3GPP and broadband providers problem solved for segmentation* */64 Current bottom* */48 =3D 64k /64s* As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes up to /80. I think while we are changing RFC 4291 I think it would make sense to allow for shorter prefixes maybe to any length or fix a a value that makes sense for shorter then /64. So in the future if 3GPP can be updated for shorter prefixes we could give out shorter as well which would be a ton of prefixes. However, I think if we made the new bottom a /80, in reality the end site allocation would be equivalent to a /48 so would not have to allow slaac really to allow for shorter then /64. Although as they say - never say never.."when you build - they will come" SLAAC would use random IID generation schemes to generate the shorter 48 bit IID via RFC 4941 or stable IID RFC 7217. >From a privacy perspective for broadband users we would still have 48 bit IID which in the scheme of things as the double edged sword for operators & law enforcement scanning I think the address correlation attacks I think the 48 bits random IID for privacy extension, I think we would be in good shape. This also solves the day 1 VLSM issue as well for mixed host static, dhcpv6 & slaac as now we can have longer prefixes up to /80. This may solve some of the aviation issues that Fred Templin is working on as well. Also with Network Slicing to be mainstream with 5G and proliferation of IoT devices I can see end user allocations growing very quickly AND =3D "NO RACE TO BOTTOM" possible even as we would fix the new boundary at "/80" as the new bottom so you cannot race down any further. Would be no different then the /64 boundary but now getting a 16 bit bonus out of the deal. IANA now does not have to dig into unallocating more ::/3s for larger allocations - see Slide 10 from v6ops preso below Slide 10 in v6 ops preso One of the reasons why 6MAN has deferred removing the 64 bit boundary is due to the ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at th= e bottom giving out /64 to mobile handsets that ISP=E2=80=99s will in theory do what histor= y has shown us what was done with IPv4 where due to address depletion issues and issues with overlapping address space ISP=E2=80=99s made the broadband stan= dard to dole out /32 WAN IP which is NAT port overloaded outside wan interface. NAT as well as CGNAT have solved issues with IPv4 shortage and overlapping ranges allowing overlapping ranges to co-exist with NAT as well as now ISP=E2=80=99s due to the risk of IPv4 address depletion made the standard a= /32 WAN IP with NAT port overloaded via PAT (Port Address translation) with private 192.168.1.0/24 subnet for SOHO hosts. IPv6 on the other hand does not have any risk of address depletion so you cannot compare what history has told us with IPv4 to IPv6 and there is no other data point to be had. On the other side of the spectrum with 64share we are looking now at shorter prefixes and maybe an idea of creating and RFC 6177bis that allows a /48 per human per mobile device. Is that possible ??? https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtm= l 2000::/3 GUI IAIA <=3D>RIR <=3D> ISP <=3D> End user Allocation RIR allocations to Service Providers: For the massive block allocations for ISPs is it tiered like this /32 - General Starting point for ISP allocation /24-26 - Medium to Large /19-20 - Exceptions and rare Since allocations are done blockwize and not linearly you have to account for future growth so generally over allocate for growth next 20 years. So with that the much larger allocations. With that being said let's say for a typical large ISP /24 - that would yield 16M /48s. That still is small since most large ISPs like, we Verizon we want to scale to a billion as right now we have 150M and that's just domestic not worldwide. Safe best for large ISPs is we want to scale to the number of humans on the planet so 7 Billion is a good number. Also that does not account for broadband. So for Verizon as an example /48 per human is not possible. I think /48 per user site is sensible for the much smaller ISPS with few million subscriber base but I think an impossibility at least for the larger Verizon size ISP=E2=80=99s. Looking on IAIA allocation link I don't= see too many RIRs getting a /12. *https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-uni= cast-address-assignments.xhtml * *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a590dd05b474d1eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

v6ops preso - "race to = bottom slide" slightly modified - new proposal for new /80 bottom so t= hat we could actually make multiple /48s I mean /64s actually wearable.=C2= =A0 =C2=A0

A /64 would be th= e new /48 as we shifted the IID by 16 bits shorter & making the prefix = 16 bits longer.


/64 =3D current Bottom fixed based= on 64 bit IID.

/48= =3D 64k /64s - Due to current 3GPP architecture limitation we cannot dole = out shorter prefixes=C2=A0via 64share v2 even that Cameron proposed.=C2=A0 = Also with the RA PD style trickery w/o A bit set as Lorenzo mentioned the h= ost would not accept the shorter prefix as it is expecting a 64 bit prefix = from the 3GPP gateway.


Why /48's wearable is not poss= ible today for 2 reasons:

1. Large providers such as Verizon subscribers =3D 150M not includin= g broadband and /24 equates to 16M /48 way short and /20 even 160M but larg= e providers as Verizon's of the world need to scale to 1B or 7B.=

2. 64share v2 even if 3GP= P arch allowed shorter prefixes /56 or even /48, RFC 4291 would have=C2=A0t= o change the 64 bit fixed boundary requirement=C2=A0for any handset to acce= pt shorter prefix.=C2=A0 So we are stuck and 64 share v2 is not possible w/= o RFC 4291 changing.


What if we m= ade the new fixed bottom a /80 meaning.=C2=A0 So that would essentially be = the new bottom that ISPs cannot race any further since the standard would b= e fixed at the new /80 bottom just as its fixed at the /64 bottom.=C2=A0 We= just gave ourselves 16 bits to play with.


64 share v2 - = Allocate /64 as it does today and that would basically be equivalent to a /= 48 allocation. Nice!

/80 =3D New bottom =3D> Problem solved=C2=A0

/64 =3D 64= k /80s - wearable - so now both 3GPP and broadband=C2=A0 providers problem = solved for segmentation

<= font size=3D"4" color=3D"#ff0000">/64 Current bottom

/48 =3D 64k /= 64s

As far as S= LAAC goes we would modify RFC 4291 to allow for longer prefixes up to /80.= =C2=A0 I think while we are changing RFC 4291 I think it would make sense t= o allow for shorter prefixes maybe to any length or fix a a value that make= s sense for shorter then /64.=C2=A0 So in the future if 3GPP can be updated= for shorter prefixes we could give out shorter as well which would be a to= n of prefixes.=C2=A0=C2=A0

However, I think if we made the new bottom a /80, in reality the=C2= =A0end site allocation would be equivalent to a /48 so would not have to al= low slaac really to allow for shorter then /64.=C2=A0=C2=A0


Although as they say - never say never.."wh= en you build - they will come"

=

SLAAC would use rando= m IID generation schemes to generate the shorter 48 bit IID via RFC 4941 or= stable IID RFC 7217.


From a priv= acy perspective for broadband users we would still have 48 bit IID which in= the scheme of things as the double edged sword for operators & law enf= orcement scanning I think the address correlation attacks I think the 48 bi= ts random IID for privacy extension, I think we would=C2=A0be in good shape= .=C2=A0


This also solves the day 1 VLSM issue as well for= mixed host static, dhcpv6 & slaac as now we can have longer prefixes u= p=C2=A0 to /80.=C2=A0 =C2=A0


This= may solve some of the aviation issues that Fred Templin is working on as w= ell.=C2=A0=C2=A0

Also with Networ= k Slicing to be mainstream with 5G=C2=A0 and proliferation of IoT devices I= can see end user allocations growing very quickly


AND =3D "NO RACE TO BOTTOM" possible even=C2=A0= as we would fix the new boundary at "/80" as the new bottom so y= ou cannot race down any further. Would be no different then the /64 boundar= y but now getting a 16 bit bonus out of the deal.=C2=A0


= IANA now does not have to dig into unallocating more ::/3s for larger alloc= ations - see Slide 10 from v6ops preso below


Slid= e 10 in v6 ops preso

One of = the reasons why 6MAN has deferred removing the 64 bit boundary is due to the=C2=A0 ISP =E2=80=9Crace to the bottom=E2=80=9D f= ear that we are at the bottom giving out /64 to mobile handsets that ISP=E2=80=99s will in the= ory do what history has shown us what was done with IPv4 where due to address depletion issues and issues with overlapping address space ISP=E2=80=99s made the bro= adband standard to dole out /32 WAN IP which is NAT port overloaded outside wan interface.=C2=A0 NAT as well as CGNAT have solved issues with IPv4 shortage= and overlapping ranges allowing overlapping ranges to co-exist with NAT as well= as now ISP=E2=80=99s due to the risk of IPv4 address depletion made the standa= rd a /32 WAN IP with NAT port overloaded via PAT (Port Address translation) with private 192.168.1.0/24 subnet for SOHO hosts.= =C2=A0 =

IPv6 on the other hand does not have any risk= of address depletion so you cannot compare what history has told us with IPv4 to IPv6 = and there is no other data point to be had.

On the other side of the spectrum with 64shar= e we are looking now at shorter prefixes and maybe an idea of creating and RFC 6177b= is that allows a /48 per human per mobile device.=C2=A0 Is that possible ??? <= /span>

https://www.iana.org/assignment= s/ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=3D>RIR <=3D> I= SP <=3D> End user Allocation

RIR allocations to Service Provid= ers:

=C2=A0

For the massive block allocations= for ISPs is it tiered like this

/32 - General Starting point for = ISP allocation

/24-26 - Medium to Large=C2=A0=

/19-20 - Exceptions and rare

=C2=A0

Since allocations are done blockw= ize and not linearly you have to account for future growth so generally over allocate for growth next 20 years.=C2=A0 So with that the much larger allocations.

=C2=A0

With that being said let's sa= y for a typical large ISP /24 - that would yield 16M /48s.=C2=A0 That still is small since most large ISPs like, we Verizon we want to scale to a billion as right now we have 150M and that= 9;s just domestic not worldwide.=C2=A0 Safe best for large ISPs is we want to scale = to the number of humans on the planet so 7 Billion is a good number.=C2=A0 Als= o that does not account for broadband.=C2=A0 So for Verizon as an example /48=C2=A0 per human is not possible.=C2=A0

=C2=A0

I think /48 per user site is sens= ible for the much smaller ISPS with few million subscriber base=C2=A0 but I think an impossibility=C2=A0at leas= t for the larger Verizon size ISP=E2=80=99s.=C2=A0 Looking on IAIA allocation link I don't see too many RIRs getting a /12.=

https://ww= w.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-addres= s-assignments.xhtml

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


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver S= pring, MD


--000000000000a590dd05b474d1eb-- From nobody Thu Nov 19 05:01:14 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A223A0E15; Thu, 19 Nov 2020 05:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 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, MIME_QP_LONG_LINE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGR74TVirei5; Thu, 19 Nov 2020 05:01:04 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2234A3A0E01; Thu, 19 Nov 2020 05:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1605790861; x=1606395661; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=WYyU/BJFsmL5YtvmvUE6ZBrG53S+maLH1Z psoBsEg4c=; b=tZCwEfTqfKxa5V6RyWh0HPH/kN/TCJZnnFsdgufucwOvkqbahE ELRuvsHe6aevXjbHdTmzE737g13QXGza2WpT7fKfn1NnoO30H43pOmsz7Hk82iCY g3Wy3/1/xBGEtVhlG4/XPcv8d4GtMsDzWB6c9ykkUwJY977CcPN9bqQwY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 19 Nov 2020 14:01:01 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 19 Nov 2020 14:00:59 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000467881.msg; Thu, 19 Nov 2020 14:00:58 +0100 X-MDRemoteIP: 2001:470:1f09:495:396c:2d31:407e:931b X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 19 Nov 2020 14:00:58 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=15925babf5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Thu, 19 Nov 2020 14:00:57 +0100 From: JORDI PALET MARTINEZ To: 6MAN <6man@ietf.org>, IPv6 Operations Message-ID: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> Thread-Topic: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688639257_1047896013" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:01:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688639257_1047896013 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The right way to resolve this is very simple. =20 Go to your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for eac= h of my subscribers, so I need a subsequent allocation, following the secti= on 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy Man= ual, and this is my justification =E2=80=A6=E2=80=9D. =20 Done! =20 https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocations-= to-lirs =20 Regards, Jordi @jordipalet =20 =20 =20 El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" escribi=C3=B3: =20 v6ops preso - "race to bottom slide" slightly modified - new proposal for n= ew /80 bottom so that we could actually make multiple /48s I mean /64s actu= ally wearable. =20 A /64 would be the new /48 as we shifted the IID by 16 bits shorter & makin= g the prefix 16 bits longer. =20 /64 =3D current Bottom fixed based on 64 bit IID. /48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot do= le out shorter prefixes via 64share v2 even that Cameron proposed. Also wi= th the RA PD style trickery w/o A bit set as Lorenzo mentioned the host wou= ld not accept the shorter prefix as it is expecting a 64 bit prefix from th= e 3GPP gateway. =20 Why /48's wearable is not possible today for 2 reasons: 1. Large providers such as Verizon subscribers =3D 150M not including broad= band and /24 equates to 16M /48 way short and /20 even 160M but large provi= ders as Verizon's of the world need to scale to 1B or 7B. 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, R= FC 4291 would have to change the 64 bit fixed boundary requirement for any = handset to accept shorter prefix. So we are stuck and 64 share v2 is not p= ossible w/o RFC 4291 changing. =20 What if we made the new fixed bottom a /80 meaning. So that would essentia= lly be the new bottom that ISPs cannot race any further since the standard = would be fixed at the new /80 bottom just as its fixed at the /64 bottom. = We just gave ourselves 16 bits to play with. =20 64 share v2 - Allocate /64 as it does today and that would basically be equ= ivalent to a /48 allocation. Nice! /80 =3D New bottom =3D> Problem solved=20 /64 =3D 64k /80s - wearable - so now both 3GPP and broadband providers pro= blem solved for segmentation /64 Current bottom /48 =3D 64k /64s As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes = up to /80. I think while we are changing RFC 4291 I think it would make se= nse to allow for shorter prefixes maybe to any length or fix a a value that= makes sense for shorter then /64. So in the future if 3GPP can be updated= for shorter prefixes we could give out shorter as well which would be a to= n of prefixes. =20 However, I think if we made the new bottom a /80, in reality the end site a= llocation would be equivalent to a /48 so would not have to allow slaac rea= lly to allow for shorter then /64. =20 =20 Although as they say - never say never.."when you build - they will come" =20 SLAAC would use random IID generation schemes to generate the shorter 48 bi= t IID via RFC 4941 or stable IID RFC 7217. =20 >From a privacy perspective for broadband users we would still have 48 bit I= ID which in the scheme of things as the double edged sword for operators & = law enforcement scanning I think the address correlation attacks I think th= e 48 bits random IID for privacy extension, I think we would be in good sha= pe.=20 =20 This also solves the day 1 VLSM issue as well for mixed host static, dhcpv6= & slaac as now we can have longer prefixes up to /80. =20 =20 This may solve some of the aviation issues that Fred Templin is working on = as well. =20 =20 Also with Network Slicing to be mainstream with 5G and proliferation of Io= T devices I can see end user allocations growing very quickly =20 AND =3D "NO RACE TO BOTTOM" possible even as we would fix the new boundary= at "/80" as the new bottom so you cannot race down any further. Would be n= o different then the /64 boundary but now getting a 16 bit bonus out of the= deal.=20 =20 IANA now does not have to dig into unallocating more ::/3s for larger alloc= ations - see Slide 10 from v6ops preso below =20 Slide 10 in v6 ops preso One of the reasons why 6MAN has deferred removing the 64 bit boundary is du= e to the ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at the = bottom giving out /64 to mobile handsets that ISP=E2=80=99s will in theory = do what history has shown us what was done with IPv4 where due to address d= epletion issues and issues with overlapping address space ISP=E2=80=99s mad= e the broadband standard to dole out /32 WAN IP which is NAT port overloade= d outside wan interface. NAT as well as CGNAT have solved issues with IPv4= shortage and overlapping ranges allowing overlapping ranges to co-exist wi= th NAT as well as now ISP=E2=80=99s due to the risk of IPv4 address depleti= on made the standard a /32 WAN IP with NAT port overloaded via PAT (Port Ad= dress translation) with private 192.168.1.0/24 subnet for SOHO hosts. =20 IPv6 on the other hand does not have any risk of address depletion so you c= annot compare what history has told us with IPv4 to IPv6 and there is no ot= her data point to be had.=20 On the other side of the spectrum with 64share we are looking now at shorte= r prefixes and maybe an idea of creating and RFC 6177bis that allows a /48 = per human per mobile device. Is that possible ???=20 https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtm= l 2000::/3 GUI=20 IAIA <=3D>RIR <=3D> ISP <=3D> End user Allocation RIR allocations to Service Providers:=20 =20 For the massive block allocations for ISPs is it tiered like this /32 - General Starting point for ISP allocation /24-26 - Medium to Large=20 /19-20 - Exceptions and rare =20 Since allocations are done blockwize and not linearly you have to account f= or future growth so generally over allocate for growth next 20 years. So w= ith that the much larger allocations. =20 With that being said let's say for a typical large ISP /24 - that would yie= ld 16M /48s. That still is small since most large ISPs like, we Verizon we= want to scale to a billion as right now we have 150M and that's just domes= tic not worldwide. Safe best for large ISPs is we want to scale to the num= ber of humans on the planet so 7 Billion is a good number. Also that does = not account for broadband. So for Verizon as an example /48 per human is = not possible.=20 =20 I think /48 per user site is sensible for the much smaller ISPS with few mi= llion subscriber base but I think an impossibility at least for the larger= Verizon size ISP=E2=80=99s. Looking on IAIA allocation link I don't see t= oo many RIRs getting a /12. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic= ast-address-assignments.xhtml =20 =20 =20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3688639257_1047896013 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The right way to resolve this is very simple.<= /p>

 

Go to = your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for each of m= y subscribers, so I need a subsequent allocation, following the section 6.5= .3. (Subsequent Allocation to LIRs) of the Number Resource Policy Manual, a= nd this is my justification =E2=80=A6=E2=80=9D.

 

Done!

 

 

 

El 19/11/20 13:26, "v6ops en nombre de Gyan Mishr= a" <v6ops-bounces@ietf.or= g en nombre de hayabusagsm@gma= il.com> escribi=C3=B3:

 

v6ops preso - "race to bottom slide" slightly modified - new = proposal for new /80 bottom so that we could actually make multiple /48s I = mean /64s actually wearable.   

A /64 would be th= e new /48 as we shifted the IID by 16 bits shorter & making the prefix = 16 bits longer.<= o:p>

 

/64 =3D current Bottom fixed based on 64 bit I= ID.

/48 =3D 64k = /64s - Due to current 3GPP architecture limitation we cannot dole out short= er prefixes via 64share v2 even that Cameron proposed.  Also with= the RA PD style trickery w/o A bit set as Lorenzo mentioned the host would= not accept the shorter prefix as it is expecting a 64 bit prefix from the = 3GPP gateway.

 

Why /48's wearable is not possible today for 2 r= easons:

1. Large providers such as = Verizon subscribers =3D 150M not including broadband and /24 equates to 16M= /48 way short and /20 even 160M but large providers as Verizon's of the wo= rld need to scale to 1B or 7B.

2. 6= 4share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, RFC 4= 291 would have to change the 64 bit fixed boundary requirement fo= r any handset to accept shorter prefix.  So we are stuck and 64 share = v2 is not possible w/o RFC 4291 changing.

 = ;

What if we made the ne= w fixed bottom a /80 meaning.  So that would essentially be the new bo= ttom that ISPs cannot race any further since the standard would be fixed at= the new /80 bottom just as its fixed at the /64 bottom.  We just gave= ourselves 16 bits to play with.

 

64 share v2 - Allocate /64 as i= t does today and that would basically be equivalent to a /48 allocation. Ni= ce!

/80 =3D New bottom =3D> P= roblem solved 

/64 =3D 64k /80s - wearable - so now both 3GPP and broadb= and  providers problem solved for segmentation

/64 Current bottom

As far as SL= AAC goes we would modify RFC 4291 to allow for longer prefixes up to /80.&n= bsp; I think while we are changing RFC 4291 I think it would make sense to = allow for shorter prefixes maybe to any length or fix a a value that makes = sense for shorter then /64.  So in the future if 3GPP can be updated f= or shorter prefixes we could give out shorter as well which would be a ton = of prefixes.  

However, I= think if we made the new bottom a /80, in reality the end site alloca= tion would be equivalent to a /48 so would not have to allow slaac really t= o allow for shorter then /64.  

 = ;

Although as they say -= never say never.."when you build - they will come"

 

SL= AAC would use random IID generation schemes to generate the shorter 48 bit = IID via RFC 4941 or stable IID RFC 7217.

 =

From a privacy perspect= ive for broadband users we would still have 48 bit IID which in the scheme = of things as the double edged sword for operators & law enforcement sca= nning I think the address correlation attacks I think the 48 bits random II= D for privacy extension, I think we would be in good shape. 

 

This also solves the day 1 VLSM issue as well for mixed host static,= dhcpv6 & slaac as now we can have longer prefixes up  to /80.&nbs= p;  

 

This may so= lve some of the aviation issues that Fred Templin is working on as well.&nb= sp; 

 

Also with Network Slicing to be mainstream with 5G&nbs= p; and proliferation of IoT devices I can see end user allocations growing = very quickly

 

AND =3D "NO RACE TO BOTTOM" possible even=   as we would fix the new boundary at "/80" as the new botto= m so you cannot race down any further. Would be no different then the /64 b= oundary but now getting a 16 bit bonus out of the deal. 

 

IA= NA now does not have to dig into unallocating more ::/3s for larger allocat= ions - see Slide 10 from v6ops preso below

&nbs= p;

Slide 10 in v6 ops preso

One = of the reasons why 6MAN has deferred removing the 64 bit boundary is due to= the  ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at the= bottom giving out /64 to mobile handsets that ISP=E2=80=99s will in theory= do what history has shown us what was done with IPv4 where due to address = depletion issues and issues with overlapping address space ISP=E2=80=99s ma= de the broadband standard to dole out /32 WAN IP which is NAT port overload= ed outside wan interface.  NAT as well as CGNAT have solved issues wit= h IPv4 shortage and overlapping ranges allowing overlapping ranges to co-ex= ist with NAT as well as now ISP=E2=80=99s due to the risk of IPv4 address d= epletion made the standard a /32 WAN IP with NAT port overloaded via PAT (P= ort Address translation) with private 192= .168.1.0/24 subnet for SOHO hosts. 

IPv6 on the other hand does not have any risk of address depletion so y= ou cannot compare what history has told us with IPv4 to IPv6 and there is n= o other data point to be had.

On the other side of the spe= ctrum with 64share we are looking now at shorter prefixes and maybe an idea= of creating and RFC 6177bis that allows a /48 per human per mobile device.=   Is that possible ???

= https://www.iana= .org/assignments/ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=3D>RIR= <=3D> ISP <=3D> End user Allocation

RIR allocations to Service Providers:

 =

For the massive block = allocations for ISPs is it tiered like this

/32 - General Starting point for ISP allocation

/24-26 - Medium to Large 

/19-20 - Exceptions and rare

&nbs= p;

Since allocations are done blockwize= and not linearly you have to account for future growth so generally over a= llocate for growth next 20 years.  So with that the much larger alloca= tions.

 = ;

With that being said let's say for a= typical large ISP /24 - that would yield 16M /48s.  That still is sma= ll since most large ISPs like, we Verizon we want to scale to a billion as = right now we have 150M and that's just domestic not worldwide.  Safe b= est for large ISPs is we want to scale to the number of humans on the plane= t so 7 Billion is a good number.  Also that does not account for broad= band.  So for Verizon as an example /48  per human is not possibl= e. 

 

I think /48 per user site is sensible for the much smaller ISP= S with few million subscriber base  but I think an impossibility = at least for the larger Verizon size ISP=E2=80=99s.  Looking on IAIA allocation link I don't see too many RIRs= getting a /12.<= o:p>

 

Gyan Mishra

Network Solutions Architect 

M 301 5= 02-1347
13101 Columbia Pike 
Silver Spring, MD

 

<= /div>

_______________________________________________ v6ops mailing l= ist v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= /p>


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3688639257_1047896013-- From nobody Thu Nov 19 05:38:53 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEE93A0EF6; Thu, 19 Nov 2020 05:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmtDJ0A485-R; Thu, 19 Nov 2020 05:38:48 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABC13A0F3D; Thu, 19 Nov 2020 05:38:48 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id bj5so2136349plb.4; Thu, 19 Nov 2020 05:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U7J4CUgOPlhjtPlC/sqMbN2JdSC8lJEr8MRFALoYnvA=; b=MSF5z25Derh77YIVL84gMqsjRzoypi/4p31cV0RAvNbyS5u/NTJQqj0B+kfcCdHGyo Odyek74E9yD/7u1EIg9NeAtk5jhgvGD3kwTmc7+3injxhYcNSpXbCYaAe3pYENc1xa1v 0ygPasZJLwWUqsdLq15icmdtZG6AeTxJ3lxybCnIysUymzSH3qpyvAVsvCZ9PZmFJes0 2p151nGSNKyaB900n81mSVnQB/I7kTZ7r3+aTi2CcZYjbpeXLmOlF4k2zda+EKrAE8xV Uzne6//PhtA9B8GprqJD9S6PVRuaT/2ew19Va1tbP+tgSD/9I0wwhDT3VLrU3OqJ28JO XXRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U7J4CUgOPlhjtPlC/sqMbN2JdSC8lJEr8MRFALoYnvA=; b=CWFIuMy78WzaAJc1IlXOtmh9JtPYnhdZ8ZXjdccF0yk6QIJp6nLcGIoUFvzlRQYxGP XlWRwa4L+tWDTm3rb8KxcB65Uxj6CL5bfGydK0txTag5sIFDLgQvDJ+Rrk3Y2dzsSkXM a5qMIEGPj0g9Zxum5m8QQxMuqTi+3ij0WDaMU0UqMZJWsCKu9pj76b3QdtpAn8a+3zeH fK94QwhNkBl2QX9M6UKmUhGvFW2tt294ObhnNlUZK4wvQ7NIDHPL4yXpq2TlsvZ1apxl ahr1h0U+3lTdRFTTRC6pGN+oMXeH/OSuqy3CC+opzrt2IFv+pIDXm4YKEF/OqhnKJ6er FmFw== X-Gm-Message-State: AOAM5330TuENqdeH9MHVJ1pAbMDpsveF+t3eWd9gpkncRI6GsDAFtjoE XCMdr6/ApnjYRKN7m6kklH5KmW2HnxsUP+/WJSVSD9aEwvs= X-Google-Smtp-Source: ABdhPJwchvpTGeuc4/QMwDmflJvXFJW+xhFQcfF1YekzoA6f9ojjKQKPeiSic7jzgCLpDEP2NsT6SMLECjE0cIf2ERk= X-Received: by 2002:a17:902:c395:b029:d7:cdcd:76bc with SMTP id g21-20020a170902c395b02900d7cdcd76bcmr8349163plg.50.1605793127698; Thu, 19 Nov 2020 05:38:47 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> In-Reply-To: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> From: Gyan Mishra Date: Thu, 19 Nov 2020 08:38:36 -0500 Message-ID: To: JORDI PALET MARTINEZ Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000f5971d05b475d8e9" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:38:51 -0000 --000000000000f5971d05b475d8e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jordi! That solves one problem but does not solve the 64share v2 issue as we have to still modify RFC 4861 for mobile to accept shorter prefix. Thanks Gyan On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ wrote: > The right way to resolve this is very simple. > > > > Go to your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for e= ach of my > subscribers, so I need a subsequent allocation, following the section > 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy > Manual, and this is my justification =E2=80=A6=E2=80=9D. > > > > Done! > > > > > https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocation= s-to-lirs > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" < > v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.com> escribi=C3=B3: > > > > v6ops preso - "race to bottom slide" slightly modified - new proposal for > new /80 bottom so that we could actually make multiple /48s I mean /64s > actually wearable. > > A /64 would be the new /48 as we shifted the IID by 16 bits shorter & > making the prefix 16 bits longer. > > > > /64 =3D current Bottom fixed based on 64 bit IID. > > /48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot > dole out shorter prefixes via 64share v2 even that Cameron proposed. Als= o > with the RA PD style trickery w/o A bit set as Lorenzo mentioned the host > would not accept the shorter prefix as it is expecting a 64 bit prefix fr= om > the 3GPP gateway. > > > > Why /48's wearable is not possible today for 2 reasons: > > 1. Large providers such as Verizon subscribers =3D 150M not including > broadband and /24 equates to 16M /48 way short and /20 even 160M but larg= e > providers as Verizon's of the world need to scale to 1B or 7B. > > 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, > RFC 4291 would have to change the 64 bit fixed boundary requirement for a= ny > handset to accept shorter prefix. So we are stuck and 64 share v2 is not > possible w/o RFC 4291 changing. > > > > What if we made the new fixed bottom a /80 meaning. So that would > essentially be the new bottom that ISPs cannot race any further since the > standard would be fixed at the new /80 bottom just as its fixed at the /6= 4 > bottom. We just gave ourselves 16 bits to play with. > > > > 64 share v2 - Allocate /64 as it does today and that would basically be > equivalent to a /48 allocation. Nice! > > */80 =3D New bottom =3D> Problem solved * > > */64 =3D 64k /80s - wearable - so now both 3GPP and broadband providers > problem solved for segmentation* > > */64 Current bottom* > > */48 =3D 64k /64s* > > As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixe= s > up to /80. I think while we are changing RFC 4291 I think it would make > sense to allow for shorter prefixes maybe to any length or fix a a value > that makes sense for shorter then /64. So in the future if 3GPP can be > updated for shorter prefixes we could give out shorter as well which woul= d > be a ton of prefixes. > > However, I think if we made the new bottom a /80, in reality the end site > allocation would be equivalent to a /48 so would not have to allow slaac > really to allow for shorter then /64. > > > > Although as they say - never say never.."when you build - they will come" > > > > SLAAC would use random IID generation schemes to generate the shorter 48 > bit IID via RFC 4941 or stable IID RFC 7217. > > > > From a privacy perspective for broadband users we would still have 48 bit > IID which in the scheme of things as the double edged sword for operators= & > law enforcement scanning I think the address correlation attacks I think > the 48 bits random IID for privacy extension, I think we would be in good > shape. > > > > This also solves the day 1 VLSM issue as well for mixed host static, > dhcpv6 & slaac as now we can have longer prefixes up to /80. > > > > This may solve some of the aviation issues that Fred Templin is working o= n > as well. > > > > Also with Network Slicing to be mainstream with 5G and proliferation of > IoT devices I can see end user allocations growing very quickly > > > > AND =3D "NO RACE TO BOTTOM" possible even as we would fix the new bounda= ry > at "/80" as the new bottom so you cannot race down any further. Would be = no > different then the /64 boundary but now getting a 16 bit bonus out of the > deal. > > > > IANA now does not have to dig into unallocating more ::/3s for larger > allocations - see Slide 10 from v6ops preso below > > > > Slide 10 in v6 ops preso > > One of the reasons why 6MAN has deferred removing the 64 bit boundary is > due to the ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at = the bottom giving > out /64 to mobile handsets that ISP=E2=80=99s will in theory do what hist= ory has > shown us what was done with IPv4 where due to address depletion issues an= d > issues with overlapping address space ISP=E2=80=99s made the broadband st= andard to > dole out /32 WAN IP which is NAT port overloaded outside wan interface. > NAT as well as CGNAT have solved issues with IPv4 shortage and overlappin= g > ranges allowing overlapping ranges to co-exist with NAT as well as now > ISP=E2=80=99s due to the risk of IPv4 address depletion made the standard= a /32 WAN > IP with NAT port overloaded via PAT (Port Address translation) with priva= te > 192.168.1.0/24 subnet for SOHO hosts. > > IPv6 on the other hand does not have any risk of address depletion so you > cannot compare what history has told us with IPv4 to IPv6 and there is no > other data point to be had. > > On the other side of the spectrum with 64share we are looking now at > shorter prefixes and maybe an idea of creating and RFC 6177bis that allow= s > a /48 per human per mobile device. Is that possible ??? > > > https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xh= tml > > 2000::/3 GUI > > IAIA <=3D>RIR <=3D> ISP <=3D> End user Allocation > > RIR allocations to Service Providers: > > > > For the massive block allocations for ISPs is it tiered like this > > /32 - General Starting point for ISP allocation > > /24-26 - Medium to Large > > /19-20 - Exceptions and rare > > > > Since allocations are done blockwize and not linearly you have to account > for future growth so generally over allocate for growth next 20 years. S= o > with that the much larger allocations. > > > > With that being said let's say for a typical large ISP /24 - that would > yield 16M /48s. That still is small since most large ISPs like, we Veriz= on > we want to scale to a billion as right now we have 150M and that's just > domestic not worldwide. Safe best for large ISPs is we want to scale to > the number of humans on the planet so 7 Billion is a good number. Also > that does not account for broadband. So for Verizon as an example /48 p= er > human is not possible. > > > > I think /48 per user site is sensible for the much smaller ISPS with few > million subscriber base but I think an impossibility at least for the > larger Verizon size ISP=E2=80=99s. Looking on IAIA allocation link I don= 't see > too many RIRs getting a /12. > > *https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-u= nicast-address-assignments.xhtml > * > > > > > > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-134713101 Columbia Pike > *Silver > Spring, MD > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000f5971d05b475d8e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Jordi!

<= /div>
That solves one problem but does not solve the 64sha= re v2 issue as we have to still modify=C2=A0
RFC 486= 1 for mobile to accept shorter prefix. =C2=A0

Thanks=C2=A0

Gyan

On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ &l= t;jordi.palet=3D40consul= intel.es@dmarc.ietf.org> wrote:

The right way to resol= ve this is very simple.

=C2=A0

=

Go t= o your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for each of= my subscribers, so I need a subsequent allocation, following the section 6= .5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy Manual,= and this is my justification =E2=80=A6=E2=80=9D.

<= p class=3D"MsoNormal">=C2=A0

Done!

= =C2=A0=

https://www.arin.net= /participate/policy/nrpm/#6-5-3-subsequent-allocations-to-lirs

=C2=A0

Regards,<= /u>

= Jordi=

@jordipalet=

=C2=A0<= /span>

=C2=A0

=C2=A0

=

El 19/11/20 13:26,= "v6ops en nombre de Gyan Mishra" <v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.= com> escribi=C3=B3:

=C2=A0

v6ops preso - "race t= o bottom slide" slightly modified - new proposal for new /80 bottom so= that we could actually make multiple /48s I mean /64s actually wearable.= =C2=A0 =C2=A0

A /64 would be the new /48 as we shifted the IID by 16 bi= ts shorter & making the prefix 16 bits longer.

= =C2=A0

/64 =3D current Bottom fixe= d based on 64 bit IID.

/48 =3D 64k /6= 4s - Due to current 3GPP architecture limitation we cannot dole out shorter= prefixes=C2=A0via 64share v2 even that Cameron proposed.=C2=A0 Also with t= he RA PD style trickery w/o A bit set as Lorenzo mentioned the host would n= ot accept the shorter prefix as it is expecting a 64 bit prefix from the 3G= PP gateway.

=C2=A0

Why /48's wearable is not possible today for 2 reasons:=

1. Large providers such as Verizon subscrib= ers =3D 150M not including broadband and /24 equates to 16M /48 way short a= nd /20 even 160M but large providers as Verizon's of the world need to = scale to 1B or 7B.

2. 64share v2 even= if 3GPP arch allowed shorter prefixes /56 or even /48, RFC 4291 would have= =C2=A0to change the 64 bit fixed boundary requirement=C2=A0for any handset = to accept shorter prefix.=C2=A0 So we are stuck and 64 share v2 is not poss= ible w/o RFC 4291 changing.

=C2=A0

What if we made the new fixed bottom a /80 meani= ng.=C2=A0 So that would essentially be the new bottom that ISPs cannot race= any further since the standard would be fixed at the new /80 bottom just a= s its fixed at the /64 bottom.=C2=A0 We just gave ourselves 16 bits to play= with.=

=C2=A0

= 64 share v2 - Allocate /64 as it does today and that would basically be= equivalent to a /48 allocation. Nice!

/80 =3D New bottom =3D> Problem solved=C2=A0

/64 =3D 64k /80s - wearab= le - so now both 3GPP and broadband=C2=A0 providers problem solved for segm= entation

/64 = Current bottom

/48 = =3D 64k /64s

As far as SLAAC goes= we would modify RFC 4291 to allow for longer prefixes up to /80.=C2=A0 I t= hink while we are changing RFC 4291 I think it would make sense to allow fo= r shorter prefixes maybe to any length or fix a a value that makes sense fo= r shorter then /64.=C2=A0 So in the future if 3GPP can be updated for short= er prefixes we could give out shorter as well which would be a ton of prefi= xes.=C2=A0=C2=A0

However, I think if = we made the new bottom a /80, in reality the=C2=A0end site allocation would= be equivalent to a /48 so would not have to allow slaac really to allow fo= r shorter then /64.=C2=A0=C2=A0

=C2=A0

Although as they say - never say never.."= when you build - they will come"

=C2=A0=

SLAAC would use random IID generation sc= hemes to generate the shorter 48 bit IID via RFC 4941 or stable IID RFC 721= 7.<= /u>

=C2=A0

= >From a privacy perspective for broadband users we would still have 48 bit I= ID which in the scheme of things as the double edged sword for operators &a= mp; law enforcement scanning I think the address correlation attacks I thin= k the 48 bits random IID for privacy extension, I think we would=C2=A0be in= good shape.=C2=A0

=C2=A0

This also solves the day 1 VLSM issue as well for mixed hos= t static, dhcpv6 & slaac as now we can have longer prefixes up=C2=A0 to= /80.=C2=A0 =C2=A0

=C2=A0

This may solve some of the aviation issues that Fred Templi= n is working on as well.=C2=A0=C2=A0

=C2=A0<= /u>

Also with Network Slicing to be mainstrea= m with 5G=C2=A0 and proliferation of IoT devices I can see end user allocat= ions growing very quickly

=C2=A0<= /p>

AND =3D "NO RACE TO BOTTOM" possible even= =C2=A0 as we would fix the new boundary at "/80" as the new botto= m so you cannot race down any further. Would be no different then the /64 b= oundary but now getting a 16 bit bonus out of the deal.=C2=A0

=C2=A0

IANA now does no= t have to dig into unallocating more ::/3s for larger allocations - see Sli= de 10 from v6ops preso below

=C2=A0

Slide 1= 0 in v6 ops preso

One of the reasons why 6MAN has deferred removing the= 64 bit boundary is due to the=C2=A0 ISP =E2=80=9Crace to the bottom=E2=80= =9D fear that we are at the bottom giving out /64 to mobile handsets that I= SP=E2=80=99s will in theory do what history has shown us what was done with= IPv4 where due to address depletion issues and issues with overlapping add= ress space ISP=E2=80=99s made the broadband standard to dole out /32 WAN IP= which is NAT port overloaded outside wan interface.=C2=A0 NAT as well as C= GNAT have solved issues with IPv4 shortage and overlapping ranges allowing = overlapping ranges to co-exist with NAT as well as now ISP=E2=80=99s due to= the risk of IPv4 address depletion made the standard a /32 WAN IP with NAT= port overloaded via PAT (Port Address translation) with private 192.168.1.0/24 subnet for SOH= O hosts.=C2=A0

IPv6 on the other hand does not have any risk of addres= s depletion so you cannot compare what history has told us with IPv4 to IPv= 6 and there is no other data point to be had.

On the other side of t= he spectrum with 64share we are looking now at shorter prefixes and maybe a= n idea of creating and RFC 6177bis that allows a /48 per human per mobile d= evice.=C2=A0 Is that possible ???

http= s://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=3D>RIR <=3D&g= t; ISP <=3D> End user Allocation

RIR alloca= tions to Service Providers:

=C2=A0

For the massive block allocations for ISPs is it tiered like t= his=

/32 - General Starting point for ISP allocati= on<= /u>

/24-26 - Medium to Large=C2=A0<= /p>

/19-20 - Exceptions and rare

=C2=A0

Since allocations are done blockwize and not linear= ly you have to account for future growth so generally over allocate for gro= wth next 20 years.=C2=A0 So with that the much larger allocations.<= /span>

=C2=A0

With that being said let= 's say for a typical large ISP /24 - that would yield 16M /48s.=C2=A0 T= hat still is small since most large ISPs like, we Verizon we want to scale = to a billion as right now we have 150M and that's just domestic not wor= ldwide.=C2=A0 Safe best for large ISPs is we want to scale to the number of= humans on the planet so 7 Billion is a good number.=C2=A0 Also that does n= ot account for broadband.=C2=A0 So for Verizon as an example /48=C2=A0 per = human is not possible.=C2=A0

=C2=A0

I think /48 per user site is sensible for the much smaller ISP= S with few million subscriber base=C2=A0 but I think an impossibility=C2=A0= at least for the larger Verizon size ISP=E2=80=99s.=C2=A0 Looking on IAIA allocation link I don't see too many = RIRs getting a /12.

<= span style=3D"color:#1155cc">https://www= .iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address= -assignments.xhtml

=C2=A0

=C2=A0

=C2=A0

=

Gyan Mishra

Network Solutions Architect=C2=A0<= /i>

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring= , MD

=C2=A0

=

___= ____________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf= .org/mailman/listinfo/v6ops


***************= *******************************
IPv4 is over
Are you ready for the new Internet ?
http://www.thei= pv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--000000000000f5971d05b475d8e9-- From nobody Thu Nov 19 05:52:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7425C3A0FC3; Thu, 19 Nov 2020 05:51:57 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 seNU_DL5_ZpQ; Thu, 19 Nov 2020 05:51:52 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58A13A0FD2; Thu, 19 Nov 2020 05:51:52 -0800 (PST) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:8134:785f:b705:6f79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id B887B4E11BAA; Thu, 19 Nov 2020 13:51:44 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C7318459D8DB; Thu, 19 Nov 2020 14:51:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: otroan@employees.org In-Reply-To: Date: Thu, 19 Nov 2020 14:51:41 +0100 Cc: JORDI PALET MARTINEZ , IPv6 Operations , 6MAN <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> To: Gyan Mishra X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:51:58 -0000 > That solves one problem but does not solve the 64share v2 issue as we = have to still modify=20 > RFC 4861 for mobile to accept shorter prefix. =20 As Lorenzo explained during the meeting reusing the PIO isn't going to = work. You would need a new option. It would likely be useful for the = requesting router to indicate interest in the option. Even hinting at = what prefix size it was expecting. Now can you explain to me again the reasons why this approach is better = than using the existing DHPCv6 protocol packets? Best regards, Ole= From nobody Thu Nov 19 05:58:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A743A0F49; Thu, 19 Nov 2020 05:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMSyWdJ5d9Jn; Thu, 19 Nov 2020 05:58:44 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E0A3A0DCA; Thu, 19 Nov 2020 05:58:44 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id 10so4575667pfp.5; Thu, 19 Nov 2020 05:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r1SGj7IUhat5xU/exxsrw1wTKd1zg5mJpOQz5tbDxf0=; b=pTIok1LBc1Du0DwlAZVtMRGCH9vejGdJQ4k1zzDGAMEB054zTl/9ChcEGvUwBpOZLt Cdo0RUvfNGkY+uj3mg2Hv+vG/f/u8bqGDIxstX9ScQAmk8FvdP3MAsp2lco+co+KWYhx VjhBLQ4kFrK5+UZqh24h9yN5gASk2BKCVKM/AUZ09KO+wzIeu7UwfzdTsw/Y7y/CV95B PptI0MebZw4Q4IzZTA94XEoas/yjCl3oN09RrH0G4OdlBS85FPFr3Kz3YEBhPaxE8U0C 2iYo5uO4x0BbhdFvsZBBKqIO060gL6QJPAy1Psraf01BzEwPFPMEjEZdiDRYaE17JM/c 4gkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r1SGj7IUhat5xU/exxsrw1wTKd1zg5mJpOQz5tbDxf0=; b=bWFbaEhXal8fGzpmsYKxgIDfMb8NGGxryGD4pfit/j1lzoXGMpnx89GT6OhDFMohGW NfrsvR1IUXy+Z/lxCHUudzPYjqJxvBe1wLvCbZdmOfX6PjR4uOx46YuBrFTSDfWlkYPO TnlF/1ShShCNEEff3VDuNyeVuNqQZrkXaPQXjDuoum0Sp/uoEHbBGoJpVhkkO694Td7y KxFwd7Rqf0V0XIn9V4xKyVyNfDc3oauXLDjgBZjm4i/UbM0+/rT4NEiZkbX4+hGTPgkG zwW8ML8MXWByr5sZ2cPbKHv3c91874DZctEJIudG4Tu3jjayZkhsDjDr4Bpjqy501ly2 k7YA== X-Gm-Message-State: AOAM530i6JVCKYSEDTVOpmM1Px/18zmmSlo9WzNfnMNyn06lI2AMpW6/ oPr3c1H1uDiBdNyRWiiYcrQAWVZ3b4R+XgOLLcKbvzNv3d0= X-Google-Smtp-Source: ABdhPJxGTBzMvTksXcKewpVq7Be65v3NdEHsXaORjF1nOXfNL0qOZ/m+bwjFQpMVMViq3Qc0n9RhPyhx6jknV0swkSQ= X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr4676594pjx.112.1605794324033; Thu, 19 Nov 2020 05:58:44 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> In-Reply-To: <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> From: Gyan Mishra Date: Thu, 19 Nov 2020 08:58:33 -0500 Message-ID: To: otroan@employees.org Cc: 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ Content-Type: multipart/alternative; boundary="00000000000044332605b4762081" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:58:46 -0000 --00000000000044332605b4762081 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 19, 2020 at 8:51 AM wrote: > > That solves one problem but does not solve the 64share v2 issue as we > have to still modify > > RFC 4861 for mobile to accept shorter prefix. > > As Lorenzo explained during the meeting reusing the PIO isn't going to > work. Gyan> Understood. Lorenzo made a key point which is why I am bringing up that we would need a new option as we defined in the variable slaac solutions draft. > > > You would need a new option. It would likely be useful for the requesting > router to indicate interest in the option. Even hinting at what prefix size > it was expecting. > Now can you explain to me again the reasons why this approach is better > than using the existing DHPCv6 protocol packets? 3GPP gateway does not support DHCPv6 > > > Best regards, > Ole -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000044332605b4762081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

--

On Thu, Nov 19, 2020 at 8:51 AM <otroan@employees.org> wrote:
> That solves one problem but does not solve the 64sha= re v2 issue as we have to still modify
> RFC 4861 for mobile to accept shorter prefix.=C2=A0

As Lorenzo explained during the meeting reusing the PIO isn't going to = work.

=C2=A0 =C2= =A0Gyan> Understood.=C2=A0 Lorenzo made a key point which is why I am br= inging up that we would need a new option as we defined in the variable sla= ac solutions draft.


You would need a new option. It would likely be useful for the requesting r= outer to indicate interest in the option. Even hinting at what prefix size = it was expecting.
Now can you explain to me again the reasons why this approach is better tha= n using the existing DHPCv6 protocol packets?

=C2=A0 =C2=A0 3GPP gateway does not support DH= CPv6


Best regards,
Ole


Gyan Mish= ra

Network So= lutions Archi= tect=C2=A0

M 301 502-1347
13101 C= olumbia Pike=C2=A0
Silver Spring, MD


=
--00000000000044332605b4762081-- From nobody Thu Nov 19 06:14:10 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD83A105B; Thu, 19 Nov 2020 06:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0boXUZZP-2Bs; Thu, 19 Nov 2020 06:14:02 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D923D3A104C; Thu, 19 Nov 2020 06:14:01 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id 131so4599943pfb.9; Thu, 19 Nov 2020 06:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Hw7WGFLBxT5dPg/diz7V6HH4uYTCHWSfKVda2EinGs=; b=TqgNMfmFMhzTVtPmwrCxsaTPFLR+AtvYyVaoa+q+jo050wogVf9H+RVrirTQl17DxM WGrUCD3OqR0Q4uhIP8sodrMqX0IjC6oiQ3Sqdnyqcc3ExupCjpQFvPgJvm7a7F2WdrCv PoBYWqKaAcN9LyJ55NtUwvGlg6NlS02pyyKLq9BiW40b52nE3f84eB0sDvGjt4mfIP3z ybYZLMIJrXC12legW+YsWz/4f8h4WXWgbsHpZy5i7vVWlRdVdEZLeV47gPf5celw54Oo AW1easaKCZIeCvsYqR3oT31kB9ezx5LoDQ3pZPuNcftrq3Hpgqtam485ITDh4vN95rQZ 06vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Hw7WGFLBxT5dPg/diz7V6HH4uYTCHWSfKVda2EinGs=; b=ksa5ryFI5jxMxy4clInRgf8MkaFOCvIkOQWVID9WJYqQlU7iw51uCK8abLXAGGpP1I 5rB1NBtvv+/agjo09vPhRQQ95hnQamIb+9XvdyC/fLuKVI0GMBoudmp/GkI4A+j2lTrj rQKAGuimfM6be+VasUDfUiLT+HnxmN8fVTNGPO5Ovok8VHXK92TmQjhHRpm2Ing+SpyJ XlVACvvs1ZCh7S/72AomqqG7HoHwmam8ogatG3hRjhqqxVq3gdtMjqVoOZAS6ZwOLyMp nw5CYvNAnGxhDAuwy1DM6YRSXe+ajNTu+2eY6dSu6khR5wz7CAFGjuLW2BRLEkEhSrSG BCkA== X-Gm-Message-State: AOAM530fA7izrUbYu7UJRut+OV9WCzt6pXe6SDtYr4xRqlqwlehyPWCB Q36hfhfY4q9tFMdlE6zJYBC3CH/5w0GdezEFuIA= X-Google-Smtp-Source: ABdhPJzy3TASCdap3ak3yZnocC4xFHeanPIa6/8nZP9VnVADJDka2BxMhIllzdQB2mUx1ntemObKBBshOSTu69gk58I= X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr4754439pjx.112.1605795240989; Thu, 19 Nov 2020 06:14:00 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> In-Reply-To: From: Gyan Mishra Date: Thu, 19 Nov 2020 09:13:50 -0500 Message-ID: To: JORDI PALET MARTINEZ Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000ebd8a805b4765625" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:14:05 -0000 --000000000000ebd8a805b4765625 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jordi I am not sure if all RIRs for example ARIN if it or others are as liberal as RIPE. Gyan On Thu, Nov 19, 2020 at 8:38 AM Gyan Mishra wrote: > > Thanks Jordi! > > That solves one problem but does not solve the 64share v2 issue as we hav= e > to still modify > RFC 4861 for mobile to accept shorter prefix. > > Thanks > > Gyan > > On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > >> The right way to resolve this is very simple. >> >> >> >> Go to your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for = each of >> my subscribers, so I need a subsequent allocation, following the section >> 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy >> Manual, and this is my justification =E2=80=A6=E2=80=9D. >> >> >> >> Done! >> >> >> >> >> https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocatio= ns-to-lirs >> >> >> >> Regards, >> >> Jordi >> >> @jordipalet >> >> >> >> >> >> >> >> El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" < >> v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.com> escribi=C3=B3= : >> >> >> >> v6ops preso - "race to bottom slide" slightly modified - new proposal fo= r >> new /80 bottom so that we could actually make multiple /48s I mean /64s >> actually wearable. >> >> A /64 would be the new /48 as we shifted the IID by 16 bits shorter & >> making the prefix 16 bits longer. >> >> >> >> /64 =3D current Bottom fixed based on 64 bit IID. >> >> /48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot >> dole out shorter prefixes via 64share v2 even that Cameron proposed. Al= so >> with the RA PD style trickery w/o A bit set as Lorenzo mentioned the hos= t >> would not accept the shorter prefix as it is expecting a 64 bit prefix f= rom >> the 3GPP gateway. >> >> >> >> Why /48's wearable is not possible today for 2 reasons: >> >> 1. Large providers such as Verizon subscribers =3D 150M not including >> broadband and /24 equates to 16M /48 way short and /20 even 160M but lar= ge >> providers as Verizon's of the world need to scale to 1B or 7B. >> >> 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48= , >> RFC 4291 would have to change the 64 bit fixed boundary requirement for = any >> handset to accept shorter prefix. So we are stuck and 64 share v2 is no= t >> possible w/o RFC 4291 changing. >> >> >> >> What if we made the new fixed bottom a /80 meaning. So that would >> essentially be the new bottom that ISPs cannot race any further since th= e >> standard would be fixed at the new /80 bottom just as its fixed at the /= 64 >> bottom. We just gave ourselves 16 bits to play with. >> >> >> >> 64 share v2 - Allocate /64 as it does today and that would basically be >> equivalent to a /48 allocation. Nice! >> >> */80 =3D New bottom =3D> Problem solved * >> >> */64 =3D 64k /80s - wearable - so now both 3GPP and broadband providers >> problem solved for segmentation* >> >> */64 Current bottom* >> >> */48 =3D 64k /64s* >> >> As far as SLAAC goes we would modify RFC 4291 to allow for longer >> prefixes up to /80. I think while we are changing RFC 4291 I think it >> would make sense to allow for shorter prefixes maybe to any length or fi= x a >> a value that makes sense for shorter then /64. So in the future if 3GPP >> can be updated for shorter prefixes we could give out shorter as well wh= ich >> would be a ton of prefixes. >> >> However, I think if we made the new bottom a /80, in reality the end sit= e >> allocation would be equivalent to a /48 so would not have to allow slaac >> really to allow for shorter then /64. >> >> >> >> Although as they say - never say never.."when you build - they will come= " >> >> >> >> SLAAC would use random IID generation schemes to generate the shorter 48 >> bit IID via RFC 4941 or stable IID RFC 7217. >> >> >> >> From a privacy perspective for broadband users we would still have 48 bi= t >> IID which in the scheme of things as the double edged sword for operator= s & >> law enforcement scanning I think the address correlation attacks I think >> the 48 bits random IID for privacy extension, I think we would be in goo= d >> shape. >> >> >> >> This also solves the day 1 VLSM issue as well for mixed host static, >> dhcpv6 & slaac as now we can have longer prefixes up to /80. >> >> >> >> This may solve some of the aviation issues that Fred Templin is working >> on as well. >> >> >> >> Also with Network Slicing to be mainstream with 5G and proliferation of >> IoT devices I can see end user allocations growing very quickly >> >> >> >> AND =3D "NO RACE TO BOTTOM" possible even as we would fix the new bound= ary >> at "/80" as the new bottom so you cannot race down any further. Would be= no >> different then the /64 boundary but now getting a 16 bit bonus out of th= e >> deal. >> >> >> >> IANA now does not have to dig into unallocating more ::/3s for larger >> allocations - see Slide 10 from v6ops preso below >> >> >> >> Slide 10 in v6 ops preso >> >> One of the reasons why 6MAN has deferred removing the 64 bit boundary is >> due to the ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at= the bottom giving >> out /64 to mobile handsets that ISP=E2=80=99s will in theory do what his= tory has >> shown us what was done with IPv4 where due to address depletion issues a= nd >> issues with overlapping address space ISP=E2=80=99s made the broadband s= tandard to >> dole out /32 WAN IP which is NAT port overloaded outside wan interface. >> NAT as well as CGNAT have solved issues with IPv4 shortage and overlappi= ng >> ranges allowing overlapping ranges to co-exist with NAT as well as now >> ISP=E2=80=99s due to the risk of IPv4 address depletion made the standar= d a /32 WAN >> IP with NAT port overloaded via PAT (Port Address translation) with priv= ate >> 192.168.1.0/24 subnet for SOHO hosts. >> >> IPv6 on the other hand does not have any risk of address depletion so yo= u >> cannot compare what history has told us with IPv4 to IPv6 and there is n= o >> other data point to be had. >> >> On the other side of the spectrum with 64share we are looking now at >> shorter prefixes and maybe an idea of creating and RFC 6177bis that allo= ws >> a /48 per human per mobile device. Is that possible ??? >> >> >> https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.x= html >> >> 2000::/3 GUI >> >> IAIA <=3D>RIR <=3D> ISP <=3D> End user Allocation >> >> RIR allocations to Service Providers: >> >> >> >> For the massive block allocations for ISPs is it tiered like this >> >> /32 - General Starting point for ISP allocation >> >> /24-26 - Medium to Large >> >> /19-20 - Exceptions and rare >> >> >> >> Since allocations are done blockwize and not linearly you have to accoun= t >> for future growth so generally over allocate for growth next 20 years. = So >> with that the much larger allocations. >> >> >> >> With that being said let's say for a typical large ISP /24 - that would >> yield 16M /48s. That still is small since most large ISPs like, we Veri= zon >> we want to scale to a billion as right now we have 150M and that's just >> domestic not worldwide. Safe best for large ISPs is we want to scale to >> the number of humans on the planet so 7 Billion is a good number. Also >> that does not account for broadband. So for Verizon as an example /48 = per >> human is not possible. >> >> >> >> I think /48 per user site is sensible for the much smaller ISPS with few >> million subscriber base but I think an impossibility at least for the >> larger Verizon size ISP=E2=80=99s. Looking on IAIA allocation link I do= n't see >> too many RIRs getting a /12. >> >> *https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-= unicast-address-assignments.xhtml >> * >> >> >> >> >> >> >> >> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> *Silver >> Spring, MD >> >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of >> the individual(s) named above and further non-explicilty authorized >> disclosure, copying, distribution or use of the contents of this >> information, even if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you are not the >> intended recipient be aware that any disclosure, copying, distribution o= r >> use of the contents of this information, even if partially, including >> attached files, is strictly prohibited, will be considered a criminal >> offense, so you must reply to the original sender to inform about this >> communication and delete it. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000ebd8a805b4765625 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jordi

= I am not sure if all RIRs for example ARIN if it or others are as liberal a= s RIPE.

Gyan
--
--000000000000ebd8a805b4765625-- From nobody Thu Nov 19 06:16:46 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB10F3A10A9 for ; Thu, 19 Nov 2020 06:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaA44MdLXbc9 for ; Thu, 19 Nov 2020 06:16:42 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 05BB13A112D for ; Thu, 19 Nov 2020 06:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1605795397; x=1637331397; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=DplgGKkqAFaysnSqNDwcUP5AUnzvb0whFbcTvavejQw=; b=hrY8HG7YbrCFlREfejOvEqH7VY3EAtWU0Om56+D4hiKdudLReaOHtpd2 IFLs/0e6zRCdLHFwcbPonlyLww+u5LvdoRbO8ZjVx6QgGg4KJi4vsHlJY ywK0Y/w3nv86BFk/fYh4ATRvg0+gaK/d4A6eMluUiuqVz0Vn3WbM907Li 3pwziuhfExyT2Cuit/oT62oSCXHInNDff8ibVxdny3NNL+FRhSmqJrSlv HnjlKz2mUPjNFocEHwX0GO/JiyOL5ucchBb2fkX4BunMyX7xSfV8NyTk3 EBWnXuZVSmXTmjAHwyMKdSSbZNL6UVVtXFzADDXjoXP5AnQXMsYIvB1/X Q==; IronPort-SDR: TMBcf4+beziQWHFHfxdUdW2HbtnKh+0MZVlazoYiK7+ldUrqil/jf62Q2LNUnyJi2zmN2i86W/ g1seeZKsiVTq5vNSaOgr0EmmzunDXGL+/p9xTa6WNT6x0LMIYnv/4lWxr4Q0bpm6Q8YQadh6LI k8tUwmKP1PJQCLWmskaO5WuPcUizLUQ0ujcplxsAuCmQvCnHTVn8G0FpDtUvN+eQ+0zUTkXvgs H/gRaZQTjq4JOZ+hL9aA+4CXlbyUqS8mVVD3cURdf5P4/pKYHkwR2ETZoV8D2r98x4zYNlGKn1 WzI= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2020 15:16:34 +0100 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 78D47427E3 for ; Thu, 19 Nov 2020 15:16:33 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 22DAE41940; Thu, 19 Nov 2020 15:16:33 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1C63B24C97; Thu, 19 Nov 2020 15:16:33 +0100 (CET) Date: Thu, 19 Nov 2020 15:16:33 +0100 From: Gert Doering To: Gyan Mishra Cc: otroan@employees.org, IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ Message-ID: <20201119141633.GC13005@Space.Net> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:16:45 -0000 Hi, On Thu, Nov 19, 2020 at 08:58:33AM -0500, Gyan Mishra wrote: > 3GPP gateway does not support DHCPv6 Why can this not be changed? A few 3GPP gateways vs. "billions of phones"? (Especially since 3G standards seems to already include DHCPv6) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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 Nov 19 06:26:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769633A003E; Thu, 19 Nov 2020 06:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 xO2fy2QQNMWr; Thu, 19 Nov 2020 06:26:42 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B6E623A0045; Thu, 19 Nov 2020 06:26:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AJEQXQW034513; Thu, 19 Nov 2020 15:26:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8A4E5201080; Thu, 19 Nov 2020 15:26:33 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 74F1A206D6F; Thu, 19 Nov 2020 15:26:33 +0100 (CET) Received: from [10.11.241.125] ([10.11.241.125]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AJEQXKO026182; Thu, 19 Nov 2020 15:26:33 +0100 To: otroan@employees.org, Gyan Mishra Cc: IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> From: Alexandre Petrescu Message-ID: <335dcf99-5178-531e-4b6f-d26032e58437@gmail.com> Date: Thu, 19 Nov 2020 15:26:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:26:44 -0000 Le 19/11/2020 Ă  14:51, otroan@employees.org a Ă©crit : >> That solves one problem but does not solve the 64share v2 issue as >> we have to still modify RFC 4861 for mobile to accept shorter >> prefix. > > As Lorenzo explained during the meeting reusing the PIO isn't going > to work. > > You would need a new option. It would likely be useful for the > requesting router to indicate interest in the option. Even hinting at > what prefix size it was expecting. Ole, Are you referring to Lorenzo's explanation in order to suggest the use of a new option in order to explain that DHCPv6-PD could be such an option? Or are you suggesting a new option in order to explain that a new option in RA, like a bit flag, might be appropriate? Do you think that an operator might be interested in implementing a new option in RA at the 3GPP gateway? (I am asking because an operator said 'no' to that question, and another operator said they'd prefer to just modify a parm in conf file - 64share-V2; maybe you see that differently). For information, a maintainer of stack implementation in linux kernel asks what is the level of 'IETF consensus' of the proposed new option in RA to kernel implementation. This is an Individual Submission. And I dont know how to move forward. Alex > Now can you explain to me again the reasons why this approach is > better than using the existing DHPCv6 protocol packets? > > Best regards, Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Nov 19 06:55:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865E33A09EA; Thu, 19 Nov 2020 06:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 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, MIME_QP_LONG_LINE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpdCQJqqiCvh; Thu, 19 Nov 2020 06:55:27 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C63A0AB7; Thu, 19 Nov 2020 06:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1605797725; x=1606402525; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=qlpPW/k9Nn4mRB0AXIGa0+ad4MTUh/jlu0 Q5aRJzkuo=; b=DK4679K2yX7gMbSassVTiIYbd9zh6IO3T597NnyeM/YdsniHC8 j1VRLJmVze5fh5ztIRbYbxbKaETP8dhOgWiVpLE9c/1N/7brsOVdT5SvfN8WeanE i0aVN6FGsY6ylCCj/2l74W1yzSwTXDS8ru2LTvQ8XWB97VDl2UhaDULt0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 19 Nov 2020 15:55:25 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 19 Nov 2020 15:55:23 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000468072.msg; Thu, 19 Nov 2020 15:55:22 +0100 X-MDRemoteIP: 2001:470:1f09:495:39a3:9029:40e2:ed12 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 19 Nov 2020 15:55:22 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=15925babf5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Thu, 19 Nov 2020 15:55:18 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations , 6MAN <6man@ietf.org> Message-ID: Thread-Topic: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688646118_90724605" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:55:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688646118_90724605 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Every RIR has their own policies, but in general they match very closely (I= tried very hard doing that thru policy proposals when it was making sense,= and this was the case for IPv6 initial and subsequent allocations). =20 As explained a few emails ago =E2=80=A6 in general I will say that you only= have a problem in LACNIC and AFRINIC if you don=E2=80=99t have your servic= es there, or at least the majority of those services. =20 Regards, Jordi @jordipalet =20 =20 =20 El 19/11/20 15:16, "v6ops en nombre de Gyan Mishra" escribi=C3=B3: =20 Jordi =20 I am not sure if all RIRs for example ARIN if it or others are as liberal a= s RIPE. =20 Gyan =20 On Thu, Nov 19, 2020 at 8:38 AM Gyan Mishra wrote: =20 Thanks Jordi! =20 That solves one problem but does not solve the 64share v2 issue as we have = to still modify=20 RFC 4861 for mobile to accept shorter prefix. =20 =20 Thanks=20 =20 Gyan =20 On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ wrote: The right way to resolve this is very simple. =20 Go to your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for eac= h of my subscribers, so I need a subsequent allocation, following the secti= on 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy Man= ual, and this is my justification =E2=80=A6=E2=80=9D. =20 Done! =20 https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocations-= to-lirs =20 Regards, Jordi @jordipalet =20 =20 =20 El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" escribi=C3=B3: =20 v6ops preso - "race to bottom slide" slightly modified - new proposal for n= ew /80 bottom so that we could actually make multiple /48s I mean /64s actu= ally wearable. =20 A /64 would be the new /48 as we shifted the IID by 16 bits shorter & makin= g the prefix 16 bits longer. =20 /64 =3D current Bottom fixed based on 64 bit IID. /48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot do= le out shorter prefixes via 64share v2 even that Cameron proposed. Also wi= th the RA PD style trickery w/o A bit set as Lorenzo mentioned the host wou= ld not accept the shorter prefix as it is expecting a 64 bit prefix from th= e 3GPP gateway. =20 Why /48's wearable is not possible today for 2 reasons: 1. Large providers such as Verizon subscribers =3D 150M not including broad= band and /24 equates to 16M /48 way short and /20 even 160M but large provi= ders as Verizon's of the world need to scale to 1B or 7B. 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, R= FC 4291 would have to change the 64 bit fixed boundary requirement for any = handset to accept shorter prefix. So we are stuck and 64 share v2 is not p= ossible w/o RFC 4291 changing. =20 What if we made the new fixed bottom a /80 meaning. So that would essentia= lly be the new bottom that ISPs cannot race any further since the standard = would be fixed at the new /80 bottom just as its fixed at the /64 bottom. = We just gave ourselves 16 bits to play with. =20 64 share v2 - Allocate /64 as it does today and that would basically be equ= ivalent to a /48 allocation. Nice! /80 =3D New bottom =3D> Problem solved=20 /64 =3D 64k /80s - wearable - so now both 3GPP and broadband providers pro= blem solved for segmentation /64 Current bottom /48 =3D 64k /64s As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes = up to /80. I think while we are changing RFC 4291 I think it would make se= nse to allow for shorter prefixes maybe to any length or fix a a value that= makes sense for shorter then /64. So in the future if 3GPP can be updated= for shorter prefixes we could give out shorter as well which would be a to= n of prefixes. =20 However, I think if we made the new bottom a /80, in reality the end site a= llocation would be equivalent to a /48 so would not have to allow slaac rea= lly to allow for shorter then /64. =20 =20 Although as they say - never say never.."when you build - they will come" =20 SLAAC would use random IID generation schemes to generate the shorter 48 bi= t IID via RFC 4941 or stable IID RFC 7217. =20 >From a privacy perspective for broadband users we would still have 48 bit I= ID which in the scheme of things as the double edged sword for operators & = law enforcement scanning I think the address correlation attacks I think th= e 48 bits random IID for privacy extension, I think we would be in good sha= pe.=20 =20 This also solves the day 1 VLSM issue as well for mixed host static, dhcpv6= & slaac as now we can have longer prefixes up to /80. =20 =20 This may solve some of the aviation issues that Fred Templin is working on = as well. =20 =20 Also with Network Slicing to be mainstream with 5G and proliferation of Io= T devices I can see end user allocations growing very quickly =20 AND =3D "NO RACE TO BOTTOM" possible even as we would fix the new boundary= at "/80" as the new bottom so you cannot race down any further. Would be n= o different then the /64 boundary but now getting a 16 bit bonus out of the= deal.=20 =20 IANA now does not have to dig into unallocating more ::/3s for larger alloc= ations - see Slide 10 from v6ops preso below =20 Slide 10 in v6 ops preso One of the reasons why 6MAN has deferred removing the 64 bit boundary is du= e to the ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at the = bottom giving out /64 to mobile handsets that ISP=E2=80=99s will in theory = do what history has shown us what was done with IPv4 where due to address d= epletion issues and issues with overlapping address space ISP=E2=80=99s mad= e the broadband standard to dole out /32 WAN IP which is NAT port overloade= d outside wan interface. NAT as well as CGNAT have solved issues with IPv4= shortage and overlapping ranges allowing overlapping ranges to co-exist wi= th NAT as well as now ISP=E2=80=99s due to the risk of IPv4 address depleti= on made the standard a /32 WAN IP with NAT port overloaded via PAT (Port Ad= dress translation) with private 192.168.1.0/24 subnet for SOHO hosts. =20 IPv6 on the other hand does not have any risk of address depletion so you c= annot compare what history has told us with IPv4 to IPv6 and there is no ot= her data point to be had.=20 On the other side of the spectrum with 64share we are looking now at shorte= r prefixes and maybe an idea of creating and RFC 6177bis that allows a /48 = per human per mobile device. Is that possible ???=20 https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtm= l 2000::/3 GUI=20 IAIA <=3D>RIR <=3D> ISP <=3D> End user Allocation RIR allocations to Service Providers:=20 =20 For the massive block allocations for ISPs is it tiered like this /32 - General Starting point for ISP allocation /24-26 - Medium to Large=20 /19-20 - Exceptions and rare =20 Since allocations are done blockwize and not linearly you have to account f= or future growth so generally over allocate for growth next 20 years. So w= ith that the much larger allocations. =20 With that being said let's say for a typical large ISP /24 - that would yie= ld 16M /48s. That still is small since most large ISPs like, we Verizon we= want to scale to a billion as right now we have 150M and that's just domes= tic not worldwide. Safe best for large ISPs is we want to scale to the num= ber of humans on the planet so 7 Billion is a good number. Also that does = not account for broadband. So for Verizon as an example /48 per human is = not possible.=20 =20 I think /48 per user site is sensible for the much smaller ISPS with few mi= llion subscriber base but I think an impossibility at least for the larger= Verizon size ISP=E2=80=99s. Looking on IAIA allocation link I don't see t= oo many RIRs getting a /12. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unic= ast-address-assignments.xhtml =20 =20 =20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --=20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 --=20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3688646118_90724605 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Every RIR has their own policies, but in general they match very= closely (I tried very hard doing that thru policy proposals when it was ma= king sense, and this was the case for IPv6 initial and subsequent allocatio= ns).

 

As explained a few emails ago =E2=80=A6 in general I will = say that you only have a problem in LACNIC and AFRINIC if you don=E2=80=99t= have your services there, or at least the majority of those services.=

 

= Regards,

= Jordi

@jordipalet

 

 

 <= /o:p>

 

Jordi

 

I am not sure if all RIRs for example = ARIN if it or others are as liberal as RIPE.

 

Gyan

 <= /p>

On Thu, Nov = 19, 2020 at 8:38 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

 

Thanks Jordi!

 

That solves one problem but do= es not solve the 64share v2 issue as we have to still modify 

RFC 4861= for mobile to accept shorter prefix.  

 

Thanks =

 = ;

Gya= n

 

On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ <jordi.pale= t=3D40consu= lintel.es@dmarc.ietf.org> wrote:

= The right way to resolve this= is very simple.

 

Go to your RIR= (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for each of my subscr= ibers, so I need a subsequent allocation, following the section 6.5.3. (Sub= sequent Allocation to LIRs) of the Number Resource Policy Manual, and this = is my justification =E2=80=A6=E2=80=9D.

 

Done!

 

 

 

El 19/11/20 13:26, "v6ops en nomb= re de Gyan Mishra" <v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.com> escribi= =C3=B3:

 

v6ops preso - "= race to bottom slide" slightly modified - new proposal for new /80 bot= tom so that we could actually make multiple /48s I mean /64s actually weara= ble.   

A /64 would b= e the new /48 as we shifted the IID by 16 bits shorter & making the pre= fix 16 bits longer.

 

/64 =3D current Bottom fixed= based on 64 bit IID.

/48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot= dole out shorter prefixes via 64share v2 even that Cameron proposed.&= nbsp; Also with the RA PD style trickery w/o A bit set as Lorenzo mentioned= the host would not accept the shorter prefix as it is expecting a 64 bit p= refix from the 3GPP gateway.

 <= /span>

Why /48's wearabl= e is not possible today for 2 reasons:

1. Large providers such as Verizon subscribers =3D 150M= not including broadband and /24 equates to 16M /48 way short and /20 even = 160M but large providers as Verizon's of the world need to scale to 1B or 7= B.

2. 64share v2 ev= en if 3GPP arch allowed shorter prefixes /56 or even /48, RFC 4291 would ha= ve to change the 64 bit fixed boundary requirement for any handse= t to accept shorter prefix.  So we are stuck and 64 share v2 is not po= ssible w/o RFC 4291 changing.

 =

What if we made t= he new fixed bottom a /80 meaning.  So that would essentially be the n= ew bottom that ISPs cannot race any further since the standard would be fix= ed at the new /80 bottom just as its fixed at the /64 bottom.  We just= gave ourselves 16 bits to play with.

64 share v= 2 - Allocate /64 as it does today and that would basically be equivalent to= a /48 allocation. Nice!

/64 =3D 64k /80s - wearable - so no= w both 3GPP and broadband  providers problem solved for segmentation

= /64 Current bottom

/48 =3D 64k /64s

As far as SLAAC goes we would modify RFC 4291 to all= ow for longer prefixes up to /80.  I think while we are changing RFC 4= 291 I think it would make sense to allow for shorter prefixes maybe to any = length or fix a a value that makes sense for shorter then /64.  So in = the future if 3GPP can be updated for shorter prefixes we could give out sh= orter as well which would be a ton of prefixes.  

However, I think if we made the ne= w bottom a /80, in reality the end site allocation would be equivalent= to a /48 so would not have to allow slaac really to allow for shorter then= /64.  

 =

Although as they say - never s= ay never.."when you build - they will come"

=

 

SLAAC would use random IID generation schemes to generate the shorter= 48 bit IID via RFC 4941 or stable IID RFC 7217.

 

From a privacy perspective for broadband users we would still have 48 bit = IID which in the scheme of things as the double edged sword for operators &= amp; law enforcement scanning I think the address correlation attacks I thi= nk the 48 bits random IID for privacy extension, I think we would be i= n good shape. 

 

This also solves the day 1 V= LSM issue as well for mixed host static, dhcpv6 & slaac as now we can h= ave longer prefixes up  to /80.   

 

This may solve some of= the aviation issues that Fred Templin is working on as well.  

 

Also with Network Slicing to be mainstream with = 5G  and proliferation of IoT devices I can see end user allocations gr= owing very quickly

 

AND =3D "NO RACE TO BOTT= OM" possible even  as we would fix the new boundary at "/80&= quot; as the new bottom so you cannot race down any further. Would be no di= fferent then the /64 boundary but now getting a 16 bit bonus out of the dea= l. 

 

IANA now does not have to dig into unal= locating more ::/3s for larger allocations - see Slide 10 from v6ops preso = below

 

Slide 10 in v6 ops preso

One of th= e reasons why 6MAN has deferred removing the 64 bit boundary is due to the&= nbsp; ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at the bott= om giving out /64 to mobile handsets that ISP=E2=80=99s will in theory do w= hat history has shown us what was done with IPv4 where due to address deple= tion issues and issues with overlapping address space ISP=E2=80=99s made th= e broadband standard to dole out /32 WAN IP which is NAT port overloaded ou= tside wan interface.  NAT as well as CGNAT have solved issues with IPv= 4 shortage and overlapping ranges allowing overlapping ranges to co-exist w= ith NAT as well as now ISP=E2=80=99s due to the risk of IPv4 address deplet= ion made the standard a /32 WAN IP with NAT port overloaded via PAT (Port A= ddress translation) with private 192.168.1.0/24 subnet for SOHO hosts. 

IPv6 on the other hand does not have any risk of address = depletion so you cannot compare what history has told us with IPv4 to IPv6 = and there is no other data point to be had.

On the other side of the spectrum with 64share we are looking now at shorter prefixes and maybe an idea of creating and RFC 6177= bis that allows a /48 per human per mobile device.  Is that possible ?= ??

https:/= /www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=3D>RIR <=3D> ISP <=3D> En= d user Allocation

RIR= allocations to Service Providers:

 

For the massive block allocations for ISPs is it tiered like this

/32 - General Starting point = for ISP allocation

/2= 4-26 - Medium to Large 

/19-20 - Exceptions and rare

 

Since allocations are done blockwize and not linearly you have to account= for future growth so generally over allocate for growth next 20 years.&nbs= p; So with that the much larger allocations.

 

With that being said let's say for a typical large ISP /24 - tha= t would yield 16M /48s.  That still is small since most large ISPs lik= e, we Verizon we want to scale to a billion as right now we have 150M and t= hat's just domestic not worldwide.  Safe best for large ISPs is we wan= t to scale to the number of humans on the planet so 7 Billion is a good num= ber.  Also that does not account for broadband.  So for Verizon a= s an example /48  per human is not possible. 

 

I think /48 p= er user site is sensible for the much smaller ISPS with few million subscri= ber base  but I think an impossibility at least for the larger Ve= rizon size ISP=E2=80=99s.  Looking = on IAIA allocation link I don't see too many RIRs getting a /12.

https://www.i= ana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-a= ssignments.xhtml

 

 

 

Gyan Mishra

<= i>Network Solutions= Architect 

M 301 502-1347
13101 Columbia Pike <= br>Silver Spring, MD

 

<= /div>

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


**********************************************=
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<= /a>
The IPv6 Company

This electronic message contains information= which may be privileged or confidential. The information is intended to be= for the exclusive use of the individual(s) named above and further non-exp= licilty authorized disclosure, copying, distribution or use of the contents= of this information, even if partially, including attached files, is stric= tly prohibited and will be considered a criminal offense. If you are not the intend= ed recipient be aware that any disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached fil= es, is strictly prohibited, will be considered a criminal offense, so you m= ust reply to the original sender to inform about this communication and del= ete it.

--------------------------------------------------------------------
= IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.iet= f.org/mailman/listinfo/ipv6
----------------------------------------= ----------------------------

--

Gyan Mishra

Network S= olutions Architect 

M 301 502-1347
13101 Columbia Pike=  
Silver Spring, MD

<= o:p> 

<= /blockquote>
<= br>
On Thu,= Nov 19, 2020 at 8:38 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

Thanks Jordi!

That solves one problem but does not solve = the 64share v2 issue as we have to still modify=C2=A0
RFC 4861 for mobile to accept shorter prefix. =C2=A0

Thanks=C2=A0

Gyan

On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET M= ARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:

The right way to resolve this is very= simple.

=C2=A0

Go to your RIR (ARI= N I guess) =E2=80=9CARIN I want to provide a /48 for each of my subscribers= , so I need a subsequent allocation, following the section 6.5.3. (Subseque= nt Allocation to LIRs) of the Number Resource Policy Manual, and this is my= justification =E2=80=A6=E2=80=9D.

=C2=A0=

Done!

=C2=A0

https://www.arin.net/participate/po= licy/nrpm/#6-5-3-subsequent-allocations-to-lirs

=C2=A0

Regards,

Jordi

@jordipalet

=C2=A0

<= u>=C2=A0

=C2=A0

El 19/11/20 13:26, "v6ops = en nombre de Gyan Mishra" <v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.com> e= scribi=C3=B3:

=C2=A0

v6ops pr= eso - "race to bottom slide" slightly modified - new proposal for= new /80 bottom so that we could actually make multiple /48s I mean /64s ac= tually wearable.=C2=A0 =C2=A0

A /64 would be the new /48 as we shifted = the IID by 16 bits shorter & making the prefix 16 bits longer.<= /span>

=C2=A0

/64 =3D cur= rent Bottom fixed based on 64 bit IID.

=C2=A0

Why /48's wearable is not possible today for= 2 reasons:

1. Large providers such a= s Verizon subscribers =3D 150M not including broadband and /24 equates to 1= 6M /48 way short and /20 even 160M but large providers as Verizon's of = the world need to scale to 1B or 7B.

= 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, R= FC 4291 would have=C2=A0to change the 64 bit fixed boundary requirement=C2= =A0for any handset to accept shorter prefix.=C2=A0 So we are stuck and 64 s= hare v2 is not possible w/o RFC 4291 changing.

=C2=A0

What if we made the new fixed= bottom a /80 meaning.=C2=A0 So that would essentially be the new bottom th= at ISPs cannot race any further since the standard would be fixed at the ne= w /80 bottom just as its fixed at the /64 bottom.=C2=A0 We just gave oursel= ves 16 bits to play with.

=C2=A0<= /p>

64 share v2 - Allocate /64 as it does today and that= would basically be equivalent to a /48 allocation. Nice!

/80 =3D New bottom =3D> Problem solved=C2=A0

/64 =3D= 64k /80s - wearable - so now both 3GPP and broadband=C2=A0 providers probl= em solved for segmentation

= /64 Current bottom

<= span style=3D"font-size:13.5pt;font-family:"Times New Roman",seri= f;color:red">/48 =3D 64k /64s

As = far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes up = to /80.=C2=A0 I think while we are changing RFC 4291 I think it would make = sense to allow for shorter prefixes maybe to any length or fix a a value th= at makes sense for shorter then /64.=C2=A0 So in the future if 3GPP can be = updated for shorter prefixes we could give out shorter as well which would = be a ton of prefixes.=C2=A0=C2=A0

How= ever, I think if we made the new bottom a /80, in reality the=C2=A0end site= allocation would be equivalent to a /48 so would not have to allow slaac r= eally to allow for shorter then /64.=C2=A0=C2=A0

=C2=A0

Although as they say - never = say never.."when you build - they will come"

=C2=A0

SLAAC would use random = IID generation schemes to generate the shorter 48 bit IID via RFC 4941 or s= table IID RFC 7217.

=C2=A0

From a privacy perspective for broadband users we would st= ill have 48 bit IID which in the scheme of things as the double edged sword= for operators & law enforcement scanning I think the address correlati= on attacks I think the 48 bits random IID for privacy extension, I think we= would=C2=A0be in good shape.=C2=A0

=C2=A0

This also solves the day 1 VLSM issue as w= ell for mixed host static, dhcpv6 & slaac as now we can have longer pre= fixes up=C2=A0 to /80.=C2=A0 =C2=A0

=C2=A0

This may solve some of the aviation issues= that Fred Templin is working on as well.=C2=A0=C2=A0

= =C2=A0

Also with Network Slicin= g to be mainstream with 5G=C2=A0 and proliferation of IoT devices I can see= end user allocations growing very quickly

=C2= =A0

AND =3D "NO RACE TO BOTTOM&qu= ot; possible even=C2=A0 as we would fix the new boundary at "/80"= as the new bottom so you cannot race down any further. Would be no differe= nt then the /64 boundary but now getting a 16 bit bonus out of the deal.=C2= =A0=

=C2=A0

IANA now does not have to dig into unallocating more ::/3s for larger allo= cations - see Slide 10 from v6ops preso below

= =C2=A0

Slide 10 in v6 ops preso

One of the reasons why 6MAN has defe= rred removing the 64 bit boundary is due to the=C2=A0 ISP =E2=80=9Crace to = the bottom=E2=80=9D fear that we are at the bottom giving out /64 to mobile= handsets that ISP=E2=80=99s will in theory do what history has shown us wh= at was done with IPv4 where due to address depletion issues and issues with= overlapping address space ISP=E2=80=99s made the broadband standard to dol= e out /32 WAN IP which is NAT port overloaded outside wan interface.=C2=A0 = NAT as well as CGNAT have solved issues with IPv4 shortage and overlapping = ranges allowing overlapping ranges to co-exist with NAT as well as now ISP= =E2=80=99s due to the risk of IPv4 address depletion made the standard a /3= 2 WAN IP with NAT port overloaded via PAT (Port Address translation) with p= rivate 192.168.1.0/24 subnet for SOHO hosts.=C2=A0

IPv6 on the other hand does not have a= ny risk of address depletion so you cannot compare what history has told us= with IPv4 to IPv6 and there is no other data point to be had.

On the = other side of the spectrum with 64share we are looking now at shorter prefi= xes and maybe an idea of creating and RFC 6177bis that allows a /48 per hum= an per mobile device.=C2=A0 Is that possible ???

https://www.iana.org/assignments/ipv6-address-space/ipv6-addres= s-space.xhtml

2000::/3 GUI

IAIA <=3D&= gt;RIR <=3D> ISP <=3D> End user Allocation

RIR allocations to Service Providers:

=C2= =A0=

For the massive block allocations for ISPs is= it tiered like this

/32 - General Starting point= for ISP allocation

/24-26 - Medium to Large=C2= =A0=

/19-20 - Exceptions and rare

=C2=A0

Since allocations are done block= wize and not linearly you have to account for future growth so generally ov= er allocate for growth next 20 years.=C2=A0 So with that the much larger al= locations.

=C2=A0

Wit= h that being said let's say for a typical large ISP /24 - that would yi= eld 16M /48s.=C2=A0 That still is small since most large ISPs like, we Veri= zon we want to scale to a billion as right now we have 150M and that's = just domestic not worldwide.=C2=A0 Safe best for large ISPs is we want to s= cale to the number of humans on the planet so 7 Billion is a good number.= =C2=A0 Also that does not account for broadband.=C2=A0 So for Verizon as an= example /48=C2=A0 per human is not possible.=C2=A0

=C2=A0

I think /48 per user site is sensible f= or the much smaller ISPS with few million subscriber base=C2=A0 but I think= an impossibility=C2=A0at least for the larger Verizon size ISP=E2=80=99s.= =C2=A0 Looking on IAIA allocation link I= don't see too many RIRs getting a /12.

https://www.iana.org/assignments/ipv6-unicast-address-assignme= nts/ipv6-unicast-address-assignments.xhtml

=C2=A0<= /u>

=C2=A0

=C2=A0

Gyan Mishra<= span style=3D"font-family:"Arial",sans-serif;color:black">=

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver = Spring, MD

=C2=A0

=

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.thei= pv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
<= /i>Silver Spring, MD


=

-= -

Gyan Mishra

Network Solutions Architect 

M 301 5= 02-1347
13101 Columbia Pike 
Silver Spring, MD

 

<= /div>

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


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3688646118_90724605-- From nobody Thu Nov 19 06:57:56 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C673A0ADE; Thu, 19 Nov 2020 06:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FonASXgdiX2; Thu, 19 Nov 2020 06:57:54 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 87AF33A1123; Thu, 19 Nov 2020 06:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1605797823; x=1606402623; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=gZahF8uR ccXZsKA/EmtFnznSX0FBbpnbO4YnZrvwwdo=; b=bg7E8/+bYaqmlOYu0DbfJrUw zAzB7El2bGyx+xjtx8TLfmgA3U7+mo498KbIU+m3r5sHJMZSTk7Wvwqk0kCUBb8C dwUGsQzyu11i4r1kray0UG1ji6DlVxvl4DCWar9FwGin+u3F5X3TSUOv0rp0w7BL r6nFLWQei35VQFZwunU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 19 Nov 2020 15:57:03 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 19 Nov 2020 15:57:03 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000468077.msg; Thu, 19 Nov 2020 15:57:02 +0100 X-MDRemoteIP: 2001:470:1f09:495:39a3:9029:40e2:ed12 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 19 Nov 2020 15:57:02 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=15925babf5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Thu, 19 Nov 2020 15:57:01 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations , 6MAN <6man@ietf.org> Message-ID: <1E62A56C-85BF-47C6-A554-1E296042E40A@consulintel.es> Thread-Topic: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <20201119141633.GC13005@Space.Net> In-Reply-To: <20201119141633.GC13005@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:57:56 -0000 Exactly! Blame vendors that did a bad job, not IETF or RIRs. Vendors should follow s= tandards, and if they not, pay for the consequences. Standards should not b= e "adapted" to vendors. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 19/11/20 15:19, "ipv6 en nombre de Gert Doering" escribi=C3=B3: Hi, On Thu, Nov 19, 2020 at 08:58:33AM -0500, Gyan Mishra wrote: > 3GPP gateway does not support DHCPv6 Why can this not be changed? A few 3GPP gateways vs. "billions of phones"? (Especially since 3G standards seems to already include DHCPv6) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michae= l Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Nov 19 07:11:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B63A0A4A; Thu, 19 Nov 2020 07:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34kb4UvICxQ0; Thu, 19 Nov 2020 07:11:32 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE9A3A09CC; Thu, 19 Nov 2020 07:11:32 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id g7so4782125pfc.2; Thu, 19 Nov 2020 07:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=trAS9BKtbDbqCZwlXjw4og0jDESO6gFugMbpSO2ZpiY=; b=SzuA5C+IZy5Lc+GPfiNFma6OfNu6rVKclGyzb/fX9fAMSi8TZh+meBOe5OBGZPuPss Q20sGIygPr130tSrQlgIKS0YIfAHWeTzI7F5DAEyGJVpa8YSQ3iQdg0oJwRcrLeWAZ30 pdV1HraYLUpBjUBFC2t4pApJzxhDpFWwmprbCllJ1AmCKbJHrjqdtwLe32gjwhT07yEy JSXLHA8PPbyrK70QDheV9DJlkDaJmboZhrRIBBXTAda5Knzir+4Pwxyu8bef5WCphKju AgaTMn3oj7vGLnaD5rjV73CMMdLvhIjAkg31yrDW1hL/nJzERzZkQalFLZBWwlOn4+84 +2VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=trAS9BKtbDbqCZwlXjw4og0jDESO6gFugMbpSO2ZpiY=; b=OdzJRqLi0OQt1Pa5j6f7sf+INIbDLZz8y2HJ9wF492n7+kGr9c2QlhYag0HaicyRFB qNGjVQPYWx6H1eMhqgYY27WX0od8tEjO39m2Trf9uo5A4IZsKYCmFJIOCnjB8ipZv4SM d84NUWE4sy19Gv+1vV95kGmnKVfLIitITkF46e6lN7cKf1jRKQitYPD8ccn5s2vBZ4N+ OYVlq+YV15Uf5TXwPFdNP+YRbQqQEXf8xdhmLkuD7yW7+7OQZRG3SyP9vAhkiTmkO/JZ R5bd52+/IZsdFhdwbZRgd56dh2fY7+ID5mJky1eUlcqFO50o4DKbq7M2yw9GbPfDPDM1 8Nyw== X-Gm-Message-State: AOAM530eZ78bcXHcCC+XY8++pFHIcBdYxY5/qAcLRwZSj0Lo1yI/EIAf MfslfJYEC3DdyJOQBgcqjBa7XOv+FGA5tLD3kieYD6yrOxA= X-Google-Smtp-Source: ABdhPJwVgEK93zHAR/FtdB6MzM0nXJ64CXlt7xEIQ6JLFRStnSK1l057O0tvXdjYS2vrijsu9cPJ14HF1KHQC4mZSIY= X-Received: by 2002:a17:90b:1490:: with SMTP id js16mr4904653pjb.215.1605798691881; Thu, 19 Nov 2020 07:11:31 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> In-Reply-To: From: Gyan Mishra Date: Thu, 19 Nov 2020 10:11:20 -0500 Message-ID: To: JORDI PALET MARTINEZ Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000009c472305b4772472" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:11:36 -0000 --0000000000009c472305b4772472 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jordi! On Thu, Nov 19, 2020 at 9:55 AM JORDI PALET MARTINEZ wrote: > Every RIR has their own policies, but in general they match very closely > (I tried very hard doing that thru policy proposals when it was making > sense, and this was the case for IPv6 initial and subsequent allocations)= . > > > > As explained a few emails ago =E2=80=A6 in general I will say that you on= ly have a > problem in LACNIC and AFRINIC if you don=E2=80=99t have your services the= re, or at > least the majority of those services. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 19/11/20 15:16, "v6ops en nombre de Gyan Mishra" < > v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.com> escribi=C3=B3: > > > > Jordi > > > > I am not sure if all RIRs for example ARIN if it or others are as liberal > as RIPE. > > > > Gyan > > > > On Thu, Nov 19, 2020 at 8:38 AM Gyan Mishra wrote= : > > > > Thanks Jordi! > > > > That solves one problem but does not solve the 64share v2 issue as we hav= e > to still modify > > RFC 4861 for mobile to accept shorter prefix. > > > > Thanks > > > > Gyan > > > > On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > > The right way to resolve this is very simple. > > > > Go to your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /48 for e= ach of my > subscribers, so I need a subsequent allocation, following the section > 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy > Manual, and this is my justification =E2=80=A6=E2=80=9D. > > > > Done! > > > > > https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocation= s-to-lirs > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" < > v6ops-bounces@ietf.org en nombre de hayabusagsm@gmail.com> escribi=C3=B3: > > > > v6ops preso - "race to bottom slide" slightly modified - new proposal for > new /80 bottom so that we could actually make multiple /48s I mean /64s > actually wearable. > > A /64 would be the new /48 as we shifted the IID by 16 bits shorter & > making the prefix 16 bits longer. > > > > /64 =3D current Bottom fixed based on 64 bit IID. > > /48 =3D 64k /64s - Due to current 3GPP architecture limitation we cannot > dole out shorter prefixes via 64share v2 even that Cameron proposed. Als= o > with the RA PD style trickery w/o A bit set as Lorenzo mentioned the host > would not accept the shorter prefix as it is expecting a 64 bit prefix fr= om > the 3GPP gateway. > > > > Why /48's wearable is not possible today for 2 reasons: > > 1. Large providers such as Verizon subscribers =3D 150M not including > broadband and /24 equates to 16M /48 way short and /20 even 160M but larg= e > providers as Verizon's of the world need to scale to 1B or 7B. > > 2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, > RFC 4291 would have to change the 64 bit fixed boundary requirement for a= ny > handset to accept shorter prefix. So we are stuck and 64 share v2 is not > possible w/o RFC 4291 changing. > > > > What if we made the new fixed bottom a /80 meaning. So that would > essentially be the new bottom that ISPs cannot race any further since the > standard would be fixed at the new /80 bottom just as its fixed at the /6= 4 > bottom. We just gave ourselves 16 bits to play with. > > > > 64 share v2 - Allocate /64 as it does today and that would basically be > equivalent to a /48 allocation. Nice! > > */80 =3D New bottom =3D> Problem solved * > > */64 =3D 64k /80s - wearable - so now both 3GPP and broadband providers > problem solved for segmentation* > > */64 Current bottom* > > */48 =3D 64k /64s* > > As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixe= s > up to /80. I think while we are changing RFC 4291 I think it would make > sense to allow for shorter prefixes maybe to any length or fix a a value > that makes sense for shorter then /64. So in the future if 3GPP can be > updated for shorter prefixes we could give out shorter as well which woul= d > be a ton of prefixes. > > However, I think if we made the new bottom a /80, in reality the end site > allocation would be equivalent to a /48 so would not have to allow slaac > really to allow for shorter then /64. > > > > Although as they say - never say never.."when you build - they will come" > > > > SLAAC would use random IID generation schemes to generate the shorter 48 > bit IID via RFC 4941 or stable IID RFC 7217. > > > > From a privacy perspective for broadband users we would still have 48 bit > IID which in the scheme of things as the double edged sword for operators= & > law enforcement scanning I think the address correlation attacks I think > the 48 bits random IID for privacy extension, I think we would be in good > shape. > > > > This also solves the day 1 VLSM issue as well for mixed host static, > dhcpv6 & slaac as now we can have longer prefixes up to /80. > > > > This may solve some of the aviation issues that Fred Templin is working o= n > as well. > > > > Also with Network Slicing to be mainstream with 5G and proliferation of > IoT devices I can see end user allocations growing very quickly > > > > AND =3D "NO RACE TO BOTTOM" possible even as we would fix the new bounda= ry > at "/80" as the new bottom so you cannot race down any further. Would be = no > different then the /64 boundary but now getting a 16 bit bonus out of the > deal. > > > > IANA now does not have to dig into unallocating more ::/3s for larger > allocations - see Slide 10 from v6ops preso below > > > > Slide 10 in v6 ops preso > > One of the reasons why 6MAN has deferred removing the 64 bit boundary is > due to the ISP =E2=80=9Crace to the bottom=E2=80=9D fear that we are at = the bottom giving > out /64 to mobile handsets that ISP=E2=80=99s will in theory do what hist= ory has > shown us what was done with IPv4 where due to address depletion issues an= d > issues with overlapping address space ISP=E2=80=99s made the broadband st= andard to > dole out /32 WAN IP which is NAT port overloaded outside wan interface. > NAT as well as CGNAT have solved issues with IPv4 shortage and overlappin= g > ranges allowing overlapping ranges to co-exist with NAT as well as now > ISP=E2=80=99s due to the risk of IPv4 address depletion made the standard= a /32 WAN > IP with NAT port overloaded via PAT (Port Address translation) with priva= te > 192.168.1.0/24 subnet for SOHO hosts. > > IPv6 on the other hand does not have any risk of address depletion so you > cannot compare what history has told us with IPv4 to IPv6 and there is no > other data point to be had. > > On the other side of the spectrum with 64share we are looking now at > shorter prefixes and maybe an idea of creating and RFC 6177bis that allow= s > a /48 per human per mobile device. Is that possible ??? > > > https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xh= tml > > 2000::/3 GUI > > IAIA <=3D>RIR <=3D> ISP <=3D> End user Allocation > > RIR allocations to Service Providers: > > > > For the massive block allocations for ISPs is it tiered like this > > /32 - General Starting point for ISP allocation > > /24-26 - Medium to Large > > /19-20 - Exceptions and rare > > > > Since allocations are done blockwize and not linearly you have to account > for future growth so generally over allocate for growth next 20 years. S= o > with that the much larger allocations. > > > > With that being said let's say for a typical large ISP /24 - that would > yield 16M /48s. That still is small since most large ISPs like, we Veriz= on > we want to scale to a billion as right now we have 150M and that's just > domestic not worldwide. Safe best for large ISPs is we want to scale to > the number of humans on the planet so 7 Billion is a good number. Also > that does not account for broadband. So for Verizon as an example /48 p= er > human is not possible. > > > > I think /48 per user site is sensible for the much smaller ISPS with few > million subscriber base but I think an impossibility at least for the > larger Verizon size ISP=E2=80=99s. Looking on IAIA allocation link I don= 't see > too many RIRs getting a /12. > > *https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-u= nicast-address-assignments.xhtml > * > > > > > > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-134713101 Columbia Pike > *Silver > Spring, MD > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-134713101 Columbia Pike > *Silver > Spring, MD > > > > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-134713101 Columbia Pike > *Silver > Spring, MD > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000009c472305b4772472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jordi!

On Thu, Nov 19, 2020 at 9:55 AM JORDI P= ALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:
=

Ever= y RIR has their own policies, but in general they match very closely (I tri= ed very hard doing that thru policy proposals when it was making sense, and= this was the case for IPv6 initial and subsequent allocations).<= /u>

=C2=A0

As explained a few emails ago =E2=80= =A6 in general I will say that you only have a problem in LACNIC and AFRINI= C if you don=E2=80=99t have your services there, or at least the majority o= f those services.

=C2=A0=

Regards,

Jordi

@jordipalet

=C2=A0

=C2=A0

=

<= /u>=C2=A0

El 19/11/20 15:16, "v6ops en nombre de Gyan Mishra"= <v6ops-boun= ces@ietf.org en nombre de hayabusagsm@gmail.com> escribi=C3=B3:

=C2=A0

Jor= di

=C2=A0

I am not sure if all RIRs for example ARIN if it or oth= ers are as liberal as RIPE.

=C2=A0

Gyan

=C2=A0=

On Thu, N= ov 19, 2020 at 8:38 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

=C2=A0

<= div>

Thanks Jordi!

= =C2=A0

That solves one problem but does not solve the 64share v2 issue= as we have to still modify=C2=A0

RFC 4861 for mobile to accept shorte= r prefix. =C2=A0

=C2=A0

Thanks=C2=A0

=C2=A0<= /p>

Gyan

=C2=A0

On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ <jordi.= palet=3D40consulintel.es@dmarc.ietf.org> wrote:

The right way to resolve this is very simple.=

=C2=A0

Go to your RIR (ARIN I guess) =E2=80=9CARIN I want to provide a /= 48 for each of my subscribers, so I need a subsequent allocation, following= the section 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource = Policy Manual, and this is my justification =E2=80=A6=E2=80=9D.

=C2=A0

Done!

= =C2=A0

https://www.arin.net/participate/policy= /nrpm/#6-5-3-subsequent-allocations-to-lirs

=C2=A0

Regards,

Jordi

=

@jordipalet

=C2=A0

=C2=A0

=C2=A0

El 19/11/20 = 13:26, "v6ops en nombre de Gyan Mishra" <v6ops-bounces@ietf.org en nombre= de hayabusagsm@= gmail.com> escribi=C3=B3:

<= div>

=C2=A0=

v6ops preso - "race to bottom slide" slightly modifie= d - new proposal for new /80 bottom so that we could actually make multiple= /48s I mean /64s actually wearable.=C2=A0 =C2=A0

<= p style=3D"margin-right:0cm;margin-bottom:0cm;margin-left:70.8pt;vertical-a= lign:baseline">A /64 would be = the new /48 as we shifted the IID by 16 bits shorter & making the prefi= x 16 bits longer.

=C2=A0

/64 =3D current Bottom fixed based on 64 bit IID.

/48 =3D 64k /64s - Due to current 3= GPP architecture limitation we cannot dole out shorter prefixes=C2=A0via 64= share v2 even that Cameron proposed.=C2=A0 Also with the RA PD style tricke= ry w/o A bit set as Lorenzo mentioned the host would not accept the shorter= prefix as it is expecting a 64 bit prefix from the 3GPP gateway.=

=C2=A0

Why /4= 8's wearable is not possible today for 2 reasons:<= /p>

1. Large providers such as Verizon subscribers =3D 1= 50M not including broadband and /24 equates to 16M /48 way short and /20 ev= en 160M but large providers as Verizon's of the world need to scale to = 1B or 7B.

2. 64share v2 even if= 3GPP arch allowed shorter prefixes /56 or even /48, RFC 4291 would have=C2= =A0to change the 64 bit fixed boundary requirement=C2=A0for any handset to = accept shorter prefix.=C2=A0 So we are stuck and 64 share v2 is not possibl= e w/o RFC 4291 changing.

=C2=A0=

What if we made the new fixed bottom a /80 mean= ing.=C2=A0 So that would essentially be the new bottom that ISPs cannot rac= e any further since the standard would be fixed at the new /80 bottom just = as its fixed at the /64 bottom.=C2=A0 We just gave ourselves 16 bits to pla= y with.

=C2=A0

64 share v2 - Allocate /64 as it does today and that would basi= cally be equivalent to a /48 allocation. Nice!

/80 =3D New bottom =3D> Problem solved=C2=A0

/64 = =3D 64k /80s - wearable - so now both 3GPP and broadband=C2=A0 providers pr= oblem solved for segmentation

/64 Current bottom

/48 =3D 64k /64s

=

As far as SLAAC goes we would modify RFC 4291 to allow = for longer prefixes up to /80.=C2=A0 I think while we are changing RFC 4291= I think it would make sense to allow for shorter prefixes maybe to any len= gth or fix a a value that makes sense for shorter then /64.=C2=A0 So in the= future if 3GPP can be updated for shorter prefixes we could give out short= er as well which would be a ton of prefixes.=C2=A0=C2=A0

However, I think if we made the new bottom a /80,= in reality the=C2=A0end site allocation would be equivalent to a /48 so wo= uld not have to allow slaac really to allow for shorter then /64.=C2=A0=C2= =A0

=C2=A0

Although as they say - never say never.."when you build - they = will come"

=C2=A0

<= p style=3D"margin-right:0cm;margin-bottom:0cm;margin-left:70.8pt;vertical-a= lign:baseline">SLAAC would use random IID generation schemes to generat= e the shorter 48 bit IID via RFC 4941 or stable IID RFC 7217.=

=C2=A0

From a pri= vacy perspective for broadband users we would still have 48 bit IID which i= n the scheme of things as the double edged sword for operators & law en= forcement scanning I think the address correlation attacks I think the 48 b= its random IID for privacy extension, I think we would=C2=A0be in good shap= e.=C2=A0

=C2=A0

This also solves the day 1 VLSM issue as well for mixed host st= atic, dhcpv6 & slaac as now we can have longer prefixes up=C2=A0 to /80= .=C2=A0 =C2=A0

=C2=A0

This may solve some of the aviation issues that Fred Temp= lin is working on as well.=C2=A0=C2=A0

=C2=A0

Also with Network Slicing to be m= ainstream with 5G=C2=A0 and proliferation of IoT devices I can see end user= allocations growing very quickly

<= span style=3D"font-family:"Times New Roman",serif">=C2=A0<= u>

AND =3D "NO RACE TO BOTTOM" = possible even=C2=A0 as we would fix the new boundary at "/80" as = the new bottom so you cannot race down any further. Would be no different t= hen the /64 boundary but now getting a 16 bit bonus out of the deal.=C2=A0<= /span>

=C2=A0

<= span style=3D"font-size:13.5pt;font-family:"Times New Roman",seri= f">IANA now does not have to dig into unallocating more ::/3s for larger al= locations - see Slide 10 from v6ops preso below

= =C2=A0

Slide 10 in v6 ops preso

One of the reasons why= 6MAN has deferred removing the 64 bit boundary is due to the=C2=A0 ISP =E2= =80=9Crace to the bottom=E2=80=9D fear that we are at the bottom giving out= /64 to mobile handsets that ISP=E2=80=99s will in theory do what history h= as shown us what was done with IPv4 where due to address depletion issues a= nd issues with overlapping address space ISP=E2=80=99s made the broadband s= tandard to dole out /32 WAN IP which is NAT port overloaded outside wan int= erface.=C2=A0 NAT as well as CGNAT have solved issues with IPv4 shortage an= d overlapping ranges allowing overlapping ranges to co-exist with NAT as we= ll as now ISP=E2=80=99s due to the risk of IPv4 address depletion made the = standard a /32 WAN IP with NAT port overloaded via PAT (Port Address transl= ation) with private 192= .168.1.0/24 subnet for SOHO hosts.=C2=A0

IPv6 on the other h= and does not have any risk of address depletion so you cannot compare what = history has told us with IPv4 to IPv6 and there is no other data point to b= e had.

On the other side of the spectrum with 64share we are loo= king now at shorter prefixes and maybe an idea of creating and RFC 6177bis = that allows a /48 per human per mobile device.=C2=A0 Is that possible ??? <= /span>

https://www.iana.org/assignments/= ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=3D>RIR <=3D> ISP <=3D>= ; End user Allocation

RIR allocations to Se= rvice Providers:

= =C2=A0

For the massive block allocations for ISPs is it tiered like = this

/32 - General Starting point for ISP= allocation

/24-26 - Medium to Large=C2=A0<= /span>

/19-20 - Exceptions and rare<= u>

=C2=A0

Since allocations = are done blockwize and not linearly you have to account for future growth s= o generally over allocate for growth next 20 years.=C2=A0 So with that the = much larger allocations.

=C2=A0

With that being said let's say for a typical large= ISP /24 - that would yield 16M /48s.=C2=A0 That still is small since most = large ISPs like, we Verizon we want to scale to a billion as right now we h= ave 150M and that's just domestic not worldwide.=C2=A0 Safe best for la= rge ISPs is we want to scale to the number of humans on the planet so 7 Bil= lion is a good number.=C2=A0 Also that does not account for broadband.=C2= =A0 So for Verizon as an example /48=C2=A0 per human is not possible.=C2=A0=

=C2=A0

I t= hink /48 per user site is sensible for the much smaller ISPS with few milli= on subscriber base=C2=A0 but I think an impossibility=C2=A0at least for the= larger Verizon size ISP=E2=80=99s.=C2=A0 Looking on IAIA allocation link I don't see too many RIRs getting a /= 12.

https://www.iana.org/= assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignmen= ts.xhtml

=C2=A0

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-left:70.8pt">=C2=A0

=

Gyan Mishra=

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike<= /a>=C2=A0
Silver Spring, MD

=C2=A0<= u>

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

=
**********************************************
IPv4 is over
Are y= ou ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it.=

---------= -----------------------------------------------------------
IETF IPv6 wo= rking group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailma= n/listinfo/ipv6
----------------------------------------------------= ----------------

--

--

Gyan Mishra<= span style=3D"font-family:"Arial",sans-serif;color:black">=

Network Solutions Architect=C2=A0

M 301 502-1347
1310= 1 Columbia Pike=C2=A0
Silver Spring, MD<= /p>

= =C2=A0

___________________________= ____________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6= ops


***************************************= *******
IPv4 is over
Are you ready for the new Internet ?
http://www.thei= pv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--0000000000009c472305b4772472-- From nobody Thu Nov 19 07:33:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402813A03F8; Thu, 19 Nov 2020 07:33:26 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 c5hlIJcueskq; Thu, 19 Nov 2020 07:33:24 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1B13A0ADF; Thu, 19 Nov 2020 07:33:24 -0800 (PST) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:8134:785f:b705:6f79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 4B3C64E11AFD; Thu, 19 Nov 2020 15:33:24 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id E54C645A0782; Thu, 19 Nov 2020 16:33:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: otroan@employees.org In-Reply-To: Date: Thu, 19 Nov 2020 16:33:21 +0100 Cc: 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ Content-Transfer-Encoding: quoted-printable Message-Id: <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> To: Gyan Mishra X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:33:26 -0000 > On 19 Nov 2020, at 14:58, Gyan Mishra wrote: >=20 > You would need a new option. It would likely be useful for the = requesting router to indicate interest in the option. Even hinting at = what prefix size it was expecting. > Now can you explain to me again the reasons why this approach is = better than using the existing DHPCv6 protocol packets? >=20 > 3GPP gateway does not support DHCPv6 3GPP gateway doesn't support new option. What's your point? Ole= From nobody Thu Nov 19 07:36:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142ED3A0B56 for ; Thu, 19 Nov 2020 07:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxT3p5h3FzOv for ; Thu, 19 Nov 2020 07:36:42 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587FE3A0B49 for ; Thu, 19 Nov 2020 07:36:42 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id o9so8558196ejg.1 for ; Thu, 19 Nov 2020 07:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hJdKs49Yd3P35X76Yj6DwlhGajrRbKeAN5aH77qCz5o=; b=YGRcf8fbjwVmFVrc7uB27kO0NfhCMIzOwERqI7bHFT7+PSEFSdHGamw/Wk4ZA2P3qw yL0QLgSN32DLod8V9IJu5XooktLdqWKYN00o78UklXc5RhidIh0XUotbkww4ZfGfHiPN Pmp6pr7DireofDiH/7xvZr/cHT+ufDPdesON548i4cqi6ihLHVOC+zcUQ0JS2lfPhy59 bxxHNS/XF1WLA35kKTYHRoMp8KkT0HD5AK6A7R+xndpbtZdiNKetjcC23SwbC7s02uoo H6lQXeFyK23EO80vyc6RNVvi7SFQKTxkNNVu3ohzeN98zy/erSjYg7R2QSTl8nDeSYYl 17Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hJdKs49Yd3P35X76Yj6DwlhGajrRbKeAN5aH77qCz5o=; b=iRDernM7JkoKr+Z6L9FNgL3adykoU4klP4fxd6xAUn24649wZ6g6c+bxyzEjWSgbJ3 FRCdFG3VD75C80QexdEaV3NU3/I2BFqGRZwuHhIBrt2mCvB9lEhmDmZbmFbmYeyd1i0f gLYc/i/XGMP25FymW+g4Xyi7fK3YVY1dKPwWHSSivl1nj9lfXRj04oxnkR0vrr+yz49Y 23D8NLZ9E477E3tpEiPJmOUbpblTmlXwZSaIk55vvR57dbH+qnMJxQrSBUjIZScVSKB6 fhKge8oWIuA6yGHN+FdQCd7J+19LtknFMkraFbaYmXY3JenuiRcplhv7+43JsFz7zlcX fMjA== X-Gm-Message-State: AOAM531yuo2uUvlrTEINto38Vy/ovB0oBu2452ysXqctA8MYAEDRmc5K VDrWtfL9ggkJL1SdEndZMuxWwGtp5GdeFI3LzR1YfQ== X-Google-Smtp-Source: ABdhPJx9T5g80W7SOLsW5YUhmbrZ3PgbRI/T5I/UTpvq7C295GaULVcLX+AO3ZYo9Nwp5yZpS0fzMkX9uRhTj7NXLYA= X-Received: by 2002:a17:906:8058:: with SMTP id x24mr29683123ejw.272.1605800200587; Thu, 19 Nov 2020 07:36:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Thu, 19 Nov 2020 08:36:29 -0700 Message-ID: To: Alexander Azimov Cc: tcpm , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:36:44 -0000 On Thu, Nov 19, 2020 at 3:49 AM Alexander Azimov wro= te: > > Dear colleagues, > > I have added in the cc both v6op and tcpm for a reason and let me explain= why. > > It's clear that we are moving forward with load balancing that uses flow = label (FL). And the pressure will increase with SRv6 adoption. But at the m= oment wide adoption of FL-based load-balancing may create significant issue= s for TCP Anycast services. > > RFC6437 suggests putting hash from 5-tuple into FL value. And as far as I= know, there is no document that updates this behavior. This description is= perfectly fine, but what is implemented in the Linux kernel is different: = FL is carrying hash from 5-tuple with an additional seed, and this seed is = randomly changed after each RTO/SYN_RTO event. Here are related patches: > > https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.m= tv.corp.google.com/ > https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@he= rbertland.com/ > https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/ > Alexander, The initial intent of the Linux flow label code was that the hash was persistent for the lifetime of the connection; in fact we fixed a nasty bug where the hash would change when a connection moved to TW state causing some firewalls not to see the final ACK so they can remove state. The feature where the flow hash is recalculated for a failing connection should be optional and not the default behavior. If this isn't what the implementation is doing I can take it up on Linux netdev to fix it. Have you been able to show this behavior is actually happening on a running system? Tom > > This is a great thing by the way because in the data center environment w= ith multiple equal paths it gives a way to have pseudo-multipath TCP which = jumps between paths in case of an outage. There might be interest to write = down an informational document for this. > > But the problem happens when TCP flows start jumping between anycast poin= ts. If anycast service provides connection tracking (L7/TCP proxy, stateful= L4 balancer) the 'jump' may redirect traffic to another point, and with th= e adoption of FL load balancing by the transit providers - to another locat= ion, where no TCP state is available. In other words, an established TCP se= ssion breaks after RTO event. And it's not just a theory - we already faced= this kind of issue in our network, and it is really hard to debug. > > I wonder what you think is a proper solution: > > Making FL related RTO change as knob instead of default behavior; > Adding negotiation behavior in TCP; > Something else? > > I'm looking forward to your advice. If there is a document that describes= the above problem - please give me a reference. > > -- > Best regards, > Alexander Azimov > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 19 14:03:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1AA3A12E1; Thu, 19 Nov 2020 14:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvuWW-qLYOeD; Thu, 19 Nov 2020 14:03:35 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6700F3A12D6; Thu, 19 Nov 2020 14:03:35 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id 62so5476415pgg.12; Thu, 19 Nov 2020 14:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZcezKs13sUTTVFi6yH5UNN90gkO5LJCdvK0wQHmnDmo=; b=OTXYDbBwjASzb3yNyQiy4as2deb2V2RPQlJF8q/sL1JZsXq29W13RXlzWYFBnSvoNe MLF2ufzA4XSxI9x26Ui+Y3BIP+DnfQyt5LTmmoRgDnkd0Gi4XvCLxbuo8D/w6knsCUZk 6D+RxOEOorYxXZRf/mXkjjm0K4cNoVNS4hZWAtWUe8kOpdSbUPLayIaZF6D96rgLDjJy 0pzsrkctB+IB2CDI+Wub1A1hhKvOB3LXDbIAz2GbkK4/kLrjBdS2XXROzkeZUV07zKe7 +YmrWBgZ/aQscxPKhdQ9AedXDrLNMi9bblotBVmadR/rTfQ3Q2cYue3+0XpanVbBfzG2 pCqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZcezKs13sUTTVFi6yH5UNN90gkO5LJCdvK0wQHmnDmo=; b=kON/3+RSPvqWH90Ip+O0eq/ZBLfLl13Mi7Ke8OdBz6CsiNXsHy0nulybUj5T+FEHyB Qn3Ggn+slS6TuW6XI7U0nvgYHMGOw9ZYiS54AQfIIr9a48GZR5CrP5EO+irzmwXuyAM1 b2iLVA6Bs/AuG49VZ4Afy8hiGXK/t1PooVRXoDdrfjKsASUMU4c8TPjLozQnyKqV3GVf 6GFT6ZuOHLMP3w9iqV79xN9bSQiHcoUS9RNQZ/pTqKKTbHv6NFABgMGTedRabjCMk8SA qtmplpuKMIqiDgtyNruacjERbwkNaa3KPc+58hw9vbOlnNbq3kIBqwnA/s2Y7IxWMd+R RFRw== X-Gm-Message-State: AOAM530KjhD9/WKz97EUs7tTJAdhNOqP/pQHqtYKLh1h+2bxKJiyk/0E NkIpnwzERMjWGhhZUSd6Kvf7SXN3ZwWS2zfiIoY= X-Google-Smtp-Source: ABdhPJwrTgg9kWlrn7hAgU0N2UHS5+kbD+MmLMxD1/oNDlX60bLade7qX6b/8kJnr5UoODu6FthMP+Y4kaaroarEn6g= X-Received: by 2002:a65:56c8:: with SMTP id w8mr14415111pgs.383.1605823414566; Thu, 19 Nov 2020 14:03:34 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> In-Reply-To: <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> From: Gyan Mishra Date: Thu, 19 Nov 2020 17:03:05 -0500 Message-ID: To: otroan@employees.org Cc: 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ Content-Type: multipart/alternative; boundary="0000000000003281f905b47ce63a" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 22:03:38 -0000 --0000000000003281f905b47ce63a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2020 at 10:33 AM wrote: > > > > On 19 Nov 2020, at 14:58, Gyan Mishra wrote: > > > > You would need a new option. It would likely be useful for the > requesting router to indicate interest in the option. Even hinting at wha= t > prefix size it was expecting. > > Now can you explain to me again the reasons why this approach is better > than using the existing DHPCv6 protocol packets? > > > > 3GPP gateway does not support DHCPv6 > > 3GPP gateway doesn't support new option. What's your point? > The point of the v6ops presentation and this email thread is how to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of the deck= you compiled a list of options and of the two I had highlighted in red were the 64share v2 Cameron=E2=80=99s option and the variable slaac option. So on the call thi= s morning Lorenzo shot down 64share v2 shorter prefix option as even if the 3GPP architecture was updated to support longer prefixes and even is the 3GPP gateway was able to send a shorter prefix with A flag not set, all mobile devices per Lorenzo=E2=80=99s point would be broken as they would no= t accept the shorter let=E2=80=99s say /56 prefix to build the slaac 128 bit address= . So the bottom line is the 64share v2 won=E2=80=99t work unless we update RFC 4= 291 and remove the 64 bit boundary. So we are back to square uno - no viable solution So now we had thrown out the longer >64 due to race to bottom worries which I and others believe is Fud and as described in slide 10 of the v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. So a happy medium /80 fixed boundary I came up with that I think solves a lot of the issue and not just the 3GPP initial segmentation of downstream devices problem statement. Since we have to update RFC 4291 for 64share v2 to work anyways to allow for shorter prefixes, why not instead create a new bottom at /80 giving 16 bits more of prefix length and shrinking the IID down to 48 bits. Doing so you would not even have to update the 3GPP architecture as I don=E2=80=99t = know if that would fly or not. Also this solves a few other problems at the same time. > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is mainstream for operators for static addressing on router and switch infrastructure and dhcpv6 subnets longer prefixes for network infrastructure appliance clusters, NFV/VNF virtualization and server farms. On host subnets where there is a chance of mix of slaac hosts with dhcpv6 devices the prefix length is stuck at /64. So on these mix addressing host subnets we cannot do longer prefixes following our ND cache hard limit mantra to prevent ND cache exhaustion issues as described in RFC 6164. So with the /80 new fixed boundary shifting prefix length 16 bits longer and shortening the IID by 16 bits gives resolved the 3GPP issue which 64share can work as is and subtending to downstream devices will now work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 for broadband not all operators have adopted the shorter prefix lengths /56 or /48 recommendations and now that=E2=80=99s not an issue as the /64 would n= ow suffice. >From an operators perspective that gain allows at least for 3GPP massive growth and subtending with a single /64 allows the operators such as Verizon with massive subscriber base worldwide can stay with current allocations and don=E2=80=99t have to ask for /10. As 5G gets rolled out with Enhanced VPN framework and Network slicing paradigm, the demand for shorter blocks and wearable multiple /48 will be our new reality. Making that 16 bit shift now to /80 making a /64 the new /48 will give broadband and 3GPP subscribers a ton of space to subtending their networks we would be set for the future. Especially with IOT the demand for subtending will continue to grow astronomically. Also IANA does not have to get start in allocating the other /3 and other available blocks. Lots of problems being solved here with a fixed /80 new boundary. Also with the existing random IID generation schemes which we have tested on Linux kernel can do longer prefixes using RFC 4941 privacy extension or RFC 7217 stable IID. Win-Win for all. Ole --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000003281f905b47ce63a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Also with the existing random II= D generation schemes which we have tested on Linux kernel can do longer pre= fixes using RFC 4941 privacy extension or RFC 7217 stable IID.

Win-Win for all.

Ole

On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org> wrote:


> On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
> You would need a new option. It would likely be useful for the request= ing router to indicate interest in the option. Even hinting at what prefix = size it was expecting.
> Now can you explain to me again the reasons why this approach is bette= r than using the existing DHPCv6 protocol packets?
>
>=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6

3GPP gateway doesn't support new option. What's your point?


=C2=A0 =C2=A0 The point of the v6ops presentation and this emai= l thread is how to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2= =A0in slide 1 of the deck you compiled a list of options and of the two I h= ad highlighted in red were the 64share v2 Cameron=E2=80=99s option and the = variable slaac option.=C2=A0 So on the call this morning Lorenzo shot down = 64share v2 shorter prefix option as even if the 3GPP architecture was updat= ed to support longer prefixes and even is the 3GPP gateway was able to send= a shorter prefix with A flag not set, all mobile devices per Lorenzo=E2=80= =99s point would be broken as they would not accept the shorter let=E2=80= =99s say /56 prefix to build the slaac 128 bit address.=C2=A0 So the bottom= line is the 64share v2 won=E2=80=99t work unless we update RFC 4291 and re= move the 64 bit boundary.

=C2=A0So we are back to square uno - no viable solution=C2=A0

=C2=A0So now we had thrown out the = longer >64 due to race to bottom worries which I and others believe is F= ud and as described in slide 10 of the v6ops =E2=80=9Crace to the bottom sl= ide=E2=80=9D. =C2=A0

So = a happy medium /80 fixed boundary I came up with that I think solves a lot = of the issue and not just the 3GPP initial segmentation of downstream devic= es problem statement.

Si= nce we have to update RFC 4291 for 64share v2 to work anyways to allow for = shorter prefixes, why not instead create a new bottom at /80 giving 16 bits= more of prefix length and shrinking the IID down to 48 bits.=C2=A0 Doing s= o you would not even have to update the 3GPP architecture as I don=E2=80=99= t know if that would fly or not.=C2=A0 Also this solves a few other problem= s at the same time.
As I mentioned in the v6ops deck presented that v= lsm 0 to 128 is mainstream for operators for static addressing on router an= d switch infrastructure and dhcpv6 subnets longer prefixes for network infr= astructure appliance clusters, NFV/VNF virtualization and server farms.=C2= =A0 On host subnets where there is a chance of mix of slaac hosts with dhcp= v6 =C2=A0devices the prefix length is stuck at /64.=C2=A0 So on these mix a= ddressing host subnets we cannot do longer prefixes following our ND cache = hard limit mantra to prevent ND cache exhaustion issues as described in RFC= 6164.

So with the /80 n= ew fixed boundary shifting prefix length 16 bits longer and shortening the = IID by 16 bits gives resolved the 3GPP issue which 64share can work as is a= nd subtending to downstream devices will now work as a /64 is now equivalen= t to a /48 with 64k /80s.=C2=A0 Also BCP-690 for broadband not all operator= s have adopted the shorter prefix lengths /56 or /48 recommendations =C2=A0= and now that=E2=80=99s not an issue as the /64 would now suffice.

From an operators perspective tha= t gain allows at least for 3GPP massive growth and subtending with a single= /64 allows the operators such as Verizon with massive subscriber base worl= dwide can stay with current allocations and don=E2=80=99t have to ask for /= 10. =C2=A0

As 5G gets ro= lled out with Enhanced VPN framework and Network slicing paradigm, the dema= nd for shorter blocks and wearable multiple /48 will be our new reality. = =C2=A0

Making that 16 bi= t shift now to /80 making a /64 the new /48 will give broadband and 3GPP su= bscribers a ton of space to subtending their networks we would be set for t= he future.=C2=A0 Especially with IOT the demand for subtending will continu= e to grow astronomically.

Also IANA does not have to get start in allocating the other /3 and other= available blocks.

Lots = of problems being solved here with a fixed /80 new boundary.=C2=A0

--

As this paradigm shift takes place, operators around = the world will be clamoring after the RIR for massive blocks, I would say l= ess than /8 more like a /5 or /4.=C2=A0 If you do the math on the way high = side a /10 yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR wh= ich is tiny number with the number of large size operators worldwide.=C2=A0=

With the massive prolif= eration of IOT devices and just about every home or office appliance on 5G,= the problem now gets way exacerbated.=C2=A0

As this evolution unfolds IANA will be scrambling to r= elease all remaining /3 as well as all unallocated blocks to subvert RIR IP= v6 address space depletion.

Playing Monday night quarterbacking in hindsight we would never think t= his would happen in a million years, but we would see IPv6 on the verge of = address space depletion.=C2=A0 Unheard of but it can happen as the saying g= oes =E2=80=9Cwhen you build - they will come=E2=80=9D.

It is true as history has taught that very i= mportant lesson.

The ans= wer to this real world problem is in the subject heading of this thread.

This would also fix the da= y 1 issue I mentioned allowing mix of slaac devices with static and DHCPv6 = up to /80.

The variable = slaac solution draft proposes a new =C2=A0RA PIO flag that would be used to= signal longer prefixes, and would provide backwards compatibility so that = devices not supporting woud ignore the flag =C2=A0and devices on newer code= supporting would use the flag.=C2=A0 We definitely don=E2=80=99t want to i= mpact any existing devices on the existing 64 bit slaac boundary standard.<= /div>

Dmytro has tested the so= lution on Linux kernel signaling RA PIO flag and was able to successfully t= est any length mask and random IID generation both RFC 4941 privacy extensi= on as well as stable IID RFC 7217.

If everyone is in agreemen= t with what I have stated on this thread, I would like to ask the chairs fo= r WG adoption as this is a WG effort.

I would like to garner support from all 6MAN members with ful= l consensus to change the existing RFC 4941 /64 fixed boundary to /80 fixed= boundary.

Kind Regards= =C2=A0

Gyan

On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
I am missing something in your reasoning.
You seem to say at one point that (to paraphrase) "we can't do thi= s
because it does not work with the existing UE software".
Any new solution where a UE delegates based on any change of any kind
(including lengthening the prefix, shortening the prefix, or magically
incanting new prefixes) requires that the UE be upgraded to know what to do with the information.=C2=A0 I do not see how that differentiates any of =
the solutions. (Except "don't do anything", which I think we = do not want
to take.)

Yours,
Joel

On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>
>
> On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org
> <mailto:o= troan@employees.org>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.c= om
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > You would need a new option. It would likely = be useful for the
>=C2=A0 =C2=A0 =C2=A0requesting router to indicate interest in the optio= n. Even hinting
>=C2=A0 =C2=A0 =C2=A0at what prefix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 > Now can you explain to me again the reasons w= hy this approach is
>=C2=A0 =C2=A0 =C2=A0better than using the existing DHPCv6 protocol pack= ets?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not supp= ort DHCPv6
>
>=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't support new option. What&#= 39;s your point?
>
>
>
>=C2=A0 =C2=A0 =C2=A0 The point of the v6ops presentation and this email= thread is how to
> =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 o= f the deck you compiled
> a list of options and of the two I had highlighted in red were the > 64share v2 Cameron=E2=80=99s option and the variable slaac option.=C2= =A0 So on the
> call this morning Lorenzo shot down 64share v2 shorter prefix option a= s
> even if the 3GPP architecture was updated to support longer prefixes a= nd
> even is the 3GPP gateway was able to send a shorter prefix with A flag=
> not set, all mobile devices per Lorenzo=E2=80=99s point would be broke= n as they
> would not accept the shorter let=E2=80=99s say /56 prefix to build the= slaac 128
> bit address.=C2=A0 So the bottom line is the 64share v2 won=E2=80=99t = work unless we
> update RFC 4291 and remove the 64 bit boundary.
>
>=C2=A0 =C2=A0So we are back to square uno - no viable solution
>
>=C2=A0 =C2=A0So now we had thrown out the longer >64 due to race to = bottom worries
> which I and others believe is Fud and as described in slide 10 of the =
> v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>
> So a happy medium /80 fixed boundary I came up with that I think solve= s
> a lot of the issue and not just the 3GPP initial segmentation of
> downstream devices problem statement.
>
> Since we have to update RFC 4291 for 64share v2 to work anyways to all= ow
> for shorter prefixes, why not instead create a new bottom at /80 givin= g
> 16 bits more of prefix length and shrinking the IID down to 48 bits.= =C2=A0
> Doing so you would not even have to update the 3GPP architecture as I =
> don=E2=80=99t know if that would fly or not.=C2=A0 Also this solves a = few other
> problems at the same time.
>
>
> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is
> mainstream for operators for static addressing on router and switch > infrastructure and dhcpv6 subnets longer prefixes for network
> infrastructure appliance clusters, NFV/VNF virtualization and server <= br> > farms.=C2=A0 On host subnets where there is a chance of mix of slaac h= osts
> with dhcpv6 =C2=A0devices the prefix length is stuck at /64.=C2=A0 So = on these mix
> addressing host subnets we cannot do longer prefixes following our ND =
> cache hard limit mantra to prevent ND cache exhaustion issues as
> described in RFC 6164.
>
> So with the /80 new fixed boundary shifting prefix length 16 bits long= er
> and shortening the IID by 16 bits gives resolved the 3GPP issue which =
> 64share can work as is and subtending to downstream devices will now <= br> > work as a /64 is now equivalent to a /48 with 64k /80s.=C2=A0 Also BCP= -690
> for broadband not all operators have adopted the shorter prefix length= s
> /56 or /48 recommendations =C2=A0and now that=E2=80=99s not an issue a= s the /64 would
> now suffice.
>
>=C2=A0 From an operators perspective that gain allows at least for 3GPP=
> massive growth and subtending with a single /64 allows the operators <= br> > such as Verizon with massive subscriber base worldwide can stay with <= br> > current allocations and don=E2=80=99t have to ask for /10.
>
> As 5G gets rolled out with Enhanced VPN framework and Network slicing =
> paradigm, the demand for shorter blocks and wearable multiple /48 will=
> be our new reality.
>
> Making that 16 bit shift now to /80 making a /64 the new /48 will give=
> broadband and 3GPP subscribers a ton of space to subtending their
> networks we would be set for the future.=C2=A0 Especially with IOT the= demand
> for subtending will continue to grow astronomically.
>
> Also IANA does not have to get start in allocating the other /3 and > other available blocks.
>
> Lots of problems being solved here with a fixed /80 new boundary.
>
> Also with the existing random IID generation schemes which we have > tested on Linux kernel can do = longer prefixes using RFC 4941 privacy
> extension or RFC 7217 stable IID.
>
> Win-Win for all.
>
>=C2=A0 =C2=A0 =C2=A0Ole
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>
--
--0000000000003cc5a505b4915965-- From nobody Fri Nov 20 14:41:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AF33A0B04; Fri, 20 Nov 2020 14:41:11 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 nuwa6d6Oitbl; Fri, 20 Nov 2020 14:41:10 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C323A0AFD; Fri, 20 Nov 2020 14:41:10 -0800 (PST) Received: from [192.168.10.178] (dhcp21719716422.blix.com [217.197.164.22]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D450E4E11CAB; Fri, 20 Nov 2020 22:41:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Fri, 20 Nov 2020 23:41:06 +0100 Message-Id: <7E87C304-802E-4B2F-9DDB-687C91C29E21@employees.org> References: Cc: "Joel M. Halpern" , 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ In-Reply-To: To: Gyan Mishra X-Mailer: iPhone Mail (18B92) Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 22:41:12 -0000 > On 20 Nov 2020, at 23:27, Gyan Mishra wrote: >=20 > The mobile device would receive a shorter prefix let=E2=80=99s say /56 but= not know what to do with it since it=E2=80=99s expecting a /64. >=20 > So that a major gap and the only solution is updating RFC 4291 removing th= e 64 bit boundary allowing for shorter prefix and now as well longer prefixe= s to work and in that respect now provide the much needed parity with static= and DHCPv6 which can do any prefix length. I am sorry, but I don=E2=80=99t follow how you got to that conclusion.=20 Address assignment !=3D prefix delegation.=20 In the plethora of emails I have lost track. Would you be able to reiterate t= he sets of technical problems you desire solved? Cheers, Ole= From nobody Fri Nov 20 15:02:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ADB3A0BA8; Fri, 20 Nov 2020 15:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9yjYNhQZhpe; Fri, 20 Nov 2020 15:02:43 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 59EB83A0BA4; Fri, 20 Nov 2020 15:02:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CdBsH14H2z6G8wH; Fri, 20 Nov 2020 15:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605913363; bh=31MEMLCuc99vUmZeAPKOOsJS52tyKQ1poZ7VXzwTqtg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RDcBSKvSe+16hcCh/AlGRGEJ+tzJ/MPmoc3ZDdjSEPPoAs0+sPXcm+hmigXE5it3l 5UlCjUAks1AF9K87MdebMH1B+8WAFccmgMGeucziVt/DzrbtsfRkYg8UpcgZVGjzR+ vM/MpVAZY2e4M4B3BRUTogcIz2deexAuD3oZZpl0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CdBsG3WsCz6G8l5; Fri, 20 Nov 2020 15:02:42 -0800 (PST) To: Gyan Mishra Cc: 6MAN <6man@ietf.org>, IPv6 Operations References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> From: "Joel M. Halpern" Message-ID: <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> Date: Fri, 20 Nov 2020 18:02:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 23:02:46 -0000 Gyan, separate from Ole's comments about the difference between address assignment and delegation, I have another problem following the reasoning below. Yes, the proposal for using shorter prefixes to enable UE to perform delegation will require changes to the UE. But I do not see how that is relevant to any choice we are trying to make. Any solution that enables UE to delegate addresses (in the sense that they lack the capability now) willr equire changes to the UE. Yoru proposed change to the SLAAC length if anything does more violence to the software (depending upon the exact software architecture.) So I do not follow how you got to your conclusion. Yours, Joel On 11/20/2020 5:27 PM, Gyan Mishra wrote: > > (top posting) > > As I would like to clear the air as well as get to the crux of the v6ops > presentation development results as well as next steps for this draft > and the 6man variable slaac solutions draft: > > > This thread was in light of Lorenzo kindly pointing out that upgrading > 3GPP is not all that needs be done for Cameron’s 64share v2 to work - as > all mobile devices would stop working- as slaac would not would be > effectively broken. > > The mobile device would receive a shorter prefix let’s say /56 but not > know what to do with it since it’s expecting a /64. > > So that a major gap and the only solution is updating RFC 4291 removing > the 64 bit boundary allowing for shorter prefix and now as well longer > prefixes to work and in that respect now provide the much needed parity > with static and DHCPv6 which can do any prefix length. > > So that is a drastic change to RFC 4291.  However, in light of this > development on the v6ops 109 call, my balancing act of best of both > worlds and also to keep everyone happy to make this a WG effort for this > change by proposing in the subject heading /80 fixed boundary and not a > variable slaac change allowing all bits vlsm. > > Basically stealing 16 bits for network prefix out of the IID, still > keeping the fixed boundary so longer than 80 would NOT  be allowed. > > A /64 would now be equivalent to a /48 with now 64k /80’s. > > This /80 would keep the operators and law enforcement happy as now 16 > bits less helps traceability but is still long enough for 48 bits of > privacy to IP correlation by attackers. > > This /80 would be a nice optimal balance as it would keep wired > broadband and mobile handset customers happy respecting their privacy as > the 16 bits less of heuristics is minimal change that will impact IP > correlation by attackers. > > The IID as it’s less than the current 64 bit cannot use MAC based EUI64 > IID, which is not a problem as Mac based IID is not recommended as most > all manufacturers use RFC 4941 and I believe Linux flavors some use > stable IID RFC 7217. > > So now the 48 bit IID would require a random IID generation schema so > can use either RFC 4941 privacy extension or RFC 7217 stable IID to > generate the 48 bit IID. > > 3GPP subtending would now work issue mentioned in the problem statement > draft without even having to use 64share as now longer prefixes up to > /80 would be supported allowing for further segmentation of downstream > devices. > > This also would help wired broadband and soon fixed 5G broadband > proliferation where operators in light of BCP RIPE-690, are sill > allocation via BNG gateways a /64, now operators  can stay as-is, as the > /64 would now be allowed to be further segmented supporting 64k /80s, > way more then enough for SOHO. > > This would allow 64share if used by 3GPP operators to work and would not > require the 3GPP specification to be updated.  We don’t know even if the > 3GPP architecture specification can be updated to support shorter > prefixes and if the 3GPP consortium of operators would agree to it.  So > that is all theoretical of that change is possible. > > As with 5G with Enhanced VPN framework SR steering of high priority > traffic, traffic isolation and Network slicing capabilities becomes > mainstream and will soon be a real world reality and as fixed 5G > broadband proliferation takes off and mobile 5G == the idea of a > wearable /48 will really be many /48s. > > As this paradigm shift takes place, operators around the world will be > clamoring after the RIR for massive blocks, I would say less than /8 > more like a /5 or /4.  If you do the math on the way high side a /10 > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is > tiny number with the number of large size operators worldwide. > > With the massive proliferation of IOT devices and just about every home > or office appliance on 5G, the problem now gets way exacerbated. > > As this evolution unfolds IANA will be scrambling to release all > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 > address space depletion. > > Playing Monday night quarterbacking in hindsight we would never think > this would happen in a million years, but we would see IPv6 on the verge > of address space depletion.  Unheard of but it can happen as the saying > goes “when you build - they will come”. > > It is true as history has taught that very important lesson. > > The answer to this real world problem is in the subject heading of this > thread. > > This would also fix the day 1 issue I mentioned allowing mix of slaac > devices with static and DHCPv6 up to /80. > > The variable slaac solution draft proposes a new  RA PIO flag that would > be used to signal longer prefixes, and would provide backwards > compatibility so that devices not supporting woud ignore the flag  and > devices on newer code supporting would use the flag.  We definitely > don’t want to impact any existing devices on the existing 64 bit slaac > boundary standard. > > Dmytro has tested the solution on Linux kernel signaling RA PIO flag and > was able to successfully test any length mask and random IID generation > both RFC 4941 privacy extension as well as stable IID RFC 7217. > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > If everyone is in agreement with what I have stated on this thread, I > would like to ask the chairs for WG adoption as this is a WG effort. > > I would like to garner support from all 6MAN members with full consensus > to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary. > > Kind Regards > > Gyan > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > wrote: > > I am missing something in your reasoning. > You seem to say at one point that (to paraphrase) "we can't do this > because it does not work with the existing UE software". > Any new solution where a UE delegates based on any change of any kind > (including lengthening the prefix, shortening the prefix, or magically > incanting new prefixes) requires that the UE be upgraded to know > what to > do with the information.  I do not see how that differentiates any of > the solutions. (Except "don't do anything", which I think we do not > want > to take.) > > Yours, > Joel > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > On Thu, Nov 19, 2020 at 10:33 AM > > >> wrote: > > > > > > > >      > On 19 Nov 2020, at 14:58, Gyan Mishra > > >      >> wrote: > >      > > >      > You would need a new option. It would likely be useful for the > >     requesting router to indicate interest in the option. Even > hinting > >     at what prefix size it was expecting. > >      > Now can you explain to me again the reasons why this > approach is > >     better than using the existing DHPCv6 protocol packets? > >      > > >      >     3GPP gateway does not support DHCPv6 > > > >     3GPP gateway doesn't support new option. What's your point? > > > > > > > >      The point of the v6ops presentation and this email thread is > how to > > “extend a /64” in the 3GPP use case  in slide 1 of the deck you > compiled > > a list of options and of the two I had highlighted in red were the > > 64share v2 Cameron’s option and the variable slaac option.  So on > the > > call this morning Lorenzo shot down 64share v2 shorter prefix > option as > > even if the 3GPP architecture was updated to support longer > prefixes and > > even is the 3GPP gateway was able to send a shorter prefix with A > flag > > not set, all mobile devices per Lorenzo’s point would be broken > as they > > would not accept the shorter let’s say /56 prefix to build the > slaac 128 > > bit address.  So the bottom line is the 64share v2 won’t work > unless we > > update RFC 4291 and remove the 64 bit boundary. > > > >   So we are back to square uno - no viable solution > > > >   So now we had thrown out the longer >64 due to race to bottom > worries > > which I and others believe is Fud and as described in slide 10 of > the > > v6ops “race to the bottom slide”. > > > > So a happy medium /80 fixed boundary I came up with that I think > solves > > a lot of the issue and not just the 3GPP initial segmentation of > > downstream devices problem statement. > > > > Since we have to update RFC 4291 for 64share v2 to work anyways > to allow > > for shorter prefixes, why not instead create a new bottom at /80 > giving > > 16 bits more of prefix length and shrinking the IID down to 48 bits. > > Doing so you would not even have to update the 3GPP architecture > as I > > don’t know if that would fly or not.  Also this solves a few other > > problems at the same time. > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > > mainstream for operators for static addressing on router and switch > > infrastructure and dhcpv6 subnets longer prefixes for network > > infrastructure appliance clusters, NFV/VNF virtualization and server > > farms.  On host subnets where there is a chance of mix of slaac > hosts > > with dhcpv6  devices the prefix length is stuck at /64.  So on > these mix > > addressing host subnets we cannot do longer prefixes following > our ND > > cache hard limit mantra to prevent ND cache exhaustion issues as > > described in RFC 6164. > > > > So with the /80 new fixed boundary shifting prefix length 16 bits > longer > > and shortening the IID by 16 bits gives resolved the 3GPP issue > which > > 64share can work as is and subtending to downstream devices will now > > work as a /64 is now equivalent to a /48 with 64k /80s.  Also > BCP-690 > > for broadband not all operators have adopted the shorter prefix > lengths > > /56 or /48 recommendations  and now that’s not an issue as the > /64 would > > now suffice. > > > >  From an operators perspective that gain allows at least for 3GPP > > massive growth and subtending with a single /64 allows the operators > > such as Verizon with massive subscriber base worldwide can stay with > > current allocations and don’t have to ask for /10. > > > > As 5G gets rolled out with Enhanced VPN framework and Network > slicing > > paradigm, the demand for shorter blocks and wearable multiple /48 > will > > be our new reality. > > > > Making that 16 bit shift now to /80 making a /64 the new /48 will > give > > broadband and 3GPP subscribers a ton of space to subtending their > > networks we would be set for the future.  Especially with IOT the > demand > > for subtending will continue to grow astronomically. > > > > Also IANA does not have to get start in allocating the other /3 and > > other available blocks. > > > > Lots of problems being solved here with a fixed /80 new boundary. > > > > Also with the existing random IID generation schemes which we have > > tested on Linux kernel can do longer p > refixes > using RFC 4941 privacy > > extension or RFC 7217 stable IID. > > > > Win-Win for all. > > > >     Ole > > > > -- > > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > From nobody Fri Nov 20 16:36:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7A3A0D84; Fri, 20 Nov 2020 16:36:37 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6HVa1rWxzSy; Fri, 20 Nov 2020 16:36:35 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800CE3A0D81; Fri, 20 Nov 2020 16:36:35 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id 10so9495238pfp.5; Fri, 20 Nov 2020 16:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rBN6a2iW3HFdo+sTSO/4mFAYaYBS+z4yld3///7IDkQ=; b=kV8TF+ltOv3B5qxeR7Kg2Ok9KF4nf3VTZjW0WShAj7OrbKK9fYU0w6d+I9XTwJSjR0 2aHau11PBsJ+iz3zre3lywuGJmB3mg0SnDC1PXgJVn1MJID/Q93VoRVYzwI3QrWKbFam HRvEBb3WApukJ2L40JUH8taA8vT5TjtP/lWBV4A/2NrYyGoBKfbaNLP/ByjJXiAugOuP dyMccYDQj5rTBmlQwKv3EXfF9WVwfdUGs7/w43z/YQPMgIW7uaMrnWune3t5iOu9IVH9 NsgoppOfQS9dmtyyLJ6+vAND+BFdOt8LptLGMU1zOmgTjfsbwuwHUgbyXaZE4cyOpcml xmZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rBN6a2iW3HFdo+sTSO/4mFAYaYBS+z4yld3///7IDkQ=; b=WY/cYOovGmBm8Lo86rWPyYAgyYKgzvMWC5CnwWYD6EUDaQYRMmlNJopTd5oqAHu83C iloK9+Gkx9rort9JqqK8xRmaDt5KNtoxQj3kNPehBJr4mfwEjCKa5osmZLoRYJsN29rT RcIqmtEb+LUeSmpXa3vzrHCDlJXdSQkcPOO+ohydiAQWwxmWeZEl14z8elZTzbJejVBI nAfKKaQt8bpM+tU6OeGcg4qGPIcvhMK2iQkJ7COz8Lu2NISKTaLIs2HwT2Rk0x2UpSYk 7gIdQaPoWwQwuMNJAs8de4OXujSZ/zQwcN+oHxsUq6ReI1M/6TUT2u1Xln9lPRfKsqFW FZWw== X-Gm-Message-State: AOAM532bLAfifZulG9H84zkqtUkrwD+bx+amx2aasd37pjiD8pKJjw5F WEIbrogOfw2Ds+SpAoC/9l+QxxL/lsQWaSnkUNE= X-Google-Smtp-Source: ABdhPJwEqJMs4fGKCKgBC3rTsp/rqfJzw12JleMN8lkJuW4qpFP7OFVz/Z903zwuU5PHfiJonQhkWwwZb5W2kGlZJkM= X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr13052618pjx.112.1605918993913; Fri, 20 Nov 2020 16:36:33 -0800 (PST) MIME-Version: 1.0 References: <7E87C304-802E-4B2F-9DDB-687C91C29E21@employees.org> In-Reply-To: <7E87C304-802E-4B2F-9DDB-687C91C29E21@employees.org> From: Gyan Mishra Date: Fri, 20 Nov 2020 19:36:23 -0500 Message-ID: To: Ole Troan Cc: 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ , "Joel M. Halpern" Content-Type: multipart/alternative; boundary="0000000000002b9bce05b4932776" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 00:36:37 -0000 --0000000000002b9bce05b4932776 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ole In-line On Fri, Nov 20, 2020 at 5:41 PM Ole Troan wrote: > > > > On 20 Nov 2020, at 23:27, Gyan Mishra wrote: > > > > The mobile device would receive a shorter prefix let=E2=80=99s say /56 = but not > know what to do with it since it=E2=80=99s expecting a /64. > > > > So that a major gap and the only solution is updating RFC 4291 removing > the 64 bit boundary allowing for shorter prefix and now as well longer > prefixes to work and in that respect now provide the much needed parity > with static and DHCPv6 which can do any prefix length. > > I am sorry, but I don=E2=80=99t follow how you got to that conclusion. > Address assignment !=3D prefix delegation. 3GPP Gateway does not support PD I summarized in the last email. We can start with the subject line that you had in the email you had sent a earlier =E2=80=9Cextending a /64=E2=80=9D as that is the main issue = and is part of the problem statement draft. This is in the context of 3GPP gateway proving a via RA a /64 so how can the UE segment the /64 to downstream devices. 3GPP gateway does not support PD and can only send a /64. We can extend a single /64 via PD RA 64share technique but the UE need more then a /64 for downstream devices since a /64 cannot be segmented. Even if we were able to get 3GPP architecture to send shorter prefix, we would still need mobile devices to accept /56 via RA since PD is not supported. So this would require updating RFC 4291 removing the 64 bit boundary so that slaac shorter prefix will work. > > > In the plethora of emails I have lost track. Would you be able to > reiterate the sets of technical problems you desire solved? > > Cheers, > Ole --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002b9bce05b4932776 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ole=C2=A0

In-line=C2=A0

On Fri, Nov = 20, 2020 at 5:41 PM Ole Troan <o= troan@employees.org> wrote:


> On 20 Nov 2020, at 23:27, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
> The mobile device would receive a shorter prefix let=E2=80=99s say /56= but not know what to do with it since it=E2=80=99s expecting a /64.
>
> So that a major gap and the only solution is updating RFC 4291 removin= g the 64 bit boundary allowing for shorter prefix and now as well longer pr= efixes to work and in that respect now provide the much needed parity with = static and DHCPv6 which can do any prefix length.

I am sorry, but I don=E2=80=99t follow how you got to that conclusion.
Address assignment !=3D prefix delegation.
<= br>
=C2=A0 =C2=A0 3GPP Gateway does not support PD

=C2=A0 =C2=A0 I summarize= d in the last email.

=C2= =A0 =C2=A0We can start with the subject line that you had in the email you = had sent a earlier =E2=80=9Cextending a /64=E2=80=9D as that is the main is= sue and is part of the problem statement draft.

=
This is in the context of 3GPP gateway proving a vi= a RA a /64 so how can the UE segment the /64 to downstream devices. =C2=A0<= /div>

3GPP gateway does not su= pport PD and can only send a /64.

We can extend a single /64 via PD RA 64share technique but the UE= need more then a /64 for downstream devices since a /64 cannot be segmente= d. =C2=A0

Even if we wer= e able to get 3GPP architecture to send shorter prefix, we would still need= mobile devices to accept /56 via RA since PD is not supported.

So this would require updating RFC = 4291 removing the 64 bit boundary so that slaac shorter prefix will work.


In the plethora of emails I have lost track. Would you be able to reiterate= the sets of technical problems you desire solved?

Cheers,
Ole
--


Gyan Mish= ra

Network So= lutions Archi= tect=C2=A0

M 301 502-1347
13101 C= olumbia Pike=C2=A0
Silver Spring, MD


=
--0000000000002b9bce05b4932776-- From nobody Fri Nov 20 16:59:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449F93A0DCC; Fri, 20 Nov 2020 16:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgxH1jdu1oV4; Fri, 20 Nov 2020 16:59:13 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF8C3A0DCA; Fri, 20 Nov 2020 16:59:12 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id d17so5766070plr.5; Fri, 20 Nov 2020 16:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dn4nVIwrUfml34oVDnuGPy4TPFkd/3E7onyHhhod2fU=; b=gKO84zA3xxW8WMZn+GXz5Tcq61vhQhJAGxYR4AhnC2ActB0eiaLxZuKhZLjCSqon+J Gd/cGGR8zpes5QRoEQww+TAvcNBgJ71fGn6S0nk7gXoDYQyMzUYenldrGl5WsSxvoMQK 8YCftHxVe6o9mphU4Ng0sUz+rSk0j2ulw8o9SR6rh5JVAHO1Hjzm0Z0hPbBndPcegfHH Mtvw75DAtHshZO4C6gCWC285Zk9mlUoEybjopkYe9SQun3KwgL99SqnreW/U554CvfEN y69RKgEoZqTB01jEkV5H6hG2VyoPdtGIVSUULFRCb0nI8ijWf54Vi0K7enz3otqSyyf7 +7sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dn4nVIwrUfml34oVDnuGPy4TPFkd/3E7onyHhhod2fU=; b=kNfdFB4P6UJpsWlMBGefbt+feWPhHOC6mY8P9Yo3aJ+8znE7bBCujtrMtyyi+YgGIv d4zyKc87w5p4C7WQ+ZTRCoYMsqQy676ZRxwr2egOQcYNSl38pJfYTEFZw15U3wIro43v I6yMylqEE9+QV5jo+i0yR68Sj6ejHlIcQRg/Isbx/fzorNzJsnX5k2+yjNEyYyqkfoYU zG27XtZpjOclmtDkIAPau+YkB5mp2CfQKNb+FVIkCncpDXKkLJivPzFEu89ytt4uSke2 EJLzeK0lpdoTRMQNi/TPZciZIquqGzrRI3dXSaumojHhJKy7ntbpF6P3Y56nMWadLatB BeVA== X-Gm-Message-State: AOAM531CVoRXaLOj2vxBOxTE/8sDCf+nHSVkGIFVrt3pRINAiyGRf9fT J63TK7tFPw/GSCaASNlmPfFVvbxzYobvZAO7ixIk+W14ELQ= X-Google-Smtp-Source: ABdhPJw0We8O5mG8S5xI0xBjybgqFubsi4qquXTABaP/QSO171pqu1tLIKTHVVzdc33z4Fq2ydENF0XGAXiXGLwEE2g= X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr16708270pll.22.1605920352049; Fri, 20 Nov 2020 16:59:12 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> In-Reply-To: <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> From: Gyan Mishra Date: Fri, 20 Nov 2020 19:58:52 -0500 Message-ID: To: "Joel M. Halpern" Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000001f1bfb05b493787b" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 00:59:16 -0000 --0000000000001f1bfb05b493787b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Joel In-line On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern wrote= : > Gyan, separate from Ole's comments about the difference between address > assignment and delegation, I have another problem following the > reasoning below. > > Yes, the proposal for using shorter prefixes to enable UE to perform > delegation will require changes to the UE. Gyan> Agreed. So that change would be to RFC 4291 64 bit boundary to allow for longer prefix. Do you agree? If you don=E2=80=99t agree what do think the change would be to allow the U= E to accept shorter prefix from the 3GPP gateway? > > But I do not see how that is relevant to any choice we are trying to make= . > Any solution that enables UE to delegate addresses (in the sense that > they lack the capability now) willr equire changes to the UE. Gyan> If the UE receives a /56 via RA it could delegate /64 to downstream > devices. No change needed to delegate /64, however a change is needed t= o > accept /56 via RA. If 3GPP gateway supported PD - problem solved but that=E2=80=99s not th= e case and that does not sound like it will ever change even with 5G. > Gyan> The UE needs to be able to accept shorter prefix. That=E2=80=99s = the IPV6 specification change that requires removal of the 64 bit boundary. Yoru > proposed change to the SLAAC length if anything does more violence to > the software (depending upon the exact software architecture.) Gyan> What violence to software. There would be more violence to software if we removed the 64 bit boundary and allowed slaac to support any vlsm prefix lengths. My /80 proposal would just shift the boundary 16 bits to /80. Hosts on the same subnet with two different masks would not be on-net to each other as on different subnets. The router would be configured with the two subnets /64 and /80 subnet to support the two device types. The solution would be a simple RA PIO flag that is set and older hosts not upgraded would be backwards compatible and so would only support 64 bit boundary by ignoring flag. Hosts upgraded to support would understand the flag and be able to support longer mask up to /80. > > > So I do not follow how you got to your conclusion. > > Yours, > Joel > > On 11/20/2020 5:27 PM, Gyan Mishra wrote: > > > > (top posting) > > > > As I would like to clear the air as well as get to the crux of the v6op= s > > presentation development results as well as next steps for this draft > > and the 6man variable slaac solutions draft: > > > > > > This thread was in light of Lorenzo kindly pointing out that upgrading > > 3GPP is not all that needs be done for Cameron=E2=80=99s 64share v2 to = work - as > > all mobile devices would stop working- as slaac would not would be > > effectively broken. > > > > The mobile device would receive a shorter prefix let=E2=80=99s say /56 = but not > > know what to do with it since it=E2=80=99s expecting a /64. > > > > So that a major gap and the only solution is updating RFC 4291 removing > > the 64 bit boundary allowing for shorter prefix and now as well longer > > prefixes to work and in that respect now provide the much needed parity > > with static and DHCPv6 which can do any prefix length. > > > > So that is a drastic change to RFC 4291. However, in light of this > > development on the v6ops 109 call, my balancing act of best of both > > worlds and also to keep everyone happy to make this a WG effort for thi= s > > change by proposing in the subject heading /80 fixed boundary and not a > > variable slaac change allowing all bits vlsm. > > > > Basically stealing 16 bits for network prefix out of the IID, still > > keeping the fixed boundary so longer than 80 would NOT be allowed. > > > > A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s. > > > > This /80 would keep the operators and law enforcement happy as now 16 > > bits less helps traceability but is still long enough for 48 bits of > > privacy to IP correlation by attackers. > > > > This /80 would be a nice optimal balance as it would keep wired > > broadband and mobile handset customers happy respecting their privacy a= s > > the 16 bits less of heuristics is minimal change that will impact IP > > correlation by attackers. > > > > The IID as it=E2=80=99s less than the current 64 bit cannot use MAC bas= ed EUI64 > > IID, which is not a problem as Mac based IID is not recommended as most > > all manufacturers use RFC 4941 and I believe Linux flavors some use > > stable IID RFC 7217. > > > > So now the 48 bit IID would require a random IID generation schema so > > can use either RFC 4941 privacy extension or RFC 7217 stable IID to > > generate the 48 bit IID. > > > > 3GPP subtending would now work issue mentioned in the problem statement > > draft without even having to use 64share as now longer prefixes up to > > /80 would be supported allowing for further segmentation of downstream > > devices. > > > > This also would help wired broadband and soon fixed 5G broadband > > proliferation where operators in light of BCP RIPE-690, are sill > > allocation via BNG gateways a /64, now operators can stay as-is, as th= e > > /64 would now be allowed to be further segmented supporting 64k /80s, > > way more then enough for SOHO. > > > > This would allow 64share if used by 3GPP operators to work and would no= t > > require the 3GPP specification to be updated. We don=E2=80=99t know ev= en if the > > 3GPP architecture specification can be updated to support shorter > > prefixes and if the 3GPP consortium of operators would agree to it. So > > that is all theoretical of that change is possible. > > > > As with 5G with Enhanced VPN framework SR steering of high priority > > traffic, traffic isolation and Network slicing capabilities becomes > > mainstream and will soon be a real world reality and as fixed 5G > > broadband proliferation takes off and mobile 5G =3D=3D the idea of a > > wearable /48 will really be many /48s. > > > > As this paradigm shift takes place, operators around the world will be > > clamoring after the RIR for massive blocks, I would say less than /8 > > more like a /5 or /4. If you do the math on the way high side a /10 > > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is > > tiny number with the number of large size operators worldwide. > > > > With the massive proliferation of IOT devices and just about every home > > or office appliance on 5G, the problem now gets way exacerbated. > > > > As this evolution unfolds IANA will be scrambling to release all > > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 > > address space depletion. > > > > Playing Monday night quarterbacking in hindsight we would never think > > this would happen in a million years, but we would see IPv6 on the verg= e > > of address space depletion. Unheard of but it can happen as the saying > > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. > > > > It is true as history has taught that very important lesson. > > > > The answer to this real world problem is in the subject heading of this > > thread. > > > > This would also fix the day 1 issue I mentioned allowing mix of slaac > > devices with static and DHCPv6 up to /80. > > > > The variable slaac solution draft proposes a new RA PIO flag that woul= d > > be used to signal longer prefixes, and would provide backwards > > compatibility so that devices not supporting woud ignore the flag and > > devices on newer code supporting would use the flag. We definitely > > don=E2=80=99t want to impact any existing devices on the existing 64 bi= t slaac > > boundary standard. > > > > Dmytro has tested the solution on Linux kernel signaling RA PIO flag an= d > > was able to successfully test any length mask and random IID generation > > both RFC 4941 privacy extension as well as stable IID RFC 7217. > > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > > > If everyone is in agreement with what I have stated on this thread, I > > would like to ask the chairs for WG adoption as this is a WG effort. > > > > I would like to garner support from all 6MAN members with full consensu= s > > to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundar= y. > > > > Kind Regards > > > > Gyan > > > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > > wrote: > > > > I am missing something in your reasoning. > > You seem to say at one point that (to paraphrase) "we can't do this > > because it does not work with the existing UE software". > > Any new solution where a UE delegates based on any change of any ki= nd > > (including lengthening the prefix, shortening the prefix, or > magically > > incanting new prefixes) requires that the UE be upgraded to know > > what to > > do with the information. I do not see how that differentiates any = of > > the solutions. (Except "don't do anything", which I think we do not > > want > > to take.) > > > > Yours, > > Joel > > > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > > > > On Thu, Nov 19, 2020 at 10:33 AM > > > > >> > wrote: > > > > > > > > > > > > > On 19 Nov 2020, at 14:58, Gyan Mishra > > > > > > >> wrote: > > > > > > > > You would need a new option. It would likely be useful fo= r > the > > > requesting router to indicate interest in the option. Even > > hinting > > > at what prefix size it was expecting. > > > > Now can you explain to me again the reasons why this > > approach is > > > better than using the existing DHPCv6 protocol packets? > > > > > > > > 3GPP gateway does not support DHCPv6 > > > > > > 3GPP gateway doesn't support new option. What's your point? > > > > > > > > > > > > The point of the v6ops presentation and this email thread i= s > > how to > > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 = of the deck you > > compiled > > > a list of options and of the two I had highlighted in red were t= he > > > 64share v2 Cameron=E2=80=99s option and the variable slaac optio= n. So on > > the > > > call this morning Lorenzo shot down 64share v2 shorter prefix > > option as > > > even if the 3GPP architecture was updated to support longer > > prefixes and > > > even is the 3GPP gateway was able to send a shorter prefix with = A > > flag > > > not set, all mobile devices per Lorenzo=E2=80=99s point would be= broken > > as they > > > would not accept the shorter let=E2=80=99s say /56 prefix to bui= ld the > > slaac 128 > > > bit address. So the bottom line is the 64share v2 won=E2=80=99t= work > > unless we > > > update RFC 4291 and remove the 64 bit boundary. > > > > > > So we are back to square uno - no viable solution > > > > > > So now we had thrown out the longer >64 due to race to bottom > > worries > > > which I and others believe is Fud and as described in slide 10 o= f > > the > > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. > > > > > > So a happy medium /80 fixed boundary I came up with that I think > > solves > > > a lot of the issue and not just the 3GPP initial segmentation of > > > downstream devices problem statement. > > > > > > Since we have to update RFC 4291 for 64share v2 to work anyways > > to allow > > > for shorter prefixes, why not instead create a new bottom at /80 > > giving > > > 16 bits more of prefix length and shrinking the IID down to 48 > bits. > > > Doing so you would not even have to update the 3GPP architecture > > as I > > > don=E2=80=99t know if that would fly or not. Also this solves a= few other > > > problems at the same time. > > > > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > > > mainstream for operators for static addressing on router and > switch > > > infrastructure and dhcpv6 subnets longer prefixes for network > > > infrastructure appliance clusters, NFV/VNF virtualization and > server > > > farms. On host subnets where there is a chance of mix of slaac > > hosts > > > with dhcpv6 devices the prefix length is stuck at /64. So on > > these mix > > > addressing host subnets we cannot do longer prefixes following > > our ND > > > cache hard limit mantra to prevent ND cache exhaustion issues as > > > described in RFC 6164. > > > > > > So with the /80 new fixed boundary shifting prefix length 16 bit= s > > longer > > > and shortening the IID by 16 bits gives resolved the 3GPP issue > > which > > > 64share can work as is and subtending to downstream devices will > now > > > work as a /64 is now equivalent to a /48 with 64k /80s. Also > > BCP-690 > > > for broadband not all operators have adopted the shorter prefix > > lengths > > > /56 or /48 recommendations and now that=E2=80=99s not an issue = as the > > /64 would > > > now suffice. > > > > > > From an operators perspective that gain allows at least for 3GP= P > > > massive growth and subtending with a single /64 allows the > operators > > > such as Verizon with massive subscriber base worldwide can stay > with > > > current allocations and don=E2=80=99t have to ask > > for /10. > > > > > > As 5G gets rolled out with Enhanced VPN framework and Network > > slicing > > > paradigm, the demand for shorter blocks and wearable multiple /4= 8 > > will > > > be our new reality. > > > > > > Making that 16 bit shift now to /80 making a /64 the new /48 wil= l > > give > > > broadband and 3GPP subscribers a ton of space to subtending thei= r > > > networks we would be set for the future. Especially with IOT th= e > > demand > > > for subtending will continue to grow astronomically. > > > > > > Also IANA does not have to get start in allocating the other /3 > and > > > other available blocks. > > > > > > Lots of problems being solved here with a fixed /80 new boundary= . > > > > > > Also with the existing random IID generation schemes which we ha= ve > > > tested on Linux kernel can do longer p > > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > >refixes > > using RFC 4941 privacy > > > extension or RFC 7217 stable IID. > > > > > > Win-Win for all. > > > > > > Ole > > > > > > -- > > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000001f1bfb05b493787b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel

In-line=C2=A0

On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
<= /div>
Gyan, separate from Ole's comments a= bout the difference between address
assignment and delegation, I have another problem following the
reasoning below.

Yes, the proposal for using shorter prefixes to enable UE to perform
delegation will require changes to the UE.=C2=A0
=C2=A0 =C2=A0
=C2=A0 =C2=A0 Gyan> Agreed.=C2= =A0 So that change would be to RFC 4291 64 bit boundary to allow for longer= prefix.=C2=A0 Do you agree? =C2=A0

If you don=E2=80=99t agree what do think the change would be to= allow the UE to accept shorter prefix from the 3GPP gateway?

But I do not see how that is relevant to any choice we are trying to make.<= br> Any solution that enables UE to delegate addresses (in the sense that
they lack the capability now) willr equire changes to the UE. =C2=A0


Gyan> If the UE receives a /56 via RA it could delegat= e /64 to downstream devices.=C2=A0 No change needed to delegate =C2=A0/64, = however a change is needed to accept /56 via RA. =C2=A0

=C2=A0 =C2=A0 If 3GPP gateway supported PD - problem solved but that= =E2=80=99s not the case and that does not sound like it will ever change ev= en with 5G.
=C2=A0
=C2=A0 =C2=A0Gyan> The UE n= eeds to be able to accept shorter prefix.=C2=A0 That=E2=80=99s the IPV6 spe= cification change that requires removal of the 64 bit boundary.

Yoru
proposed change to the SLAAC length if anything does more violence to
the software (depending upon the exact software architecture.)
=

=C2=A0 =C2=A0Gyan> What vi= olence to software.=C2=A0 There would be more violence to software if we re= moved the 64 bit boundary and allowed slaac to support any vlsm prefix leng= ths.

My /80 proposal wou= ld just shift the boundary 16 bits to /80.

Hosts on the same subnet with two different masks would = not be on-net to each other as on different subnets.=C2=A0 The router would= be configured with the two subnets /64 and /80 subnet to support the two d= evice types.
The solution would be a simple RA PIO f= lag that is set and older hosts not upgraded would be backwards compatible = and so would only support 64 bit boundary by ignoring flag. Hosts upgraded = to support would understand the flag and be able to support longer mask up = to /80.


So I do not follow how you got to your conclusion.

Yours,
Joel

On 11/20/2020 5:27 PM, Gyan Mishra wrote:
>
> (top posting)
>
> As I would like to clear the air as well as get to the crux of the v6o= ps
> presentation development results as well as next steps for this draft =
> and the 6man variable slaac solutions draft:
>
>
> This thread was in light of Lorenzo kindly pointing out that upgrading=
> 3GPP is not all that needs be done for Cameron=E2=80=99s 64share v2 to= work - as
> all mobile devices would stop working- as slaac would not would be > effectively broken.
>
> The mobile device would receive a shorter prefix let=E2=80=99s say /56= but not
> know what to do with it since it=E2=80=99s expecting a /64.
>
> So that a major gap and the only solution is updating RFC 4291 removin= g
> the 64 bit boundary allowing for shorter prefix and now as well longer=
> prefixes to work and in that respect now provide the much needed parit= y
> with static and DHCPv6 which can do any prefix length.
>
> So that is a drastic change to RFC 4291.=C2=A0 However, in light of th= is
> development on the v6ops 109 call, my balancing act of best of both > worlds and also to keep everyone happy to make this a WG effort for th= is
> change by proposing in the subject heading /80 fixed boundary and not = a
> variable slaac change allowing all bits vlsm.
>
> Basically stealing 16 bits for network prefix out of the IID, still > keeping the fixed boundary so longer than 80 would NOT =C2=A0be allowe= d.
>
> A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s.
>
> This /80 would keep the operators and law enforcement happy as now 16 =
> bits less helps traceability but is still long enough for 48 bits of <= br> > privacy to IP correlation by attackers.
>
> This /80 would be a nice optimal balance as it would keep wired
> broadband and mobile handset customers happy respecting their privacy = as
> the 16 bits less of heuristics is minimal change that will impact IP <= br> > correlation by attackers.
>
> The IID as it=E2=80=99s less than the current 64 bit cannot use MAC ba= sed EUI64
> IID, which is not a problem as Mac based IID is not recommended as mos= t
> all manufacturers use RFC 4941 and I believe Linux flavors some use > stable IID RFC 7217.
>
> So now the 48 bit IID would require a random IID generation schema so =
> can use either RFC 4941 privacy extension or RFC 7217 stable IID to > generate the 48 bit IID.
>
> 3GPP subtending would now work issue mentioned in the problem statemen= t
> draft without even having to use 64share as now longer prefixes up to =
> /80 would be supported allowing for further segmentation of downstream=
> devices.
>
> This also would help wired broadband and soon fixed 5G broadband
> proliferation where operators in light of BCP RIPE-690, are sill
> allocation via BNG gateways a /64, now operators =C2=A0can stay as-is,= as the
> /64 would now be allowed to be further segmented supporting 64k /80s, =
> way more then enough for SOHO.
>
> This would allow 64share if used by 3GPP operators to work and would n= ot
> require the 3GPP specification to be updated.=C2=A0 We don=E2=80=99t k= now even if the
> 3GPP architecture specification can be updated to support shorter
> prefixes and if the 3GPP consortium of operators would agree to it.=C2= =A0 So
> that is all theoretical of that change is possible.
>
> As with 5G with Enhanced VPN framework SR steering of high priority > traffic, traffic isolation and Network slicing capabilities becomes > mainstream and will soon be a real world reality and as fixed 5G
> broadband proliferation takes off and mobile 5G =3D=3D the idea of a <= br> > wearable /48 will really be many /48s.
>
> As this paradigm shift takes place, operators around the world will be=
> clamoring after the RIR for massive blocks, I would say less than /8 <= br> > more like a /5 or /4.=C2=A0 If you do the math on the way high side a = /10
> yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is=
> tiny number with the number of large size operators worldwide.
>
> With the massive proliferation of IOT devices and just about every hom= e
> or office appliance on 5G, the problem now gets way exacerbated.
>
> As this evolution unfolds IANA will be scrambling to release all
> remaining /3 as well as all unallocated blocks to subvert RIR IPv6 > address space depletion.
>
> Playing Monday night quarterbacking in hindsight we would never think =
> this would happen in a million years, but we would see IPv6 on the ver= ge
> of address space depletion.=C2=A0 Unheard of but it can happen as the = saying
> goes =E2=80=9Cwhen you build - they will come=E2=80=9D.
>
> It is true as history has taught that very important lesson.
>
> The answer to this real world problem is in the subject heading of thi= s
> thread.
>
> This would also fix the day 1 issue I mentioned allowing mix of slaac =
> devices with static and DHCPv6 up to /80.
>
> The variable slaac solution draft proposes a new =C2=A0RA PIO flag tha= t would
> be used to signal longer prefixes, and would provide backwards
> compatibility so that devices not supporting woud ignore the flag =C2= =A0and
> devices on newer code supporting would use the flag.=C2=A0 We definite= ly
> don=E2=80=99t want to impact any existing devices on the existing 64 b= it slaac
> boundary standard.
>
> Dmytro has tested the solution on Linux kernel signaling RA PIO flag a= nd
> was able to successfully test any length mask and random IID generatio= n
> both RFC 4941 privacy extension as well as stable IID RFC 7217.
>
> https://datatracker.ietf.org/= doc/draft-mishra-6man-variable-slaac/
> <https://datatracker.ietf.= org/doc/draft-mishra-6man-variable-slaac/>
>
> If everyone is in agreement with what I have stated on this thread, I =
> would like to ask the chairs for WG adoption as this is a WG effort. >
> I would like to garner support from all 6MAN members with full consens= us
> to change the existing RFC 4941 /64 fixed boundary to /80 fixed bounda= ry.
>
> Kind Regards
>
> Gyan
>
> On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jm= h@joelhalpern.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I am missing something in your reasoning.
>=C2=A0 =C2=A0 =C2=A0You seem to say at one point that (to paraphrase) &= quot;we can't do this
>=C2=A0 =C2=A0 =C2=A0because it does not work with the existing UE softw= are".
>=C2=A0 =C2=A0 =C2=A0Any new solution where a UE delegates based on any = change of any kind
>=C2=A0 =C2=A0 =C2=A0(including lengthening the prefix, shortening the p= refix, or magically
>=C2=A0 =C2=A0 =C2=A0incanting new prefixes) requires that the UE be upg= raded to know
>=C2=A0 =C2=A0 =C2=A0what to
>=C2=A0 =C2=A0 =C2=A0do with the information.=C2=A0 I do not see how tha= t differentiates any of
>=C2=A0 =C2=A0 =C2=A0the solutions. (Except "don't do anything&= quot;, which I think we do not
>=C2=A0 =C2=A0 =C2=A0want
>=C2=A0 =C2=A0 =C2=A0to take.)
>
>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org=
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:otroan@employees.org <mailto:otroan@employees.org>>= > wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at 1= 4:58, Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0<hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > You would need a new= option. It would likely be useful for the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0requesting router to indic= ate interest in the option. Even
>=C2=A0 =C2=A0 =C2=A0hinting
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0at what prefix size it was= expecting.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Now can you explain = to me again the reasons why this
>=C2=A0 =C2=A0 =C2=A0approach is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0better than using the exis= ting DHPCv6 protocol packets?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03= GPP gateway does not support DHCPv6
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't s= upport new option. What's your point?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 The point of the v6ops pr= esentation and this email thread is
>=C2=A0 =C2=A0 =C2=A0how to
>=C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP us= e case =C2=A0in slide 1 of the deck you
>=C2=A0 =C2=A0 =C2=A0compiled
>=C2=A0 =C2=A0 =C2=A0 > a list of options and of the two I had highli= ghted in red were the
>=C2=A0 =C2=A0 =C2=A0 > 64share v2 Cameron=E2=80=99s option and the v= ariable slaac option.=C2=A0 So on
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 > call this morning Lorenzo shot down 64share v= 2 shorter prefix
>=C2=A0 =C2=A0 =C2=A0option as
>=C2=A0 =C2=A0 =C2=A0 > even if the 3GPP architecture was updated to = support longer
>=C2=A0 =C2=A0 =C2=A0prefixes and
>=C2=A0 =C2=A0 =C2=A0 > even is the 3GPP gateway was able to send a s= horter prefix with A
>=C2=A0 =C2=A0 =C2=A0flag
>=C2=A0 =C2=A0 =C2=A0 > not set, all mobile devices per Lorenzo=E2=80= =99s point would be broken
>=C2=A0 =C2=A0 =C2=A0as they
>=C2=A0 =C2=A0 =C2=A0 > would not accept the shorter let=E2=80=99s sa= y /56 prefix to build the
>=C2=A0 =C2=A0 =C2=A0slaac 128
>=C2=A0 =C2=A0 =C2=A0 > bit address.=C2=A0 So the bottom line is the = 64share v2 won=E2=80=99t work
>=C2=A0 =C2=A0 =C2=A0unless we
>=C2=A0 =C2=A0 =C2=A0 > update RFC 4291 and remove the 64 bit boundar= y.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So we are back to square uno - no= viable solution
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So now we had thrown out the long= er >64 due to race to bottom
>=C2=A0 =C2=A0 =C2=A0worries
>=C2=A0 =C2=A0 =C2=A0 > which I and others believe is Fud and as desc= ribed in slide 10 of
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Crace to the bottom slide=E2=80= =9D.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So a happy medium /80 fixed boundary I came u= p with that I think
>=C2=A0 =C2=A0 =C2=A0solves
>=C2=A0 =C2=A0 =C2=A0 > a lot of the issue and not just the 3GPP init= ial segmentation of
>=C2=A0 =C2=A0 =C2=A0 > downstream devices problem statement.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Since we have to update RFC 4291 for 64share = v2 to work anyways
>=C2=A0 =C2=A0 =C2=A0to allow
>=C2=A0 =C2=A0 =C2=A0 > for shorter prefixes, why not instead create = a new bottom at /80
>=C2=A0 =C2=A0 =C2=A0giving
>=C2=A0 =C2=A0 =C2=A0 > 16 bits more of prefix length and shrinking t= he IID down to 48 bits.
>=C2=A0 =C2=A0 =C2=A0 > Doing so you would not even have to update th= e 3GPP architecture
>=C2=A0 =C2=A0 =C2=A0as I
>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t know if that would fly or not.= =C2=A0 Also this solves a few other
>=C2=A0 =C2=A0 =C2=A0 > problems at the same time.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As I mentioned in the v6ops deck presented th= at vlsm 0 to 128 is
>=C2=A0 =C2=A0 =C2=A0 > mainstream for operators for static addressin= g on router and switch
>=C2=A0 =C2=A0 =C2=A0 > infrastructure and dhcpv6 subnets longer pref= ixes for network
>=C2=A0 =C2=A0 =C2=A0 > infrastructure appliance clusters, NFV/VNF vi= rtualization and server
>=C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On host subnets where there is a= chance of mix of slaac
>=C2=A0 =C2=A0 =C2=A0hosts
>=C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2=A0devices the prefix length i= s stuck at /64.=C2=A0 So on
>=C2=A0 =C2=A0 =C2=A0these mix
>=C2=A0 =C2=A0 =C2=A0 > addressing host subnets we cannot do longer p= refixes following
>=C2=A0 =C2=A0 =C2=A0our ND
>=C2=A0 =C2=A0 =C2=A0 > cache hard limit mantra to prevent ND cache e= xhaustion issues as
>=C2=A0 =C2=A0 =C2=A0 > described in RFC 6164.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So with the /80 new fixed boundary shifting p= refix length 16 bits
>=C2=A0 =C2=A0 =C2=A0longer
>=C2=A0 =C2=A0 =C2=A0 > and shortening the IID by 16 bits gives resol= ved the 3GPP issue
>=C2=A0 =C2=A0 =C2=A0which
>=C2=A0 =C2=A0 =C2=A0 > 64share can work as is and subtending to down= stream devices will now
>=C2=A0 =C2=A0 =C2=A0 > work as a /64 is now equivalent to a /48 with= 64k /80s.=C2=A0 Also
>=C2=A0 =C2=A0 =C2=A0BCP-690
>=C2=A0 =C2=A0 =C2=A0 > for broadband not all operators have adopted = the shorter prefix
>=C2=A0 =C2=A0 =C2=A0lengths
>=C2=A0 =C2=A0 =C2=A0 > /56 or /48 recommendations =C2=A0and now that= =E2=80=99s not an issue as the
>=C2=A0 =C2=A0 =C2=A0/64 would
>=C2=A0 =C2=A0 =C2=A0 > now suffice.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an operators perspective that gain= allows at least for 3GPP
>=C2=A0 =C2=A0 =C2=A0 > massive growth and subtending with a single /= 64 allows the operators
>=C2=A0 =C2=A0 =C2=A0 > such as Verizon with massive subscriber base = worldwide can stay with
>=C2=A0 =C2=A0 =C2=A0 > current allocations and don=E2=80=99t have to ask for /10.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As 5G gets rolled out with Enhanced VPN frame= work and Network
>=C2=A0 =C2=A0 =C2=A0slicing
>=C2=A0 =C2=A0 =C2=A0 > paradigm, the demand for shorter blocks and w= earable multiple /48
>=C2=A0 =C2=A0 =C2=A0will
>=C2=A0 =C2=A0 =C2=A0 > be our new reality.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Making that 16 bit shift now to /80 making a = /64 the new /48 will
>=C2=A0 =C2=A0 =C2=A0give
>=C2=A0 =C2=A0 =C2=A0 > broadband and 3GPP subscribers a ton of space= to subtending their
>=C2=A0 =C2=A0 =C2=A0 > networks we would be set for the future.=C2= =A0 Especially with IOT the
>=C2=A0 =C2=A0 =C2=A0demand
>=C2=A0 =C2=A0 =C2=A0 > for subtending will continue to grow astronom= ically.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Also IANA does not have to get start in alloc= ating the other /3 and
>=C2=A0 =C2=A0 =C2=A0 > other available blocks.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Lots of problems being solved here with a fix= ed /80 new boundary.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Also with the existing random IID generation = schemes which we have
>=C2=A0 =C2=A0 =C2=A0 > tested on Linux kernel can do longer p
>=C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/tested+on+= Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg>refixes >=C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy
>=C2=A0 =C2=A0 =C2=A0 > extension or RFC 7217 stable IID.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Win-Win for all.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Ole
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ <http://ww= w.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailma= n/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>
--
--0000000000001f1bfb05b493787b-- From nobody Fri Nov 20 17:46:21 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6E3A0E98; Fri, 20 Nov 2020 17:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR_MbuNk5LBJ; Fri, 20 Nov 2020 17:46:16 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 B43C93A0E96; Fri, 20 Nov 2020 17:46:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CdGV0266Rz6G8wH; Fri, 20 Nov 2020 17:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605923176; bh=ylcRDT1H8j24hnXxLDZ5gFqXbV2fXzVwuwfYVbQZWpo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lxlSMElbNh+HFuqJNSJttddIQpmRBRGyD7bIPnVqBij8oFaGl65LbLzkwi2ifi/kn t6KIwcLDwCXSnR+fML1hJ8FJPFD/LH1rFIDu9YjAazwhCH6fgbEkILYUExwWRpYiC0 lpoe03f3GN2bhOWzSgD1VaGq3+s/4rCKiY6MnVPc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CdGTz3mfcz6G7qy; Fri, 20 Nov 2020 17:46:15 -0800 (PST) To: Gyan Mishra Cc: 6MAN <6man@ietf.org>, IPv6 Operations References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> Date: Fri, 20 Nov 2020 20:46:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 01:46:19 -0000 The nesting got me lost, so I will top post my take on the answer to the one quesiton I could understand. I believe you asked what I think would need to be changed to permit the delegation. As with anything, the real things that need to change are the devices in the network. With regard to IETF standards, what is proposed is a change to RA. There are several possible changes. None of them require a change to the IPv6 addressing archtiecture, as the addressing structure remains as it is. As for the exact mechanism, at the moment I lean towards Ole's proposal of using a new option in his generic option mechanism. But I am not wedded to that answer. And of course, to get this supported in mobile environments we will have to work with 3GPP and make sure there are no other hidden issues. That's the way we do things. Work together. Changing the prefix length to /80 is technically also possible. It does a lot more violence to my understanding of the architecture and software structures that go with it, and is a very limited and narrow solution to the problem. Yours, Joel On 11/20/2020 7:58 PM, Gyan Mishra wrote: > Hi Joel > > In-line > > On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern > wrote: > > Gyan, separate from Ole's comments about the difference between address > assignment and delegation, I have another problem following the > reasoning below. > > Yes, the proposal for using shorter prefixes to enable UE to perform > delegation will require changes to the UE. > >     Gyan> Agreed.  So that change would be to RFC 4291 64 bit boundary > to allow for longer prefix.  Do you agree? > > If you don’t agree what do think the change would be to allow the UE to > accept shorter prefix from the 3GPP gateway? > > > But I do not see how that is relevant to any choice we are trying to > make. > Any solution that enables UE to delegate addresses (in the sense that > they lack the capability now) willr equire changes to the UE. > > > > Gyan> If the UE receives a /56 via RA it could delegate /64 to > downstream devices.  No change needed to delegate  /64, however a > change is needed to accept /56 via RA. > > >     If 3GPP gateway supported PD - problem solved but that’s not the > case and that does not sound like it will ever change even with 5G. > >    Gyan> The UE needs to be able to accept shorter prefix.  That’s the > IPV6 specification change that requires removal of the 64 bit boundary. > > Yoru > proposed change to the SLAAC length if anything does more violence to > the software (depending upon the exact software architecture.) > > >    Gyan> What violence to software.  There would be more violence to > software if we removed the 64 bit boundary and allowed slaac to support > any vlsm prefix lengths. > > My /80 proposal would just shift the boundary 16 bits to /80. > > Hosts on the same subnet with two different masks would not be on-net to > each other as on different subnets.  The router would be configured with > the two subnets /64 and /80 subnet to support the two device types. > The solution would be a simple RA PIO flag that is set and older hosts > not upgraded would be backwards compatible and so would only support 64 > bit boundary by ignoring flag. Hosts upgraded to support would > understand the flag and be able to support longer mask up to /80. > > > > So I do not follow how you got to your conclusion. > > Yours, > Joel > > On 11/20/2020 5:27 PM, Gyan Mishra wrote: > > > > (top posting) > > > > As I would like to clear the air as well as get to the crux of > the v6ops > > presentation development results as well as next steps for this > draft > > and the 6man variable slaac solutions draft: > > > > > > This thread was in light of Lorenzo kindly pointing out that > upgrading > > 3GPP is not all that needs be done for Cameron’s 64share v2 to > work - as > > all mobile devices would stop working- as slaac would not would be > > effectively broken. > > > > The mobile device would receive a shorter prefix let’s say /56 > but not > > know what to do with it since it’s expecting a /64. > > > > So that a major gap and the only solution is updating RFC 4291 > removing > > the 64 bit boundary allowing for shorter prefix and now as well > longer > > prefixes to work and in that respect now provide the much needed > parity > > with static and DHCPv6 which can do any prefix length. > > > > So that is a drastic change to RFC 4291.  However, in light of this > > development on the v6ops 109 call, my balancing act of best of both > > worlds and also to keep everyone happy to make this a WG effort > for this > > change by proposing in the subject heading /80 fixed boundary and > not a > > variable slaac change allowing all bits vlsm. > > > > Basically stealing 16 bits for network prefix out of the IID, still > > keeping the fixed boundary so longer than 80 would NOT  be allowed. > > > > A /64 would now be equivalent to a /48 with now 64k /80’s. > > > > This /80 would keep the operators and law enforcement happy as > now 16 > > bits less helps traceability but is still long enough for 48 bits of > > privacy to IP correlation by attackers. > > > > This /80 would be a nice optimal balance as it would keep wired > > broadband and mobile handset customers happy respecting their > privacy as > > the 16 bits less of heuristics is minimal change that will impact IP > > correlation by attackers. > > > > The IID as it’s less than the current 64 bit cannot use MAC based > EUI64 > > IID, which is not a problem as Mac based IID is not recommended > as most > > all manufacturers use RFC 4941 and I believe Linux flavors some use > > stable IID RFC 7217. > > > > So now the 48 bit IID would require a random IID generation > schema so > > can use either RFC 4941 privacy extension or RFC 7217 stable IID to > > generate the 48 bit IID. > > > > 3GPP subtending would now work issue mentioned in the problem > statement > > draft without even having to use 64share as now longer prefixes > up to > > /80 would be supported allowing for further segmentation of > downstream > > devices. > > > > This also would help wired broadband and soon fixed 5G broadband > > proliferation where operators in light of BCP RIPE-690, are sill > > allocation via BNG gateways a /64, now operators  can stay as-is, > as the > > /64 would now be allowed to be further segmented supporting 64k > /80s, > > way more then enough for SOHO. > > > > This would allow 64share if used by 3GPP operators to work and > would not > > require the 3GPP specification to be updated.  We don’t know even > if the > > 3GPP architecture specification can be updated to support shorter > > prefixes and if the 3GPP consortium of operators would agree to > it.  So > > that is all theoretical of that change is possible. > > > > As with 5G with Enhanced VPN framework SR steering of high priority > > traffic, traffic isolation and Network slicing capabilities becomes > > mainstream and will soon be a real world reality and as fixed 5G > > broadband proliferation takes off and mobile 5G == the idea of a > > wearable /48 will really be many /48s. > > > > As this paradigm shift takes place, operators around the world > will be > > clamoring after the RIR for massive blocks, I would say less than /8 > > more like a /5 or /4.  If you do the math on the way high side a /10 > > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR > which is > > tiny number with the number of large size operators worldwide. > > > > With the massive proliferation of IOT devices and just about > every home > > or office appliance on 5G, the problem now gets way exacerbated. > > > > As this evolution unfolds IANA will be scrambling to release all > > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 > > address space depletion. > > > > Playing Monday night quarterbacking in hindsight we would never > think > > this would happen in a million years, but we would see IPv6 on > the verge > > of address space depletion.  Unheard of but it can happen as the > saying > > goes “when you build - they will come”. > > > > It is true as history has taught that very important lesson. > > > > The answer to this real world problem is in the subject heading > of this > > thread. > > > > This would also fix the day 1 issue I mentioned allowing mix of > slaac > > devices with static and DHCPv6 up to /80. > > > > The variable slaac solution draft proposes a new  RA PIO flag > that would > > be used to signal longer prefixes, and would provide backwards > > compatibility so that devices not supporting woud ignore the flag >  and > > devices on newer code supporting would use the flag.  We definitely > > don’t want to impact any existing devices on the existing 64 bit > slaac > > boundary standard. > > > > Dmytro has tested the solution on Linux kernel signaling RA PIO > flag and > > was able to successfully test any length mask and random IID > generation > > both RFC 4941 privacy extension as well as stable IID RFC 7217. > > > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > > > > > > If everyone is in agreement with what I have stated on this > thread, I > > would like to ask the chairs for WG adoption as this is a WG effort. > > > > I would like to garner support from all 6MAN members with full > consensus > > to change the existing RFC 4941 /64 fixed boundary to /80 fixed > boundary. > > > > Kind Regards > > > > Gyan > > > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > > > >> wrote: > > > >     I am missing something in your reasoning. > >     You seem to say at one point that (to paraphrase) "we can't > do this > >     because it does not work with the existing UE software". > >     Any new solution where a UE delegates based on any change of > any kind > >     (including lengthening the prefix, shortening the prefix, or > magically > >     incanting new prefixes) requires that the UE be upgraded to know > >     what to > >     do with the information.  I do not see how that > differentiates any of > >     the solutions. (Except "don't do anything", which I think we > do not > >     want > >     to take.) > > > >     Yours, > >     Joel > > > >     On 11/19/2020 5:03 PM, Gyan Mishra wrote: > >      > > >      > > >      > On Thu, Nov 19, 2020 at 10:33 AM > >     > > >      > > >>> wrote: > >      > > >      > > >      > > >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra > >      > > > >      >      > >      >>> wrote: > >      >      > > >      >      > You would need a new option. It would likely be > useful for the > >      >     requesting router to indicate interest in the option. Even > >     hinting > >      >     at what prefix size it was expecting. > >      >      > Now can you explain to me again the reasons why this > >     approach is > >      >     better than using the existing DHPCv6 protocol packets? > >      >      > > >      >      >     3GPP gateway does not support DHCPv6 > >      > > >      >     3GPP gateway doesn't support new option. What's your > point? > >      > > >      > > >      > > >      >      The point of the v6ops presentation and this email > thread is > >     how to > >      > “extend a /64” in the 3GPP use case  in slide 1 of the > deck you > >     compiled > >      > a list of options and of the two I had highlighted in red > were the > >      > 64share v2 Cameron’s option and the variable slaac > option.  So on > >     the > >      > call this morning Lorenzo shot down 64share v2 shorter prefix > >     option as > >      > even if the 3GPP architecture was updated to support longer > >     prefixes and > >      > even is the 3GPP gateway was able to send a shorter prefix > with A > >     flag > >      > not set, all mobile devices per Lorenzo’s point would be > broken > >     as they > >      > would not accept the shorter let’s say /56 prefix to build the > >     slaac 128 > >      > bit address.  So the bottom line is the 64share v2 won’t work > >     unless we > >      > update RFC 4291 and remove the 64 bit boundary. > >      > > >      >   So we are back to square uno - no viable solution > >      > > >      >   So now we had thrown out the longer >64 due to race to > bottom > >     worries > >      > which I and others believe is Fud and as described in > slide 10 of > >     the > >      > v6ops “race to the bottom slide”. > >      > > >      > So a happy medium /80 fixed boundary I came up with that I > think > >     solves > >      > a lot of the issue and not just the 3GPP initial > segmentation of > >      > downstream devices problem statement. > >      > > >      > Since we have to update RFC 4291 for 64share v2 to work > anyways > >     to allow > >      > for shorter prefixes, why not instead create a new bottom > at /80 > >     giving > >      > 16 bits more of prefix length and shrinking the IID down > to 48 bits. > >      > Doing so you would not even have to update the 3GPP > architecture > >     as I > >      > don’t know if that would fly or not.  Also this solves a > few other > >      > problems at the same time. > >      > > >      > > >      > As I mentioned in the v6ops deck presented that vlsm 0 to > 128 is > >      > mainstream for operators for static addressing on router > and switch > >      > infrastructure and dhcpv6 subnets longer prefixes for network > >      > infrastructure appliance clusters, NFV/VNF virtualization > and server > >      > farms.  On host subnets where there is a chance of mix of > slaac > >     hosts > >      > with dhcpv6  devices the prefix length is stuck at /64.  So on > >     these mix > >      > addressing host subnets we cannot do longer prefixes following > >     our ND > >      > cache hard limit mantra to prevent ND cache exhaustion > issues as > >      > described in RFC 6164. > >      > > >      > So with the /80 new fixed boundary shifting prefix length > 16 bits > >     longer > >      > and shortening the IID by 16 bits gives resolved the 3GPP > issue > >     which > >      > 64share can work as is and subtending to downstream > devices will now > >      > work as a /64 is now equivalent to a /48 with 64k /80s.  Also > >     BCP-690 > >      > for broadband not all operators have adopted the shorter > prefix > >     lengths > >      > /56 or /48 recommendations  and now that’s not an issue as the > >     /64 would > >      > now suffice. > >      > > >      >  From an operators perspective that gain allows at least > for 3GPP > >      > massive growth and subtending with a single /64 allows the > operators > >      > such as Verizon with massive subscriber base worldwide can > stay with > >      > current allocations and don’t have to ask > > for /10. > >      > > >      > As 5G gets rolled out with Enhanced VPN framework and Network > >     slicing > >      > paradigm, the demand for shorter blocks and wearable > multiple /48 > >     will > >      > be our new reality. > >      > > >      > Making that 16 bit shift now to /80 making a /64 the new > /48 will > >     give > >      > broadband and 3GPP subscribers a ton of space to > subtending their > >      > networks we would be set for the future.  Especially with > IOT the > >     demand > >      > for subtending will continue to grow astronomically. > >      > > >      > Also IANA does not have to get start in allocating the > other /3 and > >      > other available blocks. > >      > > >      > Lots of problems being solved here with a fixed /80 new > boundary. > >      > > >      > Also with the existing random IID generation schemes which > we have > >      > tested on Linux kernel can do longer p > > >  >refixes > >     using RFC 4941 privacy > >      > extension or RFC 7217 stable IID. > >      > > >      > Win-Win for all. > >      > > >      >     Ole > >      > > >      > -- > >      > > >      > > >> > >      > > >      > *Gyan Mishra* > >      > > >      > /Network Solutions A//rchitect / > >      > > >      > /M 301 502-1347 > >      > 13101 Columbia Pike > >      > /Silver Spring, MD > >      > > >      > > >      > > >      > _______________________________________________ > >      > v6ops mailing list > >      > v6ops@ietf.org > > > >      > https://www.ietf.org/mailman/listinfo/v6ops > > >      > > >      > > > > > -- > > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > From nobody Fri Nov 20 19:00:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F783A1071; Fri, 20 Nov 2020 19:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qunjaKtzOucJ; Fri, 20 Nov 2020 19:00:20 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4460D3A106D; Fri, 20 Nov 2020 19:00:20 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id w6so9734836pfu.1; Fri, 20 Nov 2020 19:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ve5gle+j3fo16dTatGMn6v1+cVGcnJmbVzdyFne09Bs=; b=Doq201m5zPmoemq3ooYG9v1RuG/M0G1aqBKyB2EN8mWonQoumJNluGy1d5I4E67Rd9 cCrRCagzRzvwFrhNZdiWnPZJfF2P1fPe5LVdpOOnKCsyKZe2hkgvbuGvsqfnWrcjU/2j 60KAwVFoW+l4K6O5r2Jon7hKFjXql5tbKdVQPHgXIDgPilcMVr/scFxdaZ0X7Zz/AE5n 7rpGdKh4CCl+0KqpAMDaX0YzYjJVTEjYtqeAvvDy0da/puXry0/9EBpO9gRlDXVvmidl C83XAWaFSOBR3B9dFT1TF1S3kVWPEYjJ/hqpejDIiZku2iY7VA2GC3z58UomqsDvCrGQ y2vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ve5gle+j3fo16dTatGMn6v1+cVGcnJmbVzdyFne09Bs=; b=HK3pLVM7wAC7nGdcsDIRWM/PQ7lMx8G1jVA19rkY3V5NyxZH/fCg++YLhBp8nolvTr tI2s5ZWsOz2pnjwao9zOPKc8e6s8N0Bn3BK8k9pxlJaxUWlkOgcln1LO933b0Ipu/swz /aoop3nlS2AgtGYqnA4buVkk/jAmHBRvTAXtr14dwYzkeIkDmSBzleiGg+4JmXs70l2y idHSA90QuIZmmU7o37q688MMDTfZJ/31YdTSXHHYFxPBMH84sTT1znRkBTGMqD/LNQqd H5JhosMRBqXzU5UR5DvsnpcmeQMcvd4W8dYWDv+uA/cPEtWTZFRk3zFqBR3KJVddSTyS IxSQ== X-Gm-Message-State: AOAM5324A3lmIUbCeKzZuXtVMD7XMde/TRSkJNkJdJM6cKWYqFDSSqN9 HNxU5Y2tHdC8UnQLgjr2ohrjKhECnzl+bQ== X-Google-Smtp-Source: ABdhPJwIm6EjtcogNRDwR6y/WAICtJ7wQYsP8wE5QE0n+Eb1PySLuzTIQ2MO2sdyzPcTpN8wwLdXEg== X-Received: by 2002:a17:90a:2c2:: with SMTP id d2mr13402259pjd.36.1605927619065; Fri, 20 Nov 2020 19:00:19 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v7sm5177755pfu.39.2020.11.20.19.00.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 19:00:18 -0800 (PST) To: "Joel M. Halpern" Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> From: Brian E Carpenter Message-ID: <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> Date: Sat, 21 Nov 2020 16:00:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 03:00:23 -0000 Joel, It seems to me that it's high time to draft a liaison statement to 3GPP, observing that: (1) There is a serious problem for the design and implementation of 5G-based IPv6 "hot spots" and CEs [which is where this conversation start= ed]; (2) Although the best solution is not yet obvious, defining and standardizing it will require a joint effort by the IETF and 3GPP. Followed by a proposal to form an ad hoc joint design team. Regards Brian Carpenter On 21-Nov-20 14:46, Joel M. Halpern wrote: > The nesting got me lost, so I will top post my take on the answer to th= e=20 > one quesiton I could understand. >=20 > I believe you asked what I think would need to be changed to permit the= =20 > delegation. > As with anything, the real things that need to change are the devices i= n=20 > the network. >=20 > With regard to IETF standards, what is proposed is a change to RA.=20 > There are several possible changes. None of them require a change to=20 > the IPv6 addressing archtiecture, as the addressing structure remains a= s=20 > it is. > As for the exact mechanism, at the moment I lean towards Ole's proposal= =20 > of using a new option in his generic option mechanism. But I am not=20 > wedded to that answer. >=20 > And of course, to get this supported in mobile environments we will hav= e=20 > to work with 3GPP and make sure there are no other hidden issues.=20 > That's the way we do things. Work together. >=20 > Changing the prefix length to /80 is technically also possible. It doe= s=20 > a lot more violence to my understanding of the architecture and softwar= e=20 > structures that go with it, and is a very limited and narrow solution t= o=20 > the problem. >=20 > Yours, > Joel >=20 > On 11/20/2020 7:58 PM, Gyan Mishra wrote: >> Hi Joel >> >> In-line >> >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern > > wrote: >> >> Gyan, separate from Ole's comments about the difference between ad= dress >> assignment and delegation, I have another problem following the >> reasoning below. >> >> Yes, the proposal for using shorter prefixes to enable UE to perfo= rm >> delegation will require changes to the UE.=20 >> >> =C2=A0 =C2=A0 Gyan> Agreed.=C2=A0 So that change would be to RFC 4291= 64 bit boundary=20 >> to allow for longer prefix.=C2=A0 Do you agree? >> >> If you don=E2=80=99t agree what do think the change would be to allow = the UE to=20 >> accept shorter prefix from the 3GPP gateway? >> >> >> But I do not see how that is relevant to any choice we are trying = to >> make. >> Any solution that enables UE to delegate addresses (in the sense t= hat >> they lack the capability now) willr equire changes to the UE.=20 >> >> >> >> Gyan> If the UE receives a /56 via RA it could delegate /64 to >> downstream devices.=C2=A0 No change needed to delegate =C2=A0/64, = however a >> change is needed to accept /56 via RA.=20 >> >> >> =C2=A0 =C2=A0 If 3GPP gateway supported PD - problem solved but that=E2= =80=99s not the=20 >> case and that does not sound like it will ever change even with 5G. >> >> =C2=A0 =C2=A0Gyan> The UE needs to be able to accept shorter prefix.=C2= =A0 That=E2=80=99s the=20 >> IPV6 specification change that requires removal of the 64 bit boundary= =2E >> >> Yoru >> proposed change to the SLAAC length if anything does more violence= to >> the software (depending upon the exact software architecture.) >> >> >> =C2=A0 =C2=A0Gyan> What violence to software.=C2=A0 There would be mo= re violence to=20 >> software if we removed the 64 bit boundary and allowed slaac to suppor= t=20 >> any vlsm prefix lengths. >> >> My /80 proposal would just shift the boundary 16 bits to /80. >> >> Hosts on the same subnet with two different masks would not be on-net = to=20 >> each other as on different subnets.=C2=A0 The router would be configur= ed with=20 >> the two subnets /64 and /80 subnet to support the two device types. >> The solution would be a simple RA PIO flag that is set and older hosts= =20 >> not upgraded would be backwards compatible and so would only support 6= 4=20 >> bit boundary by ignoring flag. Hosts upgraded to support would=20 >> understand the flag and be able to support longer mask up to /80. >> >> >> >> So I do not follow how you got to your conclusion. >> >> Yours, >> Joel >> >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >> > >> > (top posting) >> > >> > As I would like to clear the air as well as get to the crux of >> the v6ops >> > presentation development results as well as next steps for this= >> draft >> > and the 6man variable slaac solutions draft: >> > >> > >> > This thread was in light of Lorenzo kindly pointing out that >> upgrading >> > 3GPP is not all that needs be done for Cameron=E2=80=99s 64shar= e v2 to >> work - as >> > all mobile devices would stop working- as slaac would not would= be >> > effectively broken. >> > >> > The mobile device would receive a shorter prefix let=E2=80=99s = say /56 >> but not >> > know what to do with it since it=E2=80=99s expecting a /64. >> > >> > So that a major gap and the only solution is updating RFC 4291 >> removing >> > the 64 bit boundary allowing for shorter prefix and now as well= >> longer >> > prefixes to work and in that respect now provide the much neede= d >> parity >> > with static and DHCPv6 which can do any prefix length. >> > >> > So that is a drastic change to RFC 4291.=C2=A0 However, in ligh= t of this >> > development on the v6ops 109 call, my balancing act of best of = both >> > worlds and also to keep everyone happy to make this a WG effort= >> for this >> > change by proposing in the subject heading /80 fixed boundary a= nd >> not a >> > variable slaac change allowing all bits vlsm. >> > >> > Basically stealing 16 bits for network prefix out of the IID, s= till >> > keeping the fixed boundary so longer than 80 would NOT =C2=A0be= allowed. >> > >> > A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99= s. >> > >> > This /80 would keep the operators and law enforcement happy as >> now 16 >> > bits less helps traceability but is still long enough for 48 bi= ts of >> > privacy to IP correlation by attackers. >> > >> > This /80 would be a nice optimal balance as it would keep wired= >> > broadband and mobile handset customers happy respecting their >> privacy as >> > the 16 bits less of heuristics is minimal change that will impa= ct IP >> > correlation by attackers. >> > >> > The IID as it=E2=80=99s less than the current 64 bit cannot use= MAC based >> EUI64 >> > IID, which is not a problem as Mac based IID is not recommended= >> as most >> > all manufacturers use RFC 4941 and I believe Linux flavors some= use >> > stable IID RFC 7217. >> > >> > So now the 48 bit IID would require a random IID generation >> schema so >> > can use either RFC 4941 privacy extension or RFC 7217 stable II= D to >> > generate the 48 bit IID. >> > >> > 3GPP subtending would now work issue mentioned in the problem >> statement >> > draft without even having to use 64share as now longer prefixes= >> up to >> > /80 would be supported allowing for further segmentation of >> downstream >> > devices. >> > >> > This also would help wired broadband and soon fixed 5G broadban= d >> > proliferation where operators in light of BCP RIPE-690, are sil= l >> > allocation via BNG gateways a /64, now operators =C2=A0can stay= as-is, >> as the >> > /64 would now be allowed to be further segmented supporting 64k= >> /80s, >> > way more then enough for SOHO. >> > >> > This would allow 64share if used by 3GPP operators to work and >> would not >> > require the 3GPP specification to be updated.=C2=A0 We don=E2=80= =99t know even >> if the >> > 3GPP architecture specification can be updated to support short= er >> > prefixes and if the 3GPP consortium of operators would agree to= >> it.=C2=A0 So >> > that is all theoretical of that change is possible. >> > >> > As with 5G with Enhanced VPN framework SR steering of high prio= rity >> > traffic, traffic isolation and Network slicing capabilities bec= omes >> > mainstream and will soon be a real world reality and as fixed 5= G >> > broadband proliferation takes off and mobile 5G =3D=3D the idea= of a >> > wearable /48 will really be many /48s. >> > >> > As this paradigm shift takes place, operators around the world >> will be >> > clamoring after the RIR for massive blocks, I would say less th= an /8 >> > more like a /5 or /4.=C2=A0 If you do the math on the way high = side a /10 >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR >> which is >> > tiny number with the number of large size operators worldwide. >> > >> > With the massive proliferation of IOT devices and just about >> every home >> > or office appliance on 5G, the problem now gets way exacerbated= =2E >> > >> > As this evolution unfolds IANA will be scrambling to release al= l >> > remaining /3 as well as all unallocated blocks to subvert RIR I= Pv6 >> > address space depletion. >> > >> > Playing Monday night quarterbacking in hindsight we would never= >> think >> > this would happen in a million years, but we would see IPv6 on >> the verge >> > of address space depletion.=C2=A0 Unheard of but it can happen = as the >> saying >> > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. >> > >> > It is true as history has taught that very important lesson. >> > >> > The answer to this real world problem is in the subject heading= >> of this >> > thread. >> > >> > This would also fix the day 1 issue I mentioned allowing mix of= >> slaac >> > devices with static and DHCPv6 up to /80. >> > >> > The variable slaac solution draft proposes a new =C2=A0RA PIO f= lag >> that would >> > be used to signal longer prefixes, and would provide backwards >> > compatibility so that devices not supporting woud ignore the fl= ag >> =C2=A0and >> > devices on newer code supporting would use the flag.=C2=A0 We d= efinitely >> > don=E2=80=99t want to impact any existing devices on the existi= ng 64 bit >> slaac >> > boundary standard. >> > >> > Dmytro has tested the solution on Linux kernel signaling RA PIO= >> flag and >> > was able to successfully test any length mask and random IID >> generation >> > both RFC 4941 privacy extension as well as stable IID RFC 7217.= >> > >> > >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/= >> >> > >> > > >> > >> > If everyone is in agreement with what I have stated on this >> thread, I >> > would like to ask the chairs for WG adoption as this is a WG ef= fort. >> > >> > I would like to garner support from all 6MAN members with full >> consensus >> > to change the existing RFC 4941 /64 fixed boundary to /80 fixed= >> boundary. >> > >> > Kind Regards >> > >> > Gyan >> > >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >> >> > >> wrot= e: >> > >> >=C2=A0 =C2=A0 =C2=A0I am missing something in your reasoning. >> >=C2=A0 =C2=A0 =C2=A0You seem to say at one point that (to paraph= rase) "we can't >> do this >> >=C2=A0 =C2=A0 =C2=A0because it does not work with the existing U= E software". >> >=C2=A0 =C2=A0 =C2=A0Any new solution where a UE delegates based = on any change of >> any kind >> >=C2=A0 =C2=A0 =C2=A0(including lengthening the prefix, shortenin= g the prefix, or >> magically >> >=C2=A0 =C2=A0 =C2=A0incanting new prefixes) requires that the UE= be upgraded to know >> >=C2=A0 =C2=A0 =C2=A0what to >> >=C2=A0 =C2=A0 =C2=A0do with the information.=C2=A0 I do not see = how that >> differentiates any of >> >=C2=A0 =C2=A0 =C2=A0the solutions. (Except "don't do anything", = which I think we >> do not >> >=C2=A0 =C2=A0 =C2=A0want >> >=C2=A0 =C2=A0 =C2=A0to take.) >> > >> >=C2=A0 =C2=A0 =C2=A0Yours, >> >=C2=A0 =C2=A0 =C2=A0Joel >> > >> >=C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM, Gyan Mishra wrote: >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 10:33 AM > >> >=C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0 > >> >>> wrot= e: >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at = 14:58, Gyan Mishra >> >=C2=A0 =C2=A0 =C2=A0 >> > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0> >>> wrote: >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > You would need a ne= w option. It would likely be >> useful for the >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0requesting router to i= ndicate interest in the option. Even >> >=C2=A0 =C2=A0 =C2=A0hinting >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0at what prefix size it= was expecting. >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Now can you explain= to me again the reasons why this >> >=C2=A0 =C2=A0 =C2=A0approach is >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0better than using the = existing DHPCv6 protocol packets? >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0= 3GPP gateway does not support DHCPv6 >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't s= upport new option. What's your >> point? >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 The point of the v6op= s presentation and this email >> thread is >> >=C2=A0 =C2=A0 =C2=A0how to >> >=C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend a /64=E2=80=9D in the 3GP= P use case =C2=A0in slide 1 of the >> deck you >> >=C2=A0 =C2=A0 =C2=A0compiled >> >=C2=A0 =C2=A0 =C2=A0 > a list of options and of the two I had hi= ghlighted in red >> were the >> >=C2=A0 =C2=A0 =C2=A0 > 64share v2 Cameron=E2=80=99s option and t= he variable slaac >> option.=C2=A0 So on >> >=C2=A0 =C2=A0 =C2=A0the >> >=C2=A0 =C2=A0 =C2=A0 > call this morning Lorenzo shot down 64sha= re v2 shorter prefix >> >=C2=A0 =C2=A0 =C2=A0option as >> >=C2=A0 =C2=A0 =C2=A0 > even if the 3GPP architecture was updated= to support longer >> >=C2=A0 =C2=A0 =C2=A0prefixes and >> >=C2=A0 =C2=A0 =C2=A0 > even is the 3GPP gateway was able to send= a shorter prefix >> with A >> >=C2=A0 =C2=A0 =C2=A0flag >> >=C2=A0 =C2=A0 =C2=A0 > not set, all mobile devices per Lorenzo=E2= =80=99s point would be >> broken >> >=C2=A0 =C2=A0 =C2=A0as they >> >=C2=A0 =C2=A0 =C2=A0 > would not accept the shorter let=E2=80=99= s say /56 prefix to build the >> >=C2=A0 =C2=A0 =C2=A0slaac 128 >> >=C2=A0 =C2=A0 =C2=A0 > bit address.=C2=A0 So the bottom line is = the 64share v2 won=E2=80=99t work >> >=C2=A0 =C2=A0 =C2=A0unless we >> >=C2=A0 =C2=A0 =C2=A0 > update RFC 4291 and remove the 64 bit bou= ndary. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So we are back to square uno = - no viable solution >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So now we had thrown out the = longer >64 due to race to >> bottom >> >=C2=A0 =C2=A0 =C2=A0worries >> >=C2=A0 =C2=A0 =C2=A0 > which I and others believe is Fud and as = described in >> slide 10 of >> >=C2=A0 =C2=A0 =C2=A0the >> >=C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Crace to the bottom slide=E2= =80=9D. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > So a happy medium /80 fixed boundary I ca= me up with that I >> think >> >=C2=A0 =C2=A0 =C2=A0solves >> >=C2=A0 =C2=A0 =C2=A0 > a lot of the issue and not just the 3GPP = initial >> segmentation of >> >=C2=A0 =C2=A0 =C2=A0 > downstream devices problem statement. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > Since we have to update RFC 4291 for 64sh= are v2 to work >> anyways >> >=C2=A0 =C2=A0 =C2=A0to allow >> >=C2=A0 =C2=A0 =C2=A0 > for shorter prefixes, why not instead cre= ate a new bottom >> at /80 >> >=C2=A0 =C2=A0 =C2=A0giving >> >=C2=A0 =C2=A0 =C2=A0 > 16 bits more of prefix length and shrinki= ng the IID down >> to 48 bits. >> >=C2=A0 =C2=A0 =C2=A0 > Doing so you would not even have to updat= e the 3GPP >> architecture >> >=C2=A0 =C2=A0 =C2=A0as I >> >=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t know if that would fly or n= ot.=C2=A0 Also this solves a >> few other >> >=C2=A0 =C2=A0 =C2=A0 > problems at the same time. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > As I mentioned in the v6ops deck presente= d that vlsm 0 to >> 128 is >> >=C2=A0 =C2=A0 =C2=A0 > mainstream for operators for static addre= ssing on router >> and switch >> >=C2=A0 =C2=A0 =C2=A0 > infrastructure and dhcpv6 subnets longer = prefixes for network >> >=C2=A0 =C2=A0 =C2=A0 > infrastructure appliance clusters, NFV/VN= F virtualization >> and server >> >=C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On host subnets where there = is a chance of mix of >> slaac >> >=C2=A0 =C2=A0 =C2=A0hosts >> >=C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2=A0devices the prefix leng= th is stuck at /64.=C2=A0 So on >> >=C2=A0 =C2=A0 =C2=A0these mix >> >=C2=A0 =C2=A0 =C2=A0 > addressing host subnets we cannot do long= er prefixes following >> >=C2=A0 =C2=A0 =C2=A0our ND >> >=C2=A0 =C2=A0 =C2=A0 > cache hard limit mantra to prevent ND cac= he exhaustion >> issues as >> >=C2=A0 =C2=A0 =C2=A0 > described in RFC 6164. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > So with the /80 new fixed boundary shifti= ng prefix length >> 16 bits >> >=C2=A0 =C2=A0 =C2=A0longer >> >=C2=A0 =C2=A0 =C2=A0 > and shortening the IID by 16 bits gives r= esolved the 3GPP >> issue >> >=C2=A0 =C2=A0 =C2=A0which >> >=C2=A0 =C2=A0 =C2=A0 > 64share can work as is and subtending to = downstream >> devices will now >> >=C2=A0 =C2=A0 =C2=A0 > work as a /64 is now equivalent to a /48 = with 64k /80s.=C2=A0 Also >> >=C2=A0 =C2=A0 =C2=A0BCP-690 >> >=C2=A0 =C2=A0 =C2=A0 > for broadband not all operators have adop= ted the shorter >> prefix >> >=C2=A0 =C2=A0 =C2=A0lengths >> >=C2=A0 =C2=A0 =C2=A0 > /56 or /48 recommendations =C2=A0and now = that=E2=80=99s not an issue as the >> >=C2=A0 =C2=A0 =C2=A0/64 would >> >=C2=A0 =C2=A0 =C2=A0 > now suffice. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an operators perspective that = gain allows at least >> for 3GPP >> >=C2=A0 =C2=A0 =C2=A0 > massive growth and subtending with a sing= le /64 allows the >> operators >> >=C2=A0 =C2=A0 =C2=A0 > such as Verizon with massive subscriber b= ase worldwide can >> stay with >> >=C2=A0 =C2=A0 =C2=A0 > current allocations and don=E2=80=99t hav= e to ask >> >> for /10. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > As 5G gets rolled out with Enhanced VPN f= ramework and Network >> >=C2=A0 =C2=A0 =C2=A0slicing >> >=C2=A0 =C2=A0 =C2=A0 > paradigm, the demand for shorter blocks a= nd wearable >> multiple /48 >> >=C2=A0 =C2=A0 =C2=A0will >> >=C2=A0 =C2=A0 =C2=A0 > be our new reality. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > Making that 16 bit shift now to /80 makin= g a /64 the new >> /48 will >> >=C2=A0 =C2=A0 =C2=A0give >> >=C2=A0 =C2=A0 =C2=A0 > broadband and 3GPP subscribers a ton of s= pace to >> subtending their >> >=C2=A0 =C2=A0 =C2=A0 > networks we would be set for the future.=C2= =A0 Especially with >> IOT the >> >=C2=A0 =C2=A0 =C2=A0demand >> >=C2=A0 =C2=A0 =C2=A0 > for subtending will continue to grow astr= onomically. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > Also IANA does not have to get start in a= llocating the >> other /3 and >> >=C2=A0 =C2=A0 =C2=A0 > other available blocks. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > Lots of problems being solved here with a= fixed /80 new >> boundary. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > Also with the existing random IID generat= ion schemes which >> we have >> >=C2=A0 =C2=A0 =C2=A0 > tested on Linux kernel can do longer p >> > =20 >> =C2=A0>refi= xes >> >=C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy >> >=C2=A0 =C2=A0 =C2=A0 > extension or RFC 7217 stable IID. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > Win-Win for all. >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Ole >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > -- >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >> >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra* >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect / >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347 >> >=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike >> >=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > >> >=C2=A0 =C2=A0 =C2=A0 > _________________________________________= ______ >> >=C2=A0 =C2=A0 =C2=A0 > v6ops mailing list >> >=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org >> > >> >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/v6o= ps >> >> >=C2=A0 =C2=A0 =C2=A0> > >> >=C2=A0 =C2=A0 =C2=A0 > >> > >> > -- >> > >> > > >> > >> > *Gyan Mishra* >> > >> > /Network Solutions A//rchitect / >> > >> > /M 301 502-1347 >> > 13101 Columbia Pike >> > /Silver Spring, MD >> > >> > >> >> --=20 >> >> >> >> *Gyan Mishra* >> >> /Network Solutions A//rchitect / >> >> /M 301 502-1347 >> 13101 Columbia Pike >> /Silver Spring, MD >> >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Nov 20 20:20:13 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB94F3A11FB; Fri, 20 Nov 2020 20:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmaP_TmnacFe; Fri, 20 Nov 2020 20:20:04 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA4C3A11F7; Fri, 20 Nov 2020 20:20:04 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id q206so12923280oif.13; Fri, 20 Nov 2020 20:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YYsacTy6TlkHU2YItxQPca8qlpKdmUkuHvnjodFExEs=; b=pj3/UEN8XQdqCfbY3NiixgzFNppTgDxyRyGmRgiKorM3nePoUj934CJy6YMzneUgyS x9YC/3N3MrK0C7tbQk3S5V2Hw89dUUN9Kedmr4oQYY6N/UQo2ZNiNsd4GYPs1PjpbVUW wc6EMhWzlTcEtoRDlO8BkaUK1ptbmcIXcjPFE6VmMronJ6PrlykJc8jPAzBsqsrDoxGs TN3JopRc1lWTp1jwR3Jf/M71q81RlIRkfYc2ZoE7wVQVqjvb8MJj/evf/WviV10YtXQY knFqO/6+8pHYtRtPCn1TODSbS3f2bw8n3CNhCfoHFJ1MIpEUf1kXEUwVQWrV+I3QrllY NL0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YYsacTy6TlkHU2YItxQPca8qlpKdmUkuHvnjodFExEs=; b=XzjoJImcoXpiAyFNh5nx8TYEzs23RHvPmaArN8mV9/+k9MvAXzLpus4kI/Jzq0zPtb Ize0P+E4HVv41pkwE/oK3DALiAOZhCbWYHJVBNiTvun61KSPPT2s2ml5QZNGmJfPQv+r yppXkwEodYvPYt71bne2ALKTC9ljvlCv/9me8shrv2q4cY/rpnSwyEofoJGMDhUoqLkP 9BfoG005JcELPGQXFL7rjWNvsRCPe3FC2qfUOAh7F/LdYzUhwVJk7Vg29bREUQTH3N// thbujE7WPrSTV92xzwG+u4Cin0m332ol7y1IK/hoZ+cJH0RC7htvnDyoGkJAM3C3qMZe N5bA== X-Gm-Message-State: AOAM531yPQByMwRAOuSd9NaJIiWEnZtegTgwowjUf1RN6LRvoRgL/ldF Axo1nlIrvAQYrt+BvtD3uzlGuxEV8esnAsfbR0Y= X-Google-Smtp-Source: ABdhPJzxbVF7c7qq9SGYSm5ckGgu0X5JwIzlaMxDrtGM7fFjbkg1xba4sPDBLqy1UDhqI9X3sZOXAqWhkLxArGM3PJo= X-Received: by 2002:aca:d755:: with SMTP id o82mr8155691oig.164.1605932403186; Fri, 20 Nov 2020 20:20:03 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> In-Reply-To: <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> From: Mark Smith Date: Sat, 21 Nov 2020 15:19:36 +1100 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000006cdfa905b496467f" Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 04:20:08 -0000 --0000000000006cdfa905b496467f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, wrote: > Joel, > > It seems to me that it's high time to draft a liaison statement to 3GPP, > observing that: > > (1) There is a serious problem for the design and implementation of > 5G-based IPv6 "hot spots" and CEs [which is where this conversation > started]; > I think it is also important to find out why they haven't deployed DHCPv6 to solve this problem. Don't they think DHCPv6 infrastructure will scale? Is it just that they don't know how to scale it? Is it a vendor / mobile operator / handset developer DHCPv6 capability chicken-and-egg problem? Is there an overriding business or industry reason? The mobile industry has been resistant to tethering over the years, and probably only came to begrudgingly accept it because they couldn't prevent phone vendors from implementing Wifi and NAT, and couldn't very effectively stop their customers from using that capability (One trick I've heard of to prevent tethering working was to check if an IPv4 packet's TTL value was 64 when it arrived at the network, meaning it originated from the directly attached handset. Packets from tethered devices had a TTL of 63 so were dropped. Of course, you could set the default TTL on a tethered PC to 65 to get around that.) I guess there might be a fairly strong mindset that there must be a fee per device attached to the network in addition to a fee for network utilisation. Providing multiple /64s would be formally acknowledging that multiple devices can be attached and a fee per device isn't and can't ever be charged, counter to the mindset. Regards, Mark. > (2) Although the best solution is not yet obvious, defining and > standardizing it will require a joint effort by the IETF and 3GPP. > > Followed by a proposal to form an ad hoc joint design team. > > Regards > Brian Carpenter > On 21-Nov-20 14:46, Joel M. Halpern wrote: > > The nesting got me lost, so I will top post my take on the answer to th= e > > one quesiton I could understand. > > > > I believe you asked what I think would need to be changed to permit the > > delegation. > > As with anything, the real things that need to change are the devices i= n > > the network. > > > > With regard to IETF standards, what is proposed is a change to RA. > > There are several possible changes. None of them require a change to > > the IPv6 addressing archtiecture, as the addressing structure remains a= s > > it is. > > As for the exact mechanism, at the moment I lean towards Ole's proposal > > of using a new option in his generic option mechanism. But I am not > > wedded to that answer. > > > > And of course, to get this supported in mobile environments we will hav= e > > to work with 3GPP and make sure there are no other hidden issues. > > That's the way we do things. Work together. > > > > Changing the prefix length to /80 is technically also possible. It doe= s > > a lot more violence to my understanding of the architecture and softwar= e > > structures that go with it, and is a very limited and narrow solution t= o > > the problem. > > > > Yours, > > Joel > > > > On 11/20/2020 7:58 PM, Gyan Mishra wrote: > >> Hi Joel > >> > >> In-line > >> > >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern >> > wrote: > >> > >> Gyan, separate from Ole's comments about the difference between > address > >> assignment and delegation, I have another problem following the > >> reasoning below. > >> > >> Yes, the proposal for using shorter prefixes to enable UE to perfo= rm > >> delegation will require changes to the UE. > >> > >> Gyan> Agreed. So that change would be to RFC 4291 64 bit boundar= y > >> to allow for longer prefix. Do you agree? > >> > >> If you don=E2=80=99t agree what do think the change would be to allow = the UE to > >> accept shorter prefix from the 3GPP gateway? > >> > >> > >> But I do not see how that is relevant to any choice we are trying = to > >> make. > >> Any solution that enables UE to delegate addresses (in the sense > that > >> they lack the capability now) willr equire changes to the UE. > >> > >> > >> > >> Gyan> If the UE receives a /56 via RA it could delegate /64 to > >> downstream devices. No change needed to delegate /64, however a > >> change is needed to accept /56 via RA. > >> > >> > >> If 3GPP gateway supported PD - problem solved but that=E2=80=99s = not the > >> case and that does not sound like it will ever change even with 5G. > >> > >> Gyan> The UE needs to be able to accept shorter prefix. That=E2= =80=99s the > >> IPV6 specification change that requires removal of the 64 bit boundary= . > >> > >> Yoru > >> proposed change to the SLAAC length if anything does more violence > to > >> the software (depending upon the exact software architecture.) > >> > >> > >> Gyan> What violence to software. There would be more violence to > >> software if we removed the 64 bit boundary and allowed slaac to suppor= t > >> any vlsm prefix lengths. > >> > >> My /80 proposal would just shift the boundary 16 bits to /80. > >> > >> Hosts on the same subnet with two different masks would not be on-net > to > >> each other as on different subnets. The router would be configured > with > >> the two subnets /64 and /80 subnet to support the two device types. > >> The solution would be a simple RA PIO flag that is set and older hosts > >> not upgraded would be backwards compatible and so would only support 6= 4 > >> bit boundary by ignoring flag. Hosts upgraded to support would > >> understand the flag and be able to support longer mask up to /80. > >> > >> > >> > >> So I do not follow how you got to your conclusion. > >> > >> Yours, > >> Joel > >> > >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: > >> > > >> > (top posting) > >> > > >> > As I would like to clear the air as well as get to the crux of > >> the v6ops > >> > presentation development results as well as next steps for this > >> draft > >> > and the 6man variable slaac solutions draft: > >> > > >> > > >> > This thread was in light of Lorenzo kindly pointing out that > >> upgrading > >> > 3GPP is not all that needs be done for Cameron=E2=80=99s 64shar= e v2 to > >> work - as > >> > all mobile devices would stop working- as slaac would not would > be > >> > effectively broken. > >> > > >> > The mobile device would receive a shorter prefix let=E2=80=99s = say /56 > >> but not > >> > know what to do with it since it=E2=80=99s expecting a /64. > >> > > >> > So that a major gap and the only solution is updating RFC 4291 > >> removing > >> > the 64 bit boundary allowing for shorter prefix and now as well > >> longer > >> > prefixes to work and in that respect now provide the much neede= d > >> parity > >> > with static and DHCPv6 which can do any prefix length. > >> > > >> > So that is a drastic change to RFC 4291. However, in light of > this > >> > development on the v6ops 109 call, my balancing act of best of > both > >> > worlds and also to keep everyone happy to make this a WG effort > >> for this > >> > change by proposing in the subject heading /80 fixed boundary a= nd > >> not a > >> > variable slaac change allowing all bits vlsm. > >> > > >> > Basically stealing 16 bits for network prefix out of the IID, > still > >> > keeping the fixed boundary so longer than 80 would NOT be > allowed. > >> > > >> > A /64 would now be equivalent to a /48 with now 64k /80=E2=80= =99s. > >> > > >> > This /80 would keep the operators and law enforcement happy as > >> now 16 > >> > bits less helps traceability but is still long enough for 48 > bits of > >> > privacy to IP correlation by attackers. > >> > > >> > This /80 would be a nice optimal balance as it would keep wired > >> > broadband and mobile handset customers happy respecting their > >> privacy as > >> > the 16 bits less of heuristics is minimal change that will > impact IP > >> > correlation by attackers. > >> > > >> > The IID as it=E2=80=99s less than the current 64 bit cannot use= MAC based > >> EUI64 > >> > IID, which is not a problem as Mac based IID is not recommended > >> as most > >> > all manufacturers use RFC 4941 and I believe Linux flavors some > use > >> > stable IID RFC 7217. > >> > > >> > So now the 48 bit IID would require a random IID generation > >> schema so > >> > can use either RFC 4941 privacy extension or RFC 7217 stable II= D > to > >> > generate the 48 bit IID. > >> > > >> > 3GPP subtending would now work issue mentioned in the problem > >> statement > >> > draft without even having to use 64share as now longer prefixes > >> up to > >> > /80 would be supported allowing for further segmentation of > >> downstream > >> > devices. > >> > > >> > This also would help wired broadband and soon fixed 5G broadban= d > >> > proliferation where operators in light of BCP RIPE-690, are sil= l > >> > allocation via BNG gateways a /64, now operators can stay as-i= s, > >> as the > >> > /64 would now be allowed to be further segmented supporting 64k > >> /80s, > >> > way more then enough for SOHO. > >> > > >> > This would allow 64share if used by 3GPP operators to work and > >> would not > >> > require the 3GPP specification to be updated. We don=E2=80=99t= know even > >> if the > >> > 3GPP architecture specification can be updated to support short= er > >> > prefixes and if the 3GPP consortium of operators would agree to > >> it. So > >> > that is all theoretical of that change is possible. > >> > > >> > As with 5G with Enhanced VPN framework SR steering of high > priority > >> > traffic, traffic isolation and Network slicing capabilities > becomes > >> > mainstream and will soon be a real world reality and as fixed 5= G > >> > broadband proliferation takes off and mobile 5G =3D=3D the idea= of a > >> > wearable /48 will really be many /48s. > >> > > >> > As this paradigm shift takes place, operators around the world > >> will be > >> > clamoring after the RIR for massive blocks, I would say less > than /8 > >> > more like a /5 or /4. If you do the math on the way high side = a > /10 > >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR > >> which is > >> > tiny number with the number of large size operators worldwide. > >> > > >> > With the massive proliferation of IOT devices and just about > >> every home > >> > or office appliance on 5G, the problem now gets way exacerbated= . > >> > > >> > As this evolution unfolds IANA will be scrambling to release al= l > >> > remaining /3 as well as all unallocated blocks to subvert RIR > IPv6 > >> > address space depletion. > >> > > >> > Playing Monday night quarterbacking in hindsight we would never > >> think > >> > this would happen in a million years, but we would see IPv6 on > >> the verge > >> > of address space depletion. Unheard of but it can happen as th= e > >> saying > >> > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. > >> > > >> > It is true as history has taught that very important lesson. > >> > > >> > The answer to this real world problem is in the subject heading > >> of this > >> > thread. > >> > > >> > This would also fix the day 1 issue I mentioned allowing mix of > >> slaac > >> > devices with static and DHCPv6 up to /80. > >> > > >> > The variable slaac solution draft proposes a new RA PIO flag > >> that would > >> > be used to signal longer prefixes, and would provide backwards > >> > compatibility so that devices not supporting woud ignore the fl= ag > >> and > >> > devices on newer code supporting would use the flag. We > definitely > >> > don=E2=80=99t want to impact any existing devices on the existi= ng 64 bit > >> slaac > >> > boundary standard. > >> > > >> > Dmytro has tested the solution on Linux kernel signaling RA PIO > >> flag and > >> > was able to successfully test any length mask and random IID > >> generation > >> > both RFC 4941 privacy extension as well as stable IID RFC 7217. > >> > > >> > > >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > >> > > >> > > >> >> >> > >> > > >> > If everyone is in agreement with what I have stated on this > >> thread, I > >> > would like to ask the chairs for WG adoption as this is a WG > effort. > >> > > >> > I would like to garner support from all 6MAN members with full > >> consensus > >> > to change the existing RFC 4941 /64 fixed boundary to /80 fixed > >> boundary. > >> > > >> > Kind Regards > >> > > >> > Gyan > >> > > >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > >> > >> > >> > wrote: > >> > > >> > I am missing something in your reasoning. > >> > You seem to say at one point that (to paraphrase) "we can't > >> do this > >> > because it does not work with the existing UE software". > >> > Any new solution where a UE delegates based on any change o= f > >> any kind > >> > (including lengthening the prefix, shortening the prefix, o= r > >> magically > >> > incanting new prefixes) requires that the UE be upgraded to > know > >> > what to > >> > do with the information. I do not see how that > >> differentiates any of > >> > the solutions. (Except "don't do anything", which I think w= e > >> do not > >> > want > >> > to take.) > >> > > >> > Yours, > >> > Joel > >> > > >> > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > >> > > > >> > > > >> > > On Thu, Nov 19, 2020 at 10:33 AM >> > >> > > > >> > > > > >> >>> > wrote: > >> > > > >> > > > >> > > > >> > > > On 19 Nov 2020, at 14:58, Gyan Mishra > >> > > >> > > >> > > >> > >> > >> >>> wrote: > >> > > > > >> > > > You would need a new option. It would likely be > >> useful for the > >> > > requesting router to indicate interest in the option= . > Even > >> > hinting > >> > > at what prefix size it was expecting. > >> > > > Now can you explain to me again the reasons why > this > >> > approach is > >> > > better than using the existing DHPCv6 protocol > packets? > >> > > > > >> > > > 3GPP gateway does not support DHCPv6 > >> > > > >> > > 3GPP gateway doesn't support new option. What's your > >> point? > >> > > > >> > > > >> > > > >> > > The point of the v6ops presentation and this email > >> thread is > >> > how to > >> > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in = slide 1 of the > >> deck you > >> > compiled > >> > > a list of options and of the two I had highlighted in re= d > >> were the > >> > > 64share v2 Cameron=E2=80=99s option and the variable sla= ac > >> option. So on > >> > the > >> > > call this morning Lorenzo shot down 64share v2 shorter > prefix > >> > option as > >> > > even if the 3GPP architecture was updated to support > longer > >> > prefixes and > >> > > even is the 3GPP gateway was able to send a shorter pref= ix > >> with A > >> > flag > >> > > not set, all mobile devices per Lorenzo=E2=80=99s point = would be > >> broken > >> > as they > >> > > would not accept the shorter let=E2=80=99s say /56 prefi= x to > build the > >> > slaac 128 > >> > > bit address. So the bottom line is the 64share v2 won= =E2=80=99t > work > >> > unless we > >> > > update RFC 4291 and remove the 64 bit boundary. > >> > > > >> > > So we are back to square uno - no viable solution > >> > > > >> > > So now we had thrown out the longer >64 due to race to > >> bottom > >> > worries > >> > > which I and others believe is Fud and as described in > >> slide 10 of > >> > the > >> > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. > >> > > > >> > > So a happy medium /80 fixed boundary I came up with that= I > >> think > >> > solves > >> > > a lot of the issue and not just the 3GPP initial > >> segmentation of > >> > > downstream devices problem statement. > >> > > > >> > > Since we have to update RFC 4291 for 64share v2 to work > >> anyways > >> > to allow > >> > > for shorter prefixes, why not instead create a new botto= m > >> at /80 > >> > giving > >> > > 16 bits more of prefix length and shrinking the IID down > >> to 48 bits. > >> > > Doing so you would not even have to update the 3GPP > >> architecture > >> > as I > >> > > don=E2=80=99t know if that would fly or not. Also this = solves a > >> few other > >> > > problems at the same time. > >> > > > >> > > > >> > > As I mentioned in the v6ops deck presented that vlsm 0 t= o > >> 128 is > >> > > mainstream for operators for static addressing on router > >> and switch > >> > > infrastructure and dhcpv6 subnets longer prefixes for > network > >> > > infrastructure appliance clusters, NFV/VNF virtualizatio= n > >> and server > >> > > farms. On host subnets where there is a chance of mix o= f > >> slaac > >> > hosts > >> > > with dhcpv6 devices the prefix length is stuck at /64. > So on > >> > these mix > >> > > addressing host subnets we cannot do longer prefixes > following > >> > our ND > >> > > cache hard limit mantra to prevent ND cache exhaustion > >> issues as > >> > > described in RFC 6164. > >> > > > >> > > So with the /80 new fixed boundary shifting prefix lengt= h > >> 16 bits > >> > longer > >> > > and shortening the IID by 16 bits gives resolved the 3GP= P > >> issue > >> > which > >> > > 64share can work as is and subtending to downstream > >> devices will now > >> > > work as a /64 is now equivalent to a /48 with 64k /80s. > Also > >> > BCP-690 > >> > > for broadband not all operators have adopted the shorter > >> prefix > >> > lengths > >> > > /56 or /48 recommendations and now that=E2=80=99s not a= n issue > as the > >> > /64 would > >> > > now suffice. > >> > > > >> > > From an operators perspective that gain allows at least > >> for 3GPP > >> > > massive growth and subtending with a single /64 allows t= he > >> operators > >> > > such as Verizon with massive subscriber base worldwide c= an > >> stay with > >> > > current allocations and don=E2=80=99t have to ask > >> < > https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have= +to+ask?entry=3Dgmail&source=3Dg > > > >> for /10. > >> > > > >> > > As 5G gets rolled out with Enhanced VPN framework and > Network > >> > slicing > >> > > paradigm, the demand for shorter blocks and wearable > >> multiple /48 > >> > will > >> > > be our new reality. > >> > > > >> > > Making that 16 bit shift now to /80 making a /64 the new > >> /48 will > >> > give > >> > > broadband and 3GPP subscribers a ton of space to > >> subtending their > >> > > networks we would be set for the future. Especially wit= h > >> IOT the > >> > demand > >> > > for subtending will continue to grow astronomically. > >> > > > >> > > Also IANA does not have to get start in allocating the > >> other /3 and > >> > > other available blocks. > >> > > > >> > > Lots of problems being solved here with a fixed /80 new > >> boundary. > >> > > > >> > > Also with the existing random IID generation schemes whi= ch > >> we have > >> > > tested on Linux kernel can do longer p > >> > > >> < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > >>refixes > >> > using RFC 4941 privacy > >> > > extension or RFC 7217 stable IID. > >> > > > >> > > Win-Win for all. > >> > > > >> > > Ole > >> > > > >> > > -- > >> > > > >> > > > >> >> > >> > > > >> > > *Gyan Mishra* > >> > > > >> > > /Network Solutions A//rchitect / > >> > > > >> > > /M 301 502-1347 > >> > > 13101 Columbia Pike > >> > > /Silver Spring, MD > >> > > > >> > > > >> > > > >> > > _______________________________________________ > >> > > v6ops mailing list > >> > > v6ops@ietf.org > >> > > >> > > https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> > > >> > > > >> > > >> > -- > >> > > >> > > > >> > > >> > *Gyan Mishra* > >> > > >> > /Network Solutions A//rchitect / > >> > > >> > /M 301 502-1347 > >> > 13101 Columbia Pike > >> > /Silver Spring, MD > >> > > >> > > >> > >> -- > >> > >> > >> > >> *Gyan Mishra* > >> > >> /Network Solutions A//rchitect / > >> > >> /M 301 502-1347 > >> 13101 Columbia Pike > >> /Silver Spring, MD > >> > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000006cdfa905b496467f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 21 Nov 2020, 14:00 Brian E Ca= rpenter, <brian.e.carpenter@gmail.com> wrote:
Joel,

It seems to me that it's high time to draft a liaison statement to 3GPP= ,
observing that:

(1) There is a serious problem for the design and implementation of
5G-based IPv6 "hot spots" and CEs [which is where this conversati= on started];

I think it is also important to find out why they haven't d= eployed DHCPv6 to solve this=C2=A0problem.

Don't they think DHCPv6 infrastructure will scale? I= s it just that they don't know how to scale it?
=
Is it a vendor / mobile operator / handset developer DHCPv6 = capability=C2=A0chicken-and-egg problem?

<= div dir=3D"auto">Is there an overriding business or industry reason?
<= div dir=3D"auto">
The mobile industry has been r= esistant to tethering over the years, and probably only came to begrudgingl= y accept it because they couldn't prevent phone vendors from implementi= ng Wifi and NAT, and couldn't very effectively stop their customers fro= m using that capability (One trick I've heard of to prevent tethering w= orking was to check if an IPv4 packet's=C2=A0TTL value was 64 when it a= rrived at the network, meaning it originated from the directly attached han= dset. Packets from tethered devices had a TTL of 63 so were dropped. Of cou= rse, you could set the default TTL on a tethered=C2=A0PC to 65 to get aroun= d that.)

I guess there m= ight be a fairly strong mindset that there must be a fee per device attache= d to the network in addition to a fee for network utilisation. Providing mu= ltiple /64s would be formally acknowledging that multiple devices can be at= tached and a fee per device isn't and can't ever be charged, counte= r to the mindset.

Regards,
= Mark.


(2) Although the best solution is not yet obvious, defining and
standardizing it will require a joint effort by the IETF and 3GPP.

Followed by a proposal to form an ad hoc joint design team.

Regards
=C2=A0 =C2=A0Brian Carpenter
On 21-Nov-20 14:46, Joel M. Halpern wrote:
> The nesting got me lost, so I will top post my take on the answer to t= he
> one quesiton I could understand.
>
> I believe you asked what I think would need to be changed to permit th= e
> delegation.
> As with anything, the real things that need to change are the devices = in
> the network.
>
> With regard to IETF standards, what is proposed is a change to RA. > There are several possible changes.=C2=A0 None of them require a chang= e to
> the IPv6 addressing archtiecture, as the addressing structure remains = as
> it is.
> As for the exact mechanism, at the moment I lean towards Ole's pro= posal
> of using a new option in his generic option mechanism.=C2=A0 But I am = not
> wedded to that answer.
>
> And of course, to get this supported in mobile environments we will ha= ve
> to work with 3GPP and make sure there are no other hidden issues.
> That's the way we do things.=C2=A0 Work together.
>
> Changing the prefix length to /80 is technically also possible.=C2=A0 = It does
> a lot more violence to my understanding of the architecture and softwa= re
> structures that go with it, and is a very limited and narrow solution = to
> the problem.
>
> Yours,
> Joel
>
> On 11/20/2020 7:58 PM, Gyan Mishra wrote:
>> Hi Joel
>>
>> In-line
>>
>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpe= rn.com
>> <mailto:jmh@joelhalpern.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan, separate from Ole's comments about th= e difference between address
>>=C2=A0 =C2=A0 =C2=A0assignment and delegation, I have another probl= em following the
>>=C2=A0 =C2=A0 =C2=A0reasoning below.
>>
>>=C2=A0 =C2=A0 =C2=A0Yes, the proposal for using shorter prefixes to= enable UE to perform
>>=C2=A0 =C2=A0 =C2=A0delegation will require changes to the UE.
>>
>>=C2=A0 =C2=A0 =C2=A0 Gyan> Agreed.=C2=A0 So that change would be= to RFC 4291 64 bit boundary
>> to allow for longer prefix.=C2=A0 Do you agree?
>>
>> If you don=E2=80=99t agree what do think the change would be to al= low the UE to
>> accept shorter prefix from the 3GPP gateway?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0But I do not see how that is relevant to any ch= oice we are trying to
>>=C2=A0 =C2=A0 =C2=A0make.
>>=C2=A0 =C2=A0 =C2=A0Any solution that enables UE to delegate addres= ses (in the sense that
>>=C2=A0 =C2=A0 =C2=A0they lack the capability now) willr equire chan= ges to the UE.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> If the UE receives a /56 via RA it cou= ld delegate /64 to
>>=C2=A0 =C2=A0 =C2=A0downstream devices.=C2=A0 No change needed to d= elegate =C2=A0/64, however a
>>=C2=A0 =C2=A0 =C2=A0change is needed to accept /56 via RA.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 If 3GPP gateway supported PD - problem solved = but that=E2=80=99s not the
>> case and that does not sound like it will ever change even with 5G= .
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> The UE needs to be able to accept shor= ter prefix.=C2=A0 That=E2=80=99s the
>> IPV6 specification change that requires removal of the 64 bit boun= dary.
>>
>>=C2=A0 =C2=A0 =C2=A0Yoru
>>=C2=A0 =C2=A0 =C2=A0proposed change to the SLAAC length if anything= does more violence to
>>=C2=A0 =C2=A0 =C2=A0the software (depending upon the exact software= architecture.)
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> What violence to software.=C2=A0 There= would be more violence to
>> software if we removed the 64 bit boundary and allowed slaac to su= pport
>> any vlsm prefix lengths.
>>
>> My /80 proposal would just shift the boundary 16 bits to /80.
>>
>> Hosts on the same subnet with two different masks would not be on-= net to
>> each other as on different subnets.=C2=A0 The router would be conf= igured with
>> the two subnets /64 and /80 subnet to support the two device types= .
>> The solution would be a simple RA PIO flag that is set and older h= osts
>> not upgraded would be backwards compatible and so would only suppo= rt 64
>> bit boundary by ignoring flag. Hosts upgraded to support would >> understand the flag and be able to support longer mask up to /80.<= br> >>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0So I do not follow how you got to your conclusi= on.
>>
>>=C2=A0 =C2=A0 =C2=A0Yours,
>>=C2=A0 =C2=A0 =C2=A0Joel
>>
>>=C2=A0 =C2=A0 =C2=A0On 11/20/2020 5:27 PM, Gyan Mishra wrote:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > (top posting)
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As I would like to clear the air as well = as get to the crux of
>>=C2=A0 =C2=A0 =C2=A0the v6ops
>>=C2=A0 =C2=A0 =C2=A0 > presentation development results as well = as next steps for this
>>=C2=A0 =C2=A0 =C2=A0draft
>>=C2=A0 =C2=A0 =C2=A0 > and the 6man variable slaac solutions dra= ft:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This thread was in light of Lorenzo kindl= y pointing out that
>>=C2=A0 =C2=A0 =C2=A0upgrading
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP is not all that needs be done for Ca= meron=E2=80=99s 64share v2 to
>>=C2=A0 =C2=A0 =C2=A0work - as
>>=C2=A0 =C2=A0 =C2=A0 > all mobile devices would stop working- as= slaac would not would be
>>=C2=A0 =C2=A0 =C2=A0 > effectively broken.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The mobile device would receive a shorter= prefix let=E2=80=99s say /56
>>=C2=A0 =C2=A0 =C2=A0but not
>>=C2=A0 =C2=A0 =C2=A0 > know what to do with it since it=E2=80=99= s expecting a /64.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So that a major gap and the only solution= is updating RFC 4291
>>=C2=A0 =C2=A0 =C2=A0removing
>>=C2=A0 =C2=A0 =C2=A0 > the 64 bit boundary allowing for shorter = prefix and now as well
>>=C2=A0 =C2=A0 =C2=A0longer
>>=C2=A0 =C2=A0 =C2=A0 > prefixes to work and in that respect now = provide the much needed
>>=C2=A0 =C2=A0 =C2=A0parity
>>=C2=A0 =C2=A0 =C2=A0 > with static and DHCPv6 which can do any p= refix length.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So that is a drastic change to RFC 4291.= =C2=A0 However, in light of this
>>=C2=A0 =C2=A0 =C2=A0 > development on the v6ops 109 call, my bal= ancing act of best of both
>>=C2=A0 =C2=A0 =C2=A0 > worlds and also to keep everyone happy to= make this a WG effort
>>=C2=A0 =C2=A0 =C2=A0for this
>>=C2=A0 =C2=A0 =C2=A0 > change by proposing in the subject headin= g /80 fixed boundary and
>>=C2=A0 =C2=A0 =C2=A0not a
>>=C2=A0 =C2=A0 =C2=A0 > variable slaac change allowing all bits v= lsm.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Basically stealing 16 bits for network pr= efix out of the IID, still
>>=C2=A0 =C2=A0 =C2=A0 > keeping the fixed boundary so longer than= 80 would NOT =C2=A0be allowed.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > A /64 would now be equivalent to a /48 wi= th now 64k /80=E2=80=99s.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This /80 would keep the operators and law= enforcement happy as
>>=C2=A0 =C2=A0 =C2=A0now 16
>>=C2=A0 =C2=A0 =C2=A0 > bits less helps traceability but is still= long enough for 48 bits of
>>=C2=A0 =C2=A0 =C2=A0 > privacy to IP correlation by attackers. >>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This /80 would be a nice optimal balance = as it would keep wired
>>=C2=A0 =C2=A0 =C2=A0 > broadband and mobile handset customers ha= ppy respecting their
>>=C2=A0 =C2=A0 =C2=A0privacy as
>>=C2=A0 =C2=A0 =C2=A0 > the 16 bits less of heuristics is minimal= change that will impact IP
>>=C2=A0 =C2=A0 =C2=A0 > correlation by attackers.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The IID as it=E2=80=99s less than the cur= rent 64 bit cannot use MAC based
>>=C2=A0 =C2=A0 =C2=A0EUI64
>>=C2=A0 =C2=A0 =C2=A0 > IID, which is not a problem as Mac based = IID is not recommended
>>=C2=A0 =C2=A0 =C2=A0as most
>>=C2=A0 =C2=A0 =C2=A0 > all manufacturers use RFC 4941 and I beli= eve Linux flavors some use
>>=C2=A0 =C2=A0 =C2=A0 > stable IID RFC 7217.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So now the 48 bit IID would require a ran= dom IID generation
>>=C2=A0 =C2=A0 =C2=A0schema so
>>=C2=A0 =C2=A0 =C2=A0 > can use either RFC 4941 privacy extension= or RFC 7217 stable IID to
>>=C2=A0 =C2=A0 =C2=A0 > generate the 48 bit IID.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP subtending would now work issue ment= ioned in the problem
>>=C2=A0 =C2=A0 =C2=A0statement
>>=C2=A0 =C2=A0 =C2=A0 > draft without even having to use 64share = as now longer prefixes
>>=C2=A0 =C2=A0 =C2=A0up to
>>=C2=A0 =C2=A0 =C2=A0 > /80 would be supported allowing for furth= er segmentation of
>>=C2=A0 =C2=A0 =C2=A0downstream
>>=C2=A0 =C2=A0 =C2=A0 > devices.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This also would help wired broadband and = soon fixed 5G broadband
>>=C2=A0 =C2=A0 =C2=A0 > proliferation where operators in light of= BCP RIPE-690, are sill
>>=C2=A0 =C2=A0 =C2=A0 > allocation via BNG gateways a /64, now op= erators =C2=A0can stay as-is,
>>=C2=A0 =C2=A0 =C2=A0as the
>>=C2=A0 =C2=A0 =C2=A0 > /64 would now be allowed to be further se= gmented supporting 64k
>>=C2=A0 =C2=A0 =C2=A0/80s,
>>=C2=A0 =C2=A0 =C2=A0 > way more then enough for SOHO.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This would allow 64share if used by 3GPP = operators to work and
>>=C2=A0 =C2=A0 =C2=A0would not
>>=C2=A0 =C2=A0 =C2=A0 > require the 3GPP specification to be upda= ted.=C2=A0 We don=E2=80=99t know even
>>=C2=A0 =C2=A0 =C2=A0if the
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP architecture specification can be up= dated to support shorter
>>=C2=A0 =C2=A0 =C2=A0 > prefixes and if the 3GPP consortium of op= erators would agree to
>>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 So
>>=C2=A0 =C2=A0 =C2=A0 > that is all theoretical of that change is= possible.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As with 5G with Enhanced VPN framework SR= steering of high priority
>>=C2=A0 =C2=A0 =C2=A0 > traffic, traffic isolation and Network sl= icing capabilities becomes
>>=C2=A0 =C2=A0 =C2=A0 > mainstream and will soon be a real world = reality and as fixed 5G
>>=C2=A0 =C2=A0 =C2=A0 > broadband proliferation takes off and mob= ile 5G =3D=3D the idea of a
>>=C2=A0 =C2=A0 =C2=A0 > wearable /48 will really be many /48s. >>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As this paradigm shift takes place, opera= tors around the world
>>=C2=A0 =C2=A0 =C2=A0will be
>>=C2=A0 =C2=A0 =C2=A0 > clamoring after the RIR for massive block= s, I would say less than /8
>>=C2=A0 =C2=A0 =C2=A0 > more like a /5 or /4.=C2=A0 If you do the= math on the way high side a /10
>>=C2=A0 =C2=A0 =C2=A0 > yields 7 bits so 128 divided by 5 RIRs yi= elds 24 ISPs per RIR
>>=C2=A0 =C2=A0 =C2=A0which is
>>=C2=A0 =C2=A0 =C2=A0 > tiny number with the number of large size= operators worldwide.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > With the massive proliferation of IOT dev= ices and just about
>>=C2=A0 =C2=A0 =C2=A0every home
>>=C2=A0 =C2=A0 =C2=A0 > or office appliance on 5G, the problem no= w gets way exacerbated.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As this evolution unfolds IANA will be sc= rambling to release all
>>=C2=A0 =C2=A0 =C2=A0 > remaining /3 as well as all unallocated b= locks to subvert RIR IPv6
>>=C2=A0 =C2=A0 =C2=A0 > address space depletion.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Playing Monday night quarterbacking in hi= ndsight we would never
>>=C2=A0 =C2=A0 =C2=A0think
>>=C2=A0 =C2=A0 =C2=A0 > this would happen in a million years, but= we would see IPv6 on
>>=C2=A0 =C2=A0 =C2=A0the verge
>>=C2=A0 =C2=A0 =C2=A0 > of address space depletion.=C2=A0 Unheard= of but it can happen as the
>>=C2=A0 =C2=A0 =C2=A0saying
>>=C2=A0 =C2=A0 =C2=A0 > goes =E2=80=9Cwhen you build - they will = come=E2=80=9D.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > It is true as history has taught that ver= y important lesson.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The answer to this real world problem is = in the subject heading
>>=C2=A0 =C2=A0 =C2=A0of this
>>=C2=A0 =C2=A0 =C2=A0 > thread.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This would also fix the day 1 issue I men= tioned allowing mix of
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 > devices with static and DHCPv6 up to /80.=
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The variable slaac solution draft propose= s a new =C2=A0RA PIO flag
>>=C2=A0 =C2=A0 =C2=A0that would
>>=C2=A0 =C2=A0 =C2=A0 > be used to signal longer prefixes, and wo= uld provide backwards
>>=C2=A0 =C2=A0 =C2=A0 > compatibility so that devices not support= ing woud ignore the flag
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0and
>>=C2=A0 =C2=A0 =C2=A0 > devices on newer code supporting would us= e the flag.=C2=A0 We definitely
>>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t want to impact any existing= devices on the existing 64 bit
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 > boundary standard.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Dmytro has tested the solution on Linux k= ernel signaling RA PIO
>>=C2=A0 =C2=A0 =C2=A0flag and
>>=C2=A0 =C2=A0 =C2=A0 > was able to successfully test any length = mask and random IID
>>=C2=A0 =C2=A0 =C2=A0generation
>>=C2=A0 =C2=A0 =C2=A0 > both RFC 4941 privacy extension as well a= s stable IID RFC 7217.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/=
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/= >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/=
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/= >>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > If everyone is in agreement with what I h= ave stated on this
>>=C2=A0 =C2=A0 =C2=A0thread, I
>>=C2=A0 =C2=A0 =C2=A0 > would like to ask the chairs for WG adopt= ion as this is a WG effort.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > I would like to garner support from all 6= MAN members with full
>>=C2=A0 =C2=A0 =C2=A0consensus
>>=C2=A0 =C2=A0 =C2=A0 > to change the existing RFC 4941 /64 fixed= boundary to /80 fixed
>>=C2=A0 =C2=A0 =C2=A0boundary.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Kind Regards
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Gyan
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 5:14 PM Joel M. H= alpern
>>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@j= oelhalpern.com>
>>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com <m= ailto:jmh@joelhalpern.com>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am missing something= in your reasoning.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0You seem to say at one= point that (to paraphrase) "we can't
>>=C2=A0 =C2=A0 =C2=A0do this
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0because it does not wo= rk with the existing UE software".
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Any new solution where= a UE delegates based on any change of
>>=C2=A0 =C2=A0 =C2=A0any kind
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(including lengthening= the prefix, shortening the prefix, or
>>=C2=A0 =C2=A0 =C2=A0magically
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0incanting new prefixes= ) requires that the UE be upgraded to know
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0what to
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0do with the informatio= n.=C2=A0 I do not see how that
>>=C2=A0 =C2=A0 =C2=A0differentiates any of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the solutions. (Except= "don't do anything", which I think we
>>=C2=A0 =C2=A0 =C2=A0do not
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0want
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to take.)
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yours,
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Joel
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM,= Gyan Mishra wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, = 2020 at 10:33 AM <otroan@employees.org
>>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:otroan@em= ployees.org <mailto:otroan@employees.org>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:otr= oan@employees.org <mailto:otroan@employees.org>
>>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailt= o:otroan@employees.org>>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > On 19 Nov 2020, at 14:58, Gyan Mishra
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<hayabusagsm@gma= il.com <mailto:hayabusagsm@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mai= lto:hayabusagsm@gmail.com>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:hayabusagsm@gmail.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusa= gsm@gmail.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>= >> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > You would need a new option. It would likely be
>>=C2=A0 =C2=A0 =C2=A0useful for the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0requesting router to indicate interest in the option. Even
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hinting
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0at what prefix size it was expecting.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Now can you explain to me again the reasons why this
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0approach is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0better than using the existing DHPCv6 protocol packets?
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A03GPP gateway doesn't support new option. What's your
>>=C2=A0 =C2=A0 =C2=A0point?
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 The point of the v6ops presentation and this email
>>=C2=A0 =C2=A0 =C2=A0thread is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0how to
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend = a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 of the
>>=C2=A0 =C2=A0 =C2=A0deck you
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0compiled
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a list of option= s and of the two I had highlighted in red
>>=C2=A0 =C2=A0 =C2=A0were the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share v2 Camer= on=E2=80=99s option and the variable slaac
>>=C2=A0 =C2=A0 =C2=A0option.=C2=A0 So on
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > call this mornin= g Lorenzo shot down 64share v2 shorter prefix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0option as
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even if the 3GPP= architecture was updated to support longer
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0prefixes and
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even is the 3GPP= gateway was able to send a shorter prefix
>>=C2=A0 =C2=A0 =C2=A0with A
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0flag
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > not set, all mob= ile devices per Lorenzo=E2=80=99s point would be
>>=C2=A0 =C2=A0 =C2=A0broken
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as they
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > would not accept= the shorter let=E2=80=99s say /56 prefix to build the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slaac 128
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > bit address.=C2= =A0 So the bottom line is the 64share v2 won=E2=80=99t work
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0unless we
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > update RFC 4291 = and remove the 64 bit boundary.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So w= e are back to square uno - no viable solution
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So n= ow we had thrown out the longer >64 due to race to
>>=C2=A0 =C2=A0 =C2=A0bottom
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0worries
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > which I and othe= rs believe is Fud and as described in
>>=C2=A0 =C2=A0 =C2=A0slide 10 of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Cr= ace to the bottom slide=E2=80=9D.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So a happy mediu= m /80 fixed boundary I came up with that I
>>=C2=A0 =C2=A0 =C2=A0think
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0solves
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a lot of the iss= ue and not just the 3GPP initial
>>=C2=A0 =C2=A0 =C2=A0segmentation of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > downstream devic= es problem statement.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Since we have to= update RFC 4291 for 64share v2 to work
>>=C2=A0 =C2=A0 =C2=A0anyways
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to allow
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for shorter pref= ixes, why not instead create a new bottom
>>=C2=A0 =C2=A0 =C2=A0at /80
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0giving
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 16 bits more of = prefix length and shrinking the IID down
>>=C2=A0 =C2=A0 =C2=A0to 48 bits.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Doing so you wou= ld not even have to update the 3GPP
>>=C2=A0 =C2=A0 =C2=A0architecture
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as I
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t kn= ow if that would fly or not.=C2=A0 Also this solves a
>>=C2=A0 =C2=A0 =C2=A0few other
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > problems at the = same time.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As I mentioned i= n the v6ops deck presented that vlsm 0 to
>>=C2=A0 =C2=A0 =C2=A0128 is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mainstream for o= perators for static addressing on router
>>=C2=A0 =C2=A0 =C2=A0and switch
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure a= nd dhcpv6 subnets longer prefixes for network
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure a= ppliance clusters, NFV/VNF virtualization
>>=C2=A0 =C2=A0 =C2=A0and server
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On = host subnets where there is a chance of mix of
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hosts
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2= =A0devices the prefix length is stuck at /64.=C2=A0 So on
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0these mix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > addressing host = subnets we cannot do longer prefixes following
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0our ND
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > cache hard limit= mantra to prevent ND cache exhaustion
>>=C2=A0 =C2=A0 =C2=A0issues as
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > described in RFC= 6164.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So with the /80 = new fixed boundary shifting prefix length
>>=C2=A0 =C2=A0 =C2=A016 bits
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0longer
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and shortening t= he IID by 16 bits gives resolved the 3GPP
>>=C2=A0 =C2=A0 =C2=A0issue
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0which
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share can work= as is and subtending to downstream
>>=C2=A0 =C2=A0 =C2=A0devices will now
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > work as a /64 is= now equivalent to a /48 with 64k /80s.=C2=A0 Also
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0BCP-690
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for broadband no= t all operators have adopted the shorter
>>=C2=A0 =C2=A0 =C2=A0prefix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0lengths
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /56 or /48 recom= mendations =C2=A0and now that=E2=80=99s not an issue as the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0/64 would
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > now suffice.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an op= erators perspective that gain allows at least
>>=C2=A0 =C2=A0 =C2=A0for 3GPP
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > massive growth a= nd subtending with a single /64 allows the
>>=C2=A0 =C2=A0 =C2=A0operators
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > such as Verizon = with massive subscriber base worldwide can
>>=C2=A0 =C2=A0 =C2=A0stay with
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > current allocati= ons and don=E2=80=99t have to ask
>>=C2=A0 =C2=A0 =C2=A0<https://www.google.co= m/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=3Dgmail&a= mp;source=3Dg>
>>=C2=A0 =C2=A0 =C2=A0for /10.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As 5G gets rolle= d out with Enhanced VPN framework and Network
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slicing
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > paradigm, the de= mand for shorter blocks and wearable
>>=C2=A0 =C2=A0 =C2=A0multiple /48
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0will
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > be our new reali= ty.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Making that 16 b= it shift now to /80 making a /64 the new
>>=C2=A0 =C2=A0 =C2=A0/48 will
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0give
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > broadband and 3G= PP subscribers a ton of space to
>>=C2=A0 =C2=A0 =C2=A0subtending their
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > networks we woul= d be set for the future.=C2=A0 Especially with
>>=C2=A0 =C2=A0 =C2=A0IOT the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0demand
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for subtending w= ill continue to grow astronomically.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also IANA does n= ot have to get start in allocating the
>>=C2=A0 =C2=A0 =C2=A0other /3 and
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > other available = blocks.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Lots of problems= being solved here with a fixed /80 new
>>=C2=A0 =C2=A0 =C2=A0boundary.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also with the ex= isting random IID generation schemes which
>>=C2=A0 =C2=A0 =C2=A0we have
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > tested on Linux = kernel can do longer p
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.co= m/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&sour= ce=3Dg <https://www.google.com/maps/search/tested+on+Li= nux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg>>refixes<= br> >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy=
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > extension or RFC= 7217 stable IID.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Win-Win for all.=
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Ole
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > --
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <htt= p://www.verizon.com/ <http://www.verizon.com/>
>>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.com/>>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra* >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Network Solutio= ns A//rchitect /
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347<= br> >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia P= ike
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, = MD
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > ________________= _______________________________
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops mailing li= st
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org &= lt;mailto:v6ops@ietf.org>
>>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org= >>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/v6ops
>>=C2=A0 =C2=A0 =C2=A0<https://www.ie= tf.org/mailman/listinfo/v6ops>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/v6ops
>>=C2=A0 =C2=A0 =C2=A0<https://www.ie= tf.org/mailman/listinfo/v6ops>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > --
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ = <http://www.verizon.com/>>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect /
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> /Network Solutions A//rchitect /
>>
>> /M 301 502-1347
>> 13101 Columbia Pike
>> /Silver Spring, MD
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6o= ps
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
--------------------------------------------------------------------
--0000000000006cdfa905b496467f-- From nobody Fri Nov 20 21:48:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B113A0147; Fri, 20 Nov 2020 21:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-qEt5v9HELu; Fri, 20 Nov 2020 21:48:01 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7965F3A00E0; Fri, 20 Nov 2020 21:48:01 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id 92so7833687otd.5; Fri, 20 Nov 2020 21:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SAnBXZC2MePSZR2bKXmKM+IYLG3m54jbPFaxMYDBNxM=; b=NrINDXRZhia0JpYwm+GRxEmYeOCduCgTSUMbyUrPFFtNwjc4mVu8P/PG6pVXXiRwSG K+Gf+DdgB2NmCHLnzQDUS/8jKCUc2opi05uF1duXRp5aDyN1nCaRTfBMsyA653xNUruV lD5IC8Sswg9NKMBQQ8l18R6q5WtF2d2WWQOnUaUUm9ojBUFgs13AY3SJMIaKSb3wjOKZ qvfQA01iG6EQ5KCPkCto/Y0XdqrrByGY2tCYCwPYUSlOWrLzvpaBLcQxg+89aoVKPiow c59EGpQkeIOnHDONZwW3rPtce6ctwq2femsP3W5pNbajCjLyAWtC/r2O4GgLKrf3gyZt iyxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SAnBXZC2MePSZR2bKXmKM+IYLG3m54jbPFaxMYDBNxM=; b=s2r0eV/IhW8SAHOcAQDsmtM12yYfzS4a7ZowIKCUGtfeCA18dCHTAs6UIrdPNmoEhy QI23PH3t2o2a4wxLGSiwSa78ukZVxHAPjPP7Y5EC/+7X5fTHZ+3svGCmnPGnYN0kGtvq UILt2pefd44cA76H9ooS8mAyj5uAsiEAQOSYQEv+qwZsFMVxin2PJeAuVWfvn8Z98etF Q9GNuCgOX2huui/c+bW/lCdfX8N9LBmIX5UCX7PauKXQ03jYgGuZ2rU5c9rwPQe2suCc CaVux798kFlchJi71PFZw+kO9AXkokQ9E+czi/gVDQM9wFQbIO+uZCVYqkd1BmcadAnW 66wA== X-Gm-Message-State: AOAM533Z4jDd1Gfj61Hzh/4e3LkxJV8ltJ4Fg14K/ZoUAJDQU4n/djZS 9RjZozFVCeQga7mKpP8F6WT79pOIJbbdxMI6h1I= X-Google-Smtp-Source: ABdhPJxVRF/nldU377Z5Mio2OYCpwzE/2ArmcCkqzBUYSBAYy3dGca9lK/501f1NQdG3Ux1ZzsvjZm1gaUGw4A9G4b4= X-Received: by 2002:a9d:a0d:: with SMTP id 13mr15206281otg.348.1605937680583; Fri, 20 Nov 2020 21:48:00 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> In-Reply-To: From: Mark Smith Date: Sat, 21 Nov 2020 16:47:34 +1100 Message-ID: To: Gyan Mishra Cc: "Joel M. Halpern" , IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ Content-Type: multipart/alternative; boundary="000000000000fb911905b4978020" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 05:48:05 -0000 --000000000000fb911905b4978020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 21 Nov 2020, 09:27 Gyan Mishra, wrote: > > (top posting) > > As I would like to clear the air as well as get to the crux of the v6ops > presentation development results as well as next steps for this draft and > the 6man variable slaac solutions draft: > > You're asserting that everybody has accepted there is a problem to be solved, and that everybody has accepted that the only way to solve it is to change the default 64 bit IID size. This is both premature and not a representation about "everybody's" opinion you can make. I haven't accepted either of those things. I'm not happy with the idea of changing away for 64 bit IIDs because I don't think 64 bit IIDs are the problem. Plenty of operators have given out /56s. I'm working at my second one. It is not impossible. Many things below are incorrect, uninformed, or quite frankly ridiculous. Some read like you've let your imagination go wild and then have just assumed because you can imagine it it will then inevitably happen in the near future. For example, DHCPv6 does not provide a prefix length to hosts. Your proposal does not make SLAAC "consistent' with what DHCPv6 does, because DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA in the DHCPv6 RFC). "the idea of a wearable /48 will really be many /48s"? Do you really think we're going to have more devices on our person that we'll need more than 65 536 /64 subnets (a single /48) to number them? That sounds like science fiction to me for at least the next 200 years or more. IPv6 isn't and isn't required to be the final and only Internet protocol for the remainder of humanity, so we don't have to try to accommodate every conceivable idea that somebody can come up with that might cause the 128 bit address space to be too small. > > This thread was in light of Lorenzo kindly pointing out that upgrading > 3GPP is not all that needs be done for Cameron=E2=80=99s 64share v2 to wo= rk - as > all mobile devices would stop working- as slaac would not would be > effectively broken. > > The mobile device would receive a shorter prefix let=E2=80=99s say /56 bu= t not > know what to do with it since it=E2=80=99s expecting a /64. > > So that a major gap and the only solution is updating RFC 4291 removing > the 64 bit boundary allowing for shorter prefix and now as well longer > prefixes to work and in that respect now provide the much needed parity > with static and DHCPv6 which can do any prefix length. > > So that is a drastic change to RFC 4291. However, in light of this > development on the v6ops 109 call, my balancing act of best of both world= s > and also to keep everyone happy to make this a WG effort for this change = by > proposing in the subject heading /80 fixed boundary and not a variable > slaac change allowing all bits vlsm. > > Basically stealing 16 bits for network prefix out of the IID, still > keeping the fixed boundary so longer than 80 would NOT be allowed. > > A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s. > > This /80 would keep the operators and law enforcement happy as now 16 bit= s > less helps traceability but is still long enough for 48 bits of privacy t= o > IP correlation by attackers. > > This /80 would be a nice optimal balance as it would keep wired broadband > and mobile handset customers happy respecting their privacy as the 16 bit= s > less of heuristics is minimal change that will impact IP correlation by > attackers. > > The IID as it=E2=80=99s less than the current 64 bit cannot use MAC based= EUI64 > IID, which is not a problem as Mac based IID is not recommended as most a= ll > manufacturers use RFC 4941 and I believe Linux flavors some use stable II= D > RFC 7217. > > So now the 48 bit IID would require a random IID generation schema so can > use either RFC 4941 privacy extension or RFC 7217 stable IID to generate > the 48 bit IID. > > 3GPP subtending would now work issue mentioned in the problem statement > draft without even having to use 64share as now longer prefixes up to /80 > would be supported allowing for further segmentation of downstream device= s. > > This also would help wired broadband and soon fixed 5G broadband > proliferation where operators in light of BCP RIPE-690, are sill allocati= on > via BNG gateways a /64, now operators can stay as-is, as the /64 would n= ow > be allowed to be further segmented supporting 64k /80s, way more then > enough for SOHO. > > This would allow 64share if used by 3GPP operators to work and would not > require the 3GPP specification to be updated. We don=E2=80=99t know even= if the > 3GPP architecture specification can be updated to support shorter prefixe= s > and if the 3GPP consortium of operators would agree to it. So that is al= l > theoretical of that change is possible. > > As with 5G with Enhanced VPN framework SR steering of high priority > traffic, traffic isolation and Network slicing capabilities becomes > mainstream and will soon be a real world reality and as fixed 5G broadban= d > proliferation takes off and mobile 5G =3D=3D the idea of a wearable /48 w= ill > really be many /48s. > > As this paradigm shift takes place, operators around the world will be > clamoring after the RIR for massive blocks, I would say less than /8 more > like a /5 or /4. If you do the math on the way high side a /10 yields 7 > bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is tiny number > with the number of large size operators worldwide. > > With the massive proliferation of IOT devices and just about every home o= r > office appliance on 5G, the problem now gets way exacerbated. > > As this evolution unfolds IANA will be scrambling to release all remainin= g > /3 as well as all unallocated blocks to subvert RIR IPv6 address space > depletion. > > Playing Monday night quarterbacking in hindsight we would never think thi= s > would happen in a million years, but we would see IPv6 on the verge of > address space depletion. Unheard of but it can happen as the saying goes > =E2=80=9Cwhen you build - they will come=E2=80=9D. > > It is true as history has taught that very important lesson. > > The answer to this real world problem is in the subject heading of this > thread. > > This would also fix the day 1 issue I mentioned allowing mix of slaac > devices with static and DHCPv6 up to /80. > > The variable slaac solution draft proposes a new RA PIO flag that would > be used to signal longer prefixes, and would provide backwards > compatibility so that devices not supporting woud ignore the flag and > devices on newer code supporting would use the flag. We definitely don= =E2=80=99t > want to impact any existing devices on the existing 64 bit slaac boundary > standard. > > Dmytro has tested the solution on Linux kernel signaling RA PIO flag and > was able to successfully test any length mask and random IID generation > both RFC 4941 privacy extension as well as stable IID RFC 7217. > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > If everyone is in agreement with what I have stated on this thread, I > would like to ask the chairs for WG adoption as this is a WG effort. > > I would like to garner support from all 6MAN members with full consensus > to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary. > > Kind Regards > > Gyan > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > wrote: > >> I am missing something in your reasoning. >> You seem to say at one point that (to paraphrase) "we can't do this >> because it does not work with the existing UE software". >> Any new solution where a UE delegates based on any change of any kind >> (including lengthening the prefix, shortening the prefix, or magically >> incanting new prefixes) requires that the UE be upgraded to know what to >> do with the information. I do not see how that differentiates any of >> the solutions. (Except "don't do anything", which I think we do not want >> to take.) >> >> Yours, >> Joel >> >> On 11/19/2020 5:03 PM, Gyan Mishra wrote: >> > >> > >> > On Thu, Nov 19, 2020 at 10:33 AM > > > wrote: >> > >> > >> > >> > > On 19 Nov 2020, at 14:58, Gyan Mishra > > > wrote: >> > > >> > > You would need a new option. It would likely be useful for the >> > requesting router to indicate interest in the option. Even hinting >> > at what prefix size it was expecting. >> > > Now can you explain to me again the reasons why this approach i= s >> > better than using the existing DHPCv6 protocol packets? >> > > >> > > 3GPP gateway does not support DHCPv6 >> > >> > 3GPP gateway doesn't support new option. What's your point? >> > >> > >> > >> > The point of the v6ops presentation and this email thread is how >> to >> > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of the= deck you >> compiled >> > a list of options and of the two I had highlighted in red were the >> > 64share v2 Cameron=E2=80=99s option and the variable slaac option. So= on the >> > call this morning Lorenzo shot down 64share v2 shorter prefix option a= s >> > even if the 3GPP architecture was updated to support longer prefixes >> and >> > even is the 3GPP gateway was able to send a shorter prefix with A flag >> > not set, all mobile devices per Lorenzo=E2=80=99s point would be broke= n as they >> > would not accept the shorter let=E2=80=99s say /56 prefix to build the= slaac >> 128 >> > bit address. So the bottom line is the 64share v2 won=E2=80=99t work = unless we >> > update RFC 4291 and remove the 64 bit boundary. >> > >> > So we are back to square uno - no viable solution >> > >> > So now we had thrown out the longer >64 due to race to bottom worrie= s >> > which I and others believe is Fud and as described in slide 10 of the >> > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. >> > >> > So a happy medium /80 fixed boundary I came up with that I think solve= s >> > a lot of the issue and not just the 3GPP initial segmentation of >> > downstream devices problem statement. >> > >> > Since we have to update RFC 4291 for 64share v2 to work anyways to >> allow >> > for shorter prefixes, why not instead create a new bottom at /80 givin= g >> > 16 bits more of prefix length and shrinking the IID down to 48 bits. >> > Doing so you would not even have to update the 3GPP architecture as I >> > don=E2=80=99t know if that would fly or not. Also this solves a few o= ther >> > problems at the same time. >> > >> > >> > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is >> > mainstream for operators for static addressing on router and switch >> > infrastructure and dhcpv6 subnets longer prefixes for network >> > infrastructure appliance clusters, NFV/VNF virtualization and server >> > farms. On host subnets where there is a chance of mix of slaac hosts >> > with dhcpv6 devices the prefix length is stuck at /64. So on these >> mix >> > addressing host subnets we cannot do longer prefixes following our ND >> > cache hard limit mantra to prevent ND cache exhaustion issues as >> > described in RFC 6164. >> > >> > So with the /80 new fixed boundary shifting prefix length 16 bits >> longer >> > and shortening the IID by 16 bits gives resolved the 3GPP issue which >> > 64share can work as is and subtending to downstream devices will now >> > work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 >> > for broadband not all operators have adopted the shorter prefix length= s >> > /56 or /48 recommendations and now that=E2=80=99s not an issue as the= /64 >> would >> > now suffice. >> > >> > From an operators perspective that gain allows at least for 3GPP >> > massive growth and subtending with a single /64 allows the operators >> > such as Verizon with massive subscriber base worldwide can stay with >> > current allocations and don=E2=80=99t have to ask for /10. >> > >> > As 5G gets rolled out with Enhanced VPN framework and Network slicing >> > paradigm, the demand for shorter blocks and wearable multiple /48 will >> > be our new reality. >> > >> > Making that 16 bit shift now to /80 making a /64 the new /48 will give >> > broadband and 3GPP subscribers a ton of space to subtending their >> > networks we would be set for the future. Especially with IOT the >> demand >> > for subtending will continue to grow astronomically. >> > >> > Also IANA does not have to get start in allocating the other /3 and >> > other available blocks. >> > >> > Lots of problems being solved here with a fixed /80 new boundary. >> > >> > Also with the existing random IID generation schemes which we have >> > tested on Linux kernel can do longer p >> refixes >> using RFC 4941 privacy >> > extension or RFC 7217 stable IID. >> > >> > Win-Win for all. >> > >> > Ole >> > >> > -- >> > >> > >> > >> > *Gyan Mishra* >> > >> > /Network Solutions A//rchitect / >> > >> > /M 301 502-1347 >> > 13101 Columbia Pike >> > /Silver Spring, MD >> > >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000fb911905b4978020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 21 Nov 2020, 09:27 Gyan Mishra, &= lt;hayabusagsm@gmail.com= > wrote:

(top posting)=C2=A0

As I would like to clear the air as well as get to the crux of= the v6ops presentation development results as well as next steps for this = draft and the 6man variable slaac solutions draft:
<= br>

You're asserting that everybo= dy has accepted there is a problem to be solved, and that everybody has acc= epted that the only way to solve it is to change the default 64 bit IID siz= e. This is both premature and not a representation about "everybody= 9;s" opinion you can make.

I haven't acce= pted either of those things.

I'm not happy with the idea of changing awa= y for 64 bit IIDs because I don't think 64 bit IIDs are the problem. Pl= enty of operators have given out /56s. I'm working at my second one. It= is not impossible.

Many things below are incorrect, uninformed, or quite frankly ridiculous.= Some read like you've let your imagination go wild and then have just = assumed because you can imagine it it will then inevitably happen in the ne= ar future.

For example, DHCPv6 does not provide a prefix l= ength to hosts. Your proposal does not make SLAAC "consistent' wit= h what DHCPv6 does, because DHCPv6 doesn't work the way you think it do= es (look up IA_NA and IA_TA in the DHCPv6 RFC).

"the idea of a wearable /48 will really be many /48s&quo= t;? Do you really think we're going to have more devices on our person = that we'll need more than 65 536 /64 subnets (a single /48) to number t= hem? That sounds like science fiction to me for at least the next 200 years= or more.

IPv6 isn't and isn't require= d to be the final and only Internet protocol for the remainder of humanity,= so we don't have to try to accommodate every conceivable idea that som= ebody can come up with that might cause the 128 bit address space to be too= small.
=C2=A0

=
This thread was in light of Lorenzo kindly pointing out t= hat upgrading 3GPP is not all that needs be done for Cameron=E2=80=99s 64sh= are v2 to work - as all mobile devices would stop working- as slaac would n= ot would be effectively broken.

The mobile device would receive a shorter prefix let=E2=80=99s sa= y /56 but not know what to do with it since it=E2=80=99s expecting a /64.

So that a major gap and t= he only solution is updating RFC 4291 removing the 64 bit boundary allowing= for shorter prefix and now as well longer prefixes to work and in that res= pect now provide the much needed parity with static and DHCPv6 which can do= any prefix length.

So t= hat is a drastic change to RFC 4291.=C2=A0 However, in light of this develo= pment on the v6ops 109 call, my balancing act of best of both worlds and al= so to keep everyone happy to make this a WG effort for this change by propo= sing in the subject heading /80 fixed boundary and not a variable slaac cha= nge allowing all bits vlsm.

Basically stealing 16 bits for network prefix out of the IID, still kee= ping the fixed boundary so longer than 80 would NOT =C2=A0be allowed.
=

A /64 would now be equivalent= to a /48 with now 64k /80=E2=80=99s. =C2=A0

This /80 would keep the operators and law enforcement = happy as now 16 bits less helps traceability but is still long enough for 4= 8 bits of privacy to IP correlation by attackers.
This /80 would be a nice optimal balance as it wo= uld keep wired broadband and mobile handset customers happy respecting thei= r privacy as the 16 bits less of heuristics is minimal change that will imp= act IP correlation by attackers.

The IID as it=E2=80=99s less than the current 64 bit cannot use M= AC based EUI64 IID, which is not a problem as Mac based IID is not recommen= ded as most all manufacturers use RFC 4941 and I believe Linux flavors some= use stable IID RFC 7217.

So now the 48 bit IID would require a random IID generation schema so can= use either RFC 4941 privacy extension or RFC 7217 stable IID to generate t= he 48 bit IID.

3GPP subt= ending would now work issue mentioned in the problem statement draft withou= t even having to use 64share as now longer prefixes up to /80 would be supp= orted allowing for further segmentation of downstream devices.

This also would help wired broadband= and soon fixed 5G broadband proliferation where operators in light of BCP = RIPE-690, are sill allocation via BNG gateways a /64, now operators =C2=A0c= an stay as-is, as the /64 would now be allowed to be further segmented supp= orting 64k /80s, way more then enough for SOHO.

=
This would allow 64share if used by 3GPP operators = to work and would not require the 3GPP specification to be updated.=C2=A0 W= e don=E2=80=99t know even if the 3GPP architecture specification can be upd= ated to support shorter prefixes and if the 3GPP consortium of operators wo= uld agree to it.=C2=A0 So that is all theoretical of that change is possibl= e.

As with 5G with Enhan= ced VPN framework SR steering of high priority traffic, traffic isolation a= nd Network slicing capabilities becomes mainstream and will soon be a real = world reality and as fixed 5G broadband proliferation takes off and mobile = 5G =3D=3D the idea of a wearable /48 will really be many /48s.=C2=A0
<= div dir=3D"auto">
As this paradigm shift takes p= lace, operators around the world will be clamoring after the RIR for massiv= e blocks, I would say less than /8 more like a /5 or /4.=C2=A0 If you do th= e math on the way high side a /10 yields 7 bits so 128 divided by 5 RIRs yi= elds 24 ISPs per RIR which is tiny number with the number of large size ope= rators worldwide.=C2=A0

= With the massive proliferation of IOT devices and just about every home or = office appliance on 5G, the problem now gets way exacerbated.=C2=A0

As this evolution unfolds IANA = will be scrambling to release all remaining /3 as well as all unallocated b= locks to subvert RIR IPv6 address space depletion.
<= br>
Playing Monday night quarterbacking in hindsight= we would never think this would happen in a million years, but we would se= e IPv6 on the verge of address space depletion.=C2=A0 Unheard of but it can= happen as the saying goes =E2=80=9Cwhen you build - they will come=E2=80= =9D.

It is true as histo= ry has taught that very important lesson.

=
The answer to this real world problem is in the subject h= eading of this thread.

T= his would also fix the day 1 issue I mentioned allowing mix of slaac device= s with static and DHCPv6 up to /80.

The variable slaac solution draft proposes a new =C2=A0RA PIO f= lag that would be used to signal longer prefixes, and would provide backwar= ds compatibility so that devices not supporting woud ignore the flag =C2=A0= and devices on newer code supporting would use the flag.=C2=A0 We definitel= y don=E2=80=99t want to impact any existing devices on the existing 64 bit = slaac boundary standard.

Dmytro has tested the solution on Linux kernel signaling RA PIO flag and w= as able to successfully test any length mask and random IID generation both= RFC 4941 privacy extension as well as stable IID RFC 7217.

=
If everyone is in agreement with what I have stated on th= is thread, I would like to ask the chairs for WG adoption as this is a WG e= ffort.

I would like to g= arner support from all 6MAN members with full consensus to change the exist= ing RFC 4941 /64 fixed boundary to /80 fixed boundary.

Kind Regards=C2=A0
Gyan

On Thu, Nov 19= , 2020 at 5:14 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
I am missing something in your reason= ing.
You seem to say at one point that (to paraphrase) "we can't do thi= s
because it does not work with the existing UE software".
Any new solution where a UE delegates based on any change of any kind
(including lengthening the prefix, shortening the prefix, or magically
incanting new prefixes) requires that the UE be upgraded to know what to do with the information.=C2=A0 I do not see how that differentiates any of =
the solutions. (Except "don't do anything", which I think we = do not want
to take.)

Yours,
Joel

On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>
>
> On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org
> <mailto:ot= roan@employees.org>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.co= m
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > You would need a new option. It would likely = be useful for the
>=C2=A0 =C2=A0 =C2=A0requesting router to indicate interest in the optio= n. Even hinting
>=C2=A0 =C2=A0 =C2=A0at what prefix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 > Now can you explain to me again the reasons w= hy this approach is
>=C2=A0 =C2=A0 =C2=A0better than using the existing DHPCv6 protocol pack= ets?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not supp= ort DHCPv6
>
>=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't support new option. What&#= 39;s your point?
>
>
>
>=C2=A0 =C2=A0 =C2=A0 The point of the v6ops presentation and this email= thread is how to
> =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 o= f the deck you compiled
> a list of options and of the two I had highlighted in red were the > 64share v2 Cameron=E2=80=99s option and the variable slaac option.=C2= =A0 So on the
> call this morning Lorenzo shot down 64share v2 shorter prefix option a= s
> even if the 3GPP architecture was updated to support longer prefixes a= nd
> even is the 3GPP gateway was able to send a shorter prefix with A flag=
> not set, all mobile devices per Lorenzo=E2=80=99s point would be broke= n as they
> would not accept the shorter let=E2=80=99s say /56 prefix to build the= slaac 128
> bit address.=C2=A0 So the bottom line is the 64share v2 won=E2=80=99t = work unless we
> update RFC 4291 and remove the 64 bit boundary.
>
>=C2=A0 =C2=A0So we are back to square uno - no viable solution
>
>=C2=A0 =C2=A0So now we had thrown out the longer >64 due to race to = bottom worries
> which I and others believe is Fud and as described in slide 10 of the =
> v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>
> So a happy medium /80 fixed boundary I came up with that I think solve= s
> a lot of the issue and not just the 3GPP initial segmentation of
> downstream devices problem statement.
>
> Since we have to update RFC 4291 for 64share v2 to work anyways to all= ow
> for shorter prefixes, why not instead create a new bottom at /80 givin= g
> 16 bits more of prefix length and shrinking the IID down to 48 bits.= =C2=A0
> Doing so you would not even have to update the 3GPP architecture as I =
> don=E2=80=99t know if that would fly or not.=C2=A0 Also this solves a = few other
> problems at the same time.
>
>
> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is
> mainstream for operators for static addressing on router and switch > infrastructure and dhcpv6 subnets longer prefixes for network
> infrastructure appliance clusters, NFV/VNF virtualization and server <= br> > farms.=C2=A0 On host subnets where there is a chance of mix of slaac h= osts
> with dhcpv6 =C2=A0devices the prefix length is stuck at /64.=C2=A0 So = on these mix
> addressing host subnets we cannot do longer prefixes following our ND =
> cache hard limit mantra to prevent ND cache exhaustion issues as
> described in RFC 6164.
>
> So with the /80 new fixed boundary shifting prefix length 16 bits long= er
> and shortening the IID by 16 bits gives resolved the 3GPP issue which =
> 64share can work as is and subtending to downstream devices will now <= br> > work as a /64 is now equivalent to a /48 with 64k /80s.=C2=A0 Also BCP= -690
> for broadband not all operators have adopted the shorter prefix length= s
> /56 or /48 recommendations =C2=A0and now that=E2=80=99s not an issue a= s the /64 would
> now suffice.
>
>=C2=A0 From an operators perspective that gain allows at least for 3GPP=
> massive growth and subtending with a single /64 allows the operators <= br> > such as Verizon with massive subscriber base worldwide can stay with <= br> > current allocations and don=E2=80=99t have to ask for /10.
>
> As 5G gets rolled out with Enhanced VPN framework and Network slicing =
> paradigm, the demand for shorter blocks and wearable multiple /48 will=
> be our new reality.
>
> Making that 16 bit shift now to /80 making a /64 the new /48 will give=
> broadband and 3GPP subscribers a ton of space to subtending their
> networks we would be set for the future.=C2=A0 Especially with IOT the= demand
> for subtending will continue to grow astronomically.
>
> Also IANA does not have to get start in allocating the other /3 and > other available blocks.
>
> Lots of problems being solved here with a fixed /80 new boundary.
>
> Also with the existing random IID generation schemes which we have > tested on Lin= ux kernel can do longer prefixes using RFC 4941 privacy
> extension or RFC 7217 stable IID.
>
> Win-Win for all.
>
>=C2=A0 =C2=A0 =C2=A0Ole
>
> --
>
> <ht= tp://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/v6ops
>
--


Gyan Mishra

Network Solutions Architect=C2=A0

<= i>M 301 502-1347
13101 Columbia Pike=C2=A0=
Silver Spring, MD


=
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=
--------------------------------------------------------------------
--000000000000fb911905b4978020-- From nobody Fri Nov 20 22:12:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0583A0820; Fri, 20 Nov 2020 22:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EECw5mTtiW6d; Fri, 20 Nov 2020 22:12:35 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909243A0809; Fri, 20 Nov 2020 22:12:34 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id z14so8820068ilm.10; Fri, 20 Nov 2020 22:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=44E++6qCugQLP47D7wap7jk9fMPbPL/2kvckuTdxzBo=; b=M1HDW7USXK60zP684jQEtNAU3i5g9WIE+KDZ0imu/WOVGmb1J2EEy+5oL0khD8Ly7Q 7RU15DTbG2mU8cgt+kAR35uWtpARPlwCTAHk10z42BCdgNl8XpQv4QJYi1giTCXXSc5j AtKlGNQ5xupidfSsMH1fvY52FOaE+apvxFV1rhxOQ3fXlWYyPz43H+3fsxJ1zf+olyg2 MtqgT5fRDM6AVOqD4ecavVjC1HLMhhiF2sKZHG1As2aoHLOpbn0+1rScJhyAGFVceimh vqy00E5Sm/js3jUXky1s9w+olLjZTKupKuUuelTUWMBLJQFPJzpX+zHs0lwVXuQNVmP3 LGcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=44E++6qCugQLP47D7wap7jk9fMPbPL/2kvckuTdxzBo=; b=dSX+C/011B76Bpf5e4Q8jnPBeAbGah5vmKzGza9wk7zB27ugf+HwWvrSzCfAeni8pn MtQaNILZADfz86SuNexm4pKTSHl1rXCvN82Cu8FonKI8W/XxoDJ5iiSf/mR38hmkiBLW mkwvYBOcOLJD76Nm3ttO4dPKVV/o4HoIruHFLUGMbhnmBLFrLpIXf1+fQ5QF5Y4H94IV Uqcq/XJlxI+qbveGzjBoi4031AuRxM4/asYIybI0e1stvdrUlKvVr5qSFiRoa+9wABt+ K+92k7p5yBJUDvnmnsuTiKA4pgUu/vs8UBoKDehzksnNnvNpl+hOzSkK8EQLmT5Nmjgg rzOw== X-Gm-Message-State: AOAM530JaZnN2kFmtXi95A3IhL+zN4gQqIlcsXrO5+u8/DyLA9SmrpEv gwbW1Q7IjuBPMJ2u5bQP6yAoSpQUukXsnEPMq2A= X-Google-Smtp-Source: ABdhPJynkaI5CC3tzXX9hOP0pKFmyxHiQa5SCIm7aMeOvCdoy3Ae7245HiDdWA5bsR6pAKLvU4AHrBDBHVrKK+7alw0= X-Received: by 2002:a92:5e9a:: with SMTP id f26mr12690572ilg.129.1605939153336; Fri, 20 Nov 2020 22:12:33 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> In-Reply-To: From: Ca By Date: Fri, 20 Nov 2020 22:12:22 -0800 Message-ID: To: Mark Smith Cc: 6MAN <6man@ietf.org>, Brian E Carpenter , IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000c3ff4105b497d8c7" Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 06:12:40 -0000 --000000000000c3ff4105b497d8c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2020 at 8:20 PM Mark Smith wrote: > > > On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, > wrote: > >> Joel, >> >> It seems to me that it's high time to draft a liaison statement to 3GPP, >> observing that: >> >> (1) There is a serious problem for the design and implementation of >> 5G-based IPv6 "hot spots" and CEs [which is where this conversation >> started]; >> > > I think it is also important to find out why they haven't deployed DHCPv6 > to solve this problem. > > Don't they think DHCPv6 infrastructure will scale? Is it just that they > don't know how to scale it? > Definitely do not know how. I had a look at the dhcpv6 rfc and it was over 150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr. > Is it a vendor / mobile operator / handset developer DHCPv6 > capability chicken-and-egg problem? > I believe that exists too. > Is there an overriding business or industry reason? > No. Just the usual nobody will come to the shop to pay for dhcpv6, so it is hard to martial market demand. Major vendors (android) have vocally declined to support dhcpv6. Other scenarios it is supported but default off. > The mobile industry has been resistant to tethering over the years, and > probably only came to begrudgingly accept it because they couldn't preven= t > phone vendors from implementing Wifi and NAT, and couldn't very effective= ly > stop their customers from using that capability (One trick I've heard of = to > prevent tethering working was to check if an IPv4 packet's TTL value was = 64 > when it arrived at the network, meaning it originated from the directly > attached handset. Packets from tethered devices had a TTL of 63 so were > dropped. Of course, you could set the default TTL on a tethered PC to 65 = to > get around that.) > > I guess there might be a fairly strong mindset that there must be a fee > per device attached to the network in addition to a fee for network > utilisation. Providing multiple /64s would be formally acknowledging that > multiple devices can be attached and a fee per device isn't and can't eve= r > be charged, counter to the mindset. > I believe the sentiment on this list from operators has been trying to find ways to make more effective ways to support more complete ipv6 networks with the machinery we have. I don=E2=80=99t think you have seen otherwise. My own view is that i am trying to connect 10+M households, many rural, with 5G broadband... and i feel it would be negligent to not support ipv6 in the most common home networking scenarios. That said, my thinking has evolved. And, i appreciate the living and illuminating discussion. i don=E2=80=99t think i need standards work at = this point. I am i going to take a swing at making dhcpv6 work... not as specified in that long rfc, but just taking the view of a dhcpv6-pd packet as an api, which will simplify things. This has been a helpful read https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-03 > Regards, > Mark. > > >> (2) Although the best solution is not yet obvious, defining and >> standardizing it will require a joint effort by the IETF and 3GPP. >> >> Followed by a proposal to form an ad hoc joint design team. >> >> Regards >> Brian Carpenter >> On 21-Nov-20 14:46, Joel M. Halpern wrote: >> > The nesting got me lost, so I will top post my take on the answer to >> the >> > one quesiton I could understand. >> > >> > I believe you asked what I think would need to be changed to permit th= e >> > delegation. >> > As with anything, the real things that need to change are the devices >> in >> > the network. >> > >> > With regard to IETF standards, what is proposed is a change to RA. >> > There are several possible changes. None of them require a change to >> > the IPv6 addressing archtiecture, as the addressing structure remains >> as >> > it is. >> > As for the exact mechanism, at the moment I lean towards Ole's proposa= l >> > of using a new option in his generic option mechanism. But I am not >> > wedded to that answer. >> > >> > And of course, to get this supported in mobile environments we will >> have >> > to work with 3GPP and make sure there are no other hidden issues. >> > That's the way we do things. Work together. >> > >> > Changing the prefix length to /80 is technically also possible. It >> does >> > a lot more violence to my understanding of the architecture and >> software >> > structures that go with it, and is a very limited and narrow solution >> to >> > the problem. >> > >> > Yours, >> > Joel >> > >> > On 11/20/2020 7:58 PM, Gyan Mishra wrote: >> >> Hi Joel >> >> >> >> In-line >> >> >> >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern > >> > wrote: >> >> >> >> Gyan, separate from Ole's comments about the difference between >> address >> >> assignment and delegation, I have another problem following the >> >> reasoning below. >> >> >> >> Yes, the proposal for using shorter prefixes to enable UE to >> perform >> >> delegation will require changes to the UE. >> >> >> >> Gyan> Agreed. So that change would be to RFC 4291 64 bit >> boundary >> >> to allow for longer prefix. Do you agree? >> >> >> >> If you don=E2=80=99t agree what do think the change would be to allow= the UE >> to >> >> accept shorter prefix from the 3GPP gateway? >> >> >> >> >> >> But I do not see how that is relevant to any choice we are trying >> to >> >> make. >> >> Any solution that enables UE to delegate addresses (in the sense >> that >> >> they lack the capability now) willr equire changes to the UE. >> >> >> >> >> >> >> >> Gyan> If the UE receives a /56 via RA it could delegate /64 to >> >> downstream devices. No change needed to delegate /64, however a >> >> change is needed to accept /56 via RA. >> >> >> >> >> >> If 3GPP gateway supported PD - problem solved but that=E2=80=99s= not the >> >> case and that does not sound like it will ever change even with 5G. >> >> >> >> Gyan> The UE needs to be able to accept shorter prefix. That=E2= =80=99s >> the >> >> IPV6 specification change that requires removal of the 64 bit boundar= y. >> >> >> >> Yoru >> >> proposed change to the SLAAC length if anything does more violenc= e >> to >> >> the software (depending upon the exact software architecture.) >> >> >> >> >> >> Gyan> What violence to software. There would be more violence to >> >> software if we removed the 64 bit boundary and allowed slaac to >> support >> >> any vlsm prefix lengths. >> >> >> >> My /80 proposal would just shift the boundary 16 bits to /80. >> >> >> >> Hosts on the same subnet with two different masks would not be on-net >> to >> >> each other as on different subnets. The router would be configured >> with >> >> the two subnets /64 and /80 subnet to support the two device types. >> >> The solution would be a simple RA PIO flag that is set and older host= s >> >> not upgraded would be backwards compatible and so would only support >> 64 >> >> bit boundary by ignoring flag. Hosts upgraded to support would >> >> understand the flag and be able to support longer mask up to /80. >> >> >> >> >> >> >> >> So I do not follow how you got to your conclusion. >> >> >> >> Yours, >> >> Joel >> >> >> >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >> >> > >> >> > (top posting) >> >> > >> >> > As I would like to clear the air as well as get to the crux of >> >> the v6ops >> >> > presentation development results as well as next steps for thi= s >> >> draft >> >> > and the 6man variable slaac solutions draft: >> >> > >> >> > >> >> > This thread was in light of Lorenzo kindly pointing out that >> >> upgrading >> >> > 3GPP is not all that needs be done for Cameron=E2=80=99s 64sha= re v2 to >> >> work - as >> >> > all mobile devices would stop working- as slaac would not woul= d >> be >> >> > effectively broken. >> >> > >> >> > The mobile device would receive a shorter prefix let=E2=80=99s= say /56 >> >> but not >> >> > know what to do with it since it=E2=80=99s expecting a /64. >> >> > >> >> > So that a major gap and the only solution is updating RFC 4291 >> >> removing >> >> > the 64 bit boundary allowing for shorter prefix and now as wel= l >> >> longer >> >> > prefixes to work and in that respect now provide the much need= ed >> >> parity >> >> > with static and DHCPv6 which can do any prefix length. >> >> > >> >> > So that is a drastic change to RFC 4291. However, in light of >> this >> >> > development on the v6ops 109 call, my balancing act of best of >> both >> >> > worlds and also to keep everyone happy to make this a WG effor= t >> >> for this >> >> > change by proposing in the subject heading /80 fixed boundary >> and >> >> not a >> >> > variable slaac change allowing all bits vlsm. >> >> > >> >> > Basically stealing 16 bits for network prefix out of the IID, >> still >> >> > keeping the fixed boundary so longer than 80 would NOT be >> allowed. >> >> > >> >> > A /64 would now be equivalent to a /48 with now 64k /80=E2=80= =99s. >> >> > >> >> > This /80 would keep the operators and law enforcement happy as >> >> now 16 >> >> > bits less helps traceability but is still long enough for 48 >> bits of >> >> > privacy to IP correlation by attackers. >> >> > >> >> > This /80 would be a nice optimal balance as it would keep wire= d >> >> > broadband and mobile handset customers happy respecting their >> >> privacy as >> >> > the 16 bits less of heuristics is minimal change that will >> impact IP >> >> > correlation by attackers. >> >> > >> >> > The IID as it=E2=80=99s less than the current 64 bit cannot us= e MAC >> based >> >> EUI64 >> >> > IID, which is not a problem as Mac based IID is not recommende= d >> >> as most >> >> > all manufacturers use RFC 4941 and I believe Linux flavors som= e >> use >> >> > stable IID RFC 7217. >> >> > >> >> > So now the 48 bit IID would require a random IID generation >> >> schema so >> >> > can use either RFC 4941 privacy extension or RFC 7217 stable >> IID to >> >> > generate the 48 bit IID. >> >> > >> >> > 3GPP subtending would now work issue mentioned in the problem >> >> statement >> >> > draft without even having to use 64share as now longer prefixe= s >> >> up to >> >> > /80 would be supported allowing for further segmentation of >> >> downstream >> >> > devices. >> >> > >> >> > This also would help wired broadband and soon fixed 5G broadba= nd >> >> > proliferation where operators in light of BCP RIPE-690, are si= ll >> >> > allocation via BNG gateways a /64, now operators can stay >> as-is, >> >> as the >> >> > /64 would now be allowed to be further segmented supporting 64= k >> >> /80s, >> >> > way more then enough for SOHO. >> >> > >> >> > This would allow 64share if used by 3GPP operators to work and >> >> would not >> >> > require the 3GPP specification to be updated. We don=E2=80=99= t know >> even >> >> if the >> >> > 3GPP architecture specification can be updated to support >> shorter >> >> > prefixes and if the 3GPP consortium of operators would agree t= o >> >> it. So >> >> > that is all theoretical of that change is possible. >> >> > >> >> > As with 5G with Enhanced VPN framework SR steering of high >> priority >> >> > traffic, traffic isolation and Network slicing capabilities >> becomes >> >> > mainstream and will soon be a real world reality and as fixed = 5G >> >> > broadband proliferation takes off and mobile 5G =3D=3D the ide= a of a >> >> > wearable /48 will really be many /48s. >> >> > >> >> > As this paradigm shift takes place, operators around the world >> >> will be >> >> > clamoring after the RIR for massive blocks, I would say less >> than /8 >> >> > more like a /5 or /4. If you do the math on the way high side >> a /10 >> >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR >> >> which is >> >> > tiny number with the number of large size operators worldwide. >> >> > >> >> > With the massive proliferation of IOT devices and just about >> >> every home >> >> > or office appliance on 5G, the problem now gets way exacerbate= d. >> >> > >> >> > As this evolution unfolds IANA will be scrambling to release a= ll >> >> > remaining /3 as well as all unallocated blocks to subvert RIR >> IPv6 >> >> > address space depletion. >> >> > >> >> > Playing Monday night quarterbacking in hindsight we would neve= r >> >> think >> >> > this would happen in a million years, but we would see IPv6 on >> >> the verge >> >> > of address space depletion. Unheard of but it can happen as t= he >> >> saying >> >> > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. >> >> > >> >> > It is true as history has taught that very important lesson. >> >> > >> >> > The answer to this real world problem is in the subject headin= g >> >> of this >> >> > thread. >> >> > >> >> > This would also fix the day 1 issue I mentioned allowing mix o= f >> >> slaac >> >> > devices with static and DHCPv6 up to /80. >> >> > >> >> > The variable slaac solution draft proposes a new RA PIO flag >> >> that would >> >> > be used to signal longer prefixes, and would provide backwards >> >> > compatibility so that devices not supporting woud ignore the >> flag >> >> and >> >> > devices on newer code supporting would use the flag. We >> definitely >> >> > don=E2=80=99t want to impact any existing devices on the exist= ing 64 bit >> >> slaac >> >> > boundary standard. >> >> > >> >> > Dmytro has tested the solution on Linux kernel signaling RA PI= O >> >> flag and >> >> > was able to successfully test any length mask and random IID >> >> generation >> >> > both RFC 4941 privacy extension as well as stable IID RFC 7217= . >> >> > >> >> > >> >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac= / >> >> < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/> >> >> > >> >> < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >> >> < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>> >> >> > >> >> > If everyone is in agreement with what I have stated on this >> >> thread, I >> >> > would like to ask the chairs for WG adoption as this is a WG >> effort. >> >> > >> >> > I would like to garner support from all 6MAN members with full >> >> consensus >> >> > to change the existing RFC 4941 /64 fixed boundary to /80 fixe= d >> >> boundary. >> >> > >> >> > Kind Regards >> >> > >> >> > Gyan >> >> > >> >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >> >> >> >> > >> >> wrote: >> >> > >> >> > I am missing something in your reasoning. >> >> > You seem to say at one point that (to paraphrase) "we can'= t >> >> do this >> >> > because it does not work with the existing UE software". >> >> > Any new solution where a UE delegates based on any change = of >> >> any kind >> >> > (including lengthening the prefix, shortening the prefix, = or >> >> magically >> >> > incanting new prefixes) requires that the UE be upgraded t= o >> know >> >> > what to >> >> > do with the information. I do not see how that >> >> differentiates any of >> >> > the solutions. (Except "don't do anything", which I think = we >> >> do not >> >> > want >> >> > to take.) >> >> > >> >> > Yours, >> >> > Joel >> >> > >> >> > On 11/19/2020 5:03 PM, Gyan Mishra wrote: >> >> > > >> >> > > >> >> > > On Thu, Nov 19, 2020 at 10:33 AM > >> >> >> > = > >> >> > > > otroan@employees.org> >> >> >>> >> wrote: >> >> > > >> >> > > >> >> > > >> >> > > > On 19 Nov 2020, at 14:58, Gyan Mishra >> >> > >> >> > >> >> > > > >> >> >> > > >> >>> wrote: >> >> > > > >> >> > > > You would need a new option. It would likely be >> >> useful for the >> >> > > requesting router to indicate interest in the >> option. Even >> >> > hinting >> >> > > at what prefix size it was expecting. >> >> > > > Now can you explain to me again the reasons why >> this >> >> > approach is >> >> > > better than using the existing DHPCv6 protocol >> packets? >> >> > > > >> >> > > > 3GPP gateway does not support DHCPv6 >> >> > > >> >> > > 3GPP gateway doesn't support new option. What's you= r >> >> point? >> >> > > >> >> > > >> >> > > >> >> > > The point of the v6ops presentation and this email >> >> thread is >> >> > how to >> >> > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in= slide 1 of the >> >> deck you >> >> > compiled >> >> > > a list of options and of the two I had highlighted in r= ed >> >> were the >> >> > > 64share v2 Cameron=E2=80=99s option and the variable sl= aac >> >> option. So on >> >> > the >> >> > > call this morning Lorenzo shot down 64share v2 shorter >> prefix >> >> > option as >> >> > > even if the 3GPP architecture was updated to support >> longer >> >> > prefixes and >> >> > > even is the 3GPP gateway was able to send a shorter >> prefix >> >> with A >> >> > flag >> >> > > not set, all mobile devices per Lorenzo=E2=80=99s point= would be >> >> broken >> >> > as they >> >> > > would not accept the shorter let=E2=80=99s say /56 pref= ix to >> build the >> >> > slaac 128 >> >> > > bit address. So the bottom line is the 64share v2 won= =E2=80=99t >> work >> >> > unless we >> >> > > update RFC 4291 and remove the 64 bit boundary. >> >> > > >> >> > > So we are back to square uno - no viable solution >> >> > > >> >> > > So now we had thrown out the longer >64 due to race t= o >> >> bottom >> >> > worries >> >> > > which I and others believe is Fud and as described in >> >> slide 10 of >> >> > the >> >> > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. >> >> > > >> >> > > So a happy medium /80 fixed boundary I came up with tha= t >> I >> >> think >> >> > solves >> >> > > a lot of the issue and not just the 3GPP initial >> >> segmentation of >> >> > > downstream devices problem statement. >> >> > > >> >> > > Since we have to update RFC 4291 for 64share v2 to work >> >> anyways >> >> > to allow >> >> > > for shorter prefixes, why not instead create a new bott= om >> >> at /80 >> >> > giving >> >> > > 16 bits more of prefix length and shrinking the IID dow= n >> >> to 48 bits. >> >> > > Doing so you would not even have to update the 3GPP >> >> architecture >> >> > as I >> >> > > don=E2=80=99t know if that would fly or not. Also this= solves a >> >> few other >> >> > > problems at the same time. >> >> > > >> >> > > >> >> > > As I mentioned in the v6ops deck presented that vlsm 0 = to >> >> 128 is >> >> > > mainstream for operators for static addressing on route= r >> >> and switch >> >> > > infrastructure and dhcpv6 subnets longer prefixes for >> network >> >> > > infrastructure appliance clusters, NFV/VNF virtualizati= on >> >> and server >> >> > > farms. On host subnets where there is a chance of mix = of >> >> slaac >> >> > hosts >> >> > > with dhcpv6 devices the prefix length is stuck at /64. >> So on >> >> > these mix >> >> > > addressing host subnets we cannot do longer prefixes >> following >> >> > our ND >> >> > > cache hard limit mantra to prevent ND cache exhaustion >> >> issues as >> >> > > described in RFC 6164. >> >> > > >> >> > > So with the /80 new fixed boundary shifting prefix leng= th >> >> 16 bits >> >> > longer >> >> > > and shortening the IID by 16 bits gives resolved the 3G= PP >> >> issue >> >> > which >> >> > > 64share can work as is and subtending to downstream >> >> devices will now >> >> > > work as a /64 is now equivalent to a /48 with 64k /80s. >> Also >> >> > BCP-690 >> >> > > for broadband not all operators have adopted the shorte= r >> >> prefix >> >> > lengths >> >> > > /56 or /48 recommendations and now that=E2=80=99s not = an issue >> as the >> >> > /64 would >> >> > > now suffice. >> >> > > >> >> > > From an operators perspective that gain allows at leas= t >> >> for 3GPP >> >> > > massive growth and subtending with a single /64 allows >> the >> >> operators >> >> > > such as Verizon with massive subscriber base worldwide >> can >> >> stay with >> >> > > current allocations and don=E2=80=99t have to ask >> >> < >> https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+hav= e+to+ask?entry=3Dgmail&source=3Dg >> > >> >> for /10. >> >> > > >> >> > > As 5G gets rolled out with Enhanced VPN framework and >> Network >> >> > slicing >> >> > > paradigm, the demand for shorter blocks and wearable >> >> multiple /48 >> >> > will >> >> > > be our new reality. >> >> > > >> >> > > Making that 16 bit shift now to /80 making a /64 the ne= w >> >> /48 will >> >> > give >> >> > > broadband and 3GPP subscribers a ton of space to >> >> subtending their >> >> > > networks we would be set for the future. Especially wi= th >> >> IOT the >> >> > demand >> >> > > for subtending will continue to grow astronomically. >> >> > > >> >> > > Also IANA does not have to get start in allocating the >> >> other /3 and >> >> > > other available blocks. >> >> > > >> >> > > Lots of problems being solved here with a fixed /80 new >> >> boundary. >> >> > > >> >> > > Also with the existing random IID generation schemes >> which >> >> we have >> >> > > tested on Linux kernel can do longer p >> >> > >> >> < >> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+= p?entry=3Dgmail&source=3Dg >> < >> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+= p?entry=3Dgmail&source=3Dg >> >>refixes >> >> > using RFC 4941 privacy >> >> > > extension or RFC 7217 stable IID. >> >> > > >> >> > > Win-Win for all. >> >> > > >> >> > > Ole >> >> > > >> >> > > -- >> >> > > >> >> > > >> >> >> >> >> > > >> >> > > *Gyan Mishra* >> >> > > >> >> > > /Network Solutions A//rchitect / >> >> > > >> >> > > /M 301 502-1347 >> >> > > 13101 Columbia Pike >> >> >> >> >> >> >> > >> > >> /Silver Spring, MD >> >> >> > > >> >> > > >> >> > > >> >> > > _______________________________________________ >> >> > > v6ops mailing list >> >> > > v6ops@ietf.org >> >> > >> >> > > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> > > >> > >> >> > > >> >> > >> >> > -- >> >> > >> >> > > >> >> > >> >> > *Gyan Mishra* >> >> > >> >> > /Network Solutions A//rchitect / >> >> > >> >> > /M 301 502-1347 >> >> > 13101 Columbia Pike >> >> >> >> >> >> > >> /Silver Spring, MD >> >> >> > >> >> > >> >> >> >> -- >> >> >> >> >> >> >> >> *Gyan Mishra* >> >> >> >> /Network Solutions A//rchitect / >> >> >> >> /M 301 502-1347 >> >> 13101 Columbia Pike >> >> >> >> >> /Silver Spring, MD >> >> >> >> >> >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000c3ff4105b497d8c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 20, 2020 at 8:20 PM Mark Smith <markzzzsmith@gmail.com> wrote:


On Sat, 21 Nov 202= 0, 14:00 Brian E Carpenter, <brian.e.carpenter@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">Joel,

It seems to me that it's high time to draft a liaison statement to 3GPP= ,
observing that:

(1) There is a serious problem for the design and implementation of
5G-based IPv6 "hot spots" and CEs [which is where this conversati= on started];

I think it is also important to find out why they haven't d= eployed DHCPv6 to solve this=C2=A0problem.

Don't they think DHCPv6 infrastructure will scale? I= s it just that they don't know how to scale it?
=

Definitely do not know how. I had a look at the dhcpv6 rfc and it was ove= r 150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr. =C2=A0=C2=A0


Is it a vendor / mobile operator / h= andset developer DHCPv6 capability=C2=A0chicken-and-egg problem?

I believe that exists too.=C2=A0

=

Is there an overriding business or industry re= ason?

No. Just the usual nobody will come to the s= hop to pay for dhcpv6, =C2=A0so it is hard to
martia= l market demand. Major vendors (android) have vocally declined to support d= hcpv6. Other scenarios it is supported but default off.=C2=A0


The mobile industry has been res= istant to tethering over the years, and probably only came to begrudgingly = accept it because they couldn't prevent phone vendors from implementing= Wifi and NAT, and couldn't very effectively stop their customers from = using that capability (One trick I've heard of to prevent tethering wor= king was to check if an IPv4 packet's=C2=A0TTL value was 64 when it arr= ived at the network, meaning it originated from the directly attached hands= et. Packets from tethered devices had a TTL of 63 so were dropped. Of cours= e, you could set the default TTL on a tethered=C2=A0PC to 65 to get around = that.)

I guess there mig= ht be a fairly strong mindset that there must be a fee per device attached = to the network in addition to a fee for network utilisation. Providing mult= iple /64s would be formally acknowledging that multiple devices can be atta= ched and a fee per device isn't and can't ever be charged, counter = to the mindset.

I believe the sentiment on this li= st from operators has been trying to find ways to make more effective ways = to support more complete ipv6 networks with the machinery we have.=C2=A0 I = don=E2=80=99t think you have seen otherwise.=C2=A0
<= br>
My own view is that i am trying to connect 10+M = households, many rural, with 5G broadband... and i feel it would be neglige= nt to not support ipv6 in the most common home networking scenarios.=C2=A0<= /div>

That said, my thinking h= as evolved.=C2=A0 And, i appreciate the living and illuminating discussion.= =C2=A0 i don=E2=80=99t think i need standards work at =C2=A0this point. I = am i going to take a swing at making dhcpv6 work... not as specified in tha= t long rfc, but just taking the view of a dhcpv6-pd packet as an api, which= will simplify things.=C2=A0



Regards,
Mark.


(2) Although the best solution is not yet obvious, defining and
standardizing it will require a joint effort by the IETF and 3GPP.

Followed by a proposal to form an ad hoc joint design team.

Regards
=C2=A0 =C2=A0Brian Carpenter
On 21-Nov-20 14:46, Joel M. Halpern wrote:
> The nesting got me lost, so I will top post my take on the answer to t= he
> one quesiton I could understand.
>
> I believe you asked what I think would need to be changed to permit th= e
> delegation.
> As with anything, the real things that need to change are the devices = in
> the network.
>
> With regard to IETF standards, what is proposed is a change to RA. > There are several possible changes.=C2=A0 None of them require a chang= e to
> the IPv6 addressing archtiecture, as the addressing structure remains = as
> it is.
> As for the exact mechanism, at the moment I lean towards Ole's pro= posal
> of using a new option in his generic option mechanism.=C2=A0 But I am = not
> wedded to that answer.
>
> And of course, to get this supported in mobile environments we will ha= ve
> to work with 3GPP and make sure there are no other hidden issues.
> That's the way we do things.=C2=A0 Work together.
>
> Changing the prefix length to /80 is technically also possible.=C2=A0 = It does
> a lot more violence to my understanding of the architecture and softwa= re
> structures that go with it, and is a very limited and narrow solution = to
> the problem.
>
> Yours,
> Joel
>
> On 11/20/2020 7:58 PM, Gyan Mishra wrote:
>> Hi Joel
>>
>> In-line
>>
>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpe= rn.com
>> <mailto:jmh@joelhalpern.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan, separate from Ole's comments about th= e difference between address
>>=C2=A0 =C2=A0 =C2=A0assignment and delegation, I have another probl= em following the
>>=C2=A0 =C2=A0 =C2=A0reasoning below.
>>
>>=C2=A0 =C2=A0 =C2=A0Yes, the proposal for using shorter prefixes to= enable UE to perform
>>=C2=A0 =C2=A0 =C2=A0delegation will require changes to the UE.
>>
>>=C2=A0 =C2=A0 =C2=A0 Gyan> Agreed.=C2=A0 So that change would be= to RFC 4291 64 bit boundary
>> to allow for longer prefix.=C2=A0 Do you agree?
>>
>> If you don=E2=80=99t agree what do think the change would be to al= low the UE to
>> accept shorter prefix from the 3GPP gateway?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0But I do not see how that is relevant to any ch= oice we are trying to
>>=C2=A0 =C2=A0 =C2=A0make.
>>=C2=A0 =C2=A0 =C2=A0Any solution that enables UE to delegate addres= ses (in the sense that
>>=C2=A0 =C2=A0 =C2=A0they lack the capability now) willr equire chan= ges to the UE.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> If the UE receives a /56 via RA it cou= ld delegate /64 to
>>=C2=A0 =C2=A0 =C2=A0downstream devices.=C2=A0 No change needed to d= elegate =C2=A0/64, however a
>>=C2=A0 =C2=A0 =C2=A0change is needed to accept /56 via RA.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 If 3GPP gateway supported PD - problem solved = but that=E2=80=99s not the
>> case and that does not sound like it will ever change even with 5G= .
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> The UE needs to be able to accept shor= ter prefix.=C2=A0 That=E2=80=99s the
>> IPV6 specification change that requires removal of the 64 bit boun= dary.
>>
>>=C2=A0 =C2=A0 =C2=A0Yoru
>>=C2=A0 =C2=A0 =C2=A0proposed change to the SLAAC length if anything= does more violence to
>>=C2=A0 =C2=A0 =C2=A0the software (depending upon the exact software= architecture.)
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> What violence to software.=C2=A0 There= would be more violence to
>> software if we removed the 64 bit boundary and allowed slaac to su= pport
>> any vlsm prefix lengths.
>>
>> My /80 proposal would just shift the boundary 16 bits to /80.
>>
>> Hosts on the same subnet with two different masks would not be on-= net to
>> each other as on different subnets.=C2=A0 The router would be conf= igured with
>> the two subnets /64 and /80 subnet to support the two device types= .
>> The solution would be a simple RA PIO flag that is set and older h= osts
>> not upgraded would be backwards compatible and so would only suppo= rt 64
>> bit boundary by ignoring flag. Hosts upgraded to support would >> understand the flag and be able to support longer mask up to /80.<= br> >>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0So I do not follow how you got to your conclusi= on.
>>
>>=C2=A0 =C2=A0 =C2=A0Yours,
>>=C2=A0 =C2=A0 =C2=A0Joel
>>
>>=C2=A0 =C2=A0 =C2=A0On 11/20/2020 5:27 PM, Gyan Mishra wrote:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > (top posting)
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As I would like to clear the air as well = as get to the crux of
>>=C2=A0 =C2=A0 =C2=A0the v6ops
>>=C2=A0 =C2=A0 =C2=A0 > presentation development results as well = as next steps for this
>>=C2=A0 =C2=A0 =C2=A0draft
>>=C2=A0 =C2=A0 =C2=A0 > and the 6man variable slaac solutions dra= ft:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This thread was in light of Lorenzo kindl= y pointing out that
>>=C2=A0 =C2=A0 =C2=A0upgrading
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP is not all that needs be done for Ca= meron=E2=80=99s 64share v2 to
>>=C2=A0 =C2=A0 =C2=A0work - as
>>=C2=A0 =C2=A0 =C2=A0 > all mobile devices would stop working- as= slaac would not would be
>>=C2=A0 =C2=A0 =C2=A0 > effectively broken.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The mobile device would receive a shorter= prefix let=E2=80=99s say /56
>>=C2=A0 =C2=A0 =C2=A0but not
>>=C2=A0 =C2=A0 =C2=A0 > know what to do with it since it=E2=80=99= s expecting a /64.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So that a major gap and the only solution= is updating RFC 4291
>>=C2=A0 =C2=A0 =C2=A0removing
>>=C2=A0 =C2=A0 =C2=A0 > the 64 bit boundary allowing for shorter = prefix and now as well
>>=C2=A0 =C2=A0 =C2=A0longer
>>=C2=A0 =C2=A0 =C2=A0 > prefixes to work and in that respect now = provide the much needed
>>=C2=A0 =C2=A0 =C2=A0parity
>>=C2=A0 =C2=A0 =C2=A0 > with static and DHCPv6 which can do any p= refix length.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So that is a drastic change to RFC 4291.= =C2=A0 However, in light of this
>>=C2=A0 =C2=A0 =C2=A0 > development on the v6ops 109 call, my bal= ancing act of best of both
>>=C2=A0 =C2=A0 =C2=A0 > worlds and also to keep everyone happy to= make this a WG effort
>>=C2=A0 =C2=A0 =C2=A0for this
>>=C2=A0 =C2=A0 =C2=A0 > change by proposing in the subject headin= g /80 fixed boundary and
>>=C2=A0 =C2=A0 =C2=A0not a
>>=C2=A0 =C2=A0 =C2=A0 > variable slaac change allowing all bits v= lsm.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Basically stealing 16 bits for network pr= efix out of the IID, still
>>=C2=A0 =C2=A0 =C2=A0 > keeping the fixed boundary so longer than= 80 would NOT =C2=A0be allowed.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > A /64 would now be equivalent to a /48 wi= th now 64k /80=E2=80=99s.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This /80 would keep the operators and law= enforcement happy as
>>=C2=A0 =C2=A0 =C2=A0now 16
>>=C2=A0 =C2=A0 =C2=A0 > bits less helps traceability but is still= long enough for 48 bits of
>>=C2=A0 =C2=A0 =C2=A0 > privacy to IP correlation by attackers. >>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This /80 would be a nice optimal balance = as it would keep wired
>>=C2=A0 =C2=A0 =C2=A0 > broadband and mobile handset customers ha= ppy respecting their
>>=C2=A0 =C2=A0 =C2=A0privacy as
>>=C2=A0 =C2=A0 =C2=A0 > the 16 bits less of heuristics is minimal= change that will impact IP
>>=C2=A0 =C2=A0 =C2=A0 > correlation by attackers.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The IID as it=E2=80=99s less than the cur= rent 64 bit cannot use MAC based
>>=C2=A0 =C2=A0 =C2=A0EUI64
>>=C2=A0 =C2=A0 =C2=A0 > IID, which is not a problem as Mac based = IID is not recommended
>>=C2=A0 =C2=A0 =C2=A0as most
>>=C2=A0 =C2=A0 =C2=A0 > all manufacturers use RFC 4941 and I beli= eve Linux flavors some use
>>=C2=A0 =C2=A0 =C2=A0 > stable IID RFC 7217.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So now the 48 bit IID would require a ran= dom IID generation
>>=C2=A0 =C2=A0 =C2=A0schema so
>>=C2=A0 =C2=A0 =C2=A0 > can use either RFC 4941 privacy extension= or RFC 7217 stable IID to
>>=C2=A0 =C2=A0 =C2=A0 > generate the 48 bit IID.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP subtending would now work issue ment= ioned in the problem
>>=C2=A0 =C2=A0 =C2=A0statement
>>=C2=A0 =C2=A0 =C2=A0 > draft without even having to use 64share = as now longer prefixes
>>=C2=A0 =C2=A0 =C2=A0up to
>>=C2=A0 =C2=A0 =C2=A0 > /80 would be supported allowing for furth= er segmentation of
>>=C2=A0 =C2=A0 =C2=A0downstream
>>=C2=A0 =C2=A0 =C2=A0 > devices.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This also would help wired broadband and = soon fixed 5G broadband
>>=C2=A0 =C2=A0 =C2=A0 > proliferation where operators in light of= BCP RIPE-690, are sill
>>=C2=A0 =C2=A0 =C2=A0 > allocation via BNG gateways a /64, now op= erators =C2=A0can stay as-is,
>>=C2=A0 =C2=A0 =C2=A0as the
>>=C2=A0 =C2=A0 =C2=A0 > /64 would now be allowed to be further se= gmented supporting 64k
>>=C2=A0 =C2=A0 =C2=A0/80s,
>>=C2=A0 =C2=A0 =C2=A0 > way more then enough for SOHO.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This would allow 64share if used by 3GPP = operators to work and
>>=C2=A0 =C2=A0 =C2=A0would not
>>=C2=A0 =C2=A0 =C2=A0 > require the 3GPP specification to be upda= ted.=C2=A0 We don=E2=80=99t know even
>>=C2=A0 =C2=A0 =C2=A0if the
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP architecture specification can be up= dated to support shorter
>>=C2=A0 =C2=A0 =C2=A0 > prefixes and if the 3GPP consortium of op= erators would agree to
>>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 So
>>=C2=A0 =C2=A0 =C2=A0 > that is all theoretical of that change is= possible.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As with 5G with Enhanced VPN framework SR= steering of high priority
>>=C2=A0 =C2=A0 =C2=A0 > traffic, traffic isolation and Network sl= icing capabilities becomes
>>=C2=A0 =C2=A0 =C2=A0 > mainstream and will soon be a real world = reality and as fixed 5G
>>=C2=A0 =C2=A0 =C2=A0 > broadband proliferation takes off and mob= ile 5G =3D=3D the idea of a
>>=C2=A0 =C2=A0 =C2=A0 > wearable /48 will really be many /48s. >>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As this paradigm shift takes place, opera= tors around the world
>>=C2=A0 =C2=A0 =C2=A0will be
>>=C2=A0 =C2=A0 =C2=A0 > clamoring after the RIR for massive block= s, I would say less than /8
>>=C2=A0 =C2=A0 =C2=A0 > more like a /5 or /4.=C2=A0 If you do the= math on the way high side a /10
>>=C2=A0 =C2=A0 =C2=A0 > yields 7 bits so 128 divided by 5 RIRs yi= elds 24 ISPs per RIR
>>=C2=A0 =C2=A0 =C2=A0which is
>>=C2=A0 =C2=A0 =C2=A0 > tiny number with the number of large size= operators worldwide.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > With the massive proliferation of IOT dev= ices and just about
>>=C2=A0 =C2=A0 =C2=A0every home
>>=C2=A0 =C2=A0 =C2=A0 > or office appliance on 5G, the problem no= w gets way exacerbated.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As this evolution unfolds IANA will be sc= rambling to release all
>>=C2=A0 =C2=A0 =C2=A0 > remaining /3 as well as all unallocated b= locks to subvert RIR IPv6
>>=C2=A0 =C2=A0 =C2=A0 > address space depletion.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Playing Monday night quarterbacking in hi= ndsight we would never
>>=C2=A0 =C2=A0 =C2=A0think
>>=C2=A0 =C2=A0 =C2=A0 > this would happen in a million years, but= we would see IPv6 on
>>=C2=A0 =C2=A0 =C2=A0the verge
>>=C2=A0 =C2=A0 =C2=A0 > of address space depletion.=C2=A0 Unheard= of but it can happen as the
>>=C2=A0 =C2=A0 =C2=A0saying
>>=C2=A0 =C2=A0 =C2=A0 > goes =E2=80=9Cwhen you build - they will = come=E2=80=9D.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > It is true as history has taught that ver= y important lesson.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The answer to this real world problem is = in the subject heading
>>=C2=A0 =C2=A0 =C2=A0of this
>>=C2=A0 =C2=A0 =C2=A0 > thread.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This would also fix the day 1 issue I men= tioned allowing mix of
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 > devices with static and DHCPv6 up to /80.=
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The variable slaac solution draft propose= s a new =C2=A0RA PIO flag
>>=C2=A0 =C2=A0 =C2=A0that would
>>=C2=A0 =C2=A0 =C2=A0 > be used to signal longer prefixes, and wo= uld provide backwards
>>=C2=A0 =C2=A0 =C2=A0 > compatibility so that devices not support= ing woud ignore the flag
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0and
>>=C2=A0 =C2=A0 =C2=A0 > devices on newer code supporting would us= e the flag.=C2=A0 We definitely
>>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t want to impact any existing= devices on the existing 64 bit
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 > boundary standard.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Dmytro has tested the solution on Linux k= ernel signaling RA PIO
>>=C2=A0 =C2=A0 =C2=A0flag and
>>=C2=A0 =C2=A0 =C2=A0 > was able to successfully test any length = mask and random IID
>>=C2=A0 =C2=A0 =C2=A0generation
>>=C2=A0 =C2=A0 =C2=A0 > both RFC 4941 privacy extension as well a= s stable IID RFC 7217.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/=
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/= >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/=
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/= >>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > If everyone is in agreement with what I h= ave stated on this
>>=C2=A0 =C2=A0 =C2=A0thread, I
>>=C2=A0 =C2=A0 =C2=A0 > would like to ask the chairs for WG adopt= ion as this is a WG effort.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > I would like to garner support from all 6= MAN members with full
>>=C2=A0 =C2=A0 =C2=A0consensus
>>=C2=A0 =C2=A0 =C2=A0 > to change the existing RFC 4941 /64 fixed= boundary to /80 fixed
>>=C2=A0 =C2=A0 =C2=A0boundary.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Kind Regards
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Gyan
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 5:14 PM Joel M. H= alpern
>>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@j= oelhalpern.com>
>>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com <m= ailto:jmh@joelhalpern.com>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am missing something= in your reasoning.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0You seem to say at one= point that (to paraphrase) "we can't
>>=C2=A0 =C2=A0 =C2=A0do this
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0because it does not wo= rk with the existing UE software".
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Any new solution where= a UE delegates based on any change of
>>=C2=A0 =C2=A0 =C2=A0any kind
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(including lengthening= the prefix, shortening the prefix, or
>>=C2=A0 =C2=A0 =C2=A0magically
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0incanting new prefixes= ) requires that the UE be upgraded to know
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0what to
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0do with the informatio= n.=C2=A0 I do not see how that
>>=C2=A0 =C2=A0 =C2=A0differentiates any of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the solutions. (Except= "don't do anything", which I think we
>>=C2=A0 =C2=A0 =C2=A0do not
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0want
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to take.)
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yours,
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Joel
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM,= Gyan Mishra wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, = 2020 at 10:33 AM <otroan@employees.org
>>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:otroan@em= ployees.org <mailto:otroan@employees.org>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:otr= oan@employees.org <mailto:otroan@employees.org>
>>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailt= o:otroan@employees.org>>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > On 19 Nov 2020, at 14:58, Gyan Mishra
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<hayabusagsm@gma= il.com <mailto:hayabusagsm@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mai= lto:hayabusagsm@gmail.com>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:hayabusagsm@gmail.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusa= gsm@gmail.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>= >> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > You would need a new option. It would likely be
>>=C2=A0 =C2=A0 =C2=A0useful for the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0requesting router to indicate interest in the option. Even
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hinting
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0at what prefix size it was expecting.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Now can you explain to me again the reasons why this
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0approach is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0better than using the existing DHPCv6 protocol packets?
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A03GPP gateway doesn't support new option. What's your
>>=C2=A0 =C2=A0 =C2=A0point?
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 The point of the v6ops presentation and this email
>>=C2=A0 =C2=A0 =C2=A0thread is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0how to
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend = a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 of the
>>=C2=A0 =C2=A0 =C2=A0deck you
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0compiled
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a list of option= s and of the two I had highlighted in red
>>=C2=A0 =C2=A0 =C2=A0were the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share v2 Camer= on=E2=80=99s option and the variable slaac
>>=C2=A0 =C2=A0 =C2=A0option.=C2=A0 So on
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > call this mornin= g Lorenzo shot down 64share v2 shorter prefix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0option as
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even if the 3GPP= architecture was updated to support longer
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0prefixes and
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even is the 3GPP= gateway was able to send a shorter prefix
>>=C2=A0 =C2=A0 =C2=A0with A
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0flag
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > not set, all mob= ile devices per Lorenzo=E2=80=99s point would be
>>=C2=A0 =C2=A0 =C2=A0broken
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as they
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > would not accept= the shorter let=E2=80=99s say /56 prefix to build the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slaac 128
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > bit address.=C2= =A0 So the bottom line is the 64share v2 won=E2=80=99t work
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0unless we
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > update RFC 4291 = and remove the 64 bit boundary.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So w= e are back to square uno - no viable solution
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So n= ow we had thrown out the longer >64 due to race to
>>=C2=A0 =C2=A0 =C2=A0bottom
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0worries
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > which I and othe= rs believe is Fud and as described in
>>=C2=A0 =C2=A0 =C2=A0slide 10 of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Cr= ace to the bottom slide=E2=80=9D.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So a happy mediu= m /80 fixed boundary I came up with that I
>>=C2=A0 =C2=A0 =C2=A0think
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0solves
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a lot of the iss= ue and not just the 3GPP initial
>>=C2=A0 =C2=A0 =C2=A0segmentation of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > downstream devic= es problem statement.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Since we have to= update RFC 4291 for 64share v2 to work
>>=C2=A0 =C2=A0 =C2=A0anyways
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to allow
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for shorter pref= ixes, why not instead create a new bottom
>>=C2=A0 =C2=A0 =C2=A0at /80
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0giving
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 16 bits more of = prefix length and shrinking the IID down
>>=C2=A0 =C2=A0 =C2=A0to 48 bits.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Doing so you wou= ld not even have to update the 3GPP
>>=C2=A0 =C2=A0 =C2=A0architecture
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as I
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t kn= ow if that would fly or not.=C2=A0 Also this solves a
>>=C2=A0 =C2=A0 =C2=A0few other
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > problems at the = same time.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As I mentioned i= n the v6ops deck presented that vlsm 0 to
>>=C2=A0 =C2=A0 =C2=A0128 is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mainstream for o= perators for static addressing on router
>>=C2=A0 =C2=A0 =C2=A0and switch
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure a= nd dhcpv6 subnets longer prefixes for network
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure a= ppliance clusters, NFV/VNF virtualization
>>=C2=A0 =C2=A0 =C2=A0and server
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On = host subnets where there is a chance of mix of
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hosts
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2= =A0devices the prefix length is stuck at /64.=C2=A0 So on
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0these mix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > addressing host = subnets we cannot do longer prefixes following
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0our ND
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > cache hard limit= mantra to prevent ND cache exhaustion
>>=C2=A0 =C2=A0 =C2=A0issues as
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > described in RFC= 6164.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So with the /80 = new fixed boundary shifting prefix length
>>=C2=A0 =C2=A0 =C2=A016 bits
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0longer
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and shortening t= he IID by 16 bits gives resolved the 3GPP
>>=C2=A0 =C2=A0 =C2=A0issue
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0which
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share can work= as is and subtending to downstream
>>=C2=A0 =C2=A0 =C2=A0devices will now
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > work as a /64 is= now equivalent to a /48 with 64k /80s.=C2=A0 Also
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0BCP-690
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for broadband no= t all operators have adopted the shorter
>>=C2=A0 =C2=A0 =C2=A0prefix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0lengths
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /56 or /48 recom= mendations =C2=A0and now that=E2=80=99s not an issue as the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0/64 would
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > now suffice.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an op= erators perspective that gain allows at least
>>=C2=A0 =C2=A0 =C2=A0for 3GPP
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > massive growth a= nd subtending with a single /64 allows the
>>=C2=A0 =C2=A0 =C2=A0operators
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > such as Verizon = with massive subscriber base worldwide can
>>=C2=A0 =C2=A0 =C2=A0stay with
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > current allocati= ons and don=E2=80=99t have to ask
>>=C2=A0 =C2=A0 =C2=A0<https://www.google.co= m/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=3Dgmail&a= mp;source=3Dg>
>>=C2=A0 =C2=A0 =C2=A0for /10.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As 5G gets rolle= d out with Enhanced VPN framework and Network
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slicing
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > paradigm, the de= mand for shorter blocks and wearable
>>=C2=A0 =C2=A0 =C2=A0multiple /48
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0will
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > be our new reali= ty.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Making that 16 b= it shift now to /80 making a /64 the new
>>=C2=A0 =C2=A0 =C2=A0/48 will
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0give
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > broadband and 3G= PP subscribers a ton of space to
>>=C2=A0 =C2=A0 =C2=A0subtending their
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > networks we woul= d be set for the future.=C2=A0 Especially with
>>=C2=A0 =C2=A0 =C2=A0IOT the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0demand
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for subtending w= ill continue to grow astronomically.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also IANA does n= ot have to get start in allocating the
>>=C2=A0 =C2=A0 =C2=A0other /3 and
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > other available = blocks.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Lots of problems= being solved here with a fixed /80 new
>>=C2=A0 =C2=A0 =C2=A0boundary.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also with the ex= isting random IID generation schemes which
>>=C2=A0 =C2=A0 =C2=A0we have
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > tested on Linux = kernel can do longer p
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.co= m/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&sour= ce=3Dg <https://www.google.com/maps/search/tested+on+Li= nux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg>>refixes<= br> >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy=
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > extension or RFC= 7217 stable IID.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Win-Win for all.=
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Ole
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > --
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <htt= p://www.verizon.com/ <http://www.verizon.com/>
>>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.com/>>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra* >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Network Solutio= ns A//rchitect /
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347<= br> >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > ________________= _______________________________
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops mailing li= st
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org &= lt;mailto:v6ops@ietf.org>
>>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org= >>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/v6ops
>>=C2=A0 =C2=A0 =C2=A0<https://www.ie= tf.org/mailman/listinfo/v6ops>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/v6ops
>>=C2=A0 =C2=A0 =C2=A0<https://www.ie= tf.org/mailman/listinfo/v6ops>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > --
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ = <http://www.verizon.com/>>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect /
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> /Network Solutions A//rchitect /
>>
>> /M 301 502-1347
>> 13101 Columbia Pi= ke
>> /Silver Sprin= g, MD
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6o= ps
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000c3ff4105b497d8c7-- From nobody Sat Nov 21 00:50:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241433A0D1E for ; Sat, 21 Nov 2020 00:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNy2Sb4yQcEL for ; Sat, 21 Nov 2020 00:50:23 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 3F4823A0D09 for ; Sat, 21 Nov 2020 00:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1605948624; x=1637484624; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=/z9CbRAx+7PJwIW0uPXppRMafGSh6xyaB47OE4POsE0=; b=MiX6olANXutDKEdlZiQyXKiZyb+wDOKQMqkH3xM+TYL944WKqgq2NdKN 87smcUJXbS/PdSIPA9q7fL3xZiMMAhAeJMiznA7KngiONmyAmfrBOLVCF /e5sPOOuRwRfIGHnbiSZJP4g52JHfI1BQb9z0kZfoxNz0zdForEYHvIBh 4wa7Rxrrvc41idtjHiCVnPtRL8aUbzGjgwZiL3aupQD023da+YE60yFFB Qh+y1Ozr45r6h2LYNxx8bP6tI6dgWIG/mgsSG8U6diimPxG+pkmGII2s7 6htutwxhQ3vrZGte6SfnGtIblDHLzB9psuJwMMVFOFzJXlc/hy1UGT9Lu g==; IronPort-SDR: Kz889PQGxxIyUMmMQk7KegatrPNE9PNRBhEaA17Drd0vm2pbB6KXo7FDgnX5qh2xYNAhjU96dy bIK9/SpQ+gj7Ixkx9vVcmq5+0mh6bZdsfVwiAPdd+pLfzYyIsRaOFSrmtD1YE3LcA6Fsnxs48E 12zR/wPGT5HLZh+TwbDSks5sarH8i9ad1rVRTmZmYyuVDYLIMaDKi8lGUTO7BOowukGeQ7Qy1S nWNqZ7AX8c1D5+b4PhQFmuXzc5FhlQlG1pkkjlY9BSgJVqe5xZt2YPQXARUB5hc04sqp2K2brN eTY= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Nov 2020 09:50:20 +0100 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 97077427F6 for ; Sat, 21 Nov 2020 09:50:17 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 717B741D19; Sat, 21 Nov 2020 09:50:17 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 651FBA27B; Sat, 21 Nov 2020 09:50:17 +0100 (CET) Date: Sat, 21 Nov 2020 09:50:17 +0100 From: Gert Doering To: Gyan Mishra Cc: Ole Troan , IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ Message-ID: <20201121085017.GY13005@Space.Net> References: <7E87C304-802E-4B2F-9DDB-687C91C29E21@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 08:50:25 -0000 Hi, On Fri, Nov 20, 2020 at 07:36:23PM -0500, Gyan Mishra wrote: > 3GPP Gateway does not support PD I challenged that statement before, but that mail was ignored. It's not there because it is impossible to do, but because vendors and operators had no interest in making it happen. >From RFC 7066: "Starting from Release-10, DHCPv6 Prefix Delegation was added as an optional feature to the 3GPP system architecture" So - a standard compliant 3GPP Gateway could easily support DHCPv6 PD. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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 Sat Nov 21 01:43:13 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8F43A0DC8; Sat, 21 Nov 2020 01:43:12 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NwuyoDmtDWxj; Sat, 21 Nov 2020 01:43:10 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8F13A0DC1; Sat, 21 Nov 2020 01:43:08 -0800 (PST) Received: from [192.168.10.178] (dhcp21719716422.blix.com [217.197.164.22]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 75F7D4E11AED; Sat, 21 Nov 2020 09:43:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Sat, 21 Nov 2020 10:43:03 +0100 Message-Id: References: Cc: Mark Smith , IPv6 Operations , 6MAN <6man@ietf.org> In-Reply-To: To: Ca By X-Mailer: iPhone Mail (18B92) Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 09:43:12 -0000 > On 21 Nov 2020, at 07:13, Ca By wrote: >=20 > That said, my thinking has evolved. And, i appreciate the living and illu= minating discussion. i don=E2=80=99t think i need standards work at this p= oint. I am i going to take a swing at making dhcpv6 work... not as specified= in that long rfc, but just taking the view of a dhcpv6-pd packet as an api,= which will simplify things.=20 Exactly. It=E2=80=99s just a simple two packet exchange. You don=E2=80=99t n= eed much of the machinery. You do need some sort of database. But you got th= at.=20 Cheers=20 Ole= From nobody Sat Nov 21 03:24:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7450B3A0E3C; Sat, 21 Nov 2020 03:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTbVto8xPCRS; Sat, 21 Nov 2020 03:24:32 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9AD3A0F22; Sat, 21 Nov 2020 03:24:30 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id f16so11322010otl.11; Sat, 21 Nov 2020 03:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vAVOdk7Oym/IQkAf71q4CBMvkolGUeQWLIXKyZA347U=; b=rB2+iSNibyDjC1huFdOC3+Umj9hdVf8L7CES3Ah/FPfZI/UBFKGCBSLZ2nA9lTjPzs tBK6UG2QZiqZMHKElDlEeXn/Uk1Ls0Oh/6nIvE3HFFNdHwAhP/jADD7DZY8BiQyuKVTt umxi445hj1Y/KIyX0M63bdNGT9oBrTzkYY4fEy+FmCUyjUWdLJgVJGsYNqBXRfiRlHhM hEU68uac+PeWISATwdLMz4+avrIhByMnwfrZVWTVkQAYjIsaeLEkFyyYxpg4L6/NzMRM ixECK3aLhPntCrh2QQM5R4Ca0J6jVfyLo/X+WFltfZC9QvLEN9cjyQVTu3l+fZ+pp/Lk FkkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vAVOdk7Oym/IQkAf71q4CBMvkolGUeQWLIXKyZA347U=; b=YcmvvT+sg7jYR2SQCiz1cyGQu/BLWUXIgwtQCU6eVdiM61B1qSUVpjVdXubO9CIvsB XtIgdsaPD7fbGpiDPnuYIg0jyYLErRYLZSqjxRHYXbnwWNWiTVYD3OMPgNyeupwK6+Nw beatnmhTpBLUDadoijNhenClPAtR+rOU9+AjWQvMe0FOcCHlVp7IAxuqqubL1QMoQbmU wsfDnlBLaMBFsEzQC+CB/+CH7/izZXSiW9m94Pi2+8nWQCG67o2bC5gJho2sZhiJqUny rQzXJk9+SoqsDv/LyHtQ5w7ITS4w4LJZ59u7GpyrKhxTDpAaXYiYPAqNDPULEqLV1tXZ 3ATA== X-Gm-Message-State: AOAM531wfm5Grt5g2vMl1dg9xTxm8WQxgL+ta/Tcrp+oF9A7S9NJVc9I N1o3ht3l57zyNKL6/KfJAZQwvufCXFxmD5ShMJI= X-Google-Smtp-Source: ABdhPJw+zXFxo+3UHmQpk+XUqkaLUj51zy22LhWuUCroNBnPIzh0ZQDHeXb/nH8wsm2E+42lzPkRe/fg7KZbrCs2ZDM= X-Received: by 2002:a9d:a0d:: with SMTP id 13mr15767136otg.348.1605957869839; Sat, 21 Nov 2020 03:24:29 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> In-Reply-To: From: Mark Smith Date: Sat, 21 Nov 2020 22:24:17 +1100 Message-ID: To: Ca By Cc: 6MAN <6man@ietf.org>, Brian E Carpenter , IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000005b29e305b49c3467" Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 11:24:37 -0000 --0000000000005b29e305b49c3467 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 21 Nov 2020, 17:12 Ca By, wrote: > > > On Fri, Nov 20, 2020 at 8:20 PM Mark Smith wrote= : > >> >> >> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, < >> brian.e.carpenter@gmail.com> wrote: >> >>> Joel, >>> >>> It seems to me that it's high time to draft a liaison statement to 3GPP= , >>> observing that: >>> >>> (1) There is a serious problem for the design and implementation of >>> 5G-based IPv6 "hot spots" and CEs [which is where this conversation >>> started]; >>> >> >> I think it is also important to find out why they haven't deployed DHCPv= 6 >> to solve this problem. >> >> Don't they think DHCPv6 infrastructure will scale? Is it just that they >> don't know how to scale it? >> > > Definitely do not know how. I had a look at the dhcpv6 rfc and it was ove= r > 150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr. > It is long. A lot of that is really about maintaining state synchronisation between the client and the server, and that is for address state synchronisation and dynamic allocation. > >> Is it a vendor / mobile operator / handset developer DHCPv6 >> capability chicken-and-egg problem? >> > > I believe that exists too. > > >> Is there an overriding business or industry reason? >> > > No. Just the usual nobody will come to the shop to pay for dhcpv6, so it > is hard to > martial market demand. Major vendors (android) have vocally declined to > support dhcpv6. > Specifically PD? The objection to DHCPv6 support I've seen has been about not supporting DHCPv6 for address assignment to the host itself. PD is really router rather than host configuration. I sometimes wonder what a "routing protocol" solution to PD would have looked like. For example, perhaps OSPF or BGP extensions to support delegating prefixes to downstream routers. I think right now it is better to stay with using DHCPv6 PD because it exists and has been successfully deployed. However I think the idea of using RAs for PD would heading down that "routing protocol" solution path to an extent. Other scenarios it is supported but default off. > > >> The mobile industry has been resistant to tethering over the years, and >> probably only came to begrudgingly accept it because they couldn't preve= nt >> phone vendors from implementing Wifi and NAT, and couldn't very effectiv= ely >> stop their customers from using that capability (One trick I've heard of= to >> prevent tethering working was to check if an IPv4 packet's TTL value was= 64 >> when it arrived at the network, meaning it originated from the directly >> attached handset. Packets from tethered devices had a TTL of 63 so were >> dropped. Of course, you could set the default TTL on a tethered PC to 65= to >> get around that.) >> >> I guess there might be a fairly strong mindset that there must be a fee >> per device attached to the network in addition to a fee for network >> utilisation. Providing multiple /64s would be formally acknowledging tha= t >> multiple devices can be attached and a fee per device isn't and can't ev= er >> be charged, counter to the mindset. >> > > I believe the sentiment on this list from operators has been trying to > find ways to make more effective ways to support more complete ipv6 > networks with the machinery we have. I don=E2=80=99t think you have seen > otherwise. > > My own view is that i am trying to connect 10+M households, many rural, > with 5G broadband... and i feel it would be negligent to not support ipv6 > in the most common home networking scenarios. > > That said, my thinking has evolved. And, i appreciate the living and > illuminating discussion. i don=E2=80=99t think i need standards work at= this > point. I am i going to take a swing at making dhcpv6 work... not as > specified in that long rfc, but just taking the view of a dhcpv6-pd packe= t > as an api, which will simplify things. > The production wired residential deployment I worked in back in 2010 had a DHCPv6 server on the BNG, not a relay, however that was fed subscriber attributes via RADIUS. These days they would be RFC6911 RADIUS attributes rather than vendor specific ones. So the DHCPv6 server infrastructure scaling problem upsteam of the BNG gets replaced by a RADIUS scaling one, which people may be more familiar with solving and already have solved. > This has been a helpful read > https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-0= 3 > > I think some or all of these problems might go away with the above DHCPv6 server/RADIUS model, because there is a lot more DHCPv6 session state available on the first hop device. Regards, Mark. > >> Regards, >> Mark. >> >> >>> (2) Although the best solution is not yet obvious, defining and >>> standardizing it will require a joint effort by the IETF and 3GPP. >>> >>> Followed by a proposal to form an ad hoc joint design team. >>> >>> Regards >>> Brian Carpenter >>> On 21-Nov-20 14:46, Joel M. Halpern wrote: >>> > The nesting got me lost, so I will top post my take on the answer to >>> the >>> > one quesiton I could understand. >>> > >>> > I believe you asked what I think would need to be changed to permit >>> the >>> > delegation. >>> > As with anything, the real things that need to change are the devices >>> in >>> > the network. >>> > >>> > With regard to IETF standards, what is proposed is a change to RA. >>> > There are several possible changes. None of them require a change to >>> > the IPv6 addressing archtiecture, as the addressing structure remains >>> as >>> > it is. >>> > As for the exact mechanism, at the moment I lean towards Ole's >>> proposal >>> > of using a new option in his generic option mechanism. But I am not >>> > wedded to that answer. >>> > >>> > And of course, to get this supported in mobile environments we will >>> have >>> > to work with 3GPP and make sure there are no other hidden issues. >>> > That's the way we do things. Work together. >>> > >>> > Changing the prefix length to /80 is technically also possible. It >>> does >>> > a lot more violence to my understanding of the architecture and >>> software >>> > structures that go with it, and is a very limited and narrow solution >>> to >>> > the problem. >>> > >>> > Yours, >>> > Joel >>> > >>> > On 11/20/2020 7:58 PM, Gyan Mishra wrote: >>> >> Hi Joel >>> >> >>> >> In-line >>> >> >>> >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern >> >> > wrote: >>> >> >>> >> Gyan, separate from Ole's comments about the difference between >>> address >>> >> assignment and delegation, I have another problem following the >>> >> reasoning below. >>> >> >>> >> Yes, the proposal for using shorter prefixes to enable UE to >>> perform >>> >> delegation will require changes to the UE. >>> >> >>> >> Gyan> Agreed. So that change would be to RFC 4291 64 bit >>> boundary >>> >> to allow for longer prefix. Do you agree? >>> >> >>> >> If you don=E2=80=99t agree what do think the change would be to allo= w the UE >>> to >>> >> accept shorter prefix from the 3GPP gateway? >>> >> >>> >> >>> >> But I do not see how that is relevant to any choice we are tryin= g >>> to >>> >> make. >>> >> Any solution that enables UE to delegate addresses (in the sense >>> that >>> >> they lack the capability now) willr equire changes to the UE. >>> >> >>> >> >>> >> >>> >> Gyan> If the UE receives a /56 via RA it could delegate /64 to >>> >> downstream devices. No change needed to delegate /64, however = a >>> >> change is needed to accept /56 via RA. >>> >> >>> >> >>> >> If 3GPP gateway supported PD - problem solved but that=E2=80=99= s not the >>> >> case and that does not sound like it will ever change even with 5G. >>> >> >>> >> Gyan> The UE needs to be able to accept shorter prefix. That=E2= =80=99s >>> the >>> >> IPV6 specification change that requires removal of the 64 bit >>> boundary. >>> >> >>> >> Yoru >>> >> proposed change to the SLAAC length if anything does more >>> violence to >>> >> the software (depending upon the exact software architecture.) >>> >> >>> >> >>> >> Gyan> What violence to software. There would be more violence t= o >>> >> software if we removed the 64 bit boundary and allowed slaac to >>> support >>> >> any vlsm prefix lengths. >>> >> >>> >> My /80 proposal would just shift the boundary 16 bits to /80. >>> >> >>> >> Hosts on the same subnet with two different masks would not be on-ne= t >>> to >>> >> each other as on different subnets. The router would be configured >>> with >>> >> the two subnets /64 and /80 subnet to support the two device types. >>> >> The solution would be a simple RA PIO flag that is set and older >>> hosts >>> >> not upgraded would be backwards compatible and so would only support >>> 64 >>> >> bit boundary by ignoring flag. Hosts upgraded to support would >>> >> understand the flag and be able to support longer mask up to /80. >>> >> >>> >> >>> >> >>> >> So I do not follow how you got to your conclusion. >>> >> >>> >> Yours, >>> >> Joel >>> >> >>> >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >>> >> > >>> >> > (top posting) >>> >> > >>> >> > As I would like to clear the air as well as get to the crux o= f >>> >> the v6ops >>> >> > presentation development results as well as next steps for th= is >>> >> draft >>> >> > and the 6man variable slaac solutions draft: >>> >> > >>> >> > >>> >> > This thread was in light of Lorenzo kindly pointing out that >>> >> upgrading >>> >> > 3GPP is not all that needs be done for Cameron=E2=80=99s 64sh= are v2 to >>> >> work - as >>> >> > all mobile devices would stop working- as slaac would not >>> would be >>> >> > effectively broken. >>> >> > >>> >> > The mobile device would receive a shorter prefix let=E2=80=99= s say /56 >>> >> but not >>> >> > know what to do with it since it=E2=80=99s expecting a /64. >>> >> > >>> >> > So that a major gap and the only solution is updating RFC 429= 1 >>> >> removing >>> >> > the 64 bit boundary allowing for shorter prefix and now as we= ll >>> >> longer >>> >> > prefixes to work and in that respect now provide the much >>> needed >>> >> parity >>> >> > with static and DHCPv6 which can do any prefix length. >>> >> > >>> >> > So that is a drastic change to RFC 4291. However, in light o= f >>> this >>> >> > development on the v6ops 109 call, my balancing act of best o= f >>> both >>> >> > worlds and also to keep everyone happy to make this a WG effo= rt >>> >> for this >>> >> > change by proposing in the subject heading /80 fixed boundary >>> and >>> >> not a >>> >> > variable slaac change allowing all bits vlsm. >>> >> > >>> >> > Basically stealing 16 bits for network prefix out of the IID, >>> still >>> >> > keeping the fixed boundary so longer than 80 would NOT be >>> allowed. >>> >> > >>> >> > A /64 would now be equivalent to a /48 with now 64k /80=E2=80= =99s. >>> >> > >>> >> > This /80 would keep the operators and law enforcement happy a= s >>> >> now 16 >>> >> > bits less helps traceability but is still long enough for 48 >>> bits of >>> >> > privacy to IP correlation by attackers. >>> >> > >>> >> > This /80 would be a nice optimal balance as it would keep wir= ed >>> >> > broadband and mobile handset customers happy respecting their >>> >> privacy as >>> >> > the 16 bits less of heuristics is minimal change that will >>> impact IP >>> >> > correlation by attackers. >>> >> > >>> >> > The IID as it=E2=80=99s less than the current 64 bit cannot u= se MAC >>> based >>> >> EUI64 >>> >> > IID, which is not a problem as Mac based IID is not recommend= ed >>> >> as most >>> >> > all manufacturers use RFC 4941 and I believe Linux flavors >>> some use >>> >> > stable IID RFC 7217. >>> >> > >>> >> > So now the 48 bit IID would require a random IID generation >>> >> schema so >>> >> > can use either RFC 4941 privacy extension or RFC 7217 stable >>> IID to >>> >> > generate the 48 bit IID. >>> >> > >>> >> > 3GPP subtending would now work issue mentioned in the problem >>> >> statement >>> >> > draft without even having to use 64share as now longer prefix= es >>> >> up to >>> >> > /80 would be supported allowing for further segmentation of >>> >> downstream >>> >> > devices. >>> >> > >>> >> > This also would help wired broadband and soon fixed 5G >>> broadband >>> >> > proliferation where operators in light of BCP RIPE-690, are >>> sill >>> >> > allocation via BNG gateways a /64, now operators can stay >>> as-is, >>> >> as the >>> >> > /64 would now be allowed to be further segmented supporting 6= 4k >>> >> /80s, >>> >> > way more then enough for SOHO. >>> >> > >>> >> > This would allow 64share if used by 3GPP operators to work an= d >>> >> would not >>> >> > require the 3GPP specification to be updated. We don=E2=80= =99t know >>> even >>> >> if the >>> >> > 3GPP architecture specification can be updated to support >>> shorter >>> >> > prefixes and if the 3GPP consortium of operators would agree = to >>> >> it. So >>> >> > that is all theoretical of that change is possible. >>> >> > >>> >> > As with 5G with Enhanced VPN framework SR steering of high >>> priority >>> >> > traffic, traffic isolation and Network slicing capabilities >>> becomes >>> >> > mainstream and will soon be a real world reality and as fixed >>> 5G >>> >> > broadband proliferation takes off and mobile 5G =3D=3D the id= ea of >>> a >>> >> > wearable /48 will really be many /48s. >>> >> > >>> >> > As this paradigm shift takes place, operators around the worl= d >>> >> will be >>> >> > clamoring after the RIR for massive blocks, I would say less >>> than /8 >>> >> > more like a /5 or /4. If you do the math on the way high sid= e >>> a /10 >>> >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR >>> >> which is >>> >> > tiny number with the number of large size operators worldwide= . >>> >> > >>> >> > With the massive proliferation of IOT devices and just about >>> >> every home >>> >> > or office appliance on 5G, the problem now gets way >>> exacerbated. >>> >> > >>> >> > As this evolution unfolds IANA will be scrambling to release >>> all >>> >> > remaining /3 as well as all unallocated blocks to subvert RIR >>> IPv6 >>> >> > address space depletion. >>> >> > >>> >> > Playing Monday night quarterbacking in hindsight we would nev= er >>> >> think >>> >> > this would happen in a million years, but we would see IPv6 o= n >>> >> the verge >>> >> > of address space depletion. Unheard of but it can happen as >>> the >>> >> saying >>> >> > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. >>> >> > >>> >> > It is true as history has taught that very important lesson. >>> >> > >>> >> > The answer to this real world problem is in the subject headi= ng >>> >> of this >>> >> > thread. >>> >> > >>> >> > This would also fix the day 1 issue I mentioned allowing mix = of >>> >> slaac >>> >> > devices with static and DHCPv6 up to /80. >>> >> > >>> >> > The variable slaac solution draft proposes a new RA PIO flag >>> >> that would >>> >> > be used to signal longer prefixes, and would provide backward= s >>> >> > compatibility so that devices not supporting woud ignore the >>> flag >>> >> and >>> >> > devices on newer code supporting would use the flag. We >>> definitely >>> >> > don=E2=80=99t want to impact any existing devices on the exis= ting 64 >>> bit >>> >> slaac >>> >> > boundary standard. >>> >> > >>> >> > Dmytro has tested the solution on Linux kernel signaling RA P= IO >>> >> flag and >>> >> > was able to successfully test any length mask and random IID >>> >> generation >>> >> > both RFC 4941 privacy extension as well as stable IID RFC 721= 7. >>> >> > >>> >> > >>> >> >>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >>> >> < >>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/> >>> >> > >>> >> < >>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >>> >> < >>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>> >>> >> > >>> >> > If everyone is in agreement with what I have stated on this >>> >> thread, I >>> >> > would like to ask the chairs for WG adoption as this is a WG >>> effort. >>> >> > >>> >> > I would like to garner support from all 6MAN members with ful= l >>> >> consensus >>> >> > to change the existing RFC 4941 /64 fixed boundary to /80 fix= ed >>> >> boundary. >>> >> > >>> >> > Kind Regards >>> >> > >>> >> > Gyan >>> >> > >>> >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >>> >> >>> >> > >> >>> wrote: >>> >> > >>> >> > I am missing something in your reasoning. >>> >> > You seem to say at one point that (to paraphrase) "we can= 't >>> >> do this >>> >> > because it does not work with the existing UE software". >>> >> > Any new solution where a UE delegates based on any change >>> of >>> >> any kind >>> >> > (including lengthening the prefix, shortening the prefix, >>> or >>> >> magically >>> >> > incanting new prefixes) requires that the UE be upgraded >>> to know >>> >> > what to >>> >> > do with the information. I do not see how that >>> >> differentiates any of >>> >> > the solutions. (Except "don't do anything", which I think >>> we >>> >> do not >>> >> > want >>> >> > to take.) >>> >> > >>> >> > Yours, >>> >> > Joel >>> >> > >>> >> > On 11/19/2020 5:03 PM, Gyan Mishra wrote: >>> >> > > >>> >> > > >>> >> > > On Thu, Nov 19, 2020 at 10:33 AM >> >> >>> >> > >> >> >>> >> > > >> otroan@employees.org> >>> >> >>> >>> wrote: >>> >> > > >>> >> > > >>> >> > > >>> >> > > > On 19 Nov 2020, at 14:58, Gyan Mishra >>> >> > >>> >> > >>> >> > > >> >> >>> >> > >> >> >>> wrote: >>> >> > > > >>> >> > > > You would need a new option. It would likely be >>> >> useful for the >>> >> > > requesting router to indicate interest in the >>> option. Even >>> >> > hinting >>> >> > > at what prefix size it was expecting. >>> >> > > > Now can you explain to me again the reasons why >>> this >>> >> > approach is >>> >> > > better than using the existing DHPCv6 protocol >>> packets? >>> >> > > > >>> >> > > > 3GPP gateway does not support DHCPv6 >>> >> > > >>> >> > > 3GPP gateway doesn't support new option. What's yo= ur >>> >> point? >>> >> > > >>> >> > > >>> >> > > >>> >> > > The point of the v6ops presentation and this emai= l >>> >> thread is >>> >> > how to >>> >> > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case i= n slide 1 of the >>> >> deck you >>> >> > compiled >>> >> > > a list of options and of the two I had highlighted in >>> red >>> >> were the >>> >> > > 64share v2 Cameron=E2=80=99s option and the variable s= laac >>> >> option. So on >>> >> > the >>> >> > > call this morning Lorenzo shot down 64share v2 shorter >>> prefix >>> >> > option as >>> >> > > even if the 3GPP architecture was updated to support >>> longer >>> >> > prefixes and >>> >> > > even is the 3GPP gateway was able to send a shorter >>> prefix >>> >> with A >>> >> > flag >>> >> > > not set, all mobile devices per Lorenzo=E2=80=99s poin= t would be >>> >> broken >>> >> > as they >>> >> > > would not accept the shorter let=E2=80=99s say /56 pre= fix to >>> build the >>> >> > slaac 128 >>> >> > > bit address. So the bottom line is the 64share v2 >>> won=E2=80=99t work >>> >> > unless we >>> >> > > update RFC 4291 and remove the 64 bit boundary. >>> >> > > >>> >> > > So we are back to square uno - no viable solution >>> >> > > >>> >> > > So now we had thrown out the longer >64 due to race = to >>> >> bottom >>> >> > worries >>> >> > > which I and others believe is Fud and as described in >>> >> slide 10 of >>> >> > the >>> >> > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. >>> >> > > >>> >> > > So a happy medium /80 fixed boundary I came up with >>> that I >>> >> think >>> >> > solves >>> >> > > a lot of the issue and not just the 3GPP initial >>> >> segmentation of >>> >> > > downstream devices problem statement. >>> >> > > >>> >> > > Since we have to update RFC 4291 for 64share v2 to wor= k >>> >> anyways >>> >> > to allow >>> >> > > for shorter prefixes, why not instead create a new >>> bottom >>> >> at /80 >>> >> > giving >>> >> > > 16 bits more of prefix length and shrinking the IID do= wn >>> >> to 48 bits. >>> >> > > Doing so you would not even have to update the 3GPP >>> >> architecture >>> >> > as I >>> >> > > don=E2=80=99t know if that would fly or not. Also thi= s solves a >>> >> few other >>> >> > > problems at the same time. >>> >> > > >>> >> > > >>> >> > > As I mentioned in the v6ops deck presented that vlsm 0 >>> to >>> >> 128 is >>> >> > > mainstream for operators for static addressing on rout= er >>> >> and switch >>> >> > > infrastructure and dhcpv6 subnets longer prefixes for >>> network >>> >> > > infrastructure appliance clusters, NFV/VNF >>> virtualization >>> >> and server >>> >> > > farms. On host subnets where there is a chance of mix >>> of >>> >> slaac >>> >> > hosts >>> >> > > with dhcpv6 devices the prefix length is stuck at >>> /64. So on >>> >> > these mix >>> >> > > addressing host subnets we cannot do longer prefixes >>> following >>> >> > our ND >>> >> > > cache hard limit mantra to prevent ND cache exhaustion >>> >> issues as >>> >> > > described in RFC 6164. >>> >> > > >>> >> > > So with the /80 new fixed boundary shifting prefix >>> length >>> >> 16 bits >>> >> > longer >>> >> > > and shortening the IID by 16 bits gives resolved the >>> 3GPP >>> >> issue >>> >> > which >>> >> > > 64share can work as is and subtending to downstream >>> >> devices will now >>> >> > > work as a /64 is now equivalent to a /48 with 64k >>> /80s. Also >>> >> > BCP-690 >>> >> > > for broadband not all operators have adopted the short= er >>> >> prefix >>> >> > lengths >>> >> > > /56 or /48 recommendations and now that=E2=80=99s not= an issue >>> as the >>> >> > /64 would >>> >> > > now suffice. >>> >> > > >>> >> > > From an operators perspective that gain allows at lea= st >>> >> for 3GPP >>> >> > > massive growth and subtending with a single /64 allows >>> the >>> >> operators >>> >> > > such as Verizon with massive subscriber base worldwide >>> can >>> >> stay with >>> >> > > current allocations and don=E2=80=99t have to ask >>> >> < >>> https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+ha= ve+to+ask?entry=3Dgmail&source=3Dg >>> > >>> >> for /10. >>> >> > > >>> >> > > As 5G gets rolled out with Enhanced VPN framework and >>> Network >>> >> > slicing >>> >> > > paradigm, the demand for shorter blocks and wearable >>> >> multiple /48 >>> >> > will >>> >> > > be our new reality. >>> >> > > >>> >> > > Making that 16 bit shift now to /80 making a /64 the n= ew >>> >> /48 will >>> >> > give >>> >> > > broadband and 3GPP subscribers a ton of space to >>> >> subtending their >>> >> > > networks we would be set for the future. Especially >>> with >>> >> IOT the >>> >> > demand >>> >> > > for subtending will continue to grow astronomically. >>> >> > > >>> >> > > Also IANA does not have to get start in allocating the >>> >> other /3 and >>> >> > > other available blocks. >>> >> > > >>> >> > > Lots of problems being solved here with a fixed /80 ne= w >>> >> boundary. >>> >> > > >>> >> > > Also with the existing random IID generation schemes >>> which >>> >> we have >>> >> > > tested on Linux kernel can do longer p >>> >> > >>> >> < >>> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer= +p?entry=3Dgmail&source=3Dg >>> < >>> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer= +p?entry=3Dgmail&source=3Dg >>> >>refixes >>> >> > using RFC 4941 privacy >>> >> > > extension or RFC 7217 stable IID. >>> >> > > >>> >> > > Win-Win for all. >>> >> > > >>> >> > > Ole >>> >> > > >>> >> > > -- >>> >> > > >>> >> > > >>> >> >> >>> >> > > >>> >> > > *Gyan Mishra* >>> >> > > >>> >> > > /Network Solutions A//rchitect / >>> >> > > >>> >> > > /M 301 502-1347 >>> >> > > 13101 Columbia Pike >>> >>> >>> >>> >> >>> >>> > >>> > >>> /Silver Spring, MD >>> >>> >> > > >>> >> > > >>> >> > > >>> >> > > _______________________________________________ >>> >> > > v6ops mailing list >>> >> > > v6ops@ietf.org >>> >> > >>> >> > > https://www.ietf.org/mailman/listinfo/v6ops >>> >> >>> >> > >> >> > >>> >> > > >>> >> > >>> >> > -- >>> >> > >>> >> > > >>> >> > >>> >> > *Gyan Mishra* >>> >> > >>> >> > /Network Solutions A//rchitect / >>> >> > >>> >> > /M 301 502-1347 >>> >> > 13101 Columbia Pike >>> >>> >>> >>> >> >>> > >>> /Silver Spring, MD >>> >>> >> > >>> >> > >>> >> >>> >> -- >>> >> >>> >> >>> >> >>> >> *Gyan Mishra* >>> >> >>> >> /Network Solutions A//rchitect / >>> >> >>> >> /M 301 502-1347 >>> >> 13101 Columbia Pike >>> >>> >>> >> >>> /Silver Spring, MD >>> >>> >> >>> >> >>> > >>> > _______________________________________________ >>> > v6ops mailing list >>> > v6ops@ietf.org >>> > https://www.ietf.org/mailman/listinfo/v6ops >>> > >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --0000000000005b29e305b49c3467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 21 Nov 2020, 17:12 Ca By, <cb.list6@gmail.com> wrote:


On Fri, Nov 20, 2020 at 8:20 PM Mark Smith <markzzzsmith@gmail.com> wrote:


On Sat, 21 Nov 202= 0, 14:00 Brian E Carpenter, <b= rian.e.carpenter@gmail.com> wrote:
Joel,
It seems to me that it's high time to draft a liaison statement to 3GPP= ,
observing that:

(1) There is a serious problem for the design and implementation of
5G-based IPv6 "hot spots" and CEs [which is where this conversati= on started];

I think it is also important to find out why they haven't d= eployed DHCPv6 to solve this=C2=A0problem.

Don't they think DHCPv6 infrastructure will scale? I= s it just that they don't know how to scale it?
=

Definitely do not know how. I had a look at the dhcpv6 rfc and it was ove= r 150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr. =C2=A0=C2=A0

It is long. A lot of that is really about maintaining state synch= ronisation between the client and the server, and that is for address state= synchronisation and dynamic allocation.

<= div dir=3D"auto">
=


Is it= a vendor / mobile operator / handset developer DHCPv6 capability=C2=A0chic= ken-and-egg problem?
=

I believe that exists too.=C2= =A0


Is there an ove= rriding business or industry reason?

No. Just the = usual nobody will come to the shop to pay for dhcpv6, =C2=A0so it is hard t= o
martial market demand. Major vendors (android) hav= e vocally declined to support dhcpv6.
=


Specifically PD?

Th= e objection to DHCPv6 support I've seen has been about not supporting D= HCPv6 for address assignment to the host itself.
PD is really router rather than host configuration= . I sometimes wonder what a "routing protocol" solution to PD wou= ld have looked like. For example, perhaps OSPF or BGP extensions to support= delegating prefixes to downstream routers.

I think right now it is better to stay with using DHCPv= 6 PD because it exists and has been successfully deployed. However I think = the idea of using RAs for PD would heading down that "routing protocol= " solution path to an extent.=C2=A0

<= div dir=3D"auto">
=
Other scenarios it is sup= ported but default off.=C2=A0


The mobile industry has been resistant to tethering over the yea= rs, and probably only came to begrudgingly accept it because they couldn= 9;t prevent phone vendors from implementing Wifi and NAT, and couldn't = very effectively stop their customers from using that capability (One trick= I've heard of to prevent tethering working was to check if an IPv4 pac= ket's=C2=A0TTL value was 64 when it arrived at the network, meaning it = originated from the directly attached handset. Packets from tethered device= s had a TTL of 63 so were dropped. Of course, you could set the default TTL= on a tethered=C2=A0PC to 65 to get around that.)
I guess there might be a fairly strong mindset th= at there must be a fee per device attached to the network in addition to a = fee for network utilisation. Providing multiple /64s would be formally ackn= owledging that multiple devices can be attached and a fee per device isn= 9;t and can't ever be charged, counter to the mindset.

I believe the sentiment on this list from operators has been tryi= ng to find ways to make more effective ways to support more complete ipv6 n= etworks with the machinery we have.=C2=A0 I don=E2=80=99t think you have se= en otherwise.=C2=A0

My o= wn view is that i am trying to connect 10+M households, many rural, with 5G= broadband... and i feel it would be negligent to not support ipv6 in the m= ost common home networking scenarios.=C2=A0

That said, my thinking has evolved.=C2=A0 And, i apprec= iate the living and illuminating discussion. =C2=A0 i don=E2=80=99t think i= need standards work at =C2=A0this point. I am i going to take a swing at m= aking dhcpv6 work... not as specified in that long rfc, but just taking the= view of a dhcpv6-pd packet as an api, which will simplify things.=C2=A0


The production wired residential dep= loyment I worked in back in 2010 had a DHCPv6 server on the BNG, not a rela= y, however that was fed subscriber attributes via RADIUS. These days they w= ould be RFC6911 RADIUS attributes rather than vendor specific ones.

So the DHCPv6 server infrastruc= ture scaling problem upsteam of the BNG gets replaced by a RADIUS scaling o= ne, which people may be more familiar with solving and already have solved.=


I think some or all of these problems might go away with the abov= e DHCPv6 server/RADIUS model, because there is a lot more DHCPv6 session st= ate available on the first hop device.


Regards,
= Mark.



Regards,
Mark.


(2) Although the best solution is not yet obvious, defining and
standardizing it will require a joint effort by the IETF and 3GPP.

Followed by a proposal to form an ad hoc joint design team.

Regards
=C2=A0 =C2=A0Brian Carpenter
On 21-Nov-20 14:46, Joel M. Halpern wrote:
> The nesting got me lost, so I will top post my take on the answer to t= he
> one quesiton I could understand.
>
> I believe you asked what I think would need to be changed to permit th= e
> delegation.
> As with anything, the real things that need to change are the devices = in
> the network.
>
> With regard to IETF standards, what is proposed is a change to RA. > There are several possible changes.=C2=A0 None of them require a chang= e to
> the IPv6 addressing archtiecture, as the addressing structure remains = as
> it is.
> As for the exact mechanism, at the moment I lean towards Ole's pro= posal
> of using a new option in his generic option mechanism.=C2=A0 But I am = not
> wedded to that answer.
>
> And of course, to get this supported in mobile environments we will ha= ve
> to work with 3GPP and make sure there are no other hidden issues.
> That's the way we do things.=C2=A0 Work together.
>
> Changing the prefix length to /80 is technically also possible.=C2=A0 = It does
> a lot more violence to my understanding of the architecture and softwa= re
> structures that go with it, and is a very limited and narrow solution = to
> the problem.
>
> Yours,
> Joel
>
> On 11/20/2020 7:58 PM, Gyan Mishra wrote:
>> Hi Joel
>>
>> In-line
>>
>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpern.com
>> <mailto:jmh@joelha= lpern.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan, separate from Ole's comments about th= e difference between address
>>=C2=A0 =C2=A0 =C2=A0assignment and delegation, I have another probl= em following the
>>=C2=A0 =C2=A0 =C2=A0reasoning below.
>>
>>=C2=A0 =C2=A0 =C2=A0Yes, the proposal for using shorter prefixes to= enable UE to perform
>>=C2=A0 =C2=A0 =C2=A0delegation will require changes to the UE.
>>
>>=C2=A0 =C2=A0 =C2=A0 Gyan> Agreed.=C2=A0 So that change would be= to RFC 4291 64 bit boundary
>> to allow for longer prefix.=C2=A0 Do you agree?
>>
>> If you don=E2=80=99t agree what do think the change would be to al= low the UE to
>> accept shorter prefix from the 3GPP gateway?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0But I do not see how that is relevant to any ch= oice we are trying to
>>=C2=A0 =C2=A0 =C2=A0make.
>>=C2=A0 =C2=A0 =C2=A0Any solution that enables UE to delegate addres= ses (in the sense that
>>=C2=A0 =C2=A0 =C2=A0they lack the capability now) willr equire chan= ges to the UE.
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> If the UE receives a /56 via RA it cou= ld delegate /64 to
>>=C2=A0 =C2=A0 =C2=A0downstream devices.=C2=A0 No change needed to d= elegate =C2=A0/64, however a
>>=C2=A0 =C2=A0 =C2=A0change is needed to accept /56 via RA.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 If 3GPP gateway supported PD - problem solved = but that=E2=80=99s not the
>> case and that does not sound like it will ever change even with 5G= .
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> The UE needs to be able to accept shor= ter prefix.=C2=A0 That=E2=80=99s the
>> IPV6 specification change that requires removal of the 64 bit boun= dary.
>>
>>=C2=A0 =C2=A0 =C2=A0Yoru
>>=C2=A0 =C2=A0 =C2=A0proposed change to the SLAAC length if anything= does more violence to
>>=C2=A0 =C2=A0 =C2=A0the software (depending upon the exact software= architecture.)
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Gyan> What violence to software.=C2=A0 There= would be more violence to
>> software if we removed the 64 bit boundary and allowed slaac to su= pport
>> any vlsm prefix lengths.
>>
>> My /80 proposal would just shift the boundary 16 bits to /80.
>>
>> Hosts on the same subnet with two different masks would not be on-= net to
>> each other as on different subnets.=C2=A0 The router would be conf= igured with
>> the two subnets /64 and /80 subnet to support the two device types= .
>> The solution would be a simple RA PIO flag that is set and older h= osts
>> not upgraded would be backwards compatible and so would only suppo= rt 64
>> bit boundary by ignoring flag. Hosts upgraded to support would >> understand the flag and be able to support longer mask up to /80.<= br> >>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0So I do not follow how you got to your conclusi= on.
>>
>>=C2=A0 =C2=A0 =C2=A0Yours,
>>=C2=A0 =C2=A0 =C2=A0Joel
>>
>>=C2=A0 =C2=A0 =C2=A0On 11/20/2020 5:27 PM, Gyan Mishra wrote:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > (top posting)
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As I would like to clear the air as well = as get to the crux of
>>=C2=A0 =C2=A0 =C2=A0the v6ops
>>=C2=A0 =C2=A0 =C2=A0 > presentation development results as well = as next steps for this
>>=C2=A0 =C2=A0 =C2=A0draft
>>=C2=A0 =C2=A0 =C2=A0 > and the 6man variable slaac solutions dra= ft:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This thread was in light of Lorenzo kindl= y pointing out that
>>=C2=A0 =C2=A0 =C2=A0upgrading
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP is not all that needs be done for Ca= meron=E2=80=99s 64share v2 to
>>=C2=A0 =C2=A0 =C2=A0work - as
>>=C2=A0 =C2=A0 =C2=A0 > all mobile devices would stop working- as= slaac would not would be
>>=C2=A0 =C2=A0 =C2=A0 > effectively broken.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The mobile device would receive a shorter= prefix let=E2=80=99s say /56
>>=C2=A0 =C2=A0 =C2=A0but not
>>=C2=A0 =C2=A0 =C2=A0 > know what to do with it since it=E2=80=99= s expecting a /64.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So that a major gap and the only solution= is updating RFC 4291
>>=C2=A0 =C2=A0 =C2=A0removing
>>=C2=A0 =C2=A0 =C2=A0 > the 64 bit boundary allowing for shorter = prefix and now as well
>>=C2=A0 =C2=A0 =C2=A0longer
>>=C2=A0 =C2=A0 =C2=A0 > prefixes to work and in that respect now = provide the much needed
>>=C2=A0 =C2=A0 =C2=A0parity
>>=C2=A0 =C2=A0 =C2=A0 > with static and DHCPv6 which can do any p= refix length.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So that is a drastic change to RFC 4291.= =C2=A0 However, in light of this
>>=C2=A0 =C2=A0 =C2=A0 > development on the v6ops 109 call, my bal= ancing act of best of both
>>=C2=A0 =C2=A0 =C2=A0 > worlds and also to keep everyone happy to= make this a WG effort
>>=C2=A0 =C2=A0 =C2=A0for this
>>=C2=A0 =C2=A0 =C2=A0 > change by proposing in the subject headin= g /80 fixed boundary and
>>=C2=A0 =C2=A0 =C2=A0not a
>>=C2=A0 =C2=A0 =C2=A0 > variable slaac change allowing all bits v= lsm.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Basically stealing 16 bits for network pr= efix out of the IID, still
>>=C2=A0 =C2=A0 =C2=A0 > keeping the fixed boundary so longer than= 80 would NOT =C2=A0be allowed.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > A /64 would now be equivalent to a /48 wi= th now 64k /80=E2=80=99s.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This /80 would keep the operators and law= enforcement happy as
>>=C2=A0 =C2=A0 =C2=A0now 16
>>=C2=A0 =C2=A0 =C2=A0 > bits less helps traceability but is still= long enough for 48 bits of
>>=C2=A0 =C2=A0 =C2=A0 > privacy to IP correlation by attackers. >>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This /80 would be a nice optimal balance = as it would keep wired
>>=C2=A0 =C2=A0 =C2=A0 > broadband and mobile handset customers ha= ppy respecting their
>>=C2=A0 =C2=A0 =C2=A0privacy as
>>=C2=A0 =C2=A0 =C2=A0 > the 16 bits less of heuristics is minimal= change that will impact IP
>>=C2=A0 =C2=A0 =C2=A0 > correlation by attackers.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The IID as it=E2=80=99s less than the cur= rent 64 bit cannot use MAC based
>>=C2=A0 =C2=A0 =C2=A0EUI64
>>=C2=A0 =C2=A0 =C2=A0 > IID, which is not a problem as Mac based = IID is not recommended
>>=C2=A0 =C2=A0 =C2=A0as most
>>=C2=A0 =C2=A0 =C2=A0 > all manufacturers use RFC 4941 and I beli= eve Linux flavors some use
>>=C2=A0 =C2=A0 =C2=A0 > stable IID RFC 7217.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > So now the 48 bit IID would require a ran= dom IID generation
>>=C2=A0 =C2=A0 =C2=A0schema so
>>=C2=A0 =C2=A0 =C2=A0 > can use either RFC 4941 privacy extension= or RFC 7217 stable IID to
>>=C2=A0 =C2=A0 =C2=A0 > generate the 48 bit IID.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP subtending would now work issue ment= ioned in the problem
>>=C2=A0 =C2=A0 =C2=A0statement
>>=C2=A0 =C2=A0 =C2=A0 > draft without even having to use 64share = as now longer prefixes
>>=C2=A0 =C2=A0 =C2=A0up to
>>=C2=A0 =C2=A0 =C2=A0 > /80 would be supported allowing for furth= er segmentation of
>>=C2=A0 =C2=A0 =C2=A0downstream
>>=C2=A0 =C2=A0 =C2=A0 > devices.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This also would help wired broadband and = soon fixed 5G broadband
>>=C2=A0 =C2=A0 =C2=A0 > proliferation where operators in light of= BCP RIPE-690, are sill
>>=C2=A0 =C2=A0 =C2=A0 > allocation via BNG gateways a /64, now op= erators =C2=A0can stay as-is,
>>=C2=A0 =C2=A0 =C2=A0as the
>>=C2=A0 =C2=A0 =C2=A0 > /64 would now be allowed to be further se= gmented supporting 64k
>>=C2=A0 =C2=A0 =C2=A0/80s,
>>=C2=A0 =C2=A0 =C2=A0 > way more then enough for SOHO.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This would allow 64share if used by 3GPP = operators to work and
>>=C2=A0 =C2=A0 =C2=A0would not
>>=C2=A0 =C2=A0 =C2=A0 > require the 3GPP specification to be upda= ted.=C2=A0 We don=E2=80=99t know even
>>=C2=A0 =C2=A0 =C2=A0if the
>>=C2=A0 =C2=A0 =C2=A0 > 3GPP architecture specification can be up= dated to support shorter
>>=C2=A0 =C2=A0 =C2=A0 > prefixes and if the 3GPP consortium of op= erators would agree to
>>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 So
>>=C2=A0 =C2=A0 =C2=A0 > that is all theoretical of that change is= possible.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As with 5G with Enhanced VPN framework SR= steering of high priority
>>=C2=A0 =C2=A0 =C2=A0 > traffic, traffic isolation and Network sl= icing capabilities becomes
>>=C2=A0 =C2=A0 =C2=A0 > mainstream and will soon be a real world = reality and as fixed 5G
>>=C2=A0 =C2=A0 =C2=A0 > broadband proliferation takes off and mob= ile 5G =3D=3D the idea of a
>>=C2=A0 =C2=A0 =C2=A0 > wearable /48 will really be many /48s. >>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As this paradigm shift takes place, opera= tors around the world
>>=C2=A0 =C2=A0 =C2=A0will be
>>=C2=A0 =C2=A0 =C2=A0 > clamoring after the RIR for massive block= s, I would say less than /8
>>=C2=A0 =C2=A0 =C2=A0 > more like a /5 or /4.=C2=A0 If you do the= math on the way high side a /10
>>=C2=A0 =C2=A0 =C2=A0 > yields 7 bits so 128 divided by 5 RIRs yi= elds 24 ISPs per RIR
>>=C2=A0 =C2=A0 =C2=A0which is
>>=C2=A0 =C2=A0 =C2=A0 > tiny number with the number of large size= operators worldwide.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > With the massive proliferation of IOT dev= ices and just about
>>=C2=A0 =C2=A0 =C2=A0every home
>>=C2=A0 =C2=A0 =C2=A0 > or office appliance on 5G, the problem no= w gets way exacerbated.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > As this evolution unfolds IANA will be sc= rambling to release all
>>=C2=A0 =C2=A0 =C2=A0 > remaining /3 as well as all unallocated b= locks to subvert RIR IPv6
>>=C2=A0 =C2=A0 =C2=A0 > address space depletion.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Playing Monday night quarterbacking in hi= ndsight we would never
>>=C2=A0 =C2=A0 =C2=A0think
>>=C2=A0 =C2=A0 =C2=A0 > this would happen in a million years, but= we would see IPv6 on
>>=C2=A0 =C2=A0 =C2=A0the verge
>>=C2=A0 =C2=A0 =C2=A0 > of address space depletion.=C2=A0 Unheard= of but it can happen as the
>>=C2=A0 =C2=A0 =C2=A0saying
>>=C2=A0 =C2=A0 =C2=A0 > goes =E2=80=9Cwhen you build - they will = come=E2=80=9D.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > It is true as history has taught that ver= y important lesson.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The answer to this real world problem is = in the subject heading
>>=C2=A0 =C2=A0 =C2=A0of this
>>=C2=A0 =C2=A0 =C2=A0 > thread.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > This would also fix the day 1 issue I men= tioned allowing mix of
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 > devices with static and DHCPv6 up to /80.=
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > The variable slaac solution draft propose= s a new =C2=A0RA PIO flag
>>=C2=A0 =C2=A0 =C2=A0that would
>>=C2=A0 =C2=A0 =C2=A0 > be used to signal longer prefixes, and wo= uld provide backwards
>>=C2=A0 =C2=A0 =C2=A0 > compatibility so that devices not support= ing woud ignore the flag
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0and
>>=C2=A0 =C2=A0 =C2=A0 > devices on newer code supporting would us= e the flag.=C2=A0 We definitely
>>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t want to impact any existing= devices on the existing 64 bit
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 > boundary standard.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Dmytro has tested the solution on Linux k= ernel signaling RA PIO
>>=C2=A0 =C2=A0 =C2=A0flag and
>>=C2=A0 =C2=A0 =C2=A0 > was able to successfully test any length = mask and random IID
>>=C2=A0 =C2=A0 =C2=A0generation
>>=C2=A0 =C2=A0 =C2=A0 > both RFC 4941 privacy extension as well a= s stable IID RFC 7217.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.o= rg/doc/draft-mishra-6man-variable-slaac/
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ie= tf.org/doc/draft-mishra-6man-variable-slaac/>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ie= tf.org/doc/draft-mishra-6man-variable-slaac/
>>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ie= tf.org/doc/draft-mishra-6man-variable-slaac/>>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > If everyone is in agreement with what I h= ave stated on this
>>=C2=A0 =C2=A0 =C2=A0thread, I
>>=C2=A0 =C2=A0 =C2=A0 > would like to ask the chairs for WG adopt= ion as this is a WG effort.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > I would like to garner support from all 6= MAN members with full
>>=C2=A0 =C2=A0 =C2=A0consensus
>>=C2=A0 =C2=A0 =C2=A0 > to change the existing RFC 4941 /64 fixed= boundary to /80 fixed
>>=C2=A0 =C2=A0 =C2=A0boundary.
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Kind Regards
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > Gyan
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 5:14 PM Joel M. H= alpern
>>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am missing something= in your reasoning.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0You seem to say at one= point that (to paraphrase) "we can't
>>=C2=A0 =C2=A0 =C2=A0do this
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0because it does not wo= rk with the existing UE software".
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Any new solution where= a UE delegates based on any change of
>>=C2=A0 =C2=A0 =C2=A0any kind
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(including lengthening= the prefix, shortening the prefix, or
>>=C2=A0 =C2=A0 =C2=A0magically
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0incanting new prefixes= ) requires that the UE be upgraded to know
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0what to
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0do with the informatio= n.=C2=A0 I do not see how that
>>=C2=A0 =C2=A0 =C2=A0differentiates any of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the solutions. (Except= "don't do anything", which I think we
>>=C2=A0 =C2=A0 =C2=A0do not
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0want
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to take.)
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yours,
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Joel
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM,= Gyan Mishra wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, = 2020 at 10:33 AM <otroan@e= mployees.org
>>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailto:otroan@employees.org>><= br> >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:otroan@employees.org <mailt= o:otroan@employees.org>= ;
>>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailto:otroan@employees.org>>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > On 19 Nov 2020, at 14:58, Gyan Mishra
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:hayabusagsm@gm= ail.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>>> wrote:
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > You would need a new option. It would likely be
>>=C2=A0 =C2=A0 =C2=A0useful for the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0requesting router to indicate interest in the option. Even
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hinting
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0at what prefix size it was expecting.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Now can you explain to me again the reasons why this
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0approach is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0better than using the existing DHPCv6 protocol packets?
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A03GPP gateway doesn't support new option. What's your
>>=C2=A0 =C2=A0 =C2=A0point?
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 The point of the v6ops presentation and this email
>>=C2=A0 =C2=A0 =C2=A0thread is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0how to
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend = a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 of the
>>=C2=A0 =C2=A0 =C2=A0deck you
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0compiled
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a list of option= s and of the two I had highlighted in red
>>=C2=A0 =C2=A0 =C2=A0were the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share v2 Camer= on=E2=80=99s option and the variable slaac
>>=C2=A0 =C2=A0 =C2=A0option.=C2=A0 So on
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > call this mornin= g Lorenzo shot down 64share v2 shorter prefix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0option as
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even if the 3GPP= architecture was updated to support longer
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0prefixes and
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even is the 3GPP= gateway was able to send a shorter prefix
>>=C2=A0 =C2=A0 =C2=A0with A
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0flag
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > not set, all mob= ile devices per Lorenzo=E2=80=99s point would be
>>=C2=A0 =C2=A0 =C2=A0broken
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as they
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > would not accept= the shorter let=E2=80=99s say /56 prefix to build the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slaac 128
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > bit address.=C2= =A0 So the bottom line is the 64share v2 won=E2=80=99t work
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0unless we
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > update RFC 4291 = and remove the 64 bit boundary.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So w= e are back to square uno - no viable solution
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So n= ow we had thrown out the longer >64 due to race to
>>=C2=A0 =C2=A0 =C2=A0bottom
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0worries
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > which I and othe= rs believe is Fud and as described in
>>=C2=A0 =C2=A0 =C2=A0slide 10 of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Cr= ace to the bottom slide=E2=80=9D.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So a happy mediu= m /80 fixed boundary I came up with that I
>>=C2=A0 =C2=A0 =C2=A0think
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0solves
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a lot of the iss= ue and not just the 3GPP initial
>>=C2=A0 =C2=A0 =C2=A0segmentation of
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > downstream devic= es problem statement.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Since we have to= update RFC 4291 for 64share v2 to work
>>=C2=A0 =C2=A0 =C2=A0anyways
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to allow
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for shorter pref= ixes, why not instead create a new bottom
>>=C2=A0 =C2=A0 =C2=A0at /80
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0giving
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 16 bits more of = prefix length and shrinking the IID down
>>=C2=A0 =C2=A0 =C2=A0to 48 bits.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Doing so you wou= ld not even have to update the 3GPP
>>=C2=A0 =C2=A0 =C2=A0architecture
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as I
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t kn= ow if that would fly or not.=C2=A0 Also this solves a
>>=C2=A0 =C2=A0 =C2=A0few other
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > problems at the = same time.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As I mentioned i= n the v6ops deck presented that vlsm 0 to
>>=C2=A0 =C2=A0 =C2=A0128 is
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mainstream for o= perators for static addressing on router
>>=C2=A0 =C2=A0 =C2=A0and switch
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure a= nd dhcpv6 subnets longer prefixes for network
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure a= ppliance clusters, NFV/VNF virtualization
>>=C2=A0 =C2=A0 =C2=A0and server
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On = host subnets where there is a chance of mix of
>>=C2=A0 =C2=A0 =C2=A0slaac
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hosts
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2= =A0devices the prefix length is stuck at /64.=C2=A0 So on
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0these mix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > addressing host = subnets we cannot do longer prefixes following
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0our ND
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > cache hard limit= mantra to prevent ND cache exhaustion
>>=C2=A0 =C2=A0 =C2=A0issues as
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > described in RFC= 6164.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So with the /80 = new fixed boundary shifting prefix length
>>=C2=A0 =C2=A0 =C2=A016 bits
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0longer
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and shortening t= he IID by 16 bits gives resolved the 3GPP
>>=C2=A0 =C2=A0 =C2=A0issue
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0which
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share can work= as is and subtending to downstream
>>=C2=A0 =C2=A0 =C2=A0devices will now
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > work as a /64 is= now equivalent to a /48 with 64k /80s.=C2=A0 Also
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0BCP-690
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for broadband no= t all operators have adopted the shorter
>>=C2=A0 =C2=A0 =C2=A0prefix
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0lengths
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /56 or /48 recom= mendations =C2=A0and now that=E2=80=99s not an issue as the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0/64 would
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > now suffice.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an op= erators perspective that gain allows at least
>>=C2=A0 =C2=A0 =C2=A0for 3GPP
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > massive growth a= nd subtending with a single /64 allows the
>>=C2=A0 =C2=A0 =C2=A0operators
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > such as Verizon = with massive subscriber base worldwide can
>>=C2=A0 =C2=A0 =C2=A0stay with
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > current allocati= ons and don=E2=80=99t have to ask
>>=C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/ent+allocations+a= nd+don%E2%80%99t+have+to+ask?entry=3Dgmail&source=3Dg>
>>=C2=A0 =C2=A0 =C2=A0for /10.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As 5G gets rolle= d out with Enhanced VPN framework and Network
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slicing
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > paradigm, the de= mand for shorter blocks and wearable
>>=C2=A0 =C2=A0 =C2=A0multiple /48
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0will
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > be our new reali= ty.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Making that 16 b= it shift now to /80 making a /64 the new
>>=C2=A0 =C2=A0 =C2=A0/48 will
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0give
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > broadband and 3G= PP subscribers a ton of space to
>>=C2=A0 =C2=A0 =C2=A0subtending their
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > networks we woul= d be set for the future.=C2=A0 Especially with
>>=C2=A0 =C2=A0 =C2=A0IOT the
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0demand
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for subtending w= ill continue to grow astronomically.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also IANA does n= ot have to get start in allocating the
>>=C2=A0 =C2=A0 =C2=A0other /3 and
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > other available = blocks.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Lots of problems= being solved here with a fixed /80 new
>>=C2=A0 =C2=A0 =C2=A0boundary.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also with the ex= isting random IID generation schemes which
>>=C2=A0 =C2=A0 =C2=A0we have
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > tested on Linux = kernel can do longer p
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/tested+on+Linux+k= ernel+can+do+longer+p?entry=3Dgmail&source=3Dg <https://www.google.com/maps/searc= h/tested+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg&g= t;>refixes
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy=
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > extension or RFC= 7217 stable IID.
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Win-Win for all.=
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Ole
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > --
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ <http://www.verizon.com/<= /a>>
>>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.com/>>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra* >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Network Solutio= ns A//rchitect /
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347<= br> >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 131= 01 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 = =C2=A0 =C2=A0 > /Silver Spring, MD
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > ________________= _______________________________
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops mailing li= st
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@ietf.org>
>>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v= 6ops@ietf.org>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.o= rg/mailman/listinfo/v6ops
>>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/v6ops>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org= /mailman/listinfo/v6ops
>>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/v6ops>>
>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > --
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ <http://www.verizon.com/>>
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect /
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>>=C2=A0 =C2=A0 =C2=A0 >
>>=C2=A0 =C2=A0 =C2=A0 >
>>
>> --
>>
>> <http://ww= w.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> /Network Solutions A//rchitect /
>>
>> /M 301 502-1347
>> 13101 Columbia Pike
 >> /Silver Spring, MD=
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--0000000000005b29e305b49c3467-- From nobody Sat Nov 21 05:57:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4363A0C02 for ; Sat, 21 Nov 2020 05:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 sIDes_4KAFlK for ; Sat, 21 Nov 2020 05:57:07 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 7B5BE3A0BFD for ; Sat, 21 Nov 2020 05:57:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0ALDv5Wu024414 for ; Sat, 21 Nov 2020 14:57:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3563F200CAA for ; Sat, 21 Nov 2020 14:57:05 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2A932200C1B for ; Sat, 21 Nov 2020 14:57:05 +0100 (CET) Received: from [10.11.240.1] ([10.11.240.1]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0ALDv4tj017272 for ; Sat, 21 Nov 2020 14:57:04 +0100 To: v6ops@ietf.org References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> From: Alexandre Petrescu Message-ID: Date: Sat, 21 Nov 2020 14:57:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 13:57:10 -0000 Le 21/11/2020 à 06:47, Mark Smith a écrit : > > > On Sat, 21 Nov 2020, 09:27 Gyan Mishra, > wrote: > > > (top posting) > > > As I would like to clear the air as well as get to the crux of the > v6ops presentation development results as well as next steps for > this draft and the 6man variable slaac solutions draft: > > > You're asserting that everybody has accepted there is a problem to be > solved, and that everybody has accepted that the only way to solve it is > to change the default 64 bit IID size. This is both premature and not a > representation about "everybody's" opinion you can make. > > I haven't accepted either of those things. > > I'm not happy with the idea of changing away for 64 bit IIDs because I > don't think 64 bit IIDs are the problem. Plenty of operators have given > out /56s. No 3GPP operator gives out a /56 on a public deployment. There are some private trials on 3GPP operators with /56 and DHCPv6-PD, but that's a private APN with dedicated SIM cards. It is not new, it is old, and dying out, because it is not working, because no smartphone could ever use it, because modems dont implement it. > I'm working at my second one. It is not impossible. Mark, is that work in a 3GPP network on a 3G/4G link? Alex > > Many things below are incorrect, uninformed, or quite frankly > ridiculous. Some read like you've let your imagination go wild and then > have just assumed because you can imagine it it will then inevitably > happen in the near future. > > For example, DHCPv6 does not provide a prefix length to hosts. Your > proposal does not make SLAAC "consistent' with what DHCPv6 does, because > DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA > in the DHCPv6 RFC). > > "the idea of a wearable /48 will really be many /48s"? Do you really > think we're going to have more devices on our person that we'll need > more than 65 536 /64 subnets (a single /48) to number them? That sounds > like science fiction to me for at least the next 200 years or more. > > IPv6 isn't and isn't required to be the final and only Internet protocol > for the remainder of humanity, so we don't have to try to accommodate > every conceivable idea that somebody can come up with that might cause > the 128 bit address space to be too small. > > > This thread was in light of Lorenzo kindly pointing out that > upgrading 3GPP is not all that needs be done for Cameron’s 64share > v2 to work - as all mobile devices would stop working- as slaac > would not would be effectively broken. > > The mobile device would receive a shorter prefix let’s say /56 but > not know what to do with it since it’s expecting a /64. > > So that a major gap and the only solution is updating RFC 4291 > removing the 64 bit boundary allowing for shorter prefix and now as > well longer prefixes to work and in that respect now provide the > much needed parity with static and DHCPv6 which can do any prefix > length. > > So that is a drastic change to RFC 4291.  However, in light of this > development on the v6ops 109 call, my balancing act of best of both > worlds and also to keep everyone happy to make this a WG effort for > this change by proposing in the subject heading /80 fixed boundary > and not a variable slaac change allowing all bits vlsm. > > Basically stealing 16 bits for network prefix out of the IID, still > keeping the fixed boundary so longer than 80 would NOT  be allowed. > > A /64 would now be equivalent to a /48 with now 64k /80’s. > > This /80 would keep the operators and law enforcement happy as now > 16 bits less helps traceability but is still long enough for 48 bits > of privacy to IP correlation by attackers. > > This /80 would be a nice optimal balance as it would keep wired > broadband and mobile handset customers happy respecting their > privacy as the 16 bits less of heuristics is minimal change that > will impact IP correlation by attackers. > > The IID as it’s less than the current 64 bit cannot use MAC based > EUI64 IID, which is not a problem as Mac based IID is not > recommended as most all manufacturers use RFC 4941 and I believe > Linux flavors some use stable IID RFC 7217. > > So now the 48 bit IID would require a random IID generation schema > so can use either RFC 4941 privacy extension or RFC 7217 stable IID > to generate the 48 bit IID. > > 3GPP subtending would now work issue mentioned in the problem > statement draft without even having to use 64share as now longer > prefixes up to /80 would be supported allowing for further > segmentation of downstream devices. > > This also would help wired broadband and soon fixed 5G broadband > proliferation where operators in light of BCP RIPE-690, are sill > allocation via BNG gateways a /64, now operators  can stay as-is, as > the /64 would now be allowed to be further segmented supporting 64k > /80s, way more then enough for SOHO. > > This would allow 64share if used by 3GPP operators to work and would > not require the 3GPP specification to be updated.  We don’t know > even if the 3GPP architecture specification can be updated to > support shorter prefixes and if the 3GPP consortium of operators > would agree to it.  So that is all theoretical of that change is > possible. > > As with 5G with Enhanced VPN framework SR steering of high priority > traffic, traffic isolation and Network slicing capabilities becomes > mainstream and will soon be a real world reality and as fixed 5G > broadband proliferation takes off and mobile 5G == the idea of a > wearable /48 will really be many /48s. > > As this paradigm shift takes place, operators around the world will > be clamoring after the RIR for massive blocks, I would say less than > /8 more like a /5 or /4.  If you do the math on the way high side a > /10 yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR > which is tiny number with the number of large size operators worldwide. > > With the massive proliferation of IOT devices and just about every > home or office appliance on 5G, the problem now gets way exacerbated. > > As this evolution unfolds IANA will be scrambling to release all > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 > address space depletion. > > Playing Monday night quarterbacking in hindsight we would never > think this would happen in a million years, but we would see IPv6 on > the verge of address space depletion.  Unheard of but it can happen > as the saying goes “when you build - they will come”. > > It is true as history has taught that very important lesson. > > The answer to this real world problem is in the subject heading of > this thread. > > This would also fix the day 1 issue I mentioned allowing mix of > slaac devices with static and DHCPv6 up to /80. > > The variable slaac solution draft proposes a new  RA PIO flag that > would be used to signal longer prefixes, and would provide backwards > compatibility so that devices not supporting woud ignore the flag >  and devices on newer code supporting would use the flag.  We > definitely don’t want to impact any existing devices on the existing > 64 bit slaac boundary standard. > > Dmytro has tested the solution on Linux kernel signaling RA PIO flag > and was able to successfully test any length mask and random IID > generation both RFC 4941 privacy extension as well as stable IID RFC > 7217. > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > If everyone is in agreement with what I have stated on this thread, > I would like to ask the chairs for WG adoption as this is a WG effort. > > I would like to garner support from all 6MAN members with full > consensus to change the existing RFC 4941 /64 fixed boundary to /80 > fixed boundary. > > Kind Regards > > Gyan > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > wrote: > > I am missing something in your reasoning. > You seem to say at one point that (to paraphrase) "we can't do this > because it does not work with the existing UE software". > Any new solution where a UE delegates based on any change of any > kind > (including lengthening the prefix, shortening the prefix, or > magically > incanting new prefixes) requires that the UE be upgraded to know > what to > do with the information.  I do not see how that differentiates > any of > the solutions. (Except "don't do anything", which I think we do > not want > to take.) > > Yours, > Joel > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > On Thu, Nov 19, 2020 at 10:33 AM > > >> > wrote: > > > > > > > >      > On 19 Nov 2020, at 14:58, Gyan Mishra > > >      >> wrote: > >      > > >      > You would need a new option. It would likely be useful > for the > >     requesting router to indicate interest in the option. > Even hinting > >     at what prefix size it was expecting. > >      > Now can you explain to me again the reasons why this > approach is > >     better than using the existing DHPCv6 protocol packets? > >      > > >      >     3GPP gateway does not support DHCPv6 > > > >     3GPP gateway doesn't support new option. What's your point? > > > > > > > >      The point of the v6ops presentation and this email > thread is how to > > “extend a /64” in the 3GPP use case  in slide 1 of the deck > you compiled > > a list of options and of the two I had highlighted in red > were the > > 64share v2 Cameron’s option and the variable slaac option. > So on the > > call this morning Lorenzo shot down 64share v2 shorter prefix > option as > > even if the 3GPP architecture was updated to support longer > prefixes and > > even is the 3GPP gateway was able to send a shorter prefix > with A flag > > not set, all mobile devices per Lorenzo’s point would be > broken as they > > would not accept the shorter let’s say /56 prefix to build > the slaac 128 > > bit address.  So the bottom line is the 64share v2 won’t work > unless we > > update RFC 4291 and remove the 64 bit boundary. > > > >   So we are back to square uno - no viable solution > > > >   So now we had thrown out the longer >64 due to race to > bottom worries > > which I and others believe is Fud and as described in slide > 10 of the > > v6ops “race to the bottom slide”. > > > > So a happy medium /80 fixed boundary I came up with that I > think solves > > a lot of the issue and not just the 3GPP initial segmentation of > > downstream devices problem statement. > > > > Since we have to update RFC 4291 for 64share v2 to work > anyways to allow > > for shorter prefixes, why not instead create a new bottom at > /80 giving > > 16 bits more of prefix length and shrinking the IID down to > 48 bits. > > Doing so you would not even have to update the 3GPP > architecture as I > > don’t know if that would fly or not.  Also this solves a few > other > > problems at the same time. > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > > mainstream for operators for static addressing on router and > switch > > infrastructure and dhcpv6 subnets longer prefixes for network > > infrastructure appliance clusters, NFV/VNF virtualization and > server > > farms.  On host subnets where there is a chance of mix of > slaac hosts > > with dhcpv6  devices the prefix length is stuck at /64.  So > on these mix > > addressing host subnets we cannot do longer prefixes > following our ND > > cache hard limit mantra to prevent ND cache exhaustion issues as > > described in RFC 6164. > > > > So with the /80 new fixed boundary shifting prefix length 16 > bits longer > > and shortening the IID by 16 bits gives resolved the 3GPP > issue which > > 64share can work as is and subtending to downstream devices > will now > > work as a /64 is now equivalent to a /48 with 64k /80s.  Also > BCP-690 > > for broadband not all operators have adopted the shorter > prefix lengths > > /56 or /48 recommendations  and now that’s not an issue as > the /64 would > > now suffice. > > > >  From an operators perspective that gain allows at least for > 3GPP > > massive growth and subtending with a single /64 allows the > operators > > such as Verizon with massive subscriber base worldwide can > stay with > > current allocations and don’t have to ask for /10. > > > > As 5G gets rolled out with Enhanced VPN framework and Network > slicing > > paradigm, the demand for shorter blocks and wearable multiple > /48 will > > be our new reality. > > > > Making that 16 bit shift now to /80 making a /64 the new /48 > will give > > broadband and 3GPP subscribers a ton of space to subtending > their > > networks we would be set for the future.  Especially with IOT > the demand > > for subtending will continue to grow astronomically. > > > > Also IANA does not have to get start in allocating the other > /3 and > > other available blocks. > > > > Lots of problems being solved here with a fixed /80 new boundary. > > > > Also with the existing random IID generation schemes which we > have > > tested on Linux kernel can do longer p > refixes > using RFC 4941 privacy > > extension or RFC 7217 stable IID. > > > > Win-Win for all. > > > >     Ole > > > > -- > > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Nov 21 07:24:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112ED3A0DAE; Sat, 21 Nov 2020 07:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kFfdRqg8kwI; Sat, 21 Nov 2020 07:24:05 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 E79CF3A0DAD; Sat, 21 Nov 2020 07:24:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Cdcdc5K1Qz6G7rb; Sat, 21 Nov 2020 07:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605972244; bh=sldNWM3oDudE3RW8wvY2yC62E2m1d9goKdzlzHX01xg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LYGXw8GoL8XPHUKqaSS8xlvwIocwK8deYb6yeNujMUZyDeY4BxsdPvja2uB0Kv4eS gvoCJiHLf1+5RPQoi95Fs1JZqI1NHmOSue3h8FQud21mBFbxZYqATmBEXL41u7/sPm ljjlL+2VC+FHWD9MVpHkJCG38COU0tk+nLYEUIVY= X-Quarantine-ID: <0krvpXcaGc2h> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4Cdcdb57VPz6G7nC; Sat, 21 Nov 2020 07:24:03 -0800 (PST) To: Brian E Carpenter Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Sat, 21 Nov 2020 10:24:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 15:24:08 -0000 It seems to me that it would help to get agreement on what we want before we ask 3GPP to work on it with us. Once we have rough agreement, sure, getting the IETF 3GPP liaison manager to work with us and sned a liaison seems sensible. Yours, Joel On 11/20/2020 10:00 PM, Brian E Carpenter wrote: > Joel, > > It seems to me that it's high time to draft a liaison statement to 3GPP, > observing that: > > (1) There is a serious problem for the design and implementation of > 5G-based IPv6 "hot spots" and CEs [which is where this conversation started]; > > (2) Although the best solution is not yet obvious, defining and > standardizing it will require a joint effort by the IETF and 3GPP. > > Followed by a proposal to form an ad hoc joint design team. > > Regards > Brian Carpenter > On 21-Nov-20 14:46, Joel M. Halpern wrote: >> The nesting got me lost, so I will top post my take on the answer to the >> one quesiton I could understand. >> >> I believe you asked what I think would need to be changed to permit the >> delegation. >> As with anything, the real things that need to change are the devices in >> the network. >> >> With regard to IETF standards, what is proposed is a change to RA. >> There are several possible changes. None of them require a change to >> the IPv6 addressing archtiecture, as the addressing structure remains as >> it is. >> As for the exact mechanism, at the moment I lean towards Ole's proposal >> of using a new option in his generic option mechanism. But I am not >> wedded to that answer. >> >> And of course, to get this supported in mobile environments we will have >> to work with 3GPP and make sure there are no other hidden issues. >> That's the way we do things. Work together. >> >> Changing the prefix length to /80 is technically also possible. It does >> a lot more violence to my understanding of the architecture and software >> structures that go with it, and is a very limited and narrow solution to >> the problem. >> >> Yours, >> Joel >> >> On 11/20/2020 7:58 PM, Gyan Mishra wrote: >>> Hi Joel >>> >>> In-line >>> >>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern >> > wrote: >>> >>> Gyan, separate from Ole's comments about the difference between address >>> assignment and delegation, I have another problem following the >>> reasoning below. >>> >>> Yes, the proposal for using shorter prefixes to enable UE to perform >>> delegation will require changes to the UE. >>> >>>     Gyan> Agreed.  So that change would be to RFC 4291 64 bit boundary >>> to allow for longer prefix.  Do you agree? >>> >>> If you don’t agree what do think the change would be to allow the UE to >>> accept shorter prefix from the 3GPP gateway? >>> >>> >>> But I do not see how that is relevant to any choice we are trying to >>> make. >>> Any solution that enables UE to delegate addresses (in the sense that >>> they lack the capability now) willr equire changes to the UE. >>> >>> >>> >>> Gyan> If the UE receives a /56 via RA it could delegate /64 to >>> downstream devices.  No change needed to delegate  /64, however a >>> change is needed to accept /56 via RA. >>> >>> >>>     If 3GPP gateway supported PD - problem solved but that’s not the >>> case and that does not sound like it will ever change even with 5G. >>> >>>    Gyan> The UE needs to be able to accept shorter prefix.  That’s the >>> IPV6 specification change that requires removal of the 64 bit boundary. >>> >>> Yoru >>> proposed change to the SLAAC length if anything does more violence to >>> the software (depending upon the exact software architecture.) >>> >>> >>>    Gyan> What violence to software.  There would be more violence to >>> software if we removed the 64 bit boundary and allowed slaac to support >>> any vlsm prefix lengths. >>> >>> My /80 proposal would just shift the boundary 16 bits to /80. >>> >>> Hosts on the same subnet with two different masks would not be on-net to >>> each other as on different subnets.  The router would be configured with >>> the two subnets /64 and /80 subnet to support the two device types. >>> The solution would be a simple RA PIO flag that is set and older hosts >>> not upgraded would be backwards compatible and so would only support 64 >>> bit boundary by ignoring flag. Hosts upgraded to support would >>> understand the flag and be able to support longer mask up to /80. >>> >>> >>> >>> So I do not follow how you got to your conclusion. >>> >>> Yours, >>> Joel >>> >>> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >>> > >>> > (top posting) >>> > >>> > As I would like to clear the air as well as get to the crux of >>> the v6ops >>> > presentation development results as well as next steps for this >>> draft >>> > and the 6man variable slaac solutions draft: >>> > >>> > >>> > This thread was in light of Lorenzo kindly pointing out that >>> upgrading >>> > 3GPP is not all that needs be done for Cameron’s 64share v2 to >>> work - as >>> > all mobile devices would stop working- as slaac would not would be >>> > effectively broken. >>> > >>> > The mobile device would receive a shorter prefix let’s say /56 >>> but not >>> > know what to do with it since it’s expecting a /64. >>> > >>> > So that a major gap and the only solution is updating RFC 4291 >>> removing >>> > the 64 bit boundary allowing for shorter prefix and now as well >>> longer >>> > prefixes to work and in that respect now provide the much needed >>> parity >>> > with static and DHCPv6 which can do any prefix length. >>> > >>> > So that is a drastic change to RFC 4291.  However, in light of this >>> > development on the v6ops 109 call, my balancing act of best of both >>> > worlds and also to keep everyone happy to make this a WG effort >>> for this >>> > change by proposing in the subject heading /80 fixed boundary and >>> not a >>> > variable slaac change allowing all bits vlsm. >>> > >>> > Basically stealing 16 bits for network prefix out of the IID, still >>> > keeping the fixed boundary so longer than 80 would NOT  be allowed. >>> > >>> > A /64 would now be equivalent to a /48 with now 64k /80’s. >>> > >>> > This /80 would keep the operators and law enforcement happy as >>> now 16 >>> > bits less helps traceability but is still long enough for 48 bits of >>> > privacy to IP correlation by attackers. >>> > >>> > This /80 would be a nice optimal balance as it would keep wired >>> > broadband and mobile handset customers happy respecting their >>> privacy as >>> > the 16 bits less of heuristics is minimal change that will impact IP >>> > correlation by attackers. >>> > >>> > The IID as it’s less than the current 64 bit cannot use MAC based >>> EUI64 >>> > IID, which is not a problem as Mac based IID is not recommended >>> as most >>> > all manufacturers use RFC 4941 and I believe Linux flavors some use >>> > stable IID RFC 7217. >>> > >>> > So now the 48 bit IID would require a random IID generation >>> schema so >>> > can use either RFC 4941 privacy extension or RFC 7217 stable IID to >>> > generate the 48 bit IID. >>> > >>> > 3GPP subtending would now work issue mentioned in the problem >>> statement >>> > draft without even having to use 64share as now longer prefixes >>> up to >>> > /80 would be supported allowing for further segmentation of >>> downstream >>> > devices. >>> > >>> > This also would help wired broadband and soon fixed 5G broadband >>> > proliferation where operators in light of BCP RIPE-690, are sill >>> > allocation via BNG gateways a /64, now operators  can stay as-is, >>> as the >>> > /64 would now be allowed to be further segmented supporting 64k >>> /80s, >>> > way more then enough for SOHO. >>> > >>> > This would allow 64share if used by 3GPP operators to work and >>> would not >>> > require the 3GPP specification to be updated.  We don’t know even >>> if the >>> > 3GPP architecture specification can be updated to support shorter >>> > prefixes and if the 3GPP consortium of operators would agree to >>> it.  So >>> > that is all theoretical of that change is possible. >>> > >>> > As with 5G with Enhanced VPN framework SR steering of high priority >>> > traffic, traffic isolation and Network slicing capabilities becomes >>> > mainstream and will soon be a real world reality and as fixed 5G >>> > broadband proliferation takes off and mobile 5G == the idea of a >>> > wearable /48 will really be many /48s. >>> > >>> > As this paradigm shift takes place, operators around the world >>> will be >>> > clamoring after the RIR for massive blocks, I would say less than /8 >>> > more like a /5 or /4.  If you do the math on the way high side a /10 >>> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR >>> which is >>> > tiny number with the number of large size operators worldwide. >>> > >>> > With the massive proliferation of IOT devices and just about >>> every home >>> > or office appliance on 5G, the problem now gets way exacerbated. >>> > >>> > As this evolution unfolds IANA will be scrambling to release all >>> > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 >>> > address space depletion. >>> > >>> > Playing Monday night quarterbacking in hindsight we would never >>> think >>> > this would happen in a million years, but we would see IPv6 on >>> the verge >>> > of address space depletion.  Unheard of but it can happen as the >>> saying >>> > goes “when you build - they will come”. >>> > >>> > It is true as history has taught that very important lesson. >>> > >>> > The answer to this real world problem is in the subject heading >>> of this >>> > thread. >>> > >>> > This would also fix the day 1 issue I mentioned allowing mix of >>> slaac >>> > devices with static and DHCPv6 up to /80. >>> > >>> > The variable slaac solution draft proposes a new  RA PIO flag >>> that would >>> > be used to signal longer prefixes, and would provide backwards >>> > compatibility so that devices not supporting woud ignore the flag >>>  and >>> > devices on newer code supporting would use the flag.  We definitely >>> > don’t want to impact any existing devices on the existing 64 bit >>> slaac >>> > boundary standard. >>> > >>> > Dmytro has tested the solution on Linux kernel signaling RA PIO >>> flag and >>> > was able to successfully test any length mask and random IID >>> generation >>> > both RFC 4941 privacy extension as well as stable IID RFC 7217. >>> > >>> > >>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >>> >>> > >>> >> > >>> > >>> > If everyone is in agreement with what I have stated on this >>> thread, I >>> > would like to ask the chairs for WG adoption as this is a WG effort. >>> > >>> > I would like to garner support from all 6MAN members with full >>> consensus >>> > to change the existing RFC 4941 /64 fixed boundary to /80 fixed >>> boundary. >>> > >>> > Kind Regards >>> > >>> > Gyan >>> > >>> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >>> >>> > >> wrote: >>> > >>> >     I am missing something in your reasoning. >>> >     You seem to say at one point that (to paraphrase) "we can't >>> do this >>> >     because it does not work with the existing UE software". >>> >     Any new solution where a UE delegates based on any change of >>> any kind >>> >     (including lengthening the prefix, shortening the prefix, or >>> magically >>> >     incanting new prefixes) requires that the UE be upgraded to know >>> >     what to >>> >     do with the information.  I do not see how that >>> differentiates any of >>> >     the solutions. (Except "don't do anything", which I think we >>> do not >>> >     want >>> >     to take.) >>> > >>> >     Yours, >>> >     Joel >>> > >>> >     On 11/19/2020 5:03 PM, Gyan Mishra wrote: >>> >      > >>> >      > >>> >      > On Thu, Nov 19, 2020 at 10:33 AM >> >>> >     > >>> >      > >>> >>> wrote: >>> >      > >>> >      > >>> >      > >>> >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra >>> >      >>> > >>> >      >     >> >>> >     >> >>> wrote: >>> >      >      > >>> >      >      > You would need a new option. It would likely be >>> useful for the >>> >      >     requesting router to indicate interest in the option. Even >>> >     hinting >>> >      >     at what prefix size it was expecting. >>> >      >      > Now can you explain to me again the reasons why this >>> >     approach is >>> >      >     better than using the existing DHPCv6 protocol packets? >>> >      >      > >>> >      >      >     3GPP gateway does not support DHCPv6 >>> >      > >>> >      >     3GPP gateway doesn't support new option. What's your >>> point? >>> >      > >>> >      > >>> >      > >>> >      >      The point of the v6ops presentation and this email >>> thread is >>> >     how to >>> >      > “extend a /64” in the 3GPP use case  in slide 1 of the >>> deck you >>> >     compiled >>> >      > a list of options and of the two I had highlighted in red >>> were the >>> >      > 64share v2 Cameron’s option and the variable slaac >>> option.  So on >>> >     the >>> >      > call this morning Lorenzo shot down 64share v2 shorter prefix >>> >     option as >>> >      > even if the 3GPP architecture was updated to support longer >>> >     prefixes and >>> >      > even is the 3GPP gateway was able to send a shorter prefix >>> with A >>> >     flag >>> >      > not set, all mobile devices per Lorenzo’s point would be >>> broken >>> >     as they >>> >      > would not accept the shorter let’s say /56 prefix to build the >>> >     slaac 128 >>> >      > bit address.  So the bottom line is the 64share v2 won’t work >>> >     unless we >>> >      > update RFC 4291 and remove the 64 bit boundary. >>> >      > >>> >      >   So we are back to square uno - no viable solution >>> >      > >>> >      >   So now we had thrown out the longer >64 due to race to >>> bottom >>> >     worries >>> >      > which I and others believe is Fud and as described in >>> slide 10 of >>> >     the >>> >      > v6ops “race to the bottom slide”. >>> >      > >>> >      > So a happy medium /80 fixed boundary I came up with that I >>> think >>> >     solves >>> >      > a lot of the issue and not just the 3GPP initial >>> segmentation of >>> >      > downstream devices problem statement. >>> >      > >>> >      > Since we have to update RFC 4291 for 64share v2 to work >>> anyways >>> >     to allow >>> >      > for shorter prefixes, why not instead create a new bottom >>> at /80 >>> >     giving >>> >      > 16 bits more of prefix length and shrinking the IID down >>> to 48 bits. >>> >      > Doing so you would not even have to update the 3GPP >>> architecture >>> >     as I >>> >      > don’t know if that would fly or not.  Also this solves a >>> few other >>> >      > problems at the same time. >>> >      > >>> >      > >>> >      > As I mentioned in the v6ops deck presented that vlsm 0 to >>> 128 is >>> >      > mainstream for operators for static addressing on router >>> and switch >>> >      > infrastructure and dhcpv6 subnets longer prefixes for network >>> >      > infrastructure appliance clusters, NFV/VNF virtualization >>> and server >>> >      > farms.  On host subnets where there is a chance of mix of >>> slaac >>> >     hosts >>> >      > with dhcpv6  devices the prefix length is stuck at /64.  So on >>> >     these mix >>> >      > addressing host subnets we cannot do longer prefixes following >>> >     our ND >>> >      > cache hard limit mantra to prevent ND cache exhaustion >>> issues as >>> >      > described in RFC 6164. >>> >      > >>> >      > So with the /80 new fixed boundary shifting prefix length >>> 16 bits >>> >     longer >>> >      > and shortening the IID by 16 bits gives resolved the 3GPP >>> issue >>> >     which >>> >      > 64share can work as is and subtending to downstream >>> devices will now >>> >      > work as a /64 is now equivalent to a /48 with 64k /80s.  Also >>> >     BCP-690 >>> >      > for broadband not all operators have adopted the shorter >>> prefix >>> >     lengths >>> >      > /56 or /48 recommendations  and now that’s not an issue as the >>> >     /64 would >>> >      > now suffice. >>> >      > >>> >      >  From an operators perspective that gain allows at least >>> for 3GPP >>> >      > massive growth and subtending with a single /64 allows the >>> operators >>> >      > such as Verizon with massive subscriber base worldwide can >>> stay with >>> >      > current allocations and don’t have to ask >>> >>> for /10. >>> >      > >>> >      > As 5G gets rolled out with Enhanced VPN framework and Network >>> >     slicing >>> >      > paradigm, the demand for shorter blocks and wearable >>> multiple /48 >>> >     will >>> >      > be our new reality. >>> >      > >>> >      > Making that 16 bit shift now to /80 making a /64 the new >>> /48 will >>> >     give >>> >      > broadband and 3GPP subscribers a ton of space to >>> subtending their >>> >      > networks we would be set for the future.  Especially with >>> IOT the >>> >     demand >>> >      > for subtending will continue to grow astronomically. >>> >      > >>> >      > Also IANA does not have to get start in allocating the >>> other /3 and >>> >      > other available blocks. >>> >      > >>> >      > Lots of problems being solved here with a fixed /80 new >>> boundary. >>> >      > >>> >      > Also with the existing random IID generation schemes which >>> we have >>> >      > tested on Linux kernel can do longer p >>> > >>>  >refixes >>> >     using RFC 4941 privacy >>> >      > extension or RFC 7217 stable IID. >>> >      > >>> >      > Win-Win for all. >>> >      > >>> >      >     Ole >>> >      > >>> >      > -- >>> >      > >>> >      > >>> >> >>> >      > >>> >      > *Gyan Mishra* >>> >      > >>> >      > /Network Solutions A//rchitect / >>> >      > >>> >      > /M 301 502-1347 >>> >      > 13101 Columbia Pike >>> >      > /Silver Spring, MD >>> >      > >>> >      > >>> >      > >>> >      > _______________________________________________ >>> >      > v6ops mailing list >>> >      > v6ops@ietf.org >>> > >>> >      > https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >     >> > >>> >      > >>> > >>> > -- >>> > >>> > > >>> > >>> > *Gyan Mishra* >>> > >>> > /Network Solutions A//rchitect / >>> > >>> > /M 301 502-1347 >>> > 13101 Columbia Pike >>> > /Silver Spring, MD >>> > >>> > >>> >>> -- >>> >>> >>> >>> *Gyan Mishra* >>> >>> /Network Solutions A//rchitect / >>> >>> /M 301 502-1347 >>> 13101 Columbia Pike >>> /Silver Spring, MD >>> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Sat Nov 21 07:26:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DEE3A0DBA; Sat, 21 Nov 2020 07:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkHdvv1_cK8Y; Sat, 21 Nov 2020 07:26:19 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 073343A0DC8; Sat, 21 Nov 2020 07:25:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4CdcgG5j5Qz6G9sg; Sat, 21 Nov 2020 07:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605972330; bh=g8/XvBYy83kpiTsH2yXZtk6eBISHfEhA7UeFyV3/QpM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nDj39p84FlcoGSHBwWtRSlvNQVAn6+h81/bEc0cEIZZE8OAj5xGHnoldhql9AGifz eQVzE7Ksps80LE9qNBszUz2a5uF5JjB8FTr4cMWTyaztg7ZA725BHoaqWZSDp9cHMe HsmlOCvtkYXt9guxIUQXSXmF0ge4U+xFPBdy0Rf4= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4CdcgF6Q1Dz6G9jW; Sat, 21 Nov 2020 07:25:29 -0800 (PST) To: Mark Smith Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> From: "Joel M. Halpern" Message-ID: <24b3cb7e-989f-2b99-f019-74b6d39c424b@joelhalpern.com> Date: Sat, 21 Nov 2020 10:25:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 15:26:24 -0000 As I understand it, the situation is not that 3GPP has not defined use of DHCP. But rather than operators have uniformly declined to deploy it. (3GPP has defined DHCP for 5G for fixed access. We have heard here that even that is not what the operators want.) As such, asking 3GPP why they didn't deploy it seems a bit odd. Yours, Joel On 11/20/2020 11:19 PM, Mark Smith wrote: > > > On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, > > wrote: > > Joel, > > It seems to me that it's high time to draft a liaison statement to 3GPP, > observing that: > > (1) There is a serious problem for the design and implementation of > 5G-based IPv6 "hot spots" and CEs [which is where this conversation > started]; > > > I think it is also important to find out why they haven't deployed > DHCPv6 to solve this problem. > > Don't they think DHCPv6 infrastructure will scale? Is it just that they > don't know how to scale it? > > Is it a vendor / mobile operator / handset developer DHCPv6 > capability chicken-and-egg problem? > > Is there an overriding business or industry reason? > > The mobile industry has been resistant to tethering over the years, and > probably only came to begrudgingly accept it because they couldn't > prevent phone vendors from implementing Wifi and NAT, and couldn't very > effectively stop their customers from using that capability (One trick > I've heard of to prevent tethering working was to check if an IPv4 > packet's TTL value was 64 when it arrived at the network, meaning it > originated from the directly attached handset. Packets from tethered > devices had a TTL of 63 so were dropped. Of course, you could set the > default TTL on a tethered PC to 65 to get around that.) > > I guess there might be a fairly strong mindset that there must be a fee > per device attached to the network in addition to a fee for network > utilisation. Providing multiple /64s would be formally acknowledging > that multiple devices can be attached and a fee per device isn't and > can't ever be charged, counter to the mindset. > > Regards, > Mark. > > > (2) Although the best solution is not yet obvious, defining and > standardizing it will require a joint effort by the IETF and 3GPP. > > Followed by a proposal to form an ad hoc joint design team. > > Regards >    Brian Carpenter > On 21-Nov-20 14:46, Joel M. Halpern wrote: > > The nesting got me lost, so I will top post my take on the answer > to the > > one quesiton I could understand. > > > > I believe you asked what I think would need to be changed to > permit the > > delegation. > > As with anything, the real things that need to change are the > devices in > > the network. > > > > With regard to IETF standards, what is proposed is a change to RA. > > There are several possible changes.  None of them require a > change to > > the IPv6 addressing archtiecture, as the addressing structure > remains as > > it is. > > As for the exact mechanism, at the moment I lean towards Ole's > proposal > > of using a new option in his generic option mechanism.  But I am not > > wedded to that answer. > > > > And of course, to get this supported in mobile environments we > will have > > to work with 3GPP and make sure there are no other hidden issues. > > That's the way we do things.  Work together. > > > > Changing the prefix length to /80 is technically also possible. > It does > > a lot more violence to my understanding of the architecture and > software > > structures that go with it, and is a very limited and narrow > solution to > > the problem. > > > > Yours, > > Joel > > > > On 11/20/2020 7:58 PM, Gyan Mishra wrote: > >> Hi Joel > >> > >> In-line > >> > >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern > > >> >> wrote: > >> > >>     Gyan, separate from Ole's comments about the difference > between address > >>     assignment and delegation, I have another problem following the > >>     reasoning below. > >> > >>     Yes, the proposal for using shorter prefixes to enable UE to > perform > >>     delegation will require changes to the UE. > >> > >>      Gyan> Agreed.  So that change would be to RFC 4291 64 bit > boundary > >> to allow for longer prefix.  Do you agree? > >> > >> If you don’t agree what do think the change would be to allow > the UE to > >> accept shorter prefix from the 3GPP gateway? > >> > >> > >>     But I do not see how that is relevant to any choice we are > trying to > >>     make. > >>     Any solution that enables UE to delegate addresses (in the > sense that > >>     they lack the capability now) willr equire changes to the UE. > >> > >> > >> > >>     Gyan> If the UE receives a /56 via RA it could delegate /64 to > >>     downstream devices.  No change needed to delegate  /64, > however a > >>     change is needed to accept /56 via RA. > >> > >> > >>      If 3GPP gateway supported PD - problem solved but that’s > not the > >> case and that does not sound like it will ever change even with 5G. > >> > >>     Gyan> The UE needs to be able to accept shorter prefix. > That’s the > >> IPV6 specification change that requires removal of the 64 bit > boundary. > >> > >>     Yoru > >>     proposed change to the SLAAC length if anything does more > violence to > >>     the software (depending upon the exact software architecture.) > >> > >> > >>     Gyan> What violence to software.  There would be more > violence to > >> software if we removed the 64 bit boundary and allowed slaac to > support > >> any vlsm prefix lengths. > >> > >> My /80 proposal would just shift the boundary 16 bits to /80. > >> > >> Hosts on the same subnet with two different masks would not be > on-net to > >> each other as on different subnets.  The router would be > configured with > >> the two subnets /64 and /80 subnet to support the two device types. > >> The solution would be a simple RA PIO flag that is set and older > hosts > >> not upgraded would be backwards compatible and so would only > support 64 > >> bit boundary by ignoring flag. Hosts upgraded to support would > >> understand the flag and be able to support longer mask up to /80. > >> > >> > >> > >>     So I do not follow how you got to your conclusion. > >> > >>     Yours, > >>     Joel > >> > >>     On 11/20/2020 5:27 PM, Gyan Mishra wrote: > >>      > > >>      > (top posting) > >>      > > >>      > As I would like to clear the air as well as get to the > crux of > >>     the v6ops > >>      > presentation development results as well as next steps > for this > >>     draft > >>      > and the 6man variable slaac solutions draft: > >>      > > >>      > > >>      > This thread was in light of Lorenzo kindly pointing out that > >>     upgrading > >>      > 3GPP is not all that needs be done for Cameron’s 64share > v2 to > >>     work - as > >>      > all mobile devices would stop working- as slaac would not > would be > >>      > effectively broken. > >>      > > >>      > The mobile device would receive a shorter prefix let’s > say /56 > >>     but not > >>      > know what to do with it since it’s expecting a /64. > >>      > > >>      > So that a major gap and the only solution is updating RFC > 4291 > >>     removing > >>      > the 64 bit boundary allowing for shorter prefix and now > as well > >>     longer > >>      > prefixes to work and in that respect now provide the much > needed > >>     parity > >>      > with static and DHCPv6 which can do any prefix length. > >>      > > >>      > So that is a drastic change to RFC 4291.  However, in > light of this > >>      > development on the v6ops 109 call, my balancing act of > best of both > >>      > worlds and also to keep everyone happy to make this a WG > effort > >>     for this > >>      > change by proposing in the subject heading /80 fixed > boundary and > >>     not a > >>      > variable slaac change allowing all bits vlsm. > >>      > > >>      > Basically stealing 16 bits for network prefix out of the > IID, still > >>      > keeping the fixed boundary so longer than 80 would NOT >  be allowed. > >>      > > >>      > A /64 would now be equivalent to a /48 with now 64k /80’s. > >>      > > >>      > This /80 would keep the operators and law enforcement > happy as > >>     now 16 > >>      > bits less helps traceability but is still long enough for > 48 bits of > >>      > privacy to IP correlation by attackers. > >>      > > >>      > This /80 would be a nice optimal balance as it would keep > wired > >>      > broadband and mobile handset customers happy respecting their > >>     privacy as > >>      > the 16 bits less of heuristics is minimal change that > will impact IP > >>      > correlation by attackers. > >>      > > >>      > The IID as it’s less than the current 64 bit cannot use > MAC based > >>     EUI64 > >>      > IID, which is not a problem as Mac based IID is not > recommended > >>     as most > >>      > all manufacturers use RFC 4941 and I believe Linux > flavors some use > >>      > stable IID RFC 7217. > >>      > > >>      > So now the 48 bit IID would require a random IID generation > >>     schema so > >>      > can use either RFC 4941 privacy extension or RFC 7217 > stable IID to > >>      > generate the 48 bit IID. > >>      > > >>      > 3GPP subtending would now work issue mentioned in the problem > >>     statement > >>      > draft without even having to use 64share as now longer > prefixes > >>     up to > >>      > /80 would be supported allowing for further segmentation of > >>     downstream > >>      > devices. > >>      > > >>      > This also would help wired broadband and soon fixed 5G > broadband > >>      > proliferation where operators in light of BCP RIPE-690, > are sill > >>      > allocation via BNG gateways a /64, now operators  can > stay as-is, > >>     as the > >>      > /64 would now be allowed to be further segmented > supporting 64k > >>     /80s, > >>      > way more then enough for SOHO. > >>      > > >>      > This would allow 64share if used by 3GPP operators to > work and > >>     would not > >>      > require the 3GPP specification to be updated.  We don’t > know even > >>     if the > >>      > 3GPP architecture specification can be updated to support > shorter > >>      > prefixes and if the 3GPP consortium of operators would > agree to > >>     it.  So > >>      > that is all theoretical of that change is possible. > >>      > > >>      > As with 5G with Enhanced VPN framework SR steering of > high priority > >>      > traffic, traffic isolation and Network slicing > capabilities becomes > >>      > mainstream and will soon be a real world reality and as > fixed 5G > >>      > broadband proliferation takes off and mobile 5G == the > idea of a > >>      > wearable /48 will really be many /48s. > >>      > > >>      > As this paradigm shift takes place, operators around the > world > >>     will be > >>      > clamoring after the RIR for massive blocks, I would say > less than /8 > >>      > more like a /5 or /4.  If you do the math on the way high > side a /10 > >>      > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR > >>     which is > >>      > tiny number with the number of large size operators > worldwide. > >>      > > >>      > With the massive proliferation of IOT devices and just about > >>     every home > >>      > or office appliance on 5G, the problem now gets way > exacerbated. > >>      > > >>      > As this evolution unfolds IANA will be scrambling to > release all > >>      > remaining /3 as well as all unallocated blocks to subvert > RIR IPv6 > >>      > address space depletion. > >>      > > >>      > Playing Monday night quarterbacking in hindsight we would > never > >>     think > >>      > this would happen in a million years, but we would see > IPv6 on > >>     the verge > >>      > of address space depletion.  Unheard of but it can happen > as the > >>     saying > >>      > goes “when you build - they will come”. > >>      > > >>      > It is true as history has taught that very important lesson. > >>      > > >>      > The answer to this real world problem is in the subject > heading > >>     of this > >>      > thread. > >>      > > >>      > This would also fix the day 1 issue I mentioned allowing > mix of > >>     slaac > >>      > devices with static and DHCPv6 up to /80. > >>      > > >>      > The variable slaac solution draft proposes a new  RA PIO flag > >>     that would > >>      > be used to signal longer prefixes, and would provide > backwards > >>      > compatibility so that devices not supporting woud ignore > the flag > >>       and > >>      > devices on newer code supporting would use the flag.  We > definitely > >>      > don’t want to impact any existing devices on the existing > 64 bit > >>     slaac > >>      > boundary standard. > >>      > > >>      > Dmytro has tested the solution on Linux kernel signaling > RA PIO > >>     flag and > >>      > was able to successfully test any length mask and random IID > >>     generation > >>      > both RFC 4941 privacy extension as well as stable IID RFC > 7217. > >>      > > >>      > > >> > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > >> >  > > >>      > > >> >   > >> >  >> > >>      > > >>      > If everyone is in agreement with what I have stated on this > >>     thread, I > >>      > would like to ask the chairs for WG adoption as this is a > WG effort. > >>      > > >>      > I would like to garner support from all 6MAN members with > full > >>     consensus > >>      > to change the existing RFC 4941 /64 fixed boundary to /80 > fixed > >>     boundary. > >>      > > >>      > Kind Regards > >>      > > >>      > Gyan > >>      > > >>      > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > >>      > > > >>      > > >>> wrote: > >>      > > >>      >     I am missing something in your reasoning. > >>      >     You seem to say at one point that (to paraphrase) "we > can't > >>     do this > >>      >     because it does not work with the existing UE software". > >>      >     Any new solution where a UE delegates based on any > change of > >>     any kind > >>      >     (including lengthening the prefix, shortening the > prefix, or > >>     magically > >>      >     incanting new prefixes) requires that the UE be > upgraded to know > >>      >     what to > >>      >     do with the information.  I do not see how that > >>     differentiates any of > >>      >     the solutions. (Except "don't do anything", which I > think we > >>     do not > >>      >     want > >>      >     to take.) > >>      > > >>      >     Yours, > >>      >     Joel > >>      > > >>      >     On 11/19/2020 5:03 PM, Gyan Mishra wrote: > >>      >      > > >>      >      > > >>      >      > On Thu, Nov 19, 2020 at 10:33 AM > > >>     > > >>      >      >> > >>      >      > > > >>      > >>>> wrote: > >>      >      > > >>      >      > > >>      >      > > >>      >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra > >>      >      > > > >>      > >> > >>      >      >      > >>     > > >>      >      > >>      >>>> wrote: > >>      >      >      > > >>      >      >      > You would need a new option. It would likely be > >>     useful for the > >>      >      >     requesting router to indicate interest in the > option. Even > >>      >     hinting > >>      >      >     at what prefix size it was expecting. > >>      >      >      > Now can you explain to me again the reasons > why this > >>      >     approach is > >>      >      >     better than using the existing DHPCv6 protocol > packets? > >>      >      >      > > >>      >      >      >     3GPP gateway does not support DHCPv6 > >>      >      > > >>      >      >     3GPP gateway doesn't support new option. > What's your > >>     point? > >>      >      > > >>      >      > > >>      >      > > >>      >      >      The point of the v6ops presentation and this > email > >>     thread is > >>      >     how to > >>      >      > “extend a /64” in the 3GPP use case  in slide 1 of the > >>     deck you > >>      >     compiled > >>      >      > a list of options and of the two I had highlighted > in red > >>     were the > >>      >      > 64share v2 Cameron’s option and the variable slaac > >>     option.  So on > >>      >     the > >>      >      > call this morning Lorenzo shot down 64share v2 > shorter prefix > >>      >     option as > >>      >      > even if the 3GPP architecture was updated to > support longer > >>      >     prefixes and > >>      >      > even is the 3GPP gateway was able to send a > shorter prefix > >>     with A > >>      >     flag > >>      >      > not set, all mobile devices per Lorenzo’s point > would be > >>     broken > >>      >     as they > >>      >      > would not accept the shorter let’s say /56 prefix > to build the > >>      >     slaac 128 > >>      >      > bit address.  So the bottom line is the 64share v2 > won’t work > >>      >     unless we > >>      >      > update RFC 4291 and remove the 64 bit boundary. > >>      >      > > >>      >      >   So we are back to square uno - no viable solution > >>      >      > > >>      >      >   So now we had thrown out the longer >64 due to > race to > >>     bottom > >>      >     worries > >>      >      > which I and others believe is Fud and as described in > >>     slide 10 of > >>      >     the > >>      >      > v6ops “race to the bottom slide”. > >>      >      > > >>      >      > So a happy medium /80 fixed boundary I came up > with that I > >>     think > >>      >     solves > >>      >      > a lot of the issue and not just the 3GPP initial > >>     segmentation of > >>      >      > downstream devices problem statement. > >>      >      > > >>      >      > Since we have to update RFC 4291 for 64share v2 to > work > >>     anyways > >>      >     to allow > >>      >      > for shorter prefixes, why not instead create a new > bottom > >>     at /80 > >>      >     giving > >>      >      > 16 bits more of prefix length and shrinking the > IID down > >>     to 48 bits. > >>      >      > Doing so you would not even have to update the 3GPP > >>     architecture > >>      >     as I > >>      >      > don’t know if that would fly or not.  Also this > solves a > >>     few other > >>      >      > problems at the same time. > >>      >      > > >>      >      > > >>      >      > As I mentioned in the v6ops deck presented that > vlsm 0 to > >>     128 is > >>      >      > mainstream for operators for static addressing on > router > >>     and switch > >>      >      > infrastructure and dhcpv6 subnets longer prefixes > for network > >>      >      > infrastructure appliance clusters, NFV/VNF > virtualization > >>     and server > >>      >      > farms.  On host subnets where there is a chance of > mix of > >>     slaac > >>      >     hosts > >>      >      > with dhcpv6  devices the prefix length is stuck at > /64.  So on > >>      >     these mix > >>      >      > addressing host subnets we cannot do longer > prefixes following > >>      >     our ND > >>      >      > cache hard limit mantra to prevent ND cache exhaustion > >>     issues as > >>      >      > described in RFC 6164. > >>      >      > > >>      >      > So with the /80 new fixed boundary shifting prefix > length > >>     16 bits > >>      >     longer > >>      >      > and shortening the IID by 16 bits gives resolved > the 3GPP > >>     issue > >>      >     which > >>      >      > 64share can work as is and subtending to downstream > >>     devices will now > >>      >      > work as a /64 is now equivalent to a /48 with 64k > /80s.  Also > >>      >     BCP-690 > >>      >      > for broadband not all operators have adopted the > shorter > >>     prefix > >>      >     lengths > >>      >      > /56 or /48 recommendations  and now that’s not an > issue as the > >>      >     /64 would > >>      >      > now suffice. > >>      >      > > >>      >      >  From an operators perspective that gain allows at > least > >>     for 3GPP > >>      >      > massive growth and subtending with a single /64 > allows the > >>     operators > >>      >      > such as Verizon with massive subscriber base > worldwide can > >>     stay with > >>      >      > current allocations and don’t have to ask > >> >  > > >>     for /10. > >>      >      > > >>      >      > As 5G gets rolled out with Enhanced VPN framework > and Network > >>      >     slicing > >>      >      > paradigm, the demand for shorter blocks and wearable > >>     multiple /48 > >>      >     will > >>      >      > be our new reality. > >>      >      > > >>      >      > Making that 16 bit shift now to /80 making a /64 > the new > >>     /48 will > >>      >     give > >>      >      > broadband and 3GPP subscribers a ton of space to > >>     subtending their > >>      >      > networks we would be set for the future. > Especially with > >>     IOT the > >>      >     demand > >>      >      > for subtending will continue to grow astronomically. > >>      >      > > >>      >      > Also IANA does not have to get start in allocating the > >>     other /3 and > >>      >      > other available blocks. > >>      >      > > >>      >      > Lots of problems being solved here with a fixed > /80 new > >>     boundary. > >>      >      > > >>      >      > Also with the existing random IID generation > schemes which > >>     we have > >>      >      > tested on Linux kernel can do longer p > >>      > > >> >   >>refixes > >>      >     using RFC 4941 privacy > >>      >      > extension or RFC 7217 stable IID. > >>      >      > > >>      >      > Win-Win for all. > >>      >      > > >>      >      >     Ole > >>      >      > > >>      >      > -- > >>      >      > > >>      >      > > > > >>      > >>> > >>      >      > > >>      >      > *Gyan Mishra* > >>      >      > > >>      >      > /Network Solutions A//rchitect / > >>      >      > > >>      >      > /M 301 502-1347 > >>      >      > 13101 Columbia Pike > >>      >      > /Silver Spring, MD > >>      >      > > >>      >      > > >>      >      > > >>      >      > _______________________________________________ > >>      >      > v6ops mailing list > >>      >      > v6ops@ietf.org > > > >>      > >> > >>      >      > https://www.ietf.org/mailman/listinfo/v6ops > > >>      > > >>      >      > >>      >> > >>      >      > > >>      > > >>      > -- > >>      > > >>      > > >> > >>      > > >>      > *Gyan Mishra* > >>      > > >>      > /Network Solutions A//rchitect / > >>      > > >>      > /M 301 502-1347 > >>      > 13101 Columbia Pike > >>      > /Silver Spring, MD > >>      > > >>      > > >> > >> -- > >> > >> > > >> > >> *Gyan Mishra* > >> > >> /Network Solutions A//rchitect / > >> > >> /M 301 502-1347 > >> 13101 Columbia Pike > >> /Silver Spring, MD > >> > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > From nobody Sat Nov 21 14:58:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FC73A0957 for ; Sat, 21 Nov 2020 14:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yntp_1FwNAdS for ; Sat, 21 Nov 2020 14:58:44 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B963A0949 for ; Sat, 21 Nov 2020 14:58:44 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id n11so12423699ota.2 for ; Sat, 21 Nov 2020 14:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YLgM0GDiTzOdFjuUnWuuV2pfD30r9R/ALu/HDqs6EJY=; b=tWLFtrhLBS0C07vYgnIoYmZ0r6waXYYDuegzG4SmMtONWy4xl58eRvEK0qFdyI7OrE WAOSqd/kEp49hz0JWBeE/E9t2vdzmB+ky66mbaIhjTtIa0RRMDh+pAWnf+SR0Y18+Nq7 AxNq1meCDCTpSZGkRxnfnOoUtY/W6rsQfDEj8ZfESy+uBnsm7vg7iPxM/EeqqePA6LEZ 5rgqieAoqGxk3PTOzp2Wmz0e9yoDVcVy3d8wO7s3Lh2oXwUpY/CpnJQLw6n/ZVjrBzbZ zNgPVSlSrXB79XyPrBWgSadETsfaD6C/Sd5vd8JoPFBBqsR2Rwz6qSPrJdkoR7eDQ4lo U9HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YLgM0GDiTzOdFjuUnWuuV2pfD30r9R/ALu/HDqs6EJY=; b=g+uWAvynggzntWDRiXPscfWkqdIwSf38LBhbUGrw5P6AGLEEaTagfqCCc7uJUE7pP+ jIW4LigG7pPNq0WjmGXVSOAxKHLvDsbIm+whoua9WZkar69bO8HQ7i7K06AvEd5S1igU 7ZHaNhs8qAmmNu+sGe7qYgnAiD0A1UiYUroOhtzCVTs8C5nhS0RpOQ8maCa7SpgidQkR UPtktr4yd8bBM3tfFbIicE+CQUtXn9BqSYLCa5TLXDNa1ZMqqNrUjJeehePxu3wg0L20 CqHcorVGnYaiQ9huFpyjWWpwvJUw7GaAZcBh+zVz3Kcghh3XTNk1p+CEAbUjhefiRz21 gSRQ== X-Gm-Message-State: AOAM5303TLGJrVA8MK2oi7AMfoYHSK6T8ilFnkumTBwWd0lZVT2bTHXD MOuGDasZrgy832rcmAbPG6ZYvusJOaTA2wxQf0I= X-Google-Smtp-Source: ABdhPJxKG0Dh7RHQAk/hxdg8JFYl3Da7Y6IjKff8Xz7xr8L8BhoeH6Pq9ZUmKd2L65PGFY1G47v+BKPRJZ7WKfyRvOg= X-Received: by 2002:a05:6830:160d:: with SMTP id g13mr7634294otr.74.1605999523756; Sat, 21 Nov 2020 14:58:43 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> In-Reply-To: From: Mark Smith Date: Sun, 22 Nov 2020 09:58:17 +1100 Message-ID: To: Alexandre Petrescu Cc: v6ops list Content-Type: multipart/alternative; boundary="0000000000001f7e5205b4a5e72b" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 22:58:48 -0000 --0000000000001f7e5205b4a5e72b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 22 Nov 2020, 00:57 Alexandre Petrescu, wrote: > > > Le 21/11/2020 =C3=A0 06:47, Mark Smith a =C3=A9crit : > > > > > > On Sat, 21 Nov 2020, 09:27 Gyan Mishra, > > wrote: > > > > > > (top posting) > > > > > > As I would like to clear the air as well as get to the crux of the > > v6ops presentation development results as well as next steps for > > this draft and the 6man variable slaac solutions draft: > > > > > > You're asserting that everybody has accepted there is a problem to be > > solved, and that everybody has accepted that the only way to solve it i= s > > to change the default 64 bit IID size. This is both premature and not a > > representation about "everybody's" opinion you can make. > > > > I haven't accepted either of those things. > > > > I'm not happy with the idea of changing away for 64 bit IIDs because I > > don't think 64 bit IIDs are the problem. Plenty of operators have given > > out /56s. > > No 3GPP operator gives out a /56 on a public deployment. > > There are some private trials on 3GPP operators with /56 and DHCPv6-PD, > but that's a private APN with dedicated SIM cards. It is not new, it is > old, and dying out, because it is not working, because no smartphone > could ever use it, because modems dont implement it. > *Why* don't they implement it? 3GPP themselves put DHCPv6-PD support in 3GPP Release-10, more than 6 years ago. They themselves have said it is possible. We can't just accept "it hasn't been done" as a valid reason to develop a new alternative technical solution. That new solution may also not be used if the reasons the old solution hasn't been used aren't technical. There may be business / business model reasons, or education reasons, or vendors not implementing it because customers aren't asking for it. A new alternative technical solution will not solve any of these other causes. An actual solution to the actual reason may be much cheaper than developing and deploying a new technical solution. You need to ensure you properly understand exactly what problem you're trying to solve before you then try to solve it. That's the only way to ensure you're solving the actual problem, not some assumed and possibly non-existent problem. > > I'm working at my second one. It is not impossible. > > Mark, is that work in a 3GPP network on a 3G/4G link? > No. However that doesn't prove it is impossible in a 3GPP network - and the 3GPP people don't believe that either. > Alex > > > > > Many things below are incorrect, uninformed, or quite frankly > > ridiculous. Some read like you've let your imagination go wild and then > > have just assumed because you can imagine it it will then inevitably > > happen in the near future. > > > > For example, DHCPv6 does not provide a prefix length to hosts. Your > > proposal does not make SLAAC "consistent' with what DHCPv6 does, becaus= e > > DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA > > in the DHCPv6 RFC). > > > > "the idea of a wearable /48 will really be many /48s"? Do you really > > think we're going to have more devices on our person that we'll need > > more than 65 536 /64 subnets (a single /48) to number them? That sounds > > like science fiction to me for at least the next 200 years or more. > > > > IPv6 isn't and isn't required to be the final and only Internet protoco= l > > for the remainder of humanity, so we don't have to try to accommodate > > every conceivable idea that somebody can come up with that might cause > > the 128 bit address space to be too small. > > > > > > This thread was in light of Lorenzo kindly pointing out that > > upgrading 3GPP is not all that needs be done for Cameron=E2=80=99s = 64share > > v2 to work - as all mobile devices would stop working- as slaac > > would not would be effectively broken. > > > > The mobile device would receive a shorter prefix let=E2=80=99s say = /56 but > > not know what to do with it since it=E2=80=99s expecting a /64. > > > > So that a major gap and the only solution is updating RFC 4291 > > removing the 64 bit boundary allowing for shorter prefix and now as > > well longer prefixes to work and in that respect now provide the > > much needed parity with static and DHCPv6 which can do any prefix > > length. > > > > So that is a drastic change to RFC 4291. However, in light of this > > development on the v6ops 109 call, my balancing act of best of both > > worlds and also to keep everyone happy to make this a WG effort for > > this change by proposing in the subject heading /80 fixed boundary > > and not a variable slaac change allowing all bits vlsm. > > > > Basically stealing 16 bits for network prefix out of the IID, still > > keeping the fixed boundary so longer than 80 would NOT be allowed. > > > > A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s. > > > > This /80 would keep the operators and law enforcement happy as now > > 16 bits less helps traceability but is still long enough for 48 bit= s > > of privacy to IP correlation by attackers. > > > > This /80 would be a nice optimal balance as it would keep wired > > broadband and mobile handset customers happy respecting their > > privacy as the 16 bits less of heuristics is minimal change that > > will impact IP correlation by attackers. > > > > The IID as it=E2=80=99s less than the current 64 bit cannot use MAC= based > > EUI64 IID, which is not a problem as Mac based IID is not > > recommended as most all manufacturers use RFC 4941 and I believe > > Linux flavors some use stable IID RFC 7217. > > > > So now the 48 bit IID would require a random IID generation schema > > so can use either RFC 4941 privacy extension or RFC 7217 stable IID > > to generate the 48 bit IID. > > > > 3GPP subtending would now work issue mentioned in the problem > > statement draft without even having to use 64share as now longer > > prefixes up to /80 would be supported allowing for further > > segmentation of downstream devices. > > > > This also would help wired broadband and soon fixed 5G broadband > > proliferation where operators in light of BCP RIPE-690, are sill > > allocation via BNG gateways a /64, now operators can stay as-is, a= s > > the /64 would now be allowed to be further segmented supporting 64k > > /80s, way more then enough for SOHO. > > > > This would allow 64share if used by 3GPP operators to work and woul= d > > not require the 3GPP specification to be updated. We don=E2=80=99t= know > > even if the 3GPP architecture specification can be updated to > > support shorter prefixes and if the 3GPP consortium of operators > > would agree to it. So that is all theoretical of that change is > > possible. > > > > As with 5G with Enhanced VPN framework SR steering of high priority > > traffic, traffic isolation and Network slicing capabilities becomes > > mainstream and will soon be a real world reality and as fixed 5G > > broadband proliferation takes off and mobile 5G =3D=3D the idea of = a > > wearable /48 will really be many /48s. > > > > As this paradigm shift takes place, operators around the world will > > be clamoring after the RIR for massive blocks, I would say less tha= n > > /8 more like a /5 or /4. If you do the math on the way high side a > > /10 yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR > > which is tiny number with the number of large size operators > worldwide. > > > > With the massive proliferation of IOT devices and just about every > > home or office appliance on 5G, the problem now gets way exacerbate= d. > > > > As this evolution unfolds IANA will be scrambling to release all > > remaining /3 as well as all unallocated blocks to subvert RIR IPv6 > > address space depletion. > > > > Playing Monday night quarterbacking in hindsight we would never > > think this would happen in a million years, but we would see IPv6 o= n > > the verge of address space depletion. Unheard of but it can happen > > as the saying goes =E2=80=9Cwhen you build - they will come=E2=80= =9D. > > > > It is true as history has taught that very important lesson. > > > > The answer to this real world problem is in the subject heading of > > this thread. > > > > This would also fix the day 1 issue I mentioned allowing mix of > > slaac devices with static and DHCPv6 up to /80. > > > > The variable slaac solution draft proposes a new RA PIO flag that > > would be used to signal longer prefixes, and would provide backward= s > > compatibility so that devices not supporting woud ignore the flag > > and devices on newer code supporting would use the flag. We > > definitely don=E2=80=99t want to impact any existing devices on the= existing > > 64 bit slaac boundary standard. > > > > Dmytro has tested the solution on Linux kernel signaling RA PIO fla= g > > and was able to successfully test any length mask and random IID > > generation both RFC 4941 privacy extension as well as stable IID RF= C > > 7217. > > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > > > If everyone is in agreement with what I have stated on this thread, > > I would like to ask the chairs for WG adoption as this is a WG > effort. > > > > I would like to garner support from all 6MAN members with full > > consensus to change the existing RFC 4941 /64 fixed boundary to /80 > > fixed boundary. > > > > Kind Regards > > > > Gyan > > > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > > wrote: > > > > I am missing something in your reasoning. > > You seem to say at one point that (to paraphrase) "we can't do > this > > because it does not work with the existing UE software". > > Any new solution where a UE delegates based on any change of an= y > > kind > > (including lengthening the prefix, shortening the prefix, or > > magically > > incanting new prefixes) requires that the UE be upgraded to kno= w > > what to > > do with the information. I do not see how that differentiates > > any of > > the solutions. (Except "don't do anything", which I think we do > > not want > > to take.) > > > > Yours, > > Joel > > > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > > > > On Thu, Nov 19, 2020 at 10:33 AM > > > > >> > > wrote: > > > > > > > > > > > > > On 19 Nov 2020, at 14:58, Gyan Mishra > > > > > > >> wrote: > > > > > > > > You would need a new option. It would likely be usefu= l > > for the > > > requesting router to indicate interest in the option. > > Even hinting > > > at what prefix size it was expecting. > > > > Now can you explain to me again the reasons why this > > approach is > > > better than using the existing DHPCv6 protocol packets? > > > > > > > > 3GPP gateway does not support DHCPv6 > > > > > > 3GPP gateway doesn't support new option. What's your > point? > > > > > > > > > > > > The point of the v6ops presentation and this email > > thread is how to > > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slid= e 1 of the deck > > you compiled > > > a list of options and of the two I had highlighted in red > > were the > > > 64share v2 Cameron=E2=80=99s option and the variable slaac o= ption. > > So on the > > > call this morning Lorenzo shot down 64share v2 shorter prefi= x > > option as > > > even if the 3GPP architecture was updated to support longer > > prefixes and > > > even is the 3GPP gateway was able to send a shorter prefix > > with A flag > > > not set, all mobile devices per Lorenzo=E2=80=99s point woul= d be > > broken as they > > > would not accept the shorter let=E2=80=99s say /56 prefix to= build > > the slaac 128 > > > bit address. So the bottom line is the 64share v2 won=E2=80= =99t work > > unless we > > > update RFC 4291 and remove the 64 bit boundary. > > > > > > So we are back to square uno - no viable solution > > > > > > So now we had thrown out the longer >64 due to race to > > bottom worries > > > which I and others believe is Fud and as described in slide > > 10 of the > > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. > > > > > > So a happy medium /80 fixed boundary I came up with that I > > think solves > > > a lot of the issue and not just the 3GPP initial segmentatio= n > of > > > downstream devices problem statement. > > > > > > Since we have to update RFC 4291 for 64share v2 to work > > anyways to allow > > > for shorter prefixes, why not instead create a new bottom at > > /80 giving > > > 16 bits more of prefix length and shrinking the IID down to > > 48 bits. > > > Doing so you would not even have to update the 3GPP > > architecture as I > > > don=E2=80=99t know if that would fly or not. Also this solv= es a few > > other > > > problems at the same time. > > > > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to 12= 8 > is > > > mainstream for operators for static addressing on router and > > switch > > > infrastructure and dhcpv6 subnets longer prefixes for networ= k > > > infrastructure appliance clusters, NFV/VNF virtualization an= d > > server > > > farms. On host subnets where there is a chance of mix of > > slaac hosts > > > with dhcpv6 devices the prefix length is stuck at /64. So > > on these mix > > > addressing host subnets we cannot do longer prefixes > > following our ND > > > cache hard limit mantra to prevent ND cache exhaustion issue= s > as > > > described in RFC 6164. > > > > > > So with the /80 new fixed boundary shifting prefix length 16 > > bits longer > > > and shortening the IID by 16 bits gives resolved the 3GPP > > issue which > > > 64share can work as is and subtending to downstream devices > > will now > > > work as a /64 is now equivalent to a /48 with 64k /80s. Als= o > > BCP-690 > > > for broadband not all operators have adopted the shorter > > prefix lengths > > > /56 or /48 recommendations and now that=E2=80=99s not an is= sue as > > the /64 would > > > now suffice. > > > > > > From an operators perspective that gain allows at least for > > 3GPP > > > massive growth and subtending with a single /64 allows the > > operators > > > such as Verizon with massive subscriber base worldwide can > > stay with > > > current allocations and don=E2=80=99t have to ask for /10. > > > > > > As 5G gets rolled out with Enhanced VPN framework and Networ= k > > slicing > > > paradigm, the demand for shorter blocks and wearable multipl= e > > /48 will > > > be our new reality. > > > > > > Making that 16 bit shift now to /80 making a /64 the new /48 > > will give > > > broadband and 3GPP subscribers a ton of space to subtending > > their > > > networks we would be set for the future. Especially with IO= T > > the demand > > > for subtending will continue to grow astronomically. > > > > > > Also IANA does not have to get start in allocating the other > > /3 and > > > other available blocks. > > > > > > Lots of problems being solved here with a fixed /80 new > boundary. > > > > > > Also with the existing random IID generation schemes which w= e > > have > > > tested on Linux kernel can do longer p > > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > >refixes > > using RFC 4941 privacy > > > extension or RFC 7217 stable IID. > > > > > > Win-Win for all. > > > > > > Ole > > > > > > -- > > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------= - > > > > > > _______________________________________________ > > 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 > --0000000000001f7e5205b4a5e72b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, 22 Nov 2020, 00:57 Alexandre = Petrescu, <alexandre.petrescu@gmail.com> wrote:


Le 21/11/2020 =C3=A0 06:47, Mark Smith a =C3=A9crit=C2=A0:
>
>
> On Sat, 21 Nov 2020, 09:27 Gyan Mishra, <hayabusagsm@gmail.com
> <mailto:hayabusagsm@gmail.com>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0(top posting)
>
>
>=C2=A0 =C2=A0 =C2=A0As I would like to clear the air as well as get to = the crux of the
>=C2=A0 =C2=A0 =C2=A0v6ops presentation development results as well as n= ext steps for
>=C2=A0 =C2=A0 =C2=A0this draft and the 6man variable slaac solutions dr= aft:
>
>
> You're asserting that everybody has accepted there is a problem to= be
> solved, and that everybody has accepted that the only way to solve it = is
> to change the default 64 bit IID size. This is both premature and not = a
> representation about "everybody's" opinion you can make.=
>
> I haven't accepted either of those things.
>
> I'm not happy with the idea of changing away for 64 bit IIDs becau= se I
> don't think 64 bit IIDs are the problem. Plenty of operators have = given
> out /56s.

No 3GPP operator gives out a /56 on a public deployment.

There are some private trials on 3GPP operators with /56 and DHCPv6-PD, but that's a private APN with dedicated SIM cards.=C2=A0 It is not new,= it is
old, and dying out, because it is not working, because no smartphone
could ever use it, because modems dont implement it.
=

*Why* don't they im= plement it?

3GPP themsel= ves put DHCPv6-PD support in=C2=A03GPP Release-10, more than 6 years ago. T= hey themselves have said it is possible.

<= div>We can't just accept "it hasn't been done" as a valid= reason to develop a new alternative technical solution. That new solution = may also not be used if the reasons the old solution hasn't been used a= ren't technical.

There may be business / busin= ess model reasons, or education reasons, or vendors not implementing it bec= ause customers aren't asking for it. A new alternative=C2=A0technical s= olution will not solve any of these other causes. An actual solution=C2=A0t= o the actual reason may be much cheaper than developing and deploying a new= technical solution.

You need to ensure you proper= ly understand exactly what problem you're trying to solve before you th= en try to solve it. That's the only way to ensure you're solving th= e actual problem, not some assumed and possibly non-existent problem.
=


=

> I'm working at my second one. It is not impossible.

Mark, is that work in a 3GPP network on a 3G/4G link?
=
No. However that doesn't prove it is impossible in a 3GP= P network - and the 3GPP people don't believe that either.


Alex

>
> Many things below are incorrect, uninformed, or quite frankly
> ridiculous. Some read like you've let your imagination go wild and= then
> have just assumed because you can imagine it it will then inevitably <= br> > happen in the near future.
>
> For example, DHCPv6 does not provide a prefix length to hosts. Your > proposal does not make SLAAC "consistent' with what DHCPv6 do= es, because
> DHCPv6 doesn't work the way you think it does (look up IA_NA and I= A_TA
> in the DHCPv6 RFC).
>
> "the idea of a wearable /48 will really be many /48s"? Do yo= u really
> think we're going to have more devices on our person that we'l= l need
> more than 65 536 /64 subnets (a single /48) to number them? That sound= s
> like science fiction to me for at least the next 200 years or more. >
> IPv6 isn't and isn't required to be the final and only Interne= t protocol
> for the remainder of humanity, so we don't have to try to accommod= ate
> every conceivable idea that somebody can come up with that might cause=
> the 128 bit address space to be too small.
>
>
>=C2=A0 =C2=A0 =C2=A0This thread was in light of Lorenzo kindly pointing= out that
>=C2=A0 =C2=A0 =C2=A0upgrading 3GPP is not all that needs be done for Ca= meron=E2=80=99s 64share
>=C2=A0 =C2=A0 =C2=A0v2 to work - as all mobile devices would stop worki= ng- as slaac
>=C2=A0 =C2=A0 =C2=A0would not would be effectively broken.
>
>=C2=A0 =C2=A0 =C2=A0The mobile device would receive a shorter prefix le= t=E2=80=99s say /56 but
>=C2=A0 =C2=A0 =C2=A0not know what to do with it since it=E2=80=99s expe= cting a /64.
>
>=C2=A0 =C2=A0 =C2=A0So that a major gap and the only solution is updati= ng RFC 4291
>=C2=A0 =C2=A0 =C2=A0removing the 64 bit boundary allowing for shorter p= refix and now as
>=C2=A0 =C2=A0 =C2=A0well longer prefixes to work and in that respect no= w provide the
>=C2=A0 =C2=A0 =C2=A0much needed parity with static and DHCPv6 which can= do any prefix
>=C2=A0 =C2=A0 =C2=A0length.
>
>=C2=A0 =C2=A0 =C2=A0So that is a drastic change to RFC 4291.=C2=A0 Howe= ver, in light of this
>=C2=A0 =C2=A0 =C2=A0development on the v6ops 109 call, my balancing act= of best of both
>=C2=A0 =C2=A0 =C2=A0worlds and also to keep everyone happy to make this= a WG effort for
>=C2=A0 =C2=A0 =C2=A0this change by proposing in the subject heading /80= fixed boundary
>=C2=A0 =C2=A0 =C2=A0and not a variable slaac change allowing all bits v= lsm.
>
>=C2=A0 =C2=A0 =C2=A0Basically stealing 16 bits for network prefix out o= f the IID, still
>=C2=A0 =C2=A0 =C2=A0keeping the fixed boundary so longer than 80 would = NOT =C2=A0be allowed.
>
>=C2=A0 =C2=A0 =C2=A0A /64 would now be equivalent to a /48 with now 64k= /80=E2=80=99s.
>
>=C2=A0 =C2=A0 =C2=A0This /80 would keep the operators and law enforceme= nt happy as now
>=C2=A0 =C2=A0 =C2=A016 bits less helps traceability but is still long e= nough for 48 bits
>=C2=A0 =C2=A0 =C2=A0of privacy to IP correlation by attackers.
>
>=C2=A0 =C2=A0 =C2=A0This /80 would be a nice optimal balance as it woul= d keep wired
>=C2=A0 =C2=A0 =C2=A0broadband and mobile handset customers happy respec= ting their
>=C2=A0 =C2=A0 =C2=A0privacy as the 16 bits less of heuristics is minima= l change that
>=C2=A0 =C2=A0 =C2=A0will impact IP correlation by attackers.
>
>=C2=A0 =C2=A0 =C2=A0The IID as it=E2=80=99s less than the current 64 bi= t cannot use MAC based
>=C2=A0 =C2=A0 =C2=A0EUI64 IID, which is not a problem as Mac based IID = is not
>=C2=A0 =C2=A0 =C2=A0recommended as most all manufacturers use RFC 4941 = and I believe
>=C2=A0 =C2=A0 =C2=A0Linux flavors some use stable IID RFC 7217.
>
>=C2=A0 =C2=A0 =C2=A0So now the 48 bit IID would require a random IID ge= neration schema
>=C2=A0 =C2=A0 =C2=A0so can use either RFC 4941 privacy extension or RFC= 7217 stable IID
>=C2=A0 =C2=A0 =C2=A0to generate the 48 bit IID.
>
>=C2=A0 =C2=A0 =C2=A03GPP subtending would now work issue mentioned in t= he problem
>=C2=A0 =C2=A0 =C2=A0statement draft without even having to use 64share = as now longer
>=C2=A0 =C2=A0 =C2=A0prefixes up to /80 would be supported allowing for = further
>=C2=A0 =C2=A0 =C2=A0segmentation of downstream devices.
>
>=C2=A0 =C2=A0 =C2=A0This also would help wired broadband and soon fixed= 5G broadband
>=C2=A0 =C2=A0 =C2=A0proliferation where operators in light of BCP RIPE-= 690, are sill
>=C2=A0 =C2=A0 =C2=A0allocation via BNG gateways a /64, now operators = =C2=A0can stay as-is, as
>=C2=A0 =C2=A0 =C2=A0the /64 would now be allowed to be further segmente= d supporting 64k
>=C2=A0 =C2=A0 =C2=A0/80s, way more then enough for SOHO.
>
>=C2=A0 =C2=A0 =C2=A0This would allow 64share if used by 3GPP operators = to work and would
>=C2=A0 =C2=A0 =C2=A0not require the 3GPP specification to be updated.= =C2=A0 We don=E2=80=99t know
>=C2=A0 =C2=A0 =C2=A0even if the 3GPP architecture specification can be = updated to
>=C2=A0 =C2=A0 =C2=A0support shorter prefixes and if the 3GPP consortium= of operators
>=C2=A0 =C2=A0 =C2=A0would agree to it.=C2=A0 So that is all theoretical= of that change is
>=C2=A0 =C2=A0 =C2=A0possible.
>
>=C2=A0 =C2=A0 =C2=A0As with 5G with Enhanced VPN framework SR steering = of high priority
>=C2=A0 =C2=A0 =C2=A0traffic, traffic isolation and Network slicing capa= bilities becomes
>=C2=A0 =C2=A0 =C2=A0mainstream and will soon be a real world reality an= d as fixed 5G
>=C2=A0 =C2=A0 =C2=A0broadband proliferation takes off and mobile 5G =3D= =3D the idea of a
>=C2=A0 =C2=A0 =C2=A0wearable /48 will really be many /48s.
>
>=C2=A0 =C2=A0 =C2=A0As this paradigm shift takes place, operators aroun= d the world will
>=C2=A0 =C2=A0 =C2=A0be clamoring after the RIR for massive blocks, I wo= uld say less than
>=C2=A0 =C2=A0 =C2=A0/8 more like a /5 or /4.=C2=A0 If you do the math o= n the way high side a
>=C2=A0 =C2=A0 =C2=A0/10 yields 7 bits so 128 divided by 5 RIRs yields 2= 4 ISPs per RIR
>=C2=A0 =C2=A0 =C2=A0which is tiny number with the number of large size = operators worldwide.
>
>=C2=A0 =C2=A0 =C2=A0With the massive proliferation of IOT devices and j= ust about every
>=C2=A0 =C2=A0 =C2=A0home or office appliance on 5G, the problem now get= s way exacerbated.
>
>=C2=A0 =C2=A0 =C2=A0As this evolution unfolds IANA will be scrambling t= o release all
>=C2=A0 =C2=A0 =C2=A0remaining /3 as well as all unallocated blocks to s= ubvert RIR IPv6
>=C2=A0 =C2=A0 =C2=A0address space depletion.
>
>=C2=A0 =C2=A0 =C2=A0Playing Monday night quarterbacking in hindsight we= would never
>=C2=A0 =C2=A0 =C2=A0think this would happen in a million years, but we = would see IPv6 on
>=C2=A0 =C2=A0 =C2=A0the verge of address space depletion.=C2=A0 Unheard= of but it can happen
>=C2=A0 =C2=A0 =C2=A0as the saying goes =E2=80=9Cwhen you build - they w= ill come=E2=80=9D.
>
>=C2=A0 =C2=A0 =C2=A0It is true as history has taught that very importan= t lesson.
>
>=C2=A0 =C2=A0 =C2=A0The answer to this real world problem is in the sub= ject heading of
>=C2=A0 =C2=A0 =C2=A0this thread.
>
>=C2=A0 =C2=A0 =C2=A0This would also fix the day 1 issue I mentioned all= owing mix of
>=C2=A0 =C2=A0 =C2=A0slaac devices with static and DHCPv6 up to /80.
>
>=C2=A0 =C2=A0 =C2=A0The variable slaac solution draft proposes a new = =C2=A0RA PIO flag that
>=C2=A0 =C2=A0 =C2=A0would be used to signal longer prefixes, and would = provide backwards
>=C2=A0 =C2=A0 =C2=A0compatibility so that devices not supporting woud i= gnore the flag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and devices on newer code supporting would u= se the flag.=C2=A0 We
>=C2=A0 =C2=A0 =C2=A0definitely don=E2=80=99t want to impact any existin= g devices on the existing
>=C2=A0 =C2=A0 =C2=A064 bit slaac boundary standard.
>
>=C2=A0 =C2=A0 =C2=A0Dmytro has tested the solution on Linux kernel sign= aling RA PIO flag
>=C2=A0 =C2=A0 =C2=A0and was able to successfully test any length mask a= nd random IID
>=C2=A0 =C2=A0 =C2=A0generation both RFC 4941 privacy extension as well = as stable IID RFC
>=C2=A0 =C2=A0 =C2=A07217.
>
>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>=C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/= >
>
>=C2=A0 =C2=A0 =C2=A0If everyone is in agreement with what I have stated= on this thread,
>=C2=A0 =C2=A0 =C2=A0I would like to ask the chairs for WG adoption as t= his is a WG effort.
>
>=C2=A0 =C2=A0 =C2=A0I would like to garner support from all 6MAN member= s with full
>=C2=A0 =C2=A0 =C2=A0consensus to change the existing RFC 4941 /64 fixed= boundary to /80
>=C2=A0 =C2=A0 =C2=A0fixed boundary.
>
>=C2=A0 =C2=A0 =C2=A0Kind Regards
>
>=C2=A0 =C2=A0 =C2=A0Gyan
>
>=C2=A0 =C2=A0 =C2=A0On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <= ;jmh@joelhalpern.com
>=C2=A0 =C2=A0 =C2=A0<mailto:jmh@joelhalpern.com>> wrote:<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I am missing something in your reason= ing.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0You seem to say at one point that (to= paraphrase) "we can't do this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0because it does not work with the exi= sting UE software".
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Any new solution where a UE delegates= based on any change of any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kind
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(including lengthening the prefix, sh= ortening the prefix, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0magically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0incanting new prefixes) requires that= the UE be upgraded to know
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0what to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0do with the information.=C2=A0 I do n= ot see how that differentiates
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the solutions. (Except "don'= t do anything", which I think we do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not want
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to take.)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM, Gyan Mishra wr= ote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 10:33 A= M <otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > <mailto:otroan@employees.o= rg <mailto:otroan@employees.org>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On 19 = Nov 2020, at 14:58, Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<hayabusagsm@gmail.com <= mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:<= a href=3D"mailto:hayabusagsm@gmail.com" rel=3D"noreferrer" target=3D"_blank= ">hayabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > You wo= uld need a new option. It would likely be useful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0requesting r= outer to indicate interest in the option.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Even hinting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0at what pref= ix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Now ca= n you explain to me again the reasons why this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0approach is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0better than = using the existing DHPCv6 protocol packets?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 = =C2=A0 =C2=A03GPP gateway does not support DHCPv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway= doesn't support new option. What's your point?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 The point o= f the v6ops presentation and this email
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thread is how to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend a /64=E2=80=9D = in the 3GPP use case =C2=A0in slide 1 of the deck
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0you compiled
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > a list of options and of the tw= o I had highlighted in red
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0were the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 64share v2 Cameron=E2=80=99s op= tion and the variable slaac option.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > call this morning Lorenzo shot = down 64share v2 shorter prefix
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > even if the 3GPP architecture w= as updated to support longer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prefixes and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > even is the 3GPP gateway was ab= le to send a shorter prefix
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with A flag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > not set, all mobile devices per= Lorenzo=E2=80=99s point would be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0broken as they
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > would not accept the shorter le= t=E2=80=99s say /56 prefix to build
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the slaac 128
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > bit address.=C2=A0 So the botto= m line is the 64share v2 won=E2=80=99t work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unless we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > update RFC 4291 and remove the = 64 bit boundary.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So we are back to s= quare uno - no viable solution
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So now we had throw= n out the longer >64 due to race to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bottom worries
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > which I and others believe is F= ud and as described in slide
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010 of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Crace to the bott= om slide=E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > So a happy medium /80 fixed bou= ndary I came up with that I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0think solves
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > a lot of the issue and not just= the 3GPP initial segmentation of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > downstream devices problem stat= ement.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Since we have to update RFC 429= 1 for 64share v2 to work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyways to allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > for shorter prefixes, why not i= nstead create a new bottom at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/80 giving
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 16 bits more of prefix length a= nd shrinking the IID down to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A048 bits.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Doing so you would not even hav= e to update the 3GPP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0architecture as I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t know if that woul= d fly or not.=C2=A0 Also this solves a few
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > problems at the same time.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > As I mentioned in the v6ops dec= k presented that vlsm 0 to 128 is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > mainstream for operators for st= atic addressing on router and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0switch
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > infrastructure and dhcpv6 subne= ts longer prefixes for network
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > infrastructure appliance cluste= rs, NFV/VNF virtualization and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On host subnets wh= ere there is a chance of mix of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0slaac hosts
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2=A0devices the p= refix length is stuck at /64.=C2=A0 So
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on these mix
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > addressing host subnets we cann= ot do longer prefixes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0following our ND
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > cache hard limit mantra to prev= ent ND cache exhaustion issues as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > described in RFC 6164.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > So with the /80 new fixed bound= ary shifting prefix length 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bits longer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > and shortening the IID by 16 bi= ts gives resolved the 3GPP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issue which
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 64share can work as is and subt= ending to downstream devices
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will now
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > work as a /64 is now equivalent= to a /48 with 64k /80s.=C2=A0 Also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BCP-690
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > for broadband not all operators= have adopted the shorter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prefix lengths
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > /56 or /48 recommendations =C2= =A0and now that=E2=80=99s not an issue as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the /64 would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > now suffice.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an operators perspec= tive that gain allows at least for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03GPP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > massive growth and subtending w= ith a single /64 allows the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operators
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > such as Verizon with massive su= bscriber base worldwide can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stay with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > current allocations and don=E2= =80=99t have to ask for /10.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > As 5G gets rolled out with Enha= nced VPN framework and Network
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0slicing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > paradigm, the demand for shorte= r blocks and wearable multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/48 will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > be our new reality.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Making that 16 bit shift now to= /80 making a /64 the new /48
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will give
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > broadband and 3GPP subscribers = a ton of space to subtending
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > networks we would be set for th= e future.=C2=A0 Especially with IOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the demand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > for subtending will continue to= grow astronomically.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Also IANA does not have to get = start in allocating the other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/3 and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > other available blocks.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Lots of problems being solved h= ere with a fixed /80 new boundary.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Also with the existing random I= ID generation schemes which we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > tested on Linux kernel can do l= onger p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.c= om/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&sou= rce=3Dg>refixes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > extension or RFC 7217 stable II= D.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Win-Win for all.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Ole
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > <http://www.verizon= .com/ <http://www.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect = /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > _______________________________= ________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@iet= f.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ht= tps://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http= s://www.ietf.org/mailman/listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0--
>
>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/>
>
>=C2=A0 =C2=A0 =C2=A0*Gyan Mishra*
>
>=C2=A0 =C2=A0 =C2=A0/Network Solutions A//rchitect /
>
>=C2=A0 =C2=A0 =C2=A0/M 301 502-1347
>=C2=A0 =C2=A0 =C2=A013101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0/Silver Spring, MD
>
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0ipv6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.or= g/mailman/listinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6o= ps
>

_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000001f7e5205b4a5e72b-- From nobody Sun Nov 22 06:59:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2C3A17A3; Sun, 22 Nov 2020 06:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-1QPScJTiwz; Sun, 22 Nov 2020 06:59:44 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 899B73A17A2; Sun, 22 Nov 2020 06:59:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AMExedR032392; Sun, 22 Nov 2020 09:59:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606057181; bh=GMJq8DaA4B4gXtc5THFXdkh4zkQGZ8TtHmAbqRf6JY8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qsvAR4NpER97Epmvf71tuCX/OsOsNwjYMwL32MVUuZp5C0Jh8sgAnTwAGeJC9JZ/H kZ+a2YZp1lKRCsuW8SwmrgPQ6vfIp0104fgZfuzGlw5DuAaUdFz41wJ/DzCOFl+sjd /P55gPWM4++2JHJ2tV0zk9RMxzRc6253kqNca2GFYI8/1LielA2RqpiEC5KFjJcqn6 kqpNhJVODBANFoouxJOjkqPVVvp+XDJAoKEjeT9eaiq6qqe8v9qEr5hSHKyOS2sL2w W9ac96RvwCziTHfTIrcH1OYpCkrmlPwqBLYbl5MQY72NxUdeMpmYzt1+Ok5OLh0SNf dF3F5OvD9/3hw== Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AMExbod032384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sun, 22 Nov 2020 09:59:37 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Sun, 22 Nov 2020 06:59:36 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Sun, 22 Nov 2020 06:59:36 -0800 From: "Templin (US), Fred L" To: Ca By , Mark Smith , "Brian E Carpenter" CC: IPv6 Operations , 6MAN <6man@ietf.org> Thread-Topic: [EXTERNAL] Re: [v6ops] Next step? [Re: The bottom is /112] Thread-Index: AQHWv81t/98QWONPeUCYw3+yMRkiTanUO2mA Date: Sun, 22 Nov 2020 14:59:35 +0000 Message-ID: References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: CBB39D98A7F4556C91331739F299DFD8CBD0C061E89EF61F6708529AF2B69A432000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 14:59:46 -0000 SGksIEkgYmVsaWV2ZSB0aGUgQUVSTy9PTU5JIGFwcHJvYWNoIHRvIHByZWZpeCBkZWxlZ2F0aW9u IHdvdWxkIGJlIGdvb2QgZm9yIHRoZSAzR1BQDQpjYXNlIGFsc28uIFRoZSBhcHByb2FjaCBpcyBw cmVkaWNhdGVkIG9uIHRoZSByb3V0ZXIgcmV0dXJuaW5nIGFuIFJBIHdpdGggYW4gSVB2NiBsaW5r LWxvY2FsDQpkZXN0aW5hdGlvbiBhZGRyZXNzIGRldGVybWluZWQgYnkgdGhlIGRlbGVnYXRlZCBw cmVmaXguIFRoZSBsaW5rLWxvY2FsIGFkZHJlc3MgaXMgZm9ybWVkDQpieSB3cml0aW5nIHRoZSBt b3N0IHNpZ25pZmljYW50IDY0IGJpdHMgb2YgdGhlIGRlbGVnYXRlZCBwcmVmaXggaW50byB0aGUg aW50ZXJmYWNlIElEIG9mIHRoZQ0KcHJlZml4IGZlODA6Oi82NC4NCg0KRm9yIGV4YW1wbGUsIGlm IHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHdlcmUgMjAwMTpkYjg6MTowOjovNTYgdGhlbiB0aGUgSVB2 NiBsaW5rLWxvY2FsDQpkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGZlODA6OjIwMDE6ZGI4OjE6MC4g VGhpcyBwcm92aWRlcyBhdCBsZWFzdCB0d28gaW1wb3J0YW50DQpvcGVyYXRpb25hbCBhZHZhbnRh Z2VzOg0KDQoxKSBJdCBjb252ZXlzIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGluIHRoZSBJUHY2IGRl c3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIFJBIHNvIHRoYXQNCm5vIFBJT3MgaW5zaWRlIHRoZSBS QSBuZWVkIHRvIGJlIHVzZWQgZm9yIHByZWZpeCBkZWxlZ2F0aW9uLg0KDQoyKSBJdCBzdXBwbGll cyB0aGUgbW9iaWxlIG5vZGUgd2l0aCBhIGd1YXJhbnRlZWQtdW5pcXVlIGxpbmstbG9jYWwgYWRk cmVzcyB0aGF0DQppdCBjYW4gdXNlIGZvciBmdXR1cmUgY29tbXVuaWNhdGlvbnMgd2l0aG91dCB0 aGUgbmVlZCB0byBwZXJmb3JtIERBRC4NCg0KQWdhaW4sIHRoZSBwcm9wb3NhbCBjb21lcyBmcm9t IHRoZSBBRVJPL09NTkkgdXNlIGNhc2UsIGJ1dCBJIGJlbGlldmUgaXMgYWxzbw0KZ29vZCBmb3Ig M0dQUCBhbmQgcmVhbGx5IGFueSBvdGhlciB3aXJlbGVzcyB1c2UgY2FzZSB3aGVyZSBhIGxpZ2h0 d2VpZ2h0DQpwcmVmaXggZGVsZWdhdGlvbiBjYXBhYmlsaXR5IGlzIGRlc2lyZWQuDQoNCkZyZWQN Cg== From nobody Sun Nov 22 11:08:22 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC2C3A0ACB; Sun, 22 Nov 2020 11:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd3-Mk9zwVcr; Sun, 22 Nov 2020 11:08:12 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA313A0AC6; Sun, 22 Nov 2020 11:08:12 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id 62so12162306pgg.12; Sun, 22 Nov 2020 11:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DL1f+ouz3h6WDmRx0FfMXts1NPYAWj0/+2f04GFm+ao=; b=EDfQfgOOSGc60BHpToqb7+f4Cp8lomYxZERaSIWavxTZuGU6PeWq+Fn2/5/7Hyz5y/ viiIdWWfWiFI/sNbjz1OATfRYFYBX8m9O0pyxO8N/kvp/f7Ce3g5YVVvY5hfcErqC3JY BY6DKS2nWakcCQ4CeB9CKp5vrhZj8FItLmIme7hcQZ6xHJpSH725jbvZFZfK/C0Garo9 YN2rYXStPWTJNJoQdj3s2sacWIs9jdZLQnVCxN5EUUPB8mdl9bQXlJ/sHiKO29RA6V1j sbR8w1Dv/scOKpTH7P47PQZgdaIJ6P3svsSjsUfi0fL4SERpP4S8QLujkXn5jw/h559n ZvgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DL1f+ouz3h6WDmRx0FfMXts1NPYAWj0/+2f04GFm+ao=; b=QpnyEMhTUGhOKhxMUQ6iH73gtQmX9Dbfb2gjjSElviuPsqfX9/7Ms1TfgNGSE/0IRY HzpV1uxSzHjowkstUgVXuA0x0uwJaMNVsVmFZxRSgdYQeeUlL+ZjihpOZrbNcw1IFGVS oDwe8mq5F0oYPT0BbRvLaFRy3WsgOdxtKThaiv9DQbGWrzobcoCMB+o9kziNqlpeB33r jBFj98PPZP1XxQRPcUf5L3z+18H6MQ7LZDPoandpnAVZ8qaU3/zJ8bFrYVqT/y6KYwz3 sGUNoHLp8Rw2NNjFUjYIfr9RzQoTVX/tzziocgerjbkWvYOmXkeEqKUtE/IAXZEaFx9Z kI4w== X-Gm-Message-State: AOAM533J1dyixTItH9izzYyI78RF6B61a5P/yQ90ecR0NvgE+IDdrqr5 iUSAhihekT8y0NEqg+GTarpXItAu2j9nQDmLkU8= X-Google-Smtp-Source: ABdhPJyGqLCtZa8zl6ksJc8f10tfE8Sk1B9nNrttLsEtS8giEQZgYJQ2+6Zi/snVM+Te/flzsAT9Ctt1At4ZXVpJCNM= X-Received: by 2002:a17:90b:1490:: with SMTP id js16mr20938799pjb.215.1606072091502; Sun, 22 Nov 2020 11:08:11 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> In-Reply-To: <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> From: Gyan Mishra Date: Sun, 22 Nov 2020 14:08:00 -0500 Message-ID: To: "Joel M. Halpern" Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000007f6d3705b4b6cc1b" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:08:16 -0000 --0000000000007f6d3705b4b6cc1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 20, 2020 at 8:46 PM Joel M. Halpern wrote= : > The nesting got me lost, so I will top post my take on the answer to the > one quesiton I could understand. Gyan> Thank you > > > I believe you asked what I think would need to be changed to permit the > delegation. > As with anything, the real things that need to change are the devices in > the network. Gyan> Agreed > > > With regard to IETF standards, what is proposed is a change to RA. > There are several possible changes. None of them require a change to > the IPv6 addressing archtiecture, as the addressing structure remains as > it is. Gyan> Agreed > > As for the exact mechanism, at the moment I lean towards Ole's proposal > of using a new option in his generic option mechanism. But I am not > wedded to that answer. Gyan>ok > > And of course, to get this supported in mobile environments we will have > to work with 3GPP and make sure there are no other hidden issues. > That's the way we do things. Work together. Gyan> Yes Agreed. Thank you > > > Changing the prefix length to /80 is technically also possible. Gyan> > It does > a lot more violence to my understanding of the architecture and software > structures that go with it, and is a very limited and narrow solution to > the problem. Gyan> Understood. This is a multi faceted problem and may require a multi faceted solution. Thank you. > > > Yours, > Joel > > On 11/20/2020 7:58 PM, Gyan Mishra wrote: > > Hi Joel > > > > In-line > > > > On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern > > wrote: > > > > Gyan, separate from Ole's comments about the difference between > address > > assignment and delegation, I have another problem following the > > reasoning below. > > > > Yes, the proposal for using shorter prefixes to enable UE to perfor= m > > delegation will require changes to the UE. > > > > Gyan> Agreed. So that change would be to RFC 4291 64 bit boundary > > to allow for longer prefix. Do you agree? > > > > If you don=E2=80=99t agree what do think the change would be to allow t= he UE to > > accept shorter prefix from the 3GPP gateway? > > > > > > But I do not see how that is relevant to any choice we are trying t= o > > make. > > Any solution that enables UE to delegate addresses (in the sense th= at > > they lack the capability now) willr equire changes to the UE. > > > > > > > > Gyan> If the UE receives a /56 via RA it could delegate /64 to > > downstream devices. No change needed to delegate /64, however a > > change is needed to accept /56 via RA. > > > > > > If 3GPP gateway supported PD - problem solved but that=E2=80=99s n= ot the > > case and that does not sound like it will ever change even with 5G. > > > > Gyan> The UE needs to be able to accept shorter prefix. That=E2=80= =99s the > > IPV6 specification change that requires removal of the 64 bit boundary. > > > > Yoru > > proposed change to the SLAAC length if anything does more violence = to > > the software (depending upon the exact software architecture.) > > > > > > Gyan> What violence to software. There would be more violence to > > software if we removed the 64 bit boundary and allowed slaac to support > > any vlsm prefix lengths. > > > > My /80 proposal would just shift the boundary 16 bits to /80. > > > > Hosts on the same subnet with two different masks would not be on-net t= o > > each other as on different subnets. The router would be configured wit= h > > the two subnets /64 and /80 subnet to support the two device types. > > The solution would be a simple RA PIO flag that is set and older hosts > > not upgraded would be backwards compatible and so would only support 64 > > bit boundary by ignoring flag. Hosts upgraded to support would > > understand the flag and be able to support longer mask up to /80. > > > > > > > > So I do not follow how you got to your conclusion. > > > > Yours, > > Joel > > > > On 11/20/2020 5:27 PM, Gyan Mishra wrote: > > > > > > (top posting) > > > > > > As I would like to clear the air as well as get to the crux of > > the v6ops > > > presentation development results as well as next steps for this > > draft > > > and the 6man variable slaac solutions draft: > > > > > > > > > This thread was in light of Lorenzo kindly pointing out that > > upgrading > > > 3GPP is not all that needs be done for Cameron=E2=80=99s 64share= v2 to > > work - as > > > all mobile devices would stop working- as slaac would not would = be > > > effectively broken. > > > > > > The mobile device would receive a shorter prefix let=E2=80=99s s= ay /56 > > but not > > > know what to do with it since it=E2=80=99s expecting a /64. > > > > > > So that a major gap and the only solution is updating RFC 4291 > > removing > > > the 64 bit boundary allowing for shorter prefix and now as well > > longer > > > prefixes to work and in that respect now provide the much needed > > parity > > > with static and DHCPv6 which can do any prefix length. > > > > > > So that is a drastic change to RFC 4291. However, in light of > this > > > development on the v6ops 109 call, my balancing act of best of > both > > > worlds and also to keep everyone happy to make this a WG effort > > for this > > > change by proposing in the subject heading /80 fixed boundary an= d > > not a > > > variable slaac change allowing all bits vlsm. > > > > > > Basically stealing 16 bits for network prefix out of the IID, > still > > > keeping the fixed boundary so longer than 80 would NOT be > allowed. > > > > > > A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99= s. > > > > > > This /80 would keep the operators and law enforcement happy as > > now 16 > > > bits less helps traceability but is still long enough for 48 bit= s > of > > > privacy to IP correlation by attackers. > > > > > > This /80 would be a nice optimal balance as it would keep wired > > > broadband and mobile handset customers happy respecting their > > privacy as > > > the 16 bits less of heuristics is minimal change that will impac= t > IP > > > correlation by attackers. > > > > > > The IID as it=E2=80=99s less than the current 64 bit cannot use = MAC based > > EUI64 > > > IID, which is not a problem as Mac based IID is not recommended > > as most > > > all manufacturers use RFC 4941 and I believe Linux flavors some > use > > > stable IID RFC 7217. > > > > > > So now the 48 bit IID would require a random IID generation > > schema so > > > can use either RFC 4941 privacy extension or RFC 7217 stable IID > to > > > generate the 48 bit IID. > > > > > > 3GPP subtending would now work issue mentioned in the problem > > statement > > > draft without even having to use 64share as now longer prefixes > > up to > > > /80 would be supported allowing for further segmentation of > > downstream > > > devices. > > > > > > This also would help wired broadband and soon fixed 5G broadband > > > proliferation where operators in light of BCP RIPE-690, are sill > > > allocation via BNG gateways a /64, now operators can stay as-is= , > > as the > > > /64 would now be allowed to be further segmented supporting 64k > > /80s, > > > way more then enough for SOHO. > > > > > > This would allow 64share if used by 3GPP operators to work and > > would not > > > require the 3GPP specification to be updated. We don=E2=80=99t = know even > > if the > > > 3GPP architecture specification can be updated to support shorte= r > > > prefixes and if the 3GPP consortium of operators would agree to > > it. So > > > that is all theoretical of that change is possible. > > > > > > As with 5G with Enhanced VPN framework SR steering of high > priority > > > traffic, traffic isolation and Network slicing capabilities > becomes > > > mainstream and will soon be a real world reality and as fixed 5G > > > broadband proliferation takes off and mobile 5G =3D=3D the idea = of a > > > wearable /48 will really be many /48s. > > > > > > As this paradigm shift takes place, operators around the world > > will be > > > clamoring after the RIR for massive blocks, I would say less tha= n > /8 > > > more like a /5 or /4. If you do the math on the way high side a > /10 > > > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR > > which is > > > tiny number with the number of large size operators worldwide. > > > > > > With the massive proliferation of IOT devices and just about > > every home > > > or office appliance on 5G, the problem now gets way exacerbated. > > > > > > As this evolution unfolds IANA will be scrambling to release all > > > remaining /3 as well as all unallocated blocks to subvert RIR IP= v6 > > > address space depletion. > > > > > > Playing Monday night quarterbacking in hindsight we would never > > think > > > this would happen in a million years, but we would see IPv6 on > > the verge > > > of address space depletion. Unheard of but it can happen as the > > saying > > > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. > > > > > > It is true as history has taught that very important lesson. > > > > > > The answer to this real world problem is in the subject heading > > of this > > > thread. > > > > > > This would also fix the day 1 issue I mentioned allowing mix of > > slaac > > > devices with static and DHCPv6 up to /80. > > > > > > The variable slaac solution draft proposes a new RA PIO flag > > that would > > > be used to signal longer prefixes, and would provide backwards > > > compatibility so that devices not supporting woud ignore the fla= g > > and > > > devices on newer code supporting would use the flag. We > definitely > > > don=E2=80=99t want to impact any existing devices on the existin= g 64 bit > > slaac > > > boundary standard. > > > > > > Dmytro has tested the solution on Linux kernel signaling RA PIO > > flag and > > > was able to successfully test any length mask and random IID > > generation > > > both RFC 4941 privacy extension as well as stable IID RFC 7217. > > > > > > > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > > > > > >> > > > > > > If everyone is in agreement with what I have stated on this > > thread, I > > > would like to ask the chairs for WG adoption as this is a WG > effort. > > > > > > I would like to garner support from all 6MAN members with full > > consensus > > > to change the existing RFC 4941 /64 fixed boundary to /80 fixed > > boundary. > > > > > > Kind Regards > > > > > > Gyan > > > > > > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > > > > > >> wrote= : > > > > > > I am missing something in your reasoning. > > > You seem to say at one point that (to paraphrase) "we can't > > do this > > > because it does not work with the existing UE software". > > > Any new solution where a UE delegates based on any change of > > any kind > > > (including lengthening the prefix, shortening the prefix, or > > magically > > > incanting new prefixes) requires that the UE be upgraded to > know > > > what to > > > do with the information. I do not see how that > > differentiates any of > > > the solutions. (Except "don't do anything", which I think we > > do not > > > want > > > to take.) > > > > > > Yours, > > > Joel > > > > > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > > > > > > > On Thu, Nov 19, 2020 at 10:33 AM > > > > > > > > > > > >>> wrote= : > > > > > > > > > > > > > > > > > On 19 Nov 2020, at 14:58, Gyan Mishra > > > > > > > > > > > > > > > >>> wrote: > > > > > > > > > > You would need a new option. It would likely be > > useful for the > > > > requesting router to indicate interest in the option. > Even > > > hinting > > > > at what prefix size it was expecting. > > > > > Now can you explain to me again the reasons why th= is > > > approach is > > > > better than using the existing DHPCv6 protocol packet= s? > > > > > > > > > > 3GPP gateway does not support DHCPv6 > > > > > > > > 3GPP gateway doesn't support new option. What's your > > point? > > > > > > > > > > > > > > > > The point of the v6ops presentation and this email > > thread is > > > how to > > > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in s= lide 1 of the > > deck you > > > compiled > > > > a list of options and of the two I had highlighted in red > > were the > > > > 64share v2 Cameron=E2=80=99s option and the variable slaa= c > > option. So on > > > the > > > > call this morning Lorenzo shot down 64share v2 shorter > prefix > > > option as > > > > even if the 3GPP architecture was updated to support long= er > > > prefixes and > > > > even is the 3GPP gateway was able to send a shorter prefi= x > > with A > > > flag > > > > not set, all mobile devices per Lorenzo=E2=80=99s point w= ould be > > broken > > > as they > > > > would not accept the shorter let=E2=80=99s say /56 prefix= to build > the > > > slaac 128 > > > > bit address. So the bottom line is the 64share v2 won=E2= =80=99t > work > > > unless we > > > > update RFC 4291 and remove the 64 bit boundary. > > > > > > > > So we are back to square uno - no viable solution > > > > > > > > So now we had thrown out the longer >64 due to race to > > bottom > > > worries > > > > which I and others believe is Fud and as described in > > slide 10 of > > > the > > > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. > > > > > > > > So a happy medium /80 fixed boundary I came up with that = I > > think > > > solves > > > > a lot of the issue and not just the 3GPP initial > > segmentation of > > > > downstream devices problem statement. > > > > > > > > Since we have to update RFC 4291 for 64share v2 to work > > anyways > > > to allow > > > > for shorter prefixes, why not instead create a new bottom > > at /80 > > > giving > > > > 16 bits more of prefix length and shrinking the IID down > > to 48 bits. > > > > Doing so you would not even have to update the 3GPP > > architecture > > > as I > > > > don=E2=80=99t know if that would fly or not. Also this s= olves a > > few other > > > > problems at the same time. > > > > > > > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to > > 128 is > > > > mainstream for operators for static addressing on router > > and switch > > > > infrastructure and dhcpv6 subnets longer prefixes for > network > > > > infrastructure appliance clusters, NFV/VNF virtualization > > and server > > > > farms. On host subnets where there is a chance of mix of > > slaac > > > hosts > > > > with dhcpv6 devices the prefix length is stuck at /64. > So on > > > these mix > > > > addressing host subnets we cannot do longer prefixes > following > > > our ND > > > > cache hard limit mantra to prevent ND cache exhaustion > > issues as > > > > described in RFC 6164. > > > > > > > > So with the /80 new fixed boundary shifting prefix length > > 16 bits > > > longer > > > > and shortening the IID by 16 bits gives resolved the 3GPP > > issue > > > which > > > > 64share can work as is and subtending to downstream > > devices will now > > > > work as a /64 is now equivalent to a /48 with 64k /80s. > Also > > > BCP-690 > > > > for broadband not all operators have adopted the shorter > > prefix > > > lengths > > > > /56 or /48 recommendations and now that=E2=80=99s not an= issue as > the > > > /64 would > > > > now suffice. > > > > > > > > From an operators perspective that gain allows at least > > for 3GPP > > > > massive growth and subtending with a single /64 allows th= e > > operators > > > > such as Verizon with massive subscriber base worldwide ca= n > > stay with > > > > current allocations and don=E2=80=99t have to ask > > < > https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have= +to+ask?entry=3Dgmail&source=3Dg > > > > for /10. > > > > > > > > As 5G gets rolled out with Enhanced VPN framework and > Network > > > slicing > > > > paradigm, the demand for shorter blocks and wearable > > multiple /48 > > > will > > > > be our new reality. > > > > > > > > Making that 16 bit shift now to /80 making a /64 the new > > /48 will > > > give > > > > broadband and 3GPP subscribers a ton of space to > > subtending their > > > > networks we would be set for the future. Especially with > > IOT the > > > demand > > > > for subtending will continue to grow astronomically. > > > > > > > > Also IANA does not have to get start in allocating the > > other /3 and > > > > other available blocks. > > > > > > > > Lots of problems being solved here with a fixed /80 new > > boundary. > > > > > > > > Also with the existing random IID generation schemes whic= h > > we have > > > > tested on Linux kernel can do longer p > > > > > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > >>refixes > > > using RFC 4941 privacy > > > > extension or RFC 7217 stable IID. > > > > > > > > Win-Win for all. > > > > > > > > Ole > > > > > > > > -- > > > > > > > > > > >> > > > > > > > > *Gyan Mishra* > > > > > > > > /Network Solutions A//rchitect / > > > > > > > > /M 301 502-1347 > > > > 13101 Columbia Pike > > > > /Silver Spring, MD > > > > > > > > > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000007f6d3705b4b6cc1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 20, 2020 at 8:46 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
The nesting got me lost, so I will top post= my take on the answer to the
one quesiton I could understand.

=C2=A0 =C2=A0Gyan> Thank you=C2=A0


I believe you asked what I think would need to be changed to permit the delegation.
As with anything, the real things that need to change are the devices in the network.
=C2=A0
= =C2=A0 =C2=A0 Gyan> Agreed=C2=A0


With regard to IETF standards, what is proposed is a change to RA.
There are several possible changes.=C2=A0 None of them require a change to =
the IPv6 addressing archtiecture, as the addressing structure remains as it is.

=C2=A0 =C2= =A0 Gyan> Agreed

As for the exact mechanism, at the moment I lean towards Ole's proposal=
of using a new option in his generic option mechanism.=C2=A0 But I am not <= br> wedded to that answer.
=C2=A0 =C2=A0
=C2=A0 =C2=A0 Gyan>ok

And of course, to get this supported in mobile environments we will have to work with 3GPP and make sure there are no other hidden issues.
That's the way we do things.=C2=A0 Work together.

=C2=A0 =C2=A0 Gyan> Yes Agreed.=C2= =A0 Thank you


Changing the prefix length to /80 is technically also possible.=C2=A0

=C2=A0 =C2=A0 =C2=A0G= yan>=C2=A0
It does
a lot more violence to my understanding of the architecture and software structures that go with it, and is a very limited and narrow solution to the problem.

=C2= =A0 =C2=A0 Gyan> Understood.=C2=A0 This is a multi faceted problem and m= ay require a multi faceted solution.=C2=A0 Thank you.


Yours,
Joel

On 11/20/2020 7:58 PM, Gyan Mishra wrote:
> Hi Joel
>
> In-line
>
> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jm= h@joelhalpern.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Gyan, separate from Ole's comments about the di= fference between address
>=C2=A0 =C2=A0 =C2=A0assignment and delegation, I have another problem f= ollowing the
>=C2=A0 =C2=A0 =C2=A0reasoning below.
>
>=C2=A0 =C2=A0 =C2=A0Yes, the proposal for using shorter prefixes to ena= ble UE to perform
>=C2=A0 =C2=A0 =C2=A0delegation will require changes to the UE.
>
>=C2=A0 =C2=A0 =C2=A0 Gyan> Agreed.=C2=A0 So that change would be to = RFC 4291 64 bit boundary
> to allow for longer prefix.=C2=A0 Do you agree?
>
> If you don=E2=80=99t agree what do think the change would be to allow = the UE to
> accept shorter prefix from the 3GPP gateway?
>
>
>=C2=A0 =C2=A0 =C2=A0But I do not see how that is relevant to any choice= we are trying to
>=C2=A0 =C2=A0 =C2=A0make.
>=C2=A0 =C2=A0 =C2=A0Any solution that enables UE to delegate addresses = (in the sense that
>=C2=A0 =C2=A0 =C2=A0they lack the capability now) willr equire changes = to the UE.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan> If the UE receives a /56 via RA it could d= elegate /64 to
>=C2=A0 =C2=A0 =C2=A0downstream devices.=C2=A0 No change needed to deleg= ate =C2=A0/64, however a
>=C2=A0 =C2=A0 =C2=A0change is needed to accept /56 via RA.
>
>
>=C2=A0 =C2=A0 =C2=A0 If 3GPP gateway supported PD - problem solved but = that=E2=80=99s not the
> case and that does not sound like it will ever change even with 5G. >
>=C2=A0 =C2=A0 =C2=A0Gyan> The UE needs to be able to accept shorter = prefix.=C2=A0 That=E2=80=99s the
> IPV6 specification change that requires removal of the 64 bit boundary= .
>
>=C2=A0 =C2=A0 =C2=A0Yoru
>=C2=A0 =C2=A0 =C2=A0proposed change to the SLAAC length if anything doe= s more violence to
>=C2=A0 =C2=A0 =C2=A0the software (depending upon the exact software arc= hitecture.)
>
>
>=C2=A0 =C2=A0 =C2=A0Gyan> What violence to software.=C2=A0 There wou= ld be more violence to
> software if we removed the 64 bit boundary and allowed slaac to suppor= t
> any vlsm prefix lengths.
>
> My /80 proposal would just shift the boundary 16 bits to /80.
>
> Hosts on the same subnet with two different masks would not be on-net = to
> each other as on different subnets.=C2=A0 The router would be configur= ed with
> the two subnets /64 and /80 subnet to support the two device types. > The solution would be a simple RA PIO flag that is set and older hosts=
> not upgraded would be backwards compatible and so would only support 6= 4
> bit boundary by ignoring flag. Hosts upgraded to support would
> understand the flag and be able to support longer mask up to /80.
>
>
>
>=C2=A0 =C2=A0 =C2=A0So I do not follow how you got to your conclusion.<= br> >
>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0On 11/20/2020 5:27 PM, Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > (top posting)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As I would like to clear the air as well as g= et to the crux of
>=C2=A0 =C2=A0 =C2=A0the v6ops
>=C2=A0 =C2=A0 =C2=A0 > presentation development results as well as n= ext steps for this
>=C2=A0 =C2=A0 =C2=A0draft
>=C2=A0 =C2=A0 =C2=A0 > and the 6man variable slaac solutions draft:<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This thread was in light of Lorenzo kindly po= inting out that
>=C2=A0 =C2=A0 =C2=A0upgrading
>=C2=A0 =C2=A0 =C2=A0 > 3GPP is not all that needs be done for Camero= n=E2=80=99s 64share v2 to
>=C2=A0 =C2=A0 =C2=A0work - as
>=C2=A0 =C2=A0 =C2=A0 > all mobile devices would stop working- as sla= ac would not would be
>=C2=A0 =C2=A0 =C2=A0 > effectively broken.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The mobile device would receive a shorter pre= fix let=E2=80=99s say /56
>=C2=A0 =C2=A0 =C2=A0but not
>=C2=A0 =C2=A0 =C2=A0 > know what to do with it since it=E2=80=99s ex= pecting a /64.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So that a major gap and the only solution is = updating RFC 4291
>=C2=A0 =C2=A0 =C2=A0removing
>=C2=A0 =C2=A0 =C2=A0 > the 64 bit boundary allowing for shorter pref= ix and now as well
>=C2=A0 =C2=A0 =C2=A0longer
>=C2=A0 =C2=A0 =C2=A0 > prefixes to work and in that respect now prov= ide the much needed
>=C2=A0 =C2=A0 =C2=A0parity
>=C2=A0 =C2=A0 =C2=A0 > with static and DHCPv6 which can do any prefi= x length.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So that is a drastic change to RFC 4291.=C2= =A0 However, in light of this
>=C2=A0 =C2=A0 =C2=A0 > development on the v6ops 109 call, my balanci= ng act of best of both
>=C2=A0 =C2=A0 =C2=A0 > worlds and also to keep everyone happy to mak= e this a WG effort
>=C2=A0 =C2=A0 =C2=A0for this
>=C2=A0 =C2=A0 =C2=A0 > change by proposing in the subject heading /8= 0 fixed boundary and
>=C2=A0 =C2=A0 =C2=A0not a
>=C2=A0 =C2=A0 =C2=A0 > variable slaac change allowing all bits vlsm.=
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Basically stealing 16 bits for network prefix= out of the IID, still
>=C2=A0 =C2=A0 =C2=A0 > keeping the fixed boundary so longer than 80 = would NOT =C2=A0be allowed.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > A /64 would now be equivalent to a /48 with n= ow 64k /80=E2=80=99s.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This /80 would keep the operators and law enf= orcement happy as
>=C2=A0 =C2=A0 =C2=A0now 16
>=C2=A0 =C2=A0 =C2=A0 > bits less helps traceability but is still lon= g enough for 48 bits of
>=C2=A0 =C2=A0 =C2=A0 > privacy to IP correlation by attackers.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This /80 would be a nice optimal balance as i= t would keep wired
>=C2=A0 =C2=A0 =C2=A0 > broadband and mobile handset customers happy = respecting their
>=C2=A0 =C2=A0 =C2=A0privacy as
>=C2=A0 =C2=A0 =C2=A0 > the 16 bits less of heuristics is minimal cha= nge that will impact IP
>=C2=A0 =C2=A0 =C2=A0 > correlation by attackers.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The IID as it=E2=80=99s less than the current= 64 bit cannot use MAC based
>=C2=A0 =C2=A0 =C2=A0EUI64
>=C2=A0 =C2=A0 =C2=A0 > IID, which is not a problem as Mac based IID = is not recommended
>=C2=A0 =C2=A0 =C2=A0as most
>=C2=A0 =C2=A0 =C2=A0 > all manufacturers use RFC 4941 and I believe = Linux flavors some use
>=C2=A0 =C2=A0 =C2=A0 > stable IID RFC 7217.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So now the 48 bit IID would require a random = IID generation
>=C2=A0 =C2=A0 =C2=A0schema so
>=C2=A0 =C2=A0 =C2=A0 > can use either RFC 4941 privacy extension or = RFC 7217 stable IID to
>=C2=A0 =C2=A0 =C2=A0 > generate the 48 bit IID.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > 3GPP subtending would now work issue mentione= d in the problem
>=C2=A0 =C2=A0 =C2=A0statement
>=C2=A0 =C2=A0 =C2=A0 > draft without even having to use 64share as n= ow longer prefixes
>=C2=A0 =C2=A0 =C2=A0up to
>=C2=A0 =C2=A0 =C2=A0 > /80 would be supported allowing for further s= egmentation of
>=C2=A0 =C2=A0 =C2=A0downstream
>=C2=A0 =C2=A0 =C2=A0 > devices.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This also would help wired broadband and soon= fixed 5G broadband
>=C2=A0 =C2=A0 =C2=A0 > proliferation where operators in light of BCP= RIPE-690, are sill
>=C2=A0 =C2=A0 =C2=A0 > allocation via BNG gateways a /64, now operat= ors =C2=A0can stay as-is,
>=C2=A0 =C2=A0 =C2=A0as the
>=C2=A0 =C2=A0 =C2=A0 > /64 would now be allowed to be further segmen= ted supporting 64k
>=C2=A0 =C2=A0 =C2=A0/80s,
>=C2=A0 =C2=A0 =C2=A0 > way more then enough for SOHO.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This would allow 64share if used by 3GPP oper= ators to work and
>=C2=A0 =C2=A0 =C2=A0would not
>=C2=A0 =C2=A0 =C2=A0 > require the 3GPP specification to be updated.= =C2=A0 We don=E2=80=99t know even
>=C2=A0 =C2=A0 =C2=A0if the
>=C2=A0 =C2=A0 =C2=A0 > 3GPP architecture specification can be update= d to support shorter
>=C2=A0 =C2=A0 =C2=A0 > prefixes and if the 3GPP consortium of operat= ors would agree to
>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 So
>=C2=A0 =C2=A0 =C2=A0 > that is all theoretical of that change is pos= sible.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As with 5G with Enhanced VPN framework SR ste= ering of high priority
>=C2=A0 =C2=A0 =C2=A0 > traffic, traffic isolation and Network slicin= g capabilities becomes
>=C2=A0 =C2=A0 =C2=A0 > mainstream and will soon be a real world real= ity and as fixed 5G
>=C2=A0 =C2=A0 =C2=A0 > broadband proliferation takes off and mobile = 5G =3D=3D the idea of a
>=C2=A0 =C2=A0 =C2=A0 > wearable /48 will really be many /48s.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As this paradigm shift takes place, operators= around the world
>=C2=A0 =C2=A0 =C2=A0will be
>=C2=A0 =C2=A0 =C2=A0 > clamoring after the RIR for massive blocks, I= would say less than /8
>=C2=A0 =C2=A0 =C2=A0 > more like a /5 or /4.=C2=A0 If you do the mat= h on the way high side a /10
>=C2=A0 =C2=A0 =C2=A0 > yields 7 bits so 128 divided by 5 RIRs yields= 24 ISPs per RIR
>=C2=A0 =C2=A0 =C2=A0which is
>=C2=A0 =C2=A0 =C2=A0 > tiny number with the number of large size ope= rators worldwide.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > With the massive proliferation of IOT devices= and just about
>=C2=A0 =C2=A0 =C2=A0every home
>=C2=A0 =C2=A0 =C2=A0 > or office appliance on 5G, the problem now ge= ts way exacerbated.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > As this evolution unfolds IANA will be scramb= ling to release all
>=C2=A0 =C2=A0 =C2=A0 > remaining /3 as well as all unallocated block= s to subvert RIR IPv6
>=C2=A0 =C2=A0 =C2=A0 > address space depletion.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Playing Monday night quarterbacking in hindsi= ght we would never
>=C2=A0 =C2=A0 =C2=A0think
>=C2=A0 =C2=A0 =C2=A0 > this would happen in a million years, but we = would see IPv6 on
>=C2=A0 =C2=A0 =C2=A0the verge
>=C2=A0 =C2=A0 =C2=A0 > of address space depletion.=C2=A0 Unheard of = but it can happen as the
>=C2=A0 =C2=A0 =C2=A0saying
>=C2=A0 =C2=A0 =C2=A0 > goes =E2=80=9Cwhen you build - they will come= =E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > It is true as history has taught that very im= portant lesson.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The answer to this real world problem is in t= he subject heading
>=C2=A0 =C2=A0 =C2=A0of this
>=C2=A0 =C2=A0 =C2=A0 > thread.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This would also fix the day 1 issue I mention= ed allowing mix of
>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 > devices with static and DHCPv6 up to /80.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The variable slaac solution draft proposes a = new =C2=A0RA PIO flag
>=C2=A0 =C2=A0 =C2=A0that would
>=C2=A0 =C2=A0 =C2=A0 > be used to signal longer prefixes, and would = provide backwards
>=C2=A0 =C2=A0 =C2=A0 > compatibility so that devices not supporting = woud ignore the flag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0 > devices on newer code supporting would use th= e flag.=C2=A0 We definitely
>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t want to impact any existing dev= ices on the existing 64 bit
>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 > boundary standard.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Dmytro has tested the solution on Linux kerne= l signaling RA PIO
>=C2=A0 =C2=A0 =C2=A0flag and
>=C2=A0 =C2=A0 =C2=A0 > was able to successfully test any length mask= and random IID
>=C2=A0 =C2=A0 =C2=A0generation
>=C2=A0 =C2=A0 =C2=A0 > both RFC 4941 privacy extension as well as st= able IID RFC 7217.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https://da= tatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>=C2=A0 =C2=A0 =C2=A0<https:= //datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0<https:= //datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>=C2=A0 =C2=A0 =C2=A0<https:= //datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > If everyone is in agreement with what I have = stated on this
>=C2=A0 =C2=A0 =C2=A0thread, I
>=C2=A0 =C2=A0 =C2=A0 > would like to ask the chairs for WG adoption = as this is a WG effort.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I would like to garner support from all 6MAN = members with full
>=C2=A0 =C2=A0 =C2=A0consensus
>=C2=A0 =C2=A0 =C2=A0 > to change the existing RFC 4941 /64 fixed bou= ndary to /80 fixed
>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Kind Regards
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Gyan
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpe= rn
>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>= wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I am missing something in = your reasoning.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0You seem to say at one poi= nt that (to paraphrase) "we can't
>=C2=A0 =C2=A0 =C2=A0do this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0because it does not work w= ith the existing UE software".
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Any new solution where a U= E delegates based on any change of
>=C2=A0 =C2=A0 =C2=A0any kind
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(including lengthening the= prefix, shortening the prefix, or
>=C2=A0 =C2=A0 =C2=A0magically
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0incanting new prefixes) re= quires that the UE be upgraded to know
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0what to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0do with the information.= =C2=A0 I do not see how that
>=C2=A0 =C2=A0 =C2=A0differentiates any of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the solutions. (Except &qu= ot;don't do anything", which I think we
>=C2=A0 =C2=A0 =C2=A0do not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0want
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to take.)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Joel
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 11/19/2020 5:03 PM, Gya= n Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, 2020= at 10:33 AM <= otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mai= lto:otroan@employ= ees.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:otroan@employees.org= <mailto:otroa= n@employees.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailto:otroan@employees.org>>>&g= t; wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > On 19 Nov 2020, at 14:58, Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<hayabusagsm@gmail.com <mailto:<= a href=3D"mailto:hayabusagsm@gmail.com" target=3D"_blank">hayabusagsm@gmail= .com>
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= lt;mailto:hayabu= sagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > You would need a new option. It would likely be
>=C2=A0 =C2=A0 =C2=A0useful for the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0r= equesting router to indicate interest in the option. Even
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hinting
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a= t what prefix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > Now can you explain to me again the reasons why this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0approach is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0b= etter than using the existing DHPCv6 protocol packets?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03= GPP gateway doesn't support new option. What's your
>=C2=A0 =C2=A0 =C2=A0point?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = The point of the v6ops presentation and this email
>=C2=A0 =C2=A0 =C2=A0thread is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0how to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > =E2=80=9Cextend a /6= 4=E2=80=9D in the 3GPP use case =C2=A0in slide 1 of the
>=C2=A0 =C2=A0 =C2=A0deck you
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0compiled
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a list of options an= d of the two I had highlighted in red
>=C2=A0 =C2=A0 =C2=A0were the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share v2 Cameron= =E2=80=99s option and the variable slaac
>=C2=A0 =C2=A0 =C2=A0option.=C2=A0 So on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > call this morning Lo= renzo shot down 64share v2 shorter prefix
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0option as
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even if the 3GPP arc= hitecture was updated to support longer
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0prefixes and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > even is the 3GPP gat= eway was able to send a shorter prefix
>=C2=A0 =C2=A0 =C2=A0with A
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0flag
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > not set, all mobile = devices per Lorenzo=E2=80=99s point would be
>=C2=A0 =C2=A0 =C2=A0broken
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as they
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > would not accept the= shorter let=E2=80=99s say /56 prefix to build the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slaac 128
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > bit address.=C2=A0 S= o the bottom line is the 64share v2 won=E2=80=99t work
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0unless we
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > update RFC 4291 and = remove the 64 bit boundary.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So we ar= e back to square uno - no viable solution
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0So now w= e had thrown out the longer >64 due to race to
>=C2=A0 =C2=A0 =C2=A0bottom
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0worries
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > which I and others b= elieve is Fud and as described in
>=C2=A0 =C2=A0 =C2=A0slide 10 of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops =E2=80=9Crace = to the bottom slide=E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So a happy medium /8= 0 fixed boundary I came up with that I
>=C2=A0 =C2=A0 =C2=A0think
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0solves
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > a lot of the issue a= nd not just the 3GPP initial
>=C2=A0 =C2=A0 =C2=A0segmentation of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > downstream devices p= roblem statement.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Since we have to upd= ate RFC 4291 for 64share v2 to work
>=C2=A0 =C2=A0 =C2=A0anyways
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to allow
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for shorter prefixes= , why not instead create a new bottom
>=C2=A0 =C2=A0 =C2=A0at /80
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0giving
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 16 bits more of pref= ix length and shrinking the IID down
>=C2=A0 =C2=A0 =C2=A0to 48 bits.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Doing so you would n= ot even have to update the 3GPP
>=C2=A0 =C2=A0 =C2=A0architecture
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as I
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t know i= f that would fly or not.=C2=A0 Also this solves a
>=C2=A0 =C2=A0 =C2=A0few other
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > problems at the same= time.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As I mentioned in th= e v6ops deck presented that vlsm 0 to
>=C2=A0 =C2=A0 =C2=A0128 is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > mainstream for opera= tors for static addressing on router
>=C2=A0 =C2=A0 =C2=A0and switch
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure and d= hcpv6 subnets longer prefixes for network
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > infrastructure appli= ance clusters, NFV/VNF virtualization
>=C2=A0 =C2=A0 =C2=A0and server
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > farms.=C2=A0 On host= subnets where there is a chance of mix of
>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hosts
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > with dhcpv6 =C2=A0de= vices the prefix length is stuck at /64.=C2=A0 So on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0these mix
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > addressing host subn= ets we cannot do longer prefixes following
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0our ND
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > cache hard limit man= tra to prevent ND cache exhaustion
>=C2=A0 =C2=A0 =C2=A0issues as
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > described in RFC 616= 4.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > So with the /80 new = fixed boundary shifting prefix length
>=C2=A0 =C2=A0 =C2=A016 bits
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0longer
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > and shortening the I= ID by 16 bits gives resolved the 3GPP
>=C2=A0 =C2=A0 =C2=A0issue
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0which
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 64share can work as = is and subtending to downstream
>=C2=A0 =C2=A0 =C2=A0devices will now
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > work as a /64 is now= equivalent to a /48 with 64k /80s.=C2=A0 Also
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0BCP-690
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for broadband not al= l operators have adopted the shorter
>=C2=A0 =C2=A0 =C2=A0prefix
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0lengths
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /56 or /48 recommend= ations =C2=A0and now that=E2=80=99s not an issue as the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0/64 would
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > now suffice.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From an operat= ors perspective that gain allows at least
>=C2=A0 =C2=A0 =C2=A0for 3GPP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > massive growth and s= ubtending with a single /64 allows the
>=C2=A0 =C2=A0 =C2=A0operators
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > such as Verizon with= massive subscriber base worldwide can
>=C2=A0 =C2=A0 =C2=A0stay with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > current allocations = and don=E2=80=99t have to ask
>=C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/ent= +allocations+and+don%E2%80%99t+have+to+ask?entry=3Dgmail&source=3Dg= >
>=C2=A0 =C2=A0 =C2=A0for /10.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > As 5G gets rolled ou= t with Enhanced VPN framework and Network
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0slicing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > paradigm, the demand= for shorter blocks and wearable
>=C2=A0 =C2=A0 =C2=A0multiple /48
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0will
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > be our new reality.<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Making that 16 bit s= hift now to /80 making a /64 the new
>=C2=A0 =C2=A0 =C2=A0/48 will
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0give
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > broadband and 3GPP s= ubscribers a ton of space to
>=C2=A0 =C2=A0 =C2=A0subtending their
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > networks we would be= set for the future.=C2=A0 Especially with
>=C2=A0 =C2=A0 =C2=A0IOT the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0demand
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > for subtending will = continue to grow astronomically.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also IANA does not h= ave to get start in allocating the
>=C2=A0 =C2=A0 =C2=A0other /3 and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > other available bloc= ks.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Lots of problems bei= ng solved here with a fixed /80 new
>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Also with the existi= ng random IID generation schemes which
>=C2=A0 =C2=A0 =C2=A0we have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > tested on Linux kern= el can do longer p
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/tes= ted+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg <= https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?e= ntry=3Dgmail&source=3Dg>>refixes
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0using RFC 4941 privacy
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > extension or RFC 721= 7 stable IID.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Win-Win for all.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0O= le
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon= .com/ <http://www.verizon.com/>
>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A= //rchitect /
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > ____________________= ___________________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops mailing list >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > ht= tps://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<http= s://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/ <http://ww= w.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>
--
--0000000000007f6d3705b4b6cc1b-- From nobody Sun Nov 22 11:48:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0973A0B6F; Sun, 22 Nov 2020 11:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq8NHe6AGyqE; Sun, 22 Nov 2020 11:48:07 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DB83A0B6B; Sun, 22 Nov 2020 11:48:07 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id q10so12890181pfn.0; Sun, 22 Nov 2020 11:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVjguim0w+nNTCiFSz9oAX+pLS5MLuYvuLDzF7yOAY0=; b=Xeq+bCCAs70zNaLyd+1gTEU9wGZxv2RCSxtraePZTn5XTmvLskHEZqnTObTWsobYmG 9na0ocqU5J7edw2CtdFWj4+BttuUZ/SdJmETpwKtGeqluQDp7twUijtTisKwISpTAGUW 3y+n4jxMbnA0s1rzClC9JJ5W2yzMlOWRPxGESwiETrLEX9UNJzka4bA+8JyfVJBCsdru KttouWFe5FhIYYiW8onanaiZT0VK63tedYMqttsHuB5v4kGV5XW1NwmVjB3AxUzC2vYR D5BJXfp2WHJGA2SBkPvJSqa2fV2VZo3rGop2uEGaJKPYQo2AdqRxQL1Tm7t1zbQMUXHB 5LIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVjguim0w+nNTCiFSz9oAX+pLS5MLuYvuLDzF7yOAY0=; b=tCPN2kaEBX3wXH5s7JxQsPdVVryQRo024axtGLLwP5kldY5R9B/jEg18mFU7wvoiBF /UcW+gdXkHi7SzKRBj4/VSof2RQKydWvjI1zDBArtQ72FM+/AbZAiOwhQBwW9KkZyHtT gljxWV/vohuEC51QjVEvLrRpdQgF4AWuFmf2jyQZKvroZOrKzGHrq1rn/8cs3RGRtQez Xqpe2zT5/IQZqaHkYcqP9zWx4g2GBrljLvPrd+02fAar+KAHFnIv3eS2rgoHwkU0M5L9 KLgA/PJfnu0mZ4NqYwvY1x0d+NFvyxGSeLZCcCf82MZLaYV98GjQJ2PoAfIbhPxBWtWJ 3pYw== X-Gm-Message-State: AOAM533+799faXZtZD4MewPo/X+E7yPkxoSS5XoIUP3mFkOCMjIrBCLp hFhmybWncX/Fs9P08FbHqQgPheNCcYoQbzjmERM= X-Google-Smtp-Source: ABdhPJy3GulyMzUef3k9x6x/jszCoCPquLR/mbFEmOqL7XK7LnIEguQ5CNPKnqRwBKLkdiZgTCNkaxmT0uCSMQDuEkE= X-Received: by 2002:a63:9d01:: with SMTP id i1mr12505655pgd.50.1606074486404; Sun, 22 Nov 2020 11:48:06 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> In-Reply-To: From: Gyan Mishra Date: Sun, 22 Nov 2020 14:47:55 -0500 Message-ID: To: Mark Smith Cc: 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ , "Joel M. Halpern" Content-Type: multipart/alternative; boundary="0000000000003eb84a05b4b75b40" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:48:11 -0000 --0000000000003eb84a05b4b75b40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 21, 2020 at 12:48 AM Mark Smith wrote: > > > On Sat, 21 Nov 2020, 09:27 Gyan Mishra, wrote: > >> >> (top posting) >> > >> As I would like to clear the air as well as get to the crux of the v6ops >> presentation development results as well as next steps for this draft an= d >> the 6man variable slaac solutions draft: >> >> > You're asserting that everybody has accepted there is a problem to be > solved, and that everybody has accepted that the only way to solve it is = to > change the default 64 bit IID size. This is both premature and not a > representation about "everybody's" opinion you can make. > Gyan> I believe after the v6ops presentation I gave on the problem statement as well as the countless threads and interest I think more folks think their is an issue to be solved then don=E2=80=99t. I think the probl= em is clear. I never said that this is the only way to solve the problem. This is just one idea of a possible solution and there definitely maybe others that are better and I am not denying that. Nothing premature as this is just and idea of one possible proposed solution. > > I haven't accepted either of those things. > > I'm not happy with the idea of changing away for 64 bit IIDs because I > don't think 64 bit IIDs are the problem. Plenty of operators have given o= ut > /56s. I'm working at my second one. It is not impossible. > Gyan> All of the countess threads have all been spawned from the variable slaac problem statement draft and solution to change the 64 bit IID boundary. There are two sides to the camp of changing versus not changing as this idea to change is not new as it comes up every few years with a fierce onslaught of threads for and against. Their is definitely interest in changing but thus far the balance of not changing as been the weighted majority over not changing. I am hoping this time around maybe we have a game changer of a problem to be solved and the fixed 64 bit IID change gets close to workgroup consensus. > > Many things below are incorrect, uninformed, or quite frankly ridiculous. > Some read like you've let your imagination go wild and then have just > assumed because you can imagine it it will then inevitably happen in the > near future. > Gyan> That is your POV. > > > For example, DHCPv6 does not provide a prefix length to hosts. Your > proposal does not make SLAAC "consistent' with what DHCPv6 does, because > DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA in > the DHCPv6 RFC). > Gyan> Understood. I think you may have misunderstood what I meant and maybe I did not state clearly and that=E2=80=99s my fault if the latter. M= y point is that DHCPv6 is length independent as the sever sends 128 bit managed address M=3D1 to host. Point here is that both static and dhcpv6 are prefix length independent and slaac is fixed at 64 bit. This does introduce incompatibility issue with slaac host endpoints not having parity with dhcpv6 and static being prefix length agnostic. So as stated in the v6ops deck this prevents operators from having longer then 64 bit prefix lengths on host subnets due to the 64 bit boundary. I understand that there are many addressing guidelines that state that due to this parity issue that /64 is recommended for all host subnets. However operators would like this to change so that >64 prefix can be deployed to host subnets. > > "the idea of a wearable /48 will really be many /48s"? Do you really thin= k > we're going to have more devices on our person that we'll need more than = 65 > 536 /64 subnets (a single /48) to number them? That sounds like science > fiction to me for at least the next 200 years or more. > Gyan> I did not start the original thread on =E2=80=9Cwearable=E2=80=9D /64= . Please see 6MAN archives. I just took that and ran with it based on future network infrastructure developments upcoming and paradigm shift and a reality of a digital transformation with 5G in the context of =E2=80=9Cnetwork slicing= =E2=80=9D which will require exorbitant amount of address space. It=E2=80=99s no different= then concept of cloud computing and hypervisor virtualization which required many more addresses per VM as compare to physical servers. So now apply that to the wireless operators RAN front haul and backhaul xHaul virtualization framework with =E2=80=9Cnetwork slicing=E2=80=9D game change= r paradigm shift. > > IPv6 isn't and isn't required to be the final and only Internet protocol > for the remainder of humanity, so we don't have to try to accommodate eve= ry > conceivable idea that somebody can come up with that might cause the 128 > bit address space to be too small. > > >> >> This thread was in light of Lorenzo kindly pointing out that upgrading >> 3GPP is not all that needs be done for Cameron=E2=80=99s 64share v2 to w= ork - as >> all mobile devices would stop working- as slaac would not would be >> effectively broken. >> >> The mobile device would receive a shorter prefix let=E2=80=99s say /56 b= ut not >> know what to do with it since it=E2=80=99s expecting a /64. >> >> So that a major gap and the only solution is updating RFC 4291 removing >> the 64 bit boundary allowing for shorter prefix and now as well longer >> prefixes to work and in that respect now provide the much needed parity >> with static and DHCPv6 which can do any prefix length. >> >> So that is a drastic change to RFC 4291. However, in light of this >> development on the v6ops 109 call, my balancing act of best of both worl= ds >> and also to keep everyone happy to make this a WG effort for this change= by >> proposing in the subject heading /80 fixed boundary and not a variable >> slaac change allowing all bits vlsm. >> >> Basically stealing 16 bits for network prefix out of the IID, still >> keeping the fixed boundary so longer than 80 would NOT be allowed. >> >> A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s. >> >> This /80 would keep the operators and law enforcement happy as now 16 >> bits less helps traceability but is still long enough for 48 bits of >> privacy to IP correlation by attackers. >> >> This /80 would be a nice optimal balance as it would keep wired broadban= d >> and mobile handset customers happy respecting their privacy as the 16 bi= ts >> less of heuristics is minimal change that will impact IP correlation by >> attackers. >> >> The IID as it=E2=80=99s less than the current 64 bit cannot use MAC base= d EUI64 >> IID, which is not a problem as Mac based IID is not recommended as most = all >> manufacturers use RFC 4941 and I believe Linux flavors some use stable I= ID >> RFC 7217. >> >> So now the 48 bit IID would require a random IID generation schema so ca= n >> use either RFC 4941 privacy extension or RFC 7217 stable IID to generate >> the 48 bit IID. >> >> 3GPP subtending would now work issue mentioned in the problem statement >> draft without even having to use 64share as now longer prefixes up to /8= 0 >> would be supported allowing for further segmentation of downstream devic= es. >> >> This also would help wired broadband and soon fixed 5G broadband >> proliferation where operators in light of BCP RIPE-690, are sill allocat= ion >> via BNG gateways a /64, now operators can stay as-is, as the /64 would = now >> be allowed to be further segmented supporting 64k /80s, way more then >> enough for SOHO. >> >> This would allow 64share if used by 3GPP operators to work and would not >> require the 3GPP specification to be updated. We don=E2=80=99t know eve= n if the >> 3GPP architecture specification can be updated to support shorter prefix= es >> and if the 3GPP consortium of operators would agree to it. So that is a= ll >> theoretical of that change is possible. >> >> As with 5G with Enhanced VPN framework SR steering of high priority >> traffic, traffic isolation and Network slicing capabilities becomes >> mainstream and will soon be a real world reality and as fixed 5G broadba= nd >> proliferation takes off and mobile 5G =3D=3D the idea of a wearable /48 = will >> really be many /48s. >> >> As this paradigm shift takes place, operators around the world will be >> clamoring after the RIR for massive blocks, I would say less than /8 mor= e >> like a /5 or /4. If you do the math on the way high side a /10 yields 7 >> bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is tiny numbe= r >> with the number of large size operators worldwide. >> >> With the massive proliferation of IOT devices and just about every home >> or office appliance on 5G, the problem now gets way exacerbated. >> >> As this evolution unfolds IANA will be scrambling to release all >> remaining /3 as well as all unallocated blocks to subvert RIR IPv6 addre= ss >> space depletion. >> >> Playing Monday night quarterbacking in hindsight we would never think >> this would happen in a million years, but we would see IPv6 on the verge= of >> address space depletion. Unheard of but it can happen as the saying goe= s >> =E2=80=9Cwhen you build - they will come=E2=80=9D. >> >> It is true as history has taught that very important lesson. >> >> The answer to this real world problem is in the subject heading of this >> thread. >> >> This would also fix the day 1 issue I mentioned allowing mix of slaac >> devices with static and DHCPv6 up to /80. >> >> The variable slaac solution draft proposes a new RA PIO flag that would >> be used to signal longer prefixes, and would provide backwards >> compatibility so that devices not supporting woud ignore the flag and >> devices on newer code supporting would use the flag. We definitely don= =E2=80=99t >> want to impact any existing devices on the existing 64 bit slaac boundar= y >> standard. >> >> Dmytro has tested the solution on Linux kernel signaling RA PIO flag and >> was able to successfully test any length mask and random IID generation >> both RFC 4941 privacy extension as well as stable IID RFC 7217. >> >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >> >> If everyone is in agreement with what I have stated on this thread, I >> would like to ask the chairs for WG adoption as this is a WG effort. >> >> I would like to garner support from all 6MAN members with full consensus >> to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary= . >> >> Kind Regards >> >> Gyan >> >> On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >> wrote: >> >>> I am missing something in your reasoning. >>> You seem to say at one point that (to paraphrase) "we can't do this >>> because it does not work with the existing UE software". >>> Any new solution where a UE delegates based on any change of any kind >>> (including lengthening the prefix, shortening the prefix, or magically >>> incanting new prefixes) requires that the UE be upgraded to know what t= o >>> do with the information. I do not see how that differentiates any of >>> the solutions. (Except "don't do anything", which I think we do not wan= t >>> to take.) >>> >>> Yours, >>> Joel >>> >>> On 11/19/2020 5:03 PM, Gyan Mishra wrote: >>> > >>> > >>> > On Thu, Nov 19, 2020 at 10:33 AM >> > > wrote: >>> > >>> > >>> > >>> > > On 19 Nov 2020, at 14:58, Gyan Mishra >> > > wrote: >>> > > >>> > > You would need a new option. It would likely be useful for the >>> > requesting router to indicate interest in the option. Even hintin= g >>> > at what prefix size it was expecting. >>> > > Now can you explain to me again the reasons why this approach = is >>> > better than using the existing DHPCv6 protocol packets? >>> > > >>> > > 3GPP gateway does not support DHCPv6 >>> > >>> > 3GPP gateway doesn't support new option. What's your point? >>> > >>> > >>> > >>> > The point of the v6ops presentation and this email thread is how >>> to >>> > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of th= e deck you >>> compiled >>> > a list of options and of the two I had highlighted in red were the >>> > 64share v2 Cameron=E2=80=99s option and the variable slaac option. S= o on the >>> > call this morning Lorenzo shot down 64share v2 shorter prefix option >>> as >>> > even if the 3GPP architecture was updated to support longer prefixes >>> and >>> > even is the 3GPP gateway was able to send a shorter prefix with A fla= g >>> > not set, all mobile devices per Lorenzo=E2=80=99s point would be brok= en as >>> they >>> > would not accept the shorter let=E2=80=99s say /56 prefix to build th= e slaac >>> 128 >>> > bit address. So the bottom line is the 64share v2 won=E2=80=99t work= unless >>> we >>> > update RFC 4291 and remove the 64 bit boundary. >>> > >>> > So we are back to square uno - no viable solution >>> > >>> > So now we had thrown out the longer >64 due to race to bottom >>> worries >>> > which I and others believe is Fud and as described in slide 10 of the >>> > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. >>> > >>> > So a happy medium /80 fixed boundary I came up with that I think >>> solves >>> > a lot of the issue and not just the 3GPP initial segmentation of >>> > downstream devices problem statement. >>> > >>> > Since we have to update RFC 4291 for 64share v2 to work anyways to >>> allow >>> > for shorter prefixes, why not instead create a new bottom at /80 >>> giving >>> > 16 bits more of prefix length and shrinking the IID down to 48 bits. >>> > Doing so you would not even have to update the 3GPP architecture as I >>> > don=E2=80=99t know if that would fly or not. Also this solves a few = other >>> > problems at the same time. >>> > >>> > >>> > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is >>> > mainstream for operators for static addressing on router and switch >>> > infrastructure and dhcpv6 subnets longer prefixes for network >>> > infrastructure appliance clusters, NFV/VNF virtualization and server >>> > farms. On host subnets where there is a chance of mix of slaac hosts >>> > with dhcpv6 devices the prefix length is stuck at /64. So on these >>> mix >>> > addressing host subnets we cannot do longer prefixes following our ND >>> > cache hard limit mantra to prevent ND cache exhaustion issues as >>> > described in RFC 6164. >>> > >>> > So with the /80 new fixed boundary shifting prefix length 16 bits >>> longer >>> > and shortening the IID by 16 bits gives resolved the 3GPP issue which >>> > 64share can work as is and subtending to downstream devices will now >>> > work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 >>> > for broadband not all operators have adopted the shorter prefix >>> lengths >>> > /56 or /48 recommendations and now that=E2=80=99s not an issue as th= e /64 >>> would >>> > now suffice. >>> > >>> > From an operators perspective that gain allows at least for 3GPP >>> > massive growth and subtending with a single /64 allows the operators >>> > such as Verizon with massive subscriber base worldwide can stay with >>> > current allocations and don=E2=80=99t have to ask for /10. >>> > >>> > As 5G gets rolled out with Enhanced VPN framework and Network slicing >>> > paradigm, the demand for shorter blocks and wearable multiple /48 wil= l >>> > be our new reality. >>> > >>> > Making that 16 bit shift now to /80 making a /64 the new /48 will giv= e >>> > broadband and 3GPP subscribers a ton of space to subtending their >>> > networks we would be set for the future. Especially with IOT the >>> demand >>> > for subtending will continue to grow astronomically. >>> > >>> > Also IANA does not have to get start in allocating the other /3 and >>> > other available blocks. >>> > >>> > Lots of problems being solved here with a fixed /80 new boundary. >>> > >>> > Also with the existing random IID generation schemes which we have >>> > tested on Linux kernel can do longer p >>> refixes >>> using RFC 4941 privacy >>> > extension or RFC 7217 stable IID. >>> > >>> > Win-Win for all. >>> > >>> > Ole >>> > >>> > -- >>> > >>> > >>> > >>> > *Gyan Mishra* >>> > >>> > /Network Solutions A//rchitect / >>> > >>> > /M 301 502-1347 >>> > 13101 Columbia Pike >>> >>> >>> > >>> /Silver Spring, MD >>> >>> > >>> > >>> > >>> > _______________________________________________ >>> > v6ops mailing list >>> > v6ops@ietf.org >>> > https://www.ietf.org/mailman/listinfo/v6ops >>> > >>> >> -- >> >> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> *Silver >> Spring, MD >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000003eb84a05b4b75b40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C2=A0 =C2=A0 Gyan&= gt; I believe after the v6ops presentation I gave on the problem statement = as well as the countless threads and interest I think more folks think thei= r is an issue to be solved then don=E2=80=99t.=C2=A0 I think the problem is= clear. I never said that this is the only way to solve the problem.=C2=A0 = This is just one idea of a possible solution and there definitely maybe oth= ers that are better and I am not denying that.=C2=A0 Nothing premature as t= his is just and idea of one possible proposed solution.

I haven'= ;t accepted either of those things.

<= div dir=3D"auto">
I'm not happy with the idea of chang= ing away for 64 bit IIDs because I don't think 64 bit IIDs are the prob= lem. Plenty of operators have given out /56s. I'm working at my second = one. It is not impossible.=C2=A0

On Sat, Nov 21, 2020 at 12:48 AM Mark Smith <markzzzsmith@gmail.com> wrote:

=

On Sat, 21 Nov 2020, = 09:27 Gyan Mishra, <hayab= usagsm@gmail.com> wrote:

(top posting)=C2=A0

As I would like to clear the air = as well as get to the crux of the v6ops presentation development results as= well as next steps for this draft and the 6man variable slaac solutions dr= aft:


You&= #39;re asserting that everybody has accepted there is a problem to be solve= d, and that everybody has accepted that the only way to solve it is to chan= ge the default 64 bit IID size. This is both premature and not a representa= tion about "everybody's" opinion you can make.

=C2=A0 =C2=A0 Gyan> All of the c= ountess threads have all been spawned from the variable slaac problem state= ment draft and solution to change the 64 bit IID boundary.=C2=A0 There are = two sides to the camp of changing versus not changing as this idea to chang= e is not new as it comes up every few years with a fierce onslaught of thre= ads for and against.=C2=A0 Their is definitely interest in changing but thu= s far the balance of not changing as been the weighted majority over not ch= anging.=C2=A0 I am hoping this time around maybe we have a game changer of = a problem to be solved and the fixed 64 bit IID change gets close to workgr= oup consensus.
=

<= div dir=3D"auto">Many things below are incorrect, uninformed, or quite fran= kly ridiculous. Some read like you've let your imagination go wild and = then have just assumed because you can imagine it it will then inevitably h= appen in the near future.
<= br>
=C2=A0 =C2=A0Gyan> That is your POV.


For = example, DHCPv6 does not provide a prefix length to hosts. Your proposal do= es not make SLAAC "consistent' with what DHCPv6 does, because DHCP= v6 doesn't work the way you think it does (look up IA_NA and IA_TA in t= he DHCPv6 RFC).

=C2=A0 =C2=A0 Gyan> Understo= od.=C2=A0 I think you may have misunderstood what I meant and maybe I did n= ot state clearly and that=E2=80=99s my fault if the latter.=C2=A0 My point = is that DHCPv6 is length independent as the sever sends 128 bit managed add= ress M=3D1 to host. Point here is that both static and dhcpv6 are prefix le= ngth independent and slaac is fixed at 64 bit.=C2=A0 This does introduce in= compatibility issue with slaac host endpoints not having parity with dhcpv6= and static being prefix length agnostic. So as stated in the v6ops deck th= is prevents operators from having longer then 64 bit prefix lengths on host= subnets due to the 64 bit boundary.=C2=A0 I understand that there are many= addressing guidelines that state that due to this parity issue that /64 is= recommended for all host subnets. However operators would like this to cha= nge so that >64 prefix can be deployed to host subnets.

"the idea of a wearable /48 will really be many /= 48s"? Do you really think we're going to have more devices on our = person that we'll need more than 65 536 /64 subnets (a single /48) to n= umber them? That sounds like science fiction to me for at least the next 20= 0 years or more.
<= div dir=3D"auto">
Gyan> I did not start the o= riginal thread on =E2=80=9Cwearable=E2=80=9D /64. =C2=A0 Please see 6MAN ar= chives.=C2=A0 I just took that and ran with it based on future network infr= astructure developments upcoming and paradigm shift and a reality of a digi= tal transformation with 5G in the context of =E2=80=9Cnetwork slicing=E2=80= =9D which will require exorbitant amount of address space.=C2=A0 It=E2=80= =99s no different then concept of cloud computing and hypervisor virtualiza= tion which required many more addresses per VM as compare to physical serve= rs.=C2=A0 So now apply that to the wireless operators RAN front haul and ba= ckhaul xHaul virtualization framework with =E2=80=9Cnetwork slicing=E2=80= =9D game changer paradigm shift.

IPv6 isn't an= d isn't required to be the final and only Internet protocol for the rem= ainder of humanity, so we don't have to try to accommodate every concei= vable idea that somebody can come up with that might cause the 128 bit addr= ess space to be too small.
=C2=A0

This thread was in= light of Lorenzo kindly pointing out that upgrading 3GPP is not all that n= eeds be done for Cameron=E2=80=99s 64share v2 to work - as all mobile devic= es would stop working- as slaac would not would be effectively broken.

The mobile device would rece= ive a shorter prefix let=E2=80=99s say /56 but not know what to do with it = since it=E2=80=99s expecting a /64.

So that a major gap and the only solution is updating RFC 4291 = removing the 64 bit boundary allowing for shorter prefix and now as well lo= nger prefixes to work and in that respect now provide the much needed parit= y with static and DHCPv6 which can do any prefix length.

So that is a drastic change to RFC 4291.= =C2=A0 However, in light of this development on the v6ops 109 call, my bala= ncing act of best of both worlds and also to keep everyone happy to make th= is a WG effort for this change by proposing in the subject heading /80 fixe= d boundary and not a variable slaac change allowing all bits vlsm.

Basically stealing 16 bits for n= etwork prefix out of the IID, still keeping the fixed boundary so longer th= an 80 would NOT =C2=A0be allowed.

A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s= . =C2=A0

This /80 would = keep the operators and law enforcement happy as now 16 bits less helps trac= eability but is still long enough for 48 bits of privacy to IP correlation = by attackers.

This /80 w= ould be a nice optimal balance as it would keep wired broadband and mobile = handset customers happy respecting their privacy as the 16 bits less of heu= ristics is minimal change that will impact IP correlation by attackers.

The IID as it=E2=80=99s les= s than the current 64 bit cannot use MAC based EUI64 IID, which is not a pr= oblem as Mac based IID is not recommended as most all manufacturers use RFC= 4941 and I believe Linux flavors some use stable IID RFC 7217.

So now the 48 bit IID would require= a random IID generation schema so can use either RFC 4941 privacy extensio= n or RFC 7217 stable IID to generate the 48 bit IID.

3GPP subtending would now work issue mentioned= in the problem statement draft without even having to use 64share as now l= onger prefixes up to /80 would be supported allowing for further segmentati= on of downstream devices.

This also would help wired broadband and soon fixed 5G broadband prolifer= ation where operators in light of BCP RIPE-690, are sill allocation via BNG= gateways a /64, now operators =C2=A0can stay as-is, as the /64 would now b= e allowed to be further segmented supporting 64k /80s, way more then enough= for SOHO.

This would al= low 64share if used by 3GPP operators to work and would not require the 3GP= P specification to be updated.=C2=A0 We don=E2=80=99t know even if the 3GPP= architecture specification can be updated to support shorter prefixes and = if the 3GPP consortium of operators would agree to it.=C2=A0 So that is all= theoretical of that change is possible.

<= div dir=3D"auto">As with 5G with Enhanced VPN framework SR steering of high= priority traffic, traffic isolation and Network slicing capabilities becom= es mainstream and will soon be a real world reality and as fixed 5G broadba= nd proliferation takes off and mobile 5G =3D=3D the idea of a wearable /48 = will really be many /48s.=C2=A0

As this paradigm shift takes place, operators around the world wi= ll be clamoring after the RIR for massive blocks, I would say less than /8 = more like a /5 or /4.=C2=A0 If you do the math on the way high side a /10 y= ields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is tiny = number with the number of large size operators worldwide.=C2=A0

With the massive proliferation of I= OT devices and just about every home or office appliance on 5G, the problem= now gets way exacerbated.=C2=A0

As this evolution unfolds IANA will be scrambling to release all = remaining /3 as well as all unallocated blocks to subvert RIR IPv6 address = space depletion.

Playing= Monday night quarterbacking in hindsight we would never think this would h= appen in a million years, but we would see IPv6 on the verge of address spa= ce depletion.=C2=A0 Unheard of but it can happen as the saying goes =E2=80= =9Cwhen you build - they will come=E2=80=9D.

It is true as history has taught that very important l= esson.

The answer to thi= s real world problem is in the subject heading of this thread.

This would also fix the day 1 issue = I mentioned allowing mix of slaac devices with static and DHCPv6 up to /80.=

The variable slaac solu= tion draft proposes a new =C2=A0RA PIO flag that would be used to signal lo= nger prefixes, and would provide backwards compatibility so that devices no= t supporting woud ignore the flag =C2=A0and devices on newer code supportin= g would use the flag.=C2=A0 We definitely don=E2=80=99t want to impact any = existing devices on the existing 64 bit slaac boundary standard.

Dmytro has tested the solution on = Linux kernel signaling RA PIO flag and was able to successfully test any le= ngth mask and random IID generation both RFC 4941 privacy extension as well= as stable IID RFC 7217.

If everyone is in a= greement with what I have stated on this thread, I would like to ask the ch= airs for WG adoption as this is a WG effort.

I would like to garner support from all 6MAN members w= ith full consensus to change the existing RFC 4941 /64 fixed boundary to /8= 0 fixed boundary.

Kind R= egards=C2=A0

Gyan
<= div dir=3D"auto">
On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <= ;jmh@joelhalpern.co= m> wrote:
I am missing something in your r= easoning.
You seem to say at one point that (to paraphrase) "we can't do thi= s
because it does not work with the existing UE software".
Any new solution where a UE delegates based on any change of any kind
(including lengthening the prefix, shortening the prefix, or magically
incanting new prefixes) requires that the UE be upgraded to know what to do with the information.=C2=A0 I do not see how that differentiates any of =
the solutions. (Except "don't do anything", which I think we = do not want
to take.)

Yours,
Joel

On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>
>
> On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org
> <mailto:ot= roan@employees.org>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.co= m
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > You would need a new option. It would likely = be useful for the
>=C2=A0 =C2=A0 =C2=A0requesting router to indicate interest in the optio= n. Even hinting
>=C2=A0 =C2=A0 =C2=A0at what prefix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 > Now can you explain to me again the reasons w= hy this approach is
>=C2=A0 =C2=A0 =C2=A0better than using the existing DHPCv6 protocol pack= ets?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not supp= ort DHCPv6
>
>=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't support new option. What&#= 39;s your point?
>
>
>
>=C2=A0 =C2=A0 =C2=A0 The point of the v6ops presentation and this email= thread is how to
> =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 o= f the deck you compiled
> a list of options and of the two I had highlighted in red were the > 64share v2 Cameron=E2=80=99s option and the variable slaac option.=C2= =A0 So on the
> call this morning Lorenzo shot down 64share v2 shorter prefix option a= s
> even if the 3GPP architecture was updated to support longer prefixes a= nd
> even is the 3GPP gateway was able to send a shorter prefix with A flag=
> not set, all mobile devices per Lorenzo=E2=80=99s point would be broke= n as they
> would not accept the shorter let=E2=80=99s say /56 prefix to build the= slaac 128
> bit address.=C2=A0 So the bottom line is the 64share v2 won=E2=80=99t = work unless we
> update RFC 4291 and remove the 64 bit boundary.
>
>=C2=A0 =C2=A0So we are back to square uno - no viable solution
>
>=C2=A0 =C2=A0So now we had thrown out the longer >64 due to race to = bottom worries
> which I and others believe is Fud and as described in slide 10 of the =
> v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>
> So a happy medium /80 fixed boundary I came up with that I think solve= s
> a lot of the issue and not just the 3GPP initial segmentation of
> downstream devices problem statement.
>
> Since we have to update RFC 4291 for 64share v2 to work anyways to all= ow
> for shorter prefixes, why not instead create a new bottom at /80 givin= g
> 16 bits more of prefix length and shrinking the IID down to 48 bits.= =C2=A0
> Doing so you would not even have to update the 3GPP architecture as I =
> don=E2=80=99t know if that would fly or not.=C2=A0 Also this solves a = few other
> problems at the same time.
>
>
> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is
> mainstream for operators for static addressing on router and switch > infrastructure and dhcpv6 subnets longer prefixes for network
> infrastructure appliance clusters, NFV/VNF virtualization and server <= br> > farms.=C2=A0 On host subnets where there is a chance of mix of slaac h= osts
> with dhcpv6 =C2=A0devices the prefix length is stuck at /64.=C2=A0 So = on these mix
> addressing host subnets we cannot do longer prefixes following our ND =
> cache hard limit mantra to prevent ND cache exhaustion issues as
> described in RFC 6164.
>
> So with the /80 new fixed boundary shifting prefix length 16 bits long= er
> and shortening the IID by 16 bits gives resolved the 3GPP issue which =
> 64share can work as is and subtending to downstream devices will now <= br> > work as a /64 is now equivalent to a /48 with 64k /80s.=C2=A0 Also BCP= -690
> for broadband not all operators have adopted the shorter prefix length= s
> /56 or /48 recommendations =C2=A0and now that=E2=80=99s not an issue a= s the /64 would
> now suffice.
>
>=C2=A0 From an operators perspective that gain allows at least for 3GPP=
> massive growth and subtending with a single /64 allows the operators <= br> > such as Verizon with massive subscriber base worldwide can stay with <= br> > current allocations and don=E2=80=99t have to ask for /10.
>
> As 5G gets rolled out with Enhanced VPN framework and Network slicing =
> paradigm, the demand for shorter blocks and wearable multiple /48 will=
> be our new reality.
>
> Making that 16 bit shift now to /80 making a /64 the new /48 will give=
> broadband and 3GPP subscribers a ton of space to subtending their
> networks we would be set for the future.=C2=A0 Especially with IOT the= demand
> for subtending will continue to grow astronomically.
>
> Also IANA does not have to get start in allocating the other /3 and > other available blocks.
>
> Lots of problems being solved here with a fixed /80 new boundary.
>
> Also with the existing random IID generation schemes which we have > tested on Lin= ux kernel can do longer prefixes using RFC 4941 privacy
> extension or RFC 7217 stable IID.
>
> Win-Win for all.
>
>=C2=A0 =C2=A0 =C2=A0Ole
>
> --
>
> <ht= tp://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
 > /Silver Spring, M= D
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/v6ops
>
--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-134713101 Columbia Pike=C2=A0
Silver Spring, MD


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=
--------------------------------------------------------------------
--
--0000000000003eb84a05b4b75b40-- From nobody Sun Nov 22 12:10:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCA93A0C1D; Sun, 22 Nov 2020 12:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.93 X-Spam-Level: X-Spam-Status: No, score=0.93 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80CU1AKXKY1u; Sun, 22 Nov 2020 12:10:32 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD463A0C1B; Sun, 22 Nov 2020 12:10:32 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id j15so12021369oih.4; Sun, 22 Nov 2020 12:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m7QQ7U0FXlPlMWKGcTZ7Id06XE/G6oELz96dgSEhGjA=; b=Xb1YgFp6/HzoZdHk2XDlapPsMnf/mZvd8zDZ2dD+2IFwl7FT9w23D9H8KdXtrfirYd q/HMe2IPFyL8p19eAivfdt5ousthnhtyb7yJ9iFHTw9+pnmlaeUkn8XKRyb6vX8xmsoT Dp/94PM77QfTQOs6CP7DwGAfdVdtgztjtcj24JysvSLVllEEAiUsrtchzG1xaqW4eYZG pK9lTFID/2Fq42fVIFSHmOBiWNLbRhogSQGVp80bITrZAMDbX7IL4ErNI3z6Bg3Yclbh 1H61ipOiB4i1TkoEER6UcIrjKl4CWY7fd5y2x8jFvt3HLFJg5Qfag1W6Aua+YjAFHOxk fZeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m7QQ7U0FXlPlMWKGcTZ7Id06XE/G6oELz96dgSEhGjA=; b=h1n/YD3Flfuu3Vahq1PEZpkMYeGN9tvJ2digomhJ4X2FtddObK3+aWkz4+bzDWG+MQ A11rPWoV1XZnfT7ViX30ZlDHgug57u2VOoRZk5W2WdAlWWDuQ5Yj59vKQqlgJyLI3QC9 U0l3nxIEg2a3x6F0tEarPesqIPCnUikbffPGZtiZ/nkSOsSiiGc3Ap3lXZnJVdKoHI8x M5aemB/76pVxGharOPaiyPW8fIlYhQjnk3XH6NEO5qTUcBu89OtREQ8l3aflKDL71iYM CmZFqJC0y0y0U+25v7rxeLENNQY00c1gs6eUBTHLik5nARRNewcbpPKGvBZp+Pq4ltML fCRw== X-Gm-Message-State: AOAM530jQlXGa6zPRbqqUEpc/Kcv5qK/htrBsd4nSlpOMlGqxk8/VU6q dsd5aRO+TiBGzKL0FBAov7F5nAqW5shK81Ciz+M= X-Google-Smtp-Source: ABdhPJxTcSnjclpVcX1ZAlOWKf5PDsJ7LlFvmpSwyX3y4/bUKPjzvSHdzdiY0DqGuSSeCEMztqk+VLT/a0ICi68TJmQ= X-Received: by 2002:aca:d755:: with SMTP id o82mr12121620oig.164.1606075831415; Sun, 22 Nov 2020 12:10:31 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> In-Reply-To: From: Mark Smith Date: Mon, 23 Nov 2020 07:10:19 +1100 Message-ID: To: "Templin (US), Fred L" Cc: Ca By , Brian E Carpenter , IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000069f9a205b4b7ab70" Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 20:10:34 -0000 --00000000000069f9a205b4b7ab70 Content-Type: text/plain; charset="UTF-8" On Mon, 23 Nov 2020, 01:59 Templin (US), Fred L, wrote: > Hi, I believe the AERO/OMNI approach to prefix delegation would be good > for the 3GPP > case also. The approach is predicated on the router returning an RA with > an IPv6 link-local > destination address determined by the delegated prefix. The link-local > address is formed > by writing the most significant 64 bits of the delegated prefix into the > interface ID of the > prefix fe80::/64. > For example, if the delegated prefix were 2001:db8:1:0::/56 then the IPv6 > link-local > destination address is fe80::2001:db8:1:0. This provides at least two > important > operational advantages. > > 1) It conveys the delegated prefix in the IPv6 destination address of the > RA so that > no PIOs inside the RA need to be used for prefix delegation. > In my operational experience it is far better to make things explicit in packets rather than implicit. See RFC8469 for an example of where what was implicit in packets has caused so many problems that now being explicit has become the recommendation. (Absence of this in a wholesaler's network caused us and a customer months of troubleshooting for unusual performance problems, and is now costing us service outages for many customers at once while they put it in place.) > 2) It supplies the mobile node with a guaranteed-unique link-local address > that > it can use for future communications without the need to perform DAD. So the RA DA is carries both delegated prefix information and with link-local address configuration too? How does a node know to use the RA DA as its link-local address? With the rise of wireless we need to care about the global traceability of link-local addresses too. Persistent, globally unique link-local IIDs have the same privacy implications as persistent globally unique WiFi MAC addresses and Bluetooth MAC addresses. Have a look at https://wigle.net and the Android app for collecting the data. A similar app focused on Bluetooth is Ramble. Neither of these apps require a hacked phone, the can just be installed and run by anybody from the Google app store. > Again, the proposal comes from the AERO/OMNI use case, but I believe is > also > good for 3GPP and really any other wireless use case where a lightweight > prefix delegation capability is desired. > > Fred > --00000000000069f9a205b4b7ab70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= /div>
Have a look at https://wigle.net and the Andr= oid app for collecting the data.=C2=A0

A similar app focused on Bluetooth is Ramble.

Neither of these apps require a hacke= d phone, the can just be installed and run by anybody from the Google app s= tore.


Again, the proposal comes from the AERO/OMNI use case, but I believe is als= o
good for 3GPP and really any other wireless use case where a lightweight prefix delegation capability is desired.

Fred


On Mon, 23 Nov 2020, 01:59 Templin (US), Fred L, <<= a href=3D"mailto:Fred.L.Templin@boeing.com" rel=3D"noreferrer noreferrer no= referrer noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"= _blank">Fred.L.Templin@boeing.com> wrote:
Hi, I believe the AERO/OMNI approach to prefix delegation wou= ld be good for the 3GPP
case also. The approach is predicated on the router returning an RA with an= IPv6 link-local
destination address determined by the delegated prefix. The link-local addr= ess is formed
by writing the most significant 64 bits of the delegated prefix into the in= terface ID of the
prefix fe80::/64.

For example, if the delegated prefix were 2001:db8:1:0::/56 then the IPv6 l= ink-local
destination address is fe80::2001:db8:1:0. This provides at least two impor= tant
operational advantages.

1) It conveys the delegated prefix in the IPv6 destination address of the R= A so that
no PIOs inside the RA need to be used for prefix delegation.

In my operation= al experience it is far better to make things explicit in packets rather th= an implicit.

See RFC8469= for an example of where what was implicit in packets has caused so many pr= oblems that now being explicit has become the recommendation. (Absence of t= his in a wholesaler's network caused us and a customer months of troubl= eshooting for unusual performance problems, and is now costing us service o= utages for many customers at once while they put it in place.)



2) It supplies the mobile node with a guaranteed-unique link-local address = that
it can use for future communications without the need to perform DAD.


=
So the RA DA is carries both delegated prefix information= and with link-local address configuration too? How does a node know to use= the RA DA as its link-local address?

With the rise of wireless we need to care about the global tr= aceability of link-local addresses too. Persistent, globally unique link-lo= cal IIDs have the same privacy implications as persistent globally unique W= iFi MAC addresses and Bluetooth MAC addresses.
--00000000000069f9a205b4b7ab70-- From nobody Sun Nov 22 19:12:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A303A1213; Sun, 22 Nov 2020 19:12:31 -0800 (PST) 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=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 h0hBE2-J1ZJb; Sun, 22 Nov 2020 19:12:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7E33A120B; Sun, 22 Nov 2020 19:12:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5512E389B6; Sun, 22 Nov 2020 22:13:39 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lbv2l5vB7jUI; Sun, 22 Nov 2020 22:13:38 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 30033389B5; Sun, 22 Nov 2020 22:13:38 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2FA247D; Sun, 22 Nov 2020 22:12:25 -0500 (EST) From: Michael Richardson To: IPv6 Operations , 6MAN <6man@ietf.org> In-Reply-To: References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 03:12:31 -0000 --=-=-= Content-Type: text/plain Ca By wrote: >> Don't they think DHCPv6 infrastructure will scale? Is it just that they >> don't know how to scale it? >> > Definitely do not know how. I had a look at the dhcpv6 rfc and it was over > 150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr. Yes, because it details with dozens of different things. IPv6-PD is only one section, and on circuits (vs ethernet), almost of the lifetime management stuff is moot. Also, you can't write BGP4 and read only one document, so your comparison is just not on. I've written PD-only DHCPv6 for a BMS (PPPoE). The daemon is about 2000 lines of C, including test cases. Most of the logic is about learning about new interfaces and decoding Radius TLVs. (Not really open source, sorry) I thought about writing an LWIG document on this, but decided not to. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+7KJgACgkQgItw+93Q 3WXBvQf/XxH0Wow9WCwzNDht0fF8h4XU8htRThupr4Tksy6ZhZC/qEeKMXkse+B8 Dd5IQdsTNo5g+x5m1aF2oJ/o0rWQ42k+PK34VNjpo2Ct24qaakhTjd/ex4xmueL/ 9P/headMSCbBnAEXEibfst0CrwhWlrYb4yWULUkztlWJ14AxqhRuRYeng+KoGHpX o5Q+7B6I4D9zfjMGEaKy2uBlLAUBW/vxnECJ7fLpyvRLEYA03nUhXSH6cWLZ9lKX kK9jPe7FhIrxnjuIs2qhIUZ7V/ZqnTjhWN+vmD3cHBKC/8ZMv0c7bZYppLDl5x9O xoyEeigCSWfqbQBVQj/8COy/GUPRxg== =vkMm -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 22 22:41:18 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2393A14CD; Sun, 22 Nov 2020 22:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyLl6ghIIHUm; Sun, 22 Nov 2020 22:41:11 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9633A149C; Sun, 22 Nov 2020 22:41:11 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id s63so3455864pgc.8; Sun, 22 Nov 2020 22:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mBPHgKOmI84GMxJNTf8IDH6aGWTwkolw24bC4/2uqjQ=; b=D4wJCf/d/N+GOcjceWD7LLvqhsxzcTla1Yi8/evIcwQn5OfjElY36qkV1CkO8tF3KD T+cS8qKobrMBZH/CAIBV3CuwPzmcggGyZ8f4MaYz5Vde/GNBQcqwWBcqrP2/IM4H7Ie5 fv8zs740YCeI+k8NlVnY88rN7FVhTYvJQWoNMss0Xw7zwgN9Foy7HMCXGdjkiu+5xAsk 0q9bS5vz8fQWZFm1D9U487jfedYDnuNAYv6gxmw1FT0Wea8a47I0ZfgXnjUdnhxH5n8s s3pDXzhksXJ/ywAoJwwVYdO9LqePjpEmeUim0XjRM9ai60dutzbZdmvf3h2n5B6iaHB7 V3XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mBPHgKOmI84GMxJNTf8IDH6aGWTwkolw24bC4/2uqjQ=; b=huhTSoOAcZT7fkuavquGLhXmrOjRkUrB71G+cFUsrzdjs3iwxWb6ZY48Rcfe0dNlay TrgIH44EMCeWZy56SD6+48YBiXad1k6i8nH/jREQwFZ4i9U80PufyL5ia3/ddG4EDAAG ypLwxh9bnaPFPnqALl4EpQZ7Ko1Ry4QQj6OgxLM3qKxFURdaw/4ffpVJhjFu0IDuGdqd ZTQgfcdVPG+QOaIpXvQljVgieBS21d/Pfiq4rZahQMHCb2ydkEXaSn1dWAPpsVe9Ck1U r6uBlYMC5+/FGrGF/3+Qo4KK3K214qtYOIonY0fDOs4bfwbab2Yck3LaY2JW9kFvUoBK zD8g== X-Gm-Message-State: AOAM532kQ2PqHZwYdz1tCorDOPqBHgkXk2lTy3Uu3bP53S5whhjQYkjQ v+IOK0cRj99kteGs92zXWT9TQGNYa5+mszC/6OY= X-Google-Smtp-Source: ABdhPJzFlIOjg9PIQOejvdyZc/sqZM2/RjHeT7HE2J6iSBrTgOtAFK1d1AgmEHvvS76lpBgZgMRmITn5vvKM8nJ9f8o= X-Received: by 2002:a65:4241:: with SMTP id d1mr25507614pgq.18.1606113670416; Sun, 22 Nov 2020 22:41:10 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> <24b3cb7e-989f-2b99-f019-74b6d39c424b@joelhalpern.com> In-Reply-To: <24b3cb7e-989f-2b99-f019-74b6d39c424b@joelhalpern.com> From: Gyan Mishra Date: Mon, 23 Nov 2020 01:40:59 -0500 Message-ID: To: "Joel M. Halpern" Cc: 6MAN <6man@ietf.org>, IPv6 Operations , Mark Smith Content-Type: multipart/alternative; boundary="000000000000cb4f1205b4c07a2d" Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 06:41:17 -0000 --000000000000cb4f1205b4c07a2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 21, 2020 at 10:26 AM Joel M. Halpern wrote: > As I understand it, the situation is not that 3GPP has not defined use > of DHCP. But rather than operators have uniformly declined to deploy > it. (3GPP has defined DHCP for 5G for fixed access. We have heard here > that even that is not what the operators want.) As such, asking 3GPP > why they didn't deploy it seems a bit odd. Gyan> One possible non technical factor is that Android which as of 2019 statistical data below holds 87% of the global mobile market share and Apple 13% and Android is continuing to climb in 2020. Android adamantly refuses to change its position on support of DHCPv6. I think that really shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all mobile handsets won=E2=80=99t support it. https://www.statista.com/statistics/272307/market-share-forecast-for-smartp= hone-operating-systems/ > > Yours, > Joel > > On 11/20/2020 11:19 PM, Mark Smith wrote: > > > > > > On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, > > > > wrote: > > > > Joel, > > > > It seems to me that it's high time to draft a liaison statement to > 3GPP, > > observing that: > > > > (1) There is a serious problem for the design and implementation of > > 5G-based IPv6 "hot spots" and CEs [which is where this conversation > > started]; > > > > > > I think it is also important to find out why they haven't deployed > > DHCPv6 to solve this problem. > > > > Don't they think DHCPv6 infrastructure will scale? Is it just that they > > don't know how to scale it? > > > > Is it a vendor / mobile operator / handset developer DHCPv6 > > capability chicken-and-egg problem? > > > > Is there an overriding business or industry reason? > > > > The mobile industry has been resistant to tethering over the years, and > > probably only came to begrudgingly accept it because they couldn't > > prevent phone vendors from implementing Wifi and NAT, and couldn't very > > effectively stop their customers from using that capability (One trick > > I've heard of to prevent tethering working was to check if an IPv4 > > packet's TTL value was 64 when it arrived at the network, meaning it > > originated from the directly attached handset. Packets from tethered > > devices had a TTL of 63 so were dropped. Of course, you could set the > > default TTL on a tethered PC to 65 to get around that.) > > > > I guess there might be a fairly strong mindset that there must be a fee > > per device attached to the network in addition to a fee for network > > utilisation. Providing multiple /64s would be formally acknowledging > > that multiple devices can be attached and a fee per device isn't and > > can't ever be charged, counter to the mindset. > > > > Regards, > > Mark. > > > > > > (2) Although the best solution is not yet obvious, defining and > > standardizing it will require a joint effort by the IETF and 3GPP. > > > > Followed by a proposal to form an ad hoc joint design team. > > > > Regards > > Brian Carpenter > > On 21-Nov-20 14:46, Joel M. Halpern wrote: > > > The nesting got me lost, so I will top post my take on the answe= r > > to the > > > one quesiton I could understand. > > > > > > I believe you asked what I think would need to be changed to > > permit the > > > delegation. > > > As with anything, the real things that need to change are the > > devices in > > > the network. > > > > > > With regard to IETF standards, what is proposed is a change to R= A. > > > There are several possible changes. None of them require a > > change to > > > the IPv6 addressing archtiecture, as the addressing structure > > remains as > > > it is. > > > As for the exact mechanism, at the moment I lean towards Ole's > > proposal > > > of using a new option in his generic option mechanism. But I am > not > > > wedded to that answer. > > > > > > And of course, to get this supported in mobile environments we > > will have > > > to work with 3GPP and make sure there are no other hidden issues= . > > > That's the way we do things. Work together. > > > > > > Changing the prefix length to /80 is technically also possible. > > It does > > > a lot more violence to my understanding of the architecture and > > software > > > structures that go with it, and is a very limited and narrow > > solution to > > > the problem. > > > > > > Yours, > > > Joel > > > > > > On 11/20/2020 7:58 PM, Gyan Mishra wrote: > > >> Hi Joel > > >> > > >> In-line > > >> > > >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern > > > > >> >> > wrote: > > >> > > >> Gyan, separate from Ole's comments about the difference > > between address > > >> assignment and delegation, I have another problem following > the > > >> reasoning below. > > >> > > >> Yes, the proposal for using shorter prefixes to enable UE t= o > > perform > > >> delegation will require changes to the UE. > > >> > > >> Gyan> Agreed. So that change would be to RFC 4291 64 bit > > boundary > > >> to allow for longer prefix. Do you agree? > > >> > > >> If you don=E2=80=99t agree what do think the change would be to= allow > > the UE to > > >> accept shorter prefix from the 3GPP gateway? > > >> > > >> > > >> But I do not see how that is relevant to any choice we are > > trying to > > >> make. > > >> Any solution that enables UE to delegate addresses (in the > > sense that > > >> they lack the capability now) willr equire changes to the U= E. > > >> > > >> > > >> > > >> Gyan> If the UE receives a /56 via RA it could delegate /64 > to > > >> downstream devices. No change needed to delegate /64, > > however a > > >> change is needed to accept /56 via RA. > > >> > > >> > > >> If 3GPP gateway supported PD - problem solved but that=E2= =80=99s > > not the > > >> case and that does not sound like it will ever change even with > 5G. > > >> > > >> Gyan> The UE needs to be able to accept shorter prefix. > > That=E2=80=99s the > > >> IPV6 specification change that requires removal of the 64 bit > > boundary. > > >> > > >> Yoru > > >> proposed change to the SLAAC length if anything does more > > violence to > > >> the software (depending upon the exact software > architecture.) > > >> > > >> > > >> Gyan> What violence to software. There would be more > > violence to > > >> software if we removed the 64 bit boundary and allowed slaac to > > support > > >> any vlsm prefix lengths. > > >> > > >> My /80 proposal would just shift the boundary 16 bits to /80. > > >> > > >> Hosts on the same subnet with two different masks would not be > > on-net to > > >> each other as on different subnets. The router would be > > configured with > > >> the two subnets /64 and /80 subnet to support the two device > types. > > >> The solution would be a simple RA PIO flag that is set and olde= r > > hosts > > >> not upgraded would be backwards compatible and so would only > > support 64 > > >> bit boundary by ignoring flag. Hosts upgraded to support would > > >> understand the flag and be able to support longer mask up to /8= 0. > > >> > > >> > > >> > > >> So I do not follow how you got to your conclusion. > > >> > > >> Yours, > > >> Joel > > >> > > >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: > > >> > > > >> > (top posting) > > >> > > > >> > As I would like to clear the air as well as get to the > > crux of > > >> the v6ops > > >> > presentation development results as well as next steps > > for this > > >> draft > > >> > and the 6man variable slaac solutions draft: > > >> > > > >> > > > >> > This thread was in light of Lorenzo kindly pointing out > that > > >> upgrading > > >> > 3GPP is not all that needs be done for Cameron=E2=80=99s= 64share > > v2 to > > >> work - as > > >> > all mobile devices would stop working- as slaac would no= t > > would be > > >> > effectively broken. > > >> > > > >> > The mobile device would receive a shorter prefix let=E2= =80=99s > > say /56 > > >> but not > > >> > know what to do with it since it=E2=80=99s expecting a /= 64. > > >> > > > >> > So that a major gap and the only solution is updating RF= C > > 4291 > > >> removing > > >> > the 64 bit boundary allowing for shorter prefix and now > > as well > > >> longer > > >> > prefixes to work and in that respect now provide the muc= h > > needed > > >> parity > > >> > with static and DHCPv6 which can do any prefix length. > > >> > > > >> > So that is a drastic change to RFC 4291. However, in > > light of this > > >> > development on the v6ops 109 call, my balancing act of > > best of both > > >> > worlds and also to keep everyone happy to make this a WG > > effort > > >> for this > > >> > change by proposing in the subject heading /80 fixed > > boundary and > > >> not a > > >> > variable slaac change allowing all bits vlsm. > > >> > > > >> > Basically stealing 16 bits for network prefix out of the > > IID, still > > >> > keeping the fixed boundary so longer than 80 would NOT > > be allowed. > > >> > > > >> > A /64 would now be equivalent to a /48 with now 64k /80= =E2=80=99s. > > >> > > > >> > This /80 would keep the operators and law enforcement > > happy as > > >> now 16 > > >> > bits less helps traceability but is still long enough fo= r > > 48 bits of > > >> > privacy to IP correlation by attackers. > > >> > > > >> > This /80 would be a nice optimal balance as it would kee= p > > wired > > >> > broadband and mobile handset customers happy respecting > their > > >> privacy as > > >> > the 16 bits less of heuristics is minimal change that > > will impact IP > > >> > correlation by attackers. > > >> > > > >> > The IID as it=E2=80=99s less than the current 64 bit can= not use > > MAC based > > >> EUI64 > > >> > IID, which is not a problem as Mac based IID is not > > recommended > > >> as most > > >> > all manufacturers use RFC 4941 and I believe Linux > > flavors some use > > >> > stable IID RFC 7217. > > >> > > > >> > So now the 48 bit IID would require a random IID > generation > > >> schema so > > >> > can use either RFC 4941 privacy extension or RFC 7217 > > stable IID to > > >> > generate the 48 bit IID. > > >> > > > >> > 3GPP subtending would now work issue mentioned in the > problem > > >> statement > > >> > draft without even having to use 64share as now longer > > prefixes > > >> up to > > >> > /80 would be supported allowing for further segmentation > of > > >> downstream > > >> > devices. > > >> > > > >> > This also would help wired broadband and soon fixed 5G > > broadband > > >> > proliferation where operators in light of BCP RIPE-690, > > are sill > > >> > allocation via BNG gateways a /64, now operators can > > stay as-is, > > >> as the > > >> > /64 would now be allowed to be further segmented > > supporting 64k > > >> /80s, > > >> > way more then enough for SOHO. > > >> > > > >> > This would allow 64share if used by 3GPP operators to > > work and > > >> would not > > >> > require the 3GPP specification to be updated. We don=E2= =80=99t > > know even > > >> if the > > >> > 3GPP architecture specification can be updated to suppor= t > > shorter > > >> > prefixes and if the 3GPP consortium of operators would > > agree to > > >> it. So > > >> > that is all theoretical of that change is possible. > > >> > > > >> > As with 5G with Enhanced VPN framework SR steering of > > high priority > > >> > traffic, traffic isolation and Network slicing > > capabilities becomes > > >> > mainstream and will soon be a real world reality and as > > fixed 5G > > >> > broadband proliferation takes off and mobile 5G =3D=3D t= he > > idea of a > > >> > wearable /48 will really be many /48s. > > >> > > > >> > As this paradigm shift takes place, operators around the > > world > > >> will be > > >> > clamoring after the RIR for massive blocks, I would say > > less than /8 > > >> > more like a /5 or /4. If you do the math on the way hig= h > > side a /10 > > >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs pe= r > RIR > > >> which is > > >> > tiny number with the number of large size operators > > worldwide. > > >> > > > >> > With the massive proliferation of IOT devices and just > about > > >> every home > > >> > or office appliance on 5G, the problem now gets way > > exacerbated. > > >> > > > >> > As this evolution unfolds IANA will be scrambling to > > release all > > >> > remaining /3 as well as all unallocated blocks to subver= t > > RIR IPv6 > > >> > address space depletion. > > >> > > > >> > Playing Monday night quarterbacking in hindsight we woul= d > > never > > >> think > > >> > this would happen in a million years, but we would see > > IPv6 on > > >> the verge > > >> > of address space depletion. Unheard of but it can happe= n > > as the > > >> saying > > >> > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. > > >> > > > >> > It is true as history has taught that very important > lesson. > > >> > > > >> > The answer to this real world problem is in the subject > > heading > > >> of this > > >> > thread. > > >> > > > >> > This would also fix the day 1 issue I mentioned allowing > > mix of > > >> slaac > > >> > devices with static and DHCPv6 up to /80. > > >> > > > >> > The variable slaac solution draft proposes a new RA PIO > flag > > >> that would > > >> > be used to signal longer prefixes, and would provide > > backwards > > >> > compatibility so that devices not supporting woud ignore > > the flag > > >> and > > >> > devices on newer code supporting would use the flag. We > > definitely > > >> > don=E2=80=99t want to impact any existing devices on the= existing > > 64 bit > > >> slaac > > >> > boundary standard. > > >> > > > >> > Dmytro has tested the solution on Linux kernel signaling > > RA PIO > > >> flag and > > >> > was able to successfully test any length mask and random > IID > > >> generation > > >> > both RFC 4941 privacy extension as well as stable IID RF= C > > 7217. > > >> > > > >> > > > >> > > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > > > > >> > > < > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ < > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>> > > >> > > > >> > > < > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ < > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/> > > >> > > < > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ < > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>> > > >> > > > >> > If everyone is in agreement with what I have stated on > this > > >> thread, I > > >> > would like to ask the chairs for WG adoption as this is = a > > WG effort. > > >> > > > >> > I would like to garner support from all 6MAN members wit= h > > full > > >> consensus > > >> > to change the existing RFC 4941 /64 fixed boundary to /8= 0 > > fixed > > >> boundary. > > >> > > > >> > Kind Regards > > >> > > > >> > Gyan > > >> > > > >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern > > >> > > > > > >> > > > >>> wrote: > > >> > > > >> > I am missing something in your reasoning. > > >> > You seem to say at one point that (to paraphrase) "w= e > > can't > > >> do this > > >> > because it does not work with the existing UE > software". > > >> > Any new solution where a UE delegates based on any > > change of > > >> any kind > > >> > (including lengthening the prefix, shortening the > > prefix, or > > >> magically > > >> > incanting new prefixes) requires that the UE be > > upgraded to know > > >> > what to > > >> > do with the information. I do not see how that > > >> differentiates any of > > >> > the solutions. (Except "don't do anything", which I > > think we > > >> do not > > >> > want > > >> > to take.) > > >> > > > >> > Yours, > > >> > Joel > > >> > > > >> > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > >> > > > > >> > > > > >> > > On Thu, Nov 19, 2020 at 10:33 AM > > > > >> > > > >> > > > >> > > >> > > > > > > > >> > > >>>> > wrote: > > >> > > > > >> > > > > >> > > > > >> > > > On 19 Nov 2020, at 14:58, Gyan Mishra > > >> > > > > > > >> > > >> > > >> > > > > > >> >> > > >> > > > > >> > >>>> wrote: > > >> > > > > > >> > > > You would need a new option. It would > likely be > > >> useful for the > > >> > > requesting router to indicate interest in the > > option. Even > > >> > hinting > > >> > > at what prefix size it was expecting. > > >> > > > Now can you explain to me again the reason= s > > why this > > >> > approach is > > >> > > better than using the existing DHPCv6 protoco= l > > packets? > > >> > > > > > >> > > > 3GPP gateway does not support DHCPv6 > > >> > > > > >> > > 3GPP gateway doesn't support new option. > > What's your > > >> point? > > >> > > > > >> > > > > >> > > > > >> > > The point of the v6ops presentation and this > > email > > >> thread is > > >> > how to > > >> > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use ca= se in slide 1 of > the > > >> deck you > > >> > compiled > > >> > > a list of options and of the two I had highlighte= d > > in red > > >> were the > > >> > > 64share v2 Cameron=E2=80=99s option and the varia= ble slaac > > >> option. So on > > >> > the > > >> > > call this morning Lorenzo shot down 64share v2 > > shorter prefix > > >> > option as > > >> > > even if the 3GPP architecture was updated to > > support longer > > >> > prefixes and > > >> > > even is the 3GPP gateway was able to send a > > shorter prefix > > >> with A > > >> > flag > > >> > > not set, all mobile devices per Lorenzo=E2=80=99s= point > > would be > > >> broken > > >> > as they > > >> > > would not accept the shorter let=E2=80=99s say /5= 6 prefix > > to build the > > >> > slaac 128 > > >> > > bit address. So the bottom line is the 64share v= 2 > > won=E2=80=99t work > > >> > unless we > > >> > > update RFC 4291 and remove the 64 bit boundary. > > >> > > > > >> > > So we are back to square uno - no viable soluti= on > > >> > > > > >> > > So now we had thrown out the longer >64 due to > > race to > > >> bottom > > >> > worries > > >> > > which I and others believe is Fud and as describe= d > in > > >> slide 10 of > > >> > the > > >> > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. > > >> > > > > >> > > So a happy medium /80 fixed boundary I came up > > with that I > > >> think > > >> > solves > > >> > > a lot of the issue and not just the 3GPP initial > > >> segmentation of > > >> > > downstream devices problem statement. > > >> > > > > >> > > Since we have to update RFC 4291 for 64share v2 t= o > > work > > >> anyways > > >> > to allow > > >> > > for shorter prefixes, why not instead create a ne= w > > bottom > > >> at /80 > > >> > giving > > >> > > 16 bits more of prefix length and shrinking the > > IID down > > >> to 48 bits. > > >> > > Doing so you would not even have to update the 3G= PP > > >> architecture > > >> > as I > > >> > > don=E2=80=99t know if that would fly or not. Als= o this > > solves a > > >> few other > > >> > > problems at the same time. > > >> > > > > >> > > > > >> > > As I mentioned in the v6ops deck presented that > > vlsm 0 to > > >> 128 is > > >> > > mainstream for operators for static addressing on > > router > > >> and switch > > >> > > infrastructure and dhcpv6 subnets longer prefixes > > for network > > >> > > infrastructure appliance clusters, NFV/VNF > > virtualization > > >> and server > > >> > > farms. On host subnets where there is a chance o= f > > mix of > > >> slaac > > >> > hosts > > >> > > with dhcpv6 devices the prefix length is stuck a= t > > /64. So on > > >> > these mix > > >> > > addressing host subnets we cannot do longer > > prefixes following > > >> > our ND > > >> > > cache hard limit mantra to prevent ND cache > exhaustion > > >> issues as > > >> > > described in RFC 6164. > > >> > > > > >> > > So with the /80 new fixed boundary shifting prefi= x > > length > > >> 16 bits > > >> > longer > > >> > > and shortening the IID by 16 bits gives resolved > > the 3GPP > > >> issue > > >> > which > > >> > > 64share can work as is and subtending to downstre= am > > >> devices will now > > >> > > work as a /64 is now equivalent to a /48 with 64k > > /80s. Also > > >> > BCP-690 > > >> > > for broadband not all operators have adopted the > > shorter > > >> prefix > > >> > lengths > > >> > > /56 or /48 recommendations and now that=E2=80=99= s not an > > issue as the > > >> > /64 would > > >> > > now suffice. > > >> > > > > >> > > From an operators perspective that gain allows a= t > > least > > >> for 3GPP > > >> > > massive growth and subtending with a single /64 > > allows the > > >> operators > > >> > > such as Verizon with massive subscriber base > > worldwide can > > >> stay with > > >> > > current allocations and don=E2=80=99t have to ask > > >> > > < > https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have= +to+ask?entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have= +to+ask?entry=3Dgmail&source=3Dg > >> > > >> for /10. > > >> > > > > >> > > As 5G gets rolled out with Enhanced VPN framework > > and Network > > >> > slicing > > >> > > paradigm, the demand for shorter blocks and > wearable > > >> multiple /48 > > >> > will > > >> > > be our new reality. > > >> > > > > >> > > Making that 16 bit shift now to /80 making a /64 > > the new > > >> /48 will > > >> > give > > >> > > broadband and 3GPP subscribers a ton of space to > > >> subtending their > > >> > > networks we would be set for the future. > > Especially with > > >> IOT the > > >> > demand > > >> > > for subtending will continue to grow > astronomically. > > >> > > > > >> > > Also IANA does not have to get start in allocatin= g > the > > >> other /3 and > > >> > > other available blocks. > > >> > > > > >> > > Lots of problems being solved here with a fixed > > /80 new > > >> boundary. > > >> > > > > >> > > Also with the existing random IID generation > > schemes which > > >> we have > > >> > > tested on Linux kernel can do longer p > > >> > > > >> > > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg> > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > < > https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p= ?entry=3Dgmail&source=3Dg > >>>refixes > > >> > using RFC 4941 privacy > > >> > > extension or RFC 7217 stable IID. > > >> > > > > >> > > Win-Win for all. > > >> > > > > >> > > Ole > > >> > > > > >> > > -- > > >> > > > > >> > > > > > > > >> > > >>> > > >> > > > > >> > > *Gyan Mishra* > > >> > > > > >> > > /Network Solutions A//rchitect / > > >> > > > > >> > > /M 301 502-1347 > > >> > > 13101 Columbia Pike > > >> > > /Silver Spring, MD > > >> > > > > >> > > > > >> > > > > >> > > _______________________________________________ > > >> > > v6ops mailing list > > >> > > v6ops@ietf.org > > > > > >> > > >> > > >> > > https://www.ietf.org/mailman/listinfo/v6ops > > > > >> > > > > >> > > > > >> > >> > > >> > > > > >> > > > >> > -- > > >> > > > >> > > > >> > > >> > > > >> > *Gyan Mishra* > > >> > > > >> > /Network Solutions A//rchitect / > > >> > > > >> > /M 301 502-1347 > > >> > 13101 Columbia Pike > > >> > /Silver Spring, MD > > >> > > > >> > > > >> > > >> -- > > >> > > >> > > > >> > > >> *Gyan Mishra* > > >> > > >> /Network Solutions A//rchitect / > > >> > > >> /M 301 502-1347 > > >> 13101 Columbia Pike > > >> /Silver Spring, MD > > >> > > >> > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------= - > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000cb4f1205b4c07a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 21, 2020 at 10:26 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
As I understand it, the situation is not t= hat 3GPP has not defined use
of DHCP.=C2=A0 But rather than operators have uniformly declined to deploy =
it.=C2=A0 (3GPP has defined DHCP for 5G for fixed access.=C2=A0 We have hea= rd here
that even that is not what the operators want.)=C2=A0 As such, asking 3GPP =
why they didn't deploy it seems a bit odd.

=C2=A0 =C2=A0 Gyan> One possible non techn= ical factor is that Android which as of 2019 statistical data below holds 8= 7% of the global mobile market share and Apple 13% and Android is continuin= g to climb in 2020. =C2=A0 Android adamantly refuses to change its position= on support of DHCPv6.=C2=A0 I think that really shackles 3GPP carriers fro= m supporting DHCPv6 is close to 100% of all mobile handsets won=E2=80=99t s= upport it.




Yours,
Joel

On 11/20/2020 11:19 PM, Mark Smith wrote:
>
>
> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter,
> <b= rian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wro= te:
>
>=C2=A0 =C2=A0 =C2=A0Joel,
>
>=C2=A0 =C2=A0 =C2=A0It seems to me that it's high time to draft a l= iaison statement to 3GPP,
>=C2=A0 =C2=A0 =C2=A0observing that:
>
>=C2=A0 =C2=A0 =C2=A0(1) There is a serious problem for the design and i= mplementation of
>=C2=A0 =C2=A0 =C2=A05G-based IPv6 "hot spots" and CEs [which = is where this conversation
>=C2=A0 =C2=A0 =C2=A0started];
>
>
> I think it is also important to find out why they haven't deployed=
> DHCPv6 to solve this=C2=A0problem.
>
> Don't they think DHCPv6 infrastructure will scale? Is it just that= they
> don't know how to scale it?
>
> Is it a vendor / mobile operator / handset developer DHCPv6
> capability=C2=A0chicken-and-egg problem?
>
> Is there an overriding business or industry reason?
>
> The mobile industry has been resistant to tethering over the years, an= d
> probably only came to begrudgingly accept it because they couldn't=
> prevent phone vendors from implementing Wifi and NAT, and couldn't= very
> effectively stop their customers from using that capability (One trick=
> I've heard of to prevent tethering working was to check if an IPv4=
> packet's=C2=A0TTL value was 64 when it arrived at the network, mea= ning it
> originated from the directly attached handset. Packets from tethered <= br> > devices had a TTL of 63 so were dropped. Of course, you could set the =
> default TTL on a tethered=C2=A0PC to 65 to get around that.)
>
> I guess there might be a fairly strong mindset that there must be a fe= e
> per device attached to the network in addition to a fee for network > utilisation. Providing multiple /64s would be formally acknowledging <= br> > that multiple devices can be attached and a fee per device isn't a= nd
> can't ever be charged, counter to the mindset.
>
> Regards,
> Mark.
>
>
>=C2=A0 =C2=A0 =C2=A0(2) Although the best solution is not yet obvious, = defining and
>=C2=A0 =C2=A0 =C2=A0standardizing it will require a joint effort by the= IETF and 3GPP.
>
>=C2=A0 =C2=A0 =C2=A0Followed by a proposal to form an ad hoc joint desi= gn team.
>
>=C2=A0 =C2=A0 =C2=A0Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian Carpenter
>=C2=A0 =C2=A0 =C2=A0On 21-Nov-20 14:46, Joel M. Halpern wrote:
>=C2=A0 =C2=A0 =C2=A0 > The nesting got me lost, so I will top post m= y take on the answer
>=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 > one quesiton I could understand.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I believe you asked what I think would need t= o be changed to
>=C2=A0 =C2=A0 =C2=A0permit the
>=C2=A0 =C2=A0 =C2=A0 > delegation.
>=C2=A0 =C2=A0 =C2=A0 > As with anything, the real things that need t= o change are the
>=C2=A0 =C2=A0 =C2=A0devices in
>=C2=A0 =C2=A0 =C2=A0 > the network.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > With regard to IETF standards, what is propos= ed is a change to RA.
>=C2=A0 =C2=A0 =C2=A0 > There are several possible changes.=C2=A0 Non= e of them require a
>=C2=A0 =C2=A0 =C2=A0change to
>=C2=A0 =C2=A0 =C2=A0 > the IPv6 addressing archtiecture, as the addr= essing structure
>=C2=A0 =C2=A0 =C2=A0remains as
>=C2=A0 =C2=A0 =C2=A0 > it is.
>=C2=A0 =C2=A0 =C2=A0 > As for the exact mechanism, at the moment I l= ean towards Ole's
>=C2=A0 =C2=A0 =C2=A0proposal
>=C2=A0 =C2=A0 =C2=A0 > of using a new option in his generic option m= echanism.=C2=A0 But I am not
>=C2=A0 =C2=A0 =C2=A0 > wedded to that answer.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > And of course, to get this supported in mobil= e environments we
>=C2=A0 =C2=A0 =C2=A0will have
>=C2=A0 =C2=A0 =C2=A0 > to work with 3GPP and make sure there are no = other hidden issues.
>=C2=A0 =C2=A0 =C2=A0 > That's the way we do things.=C2=A0 Work t= ogether.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Changing the prefix length to /80 is technica= lly also possible.
>=C2=A0 =C2=A0 =C2=A0It does
>=C2=A0 =C2=A0 =C2=A0 > a lot more violence to my understanding of th= e architecture and
>=C2=A0 =C2=A0 =C2=A0software
>=C2=A0 =C2=A0 =C2=A0 > structures that go with it, and is a very lim= ited and narrow
>=C2=A0 =C2=A0 =C2=A0solution to
>=C2=A0 =C2=A0 =C2=A0 > the problem.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Yours,
>=C2=A0 =C2=A0 =C2=A0 > Joel
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On 11/20/2020 7:58 PM, Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >> Hi Joel
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> In-line
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. H= alpern
>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>=C2=A0 =C2=A0 =C2=A0 >> <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>= > wrote:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan, separate from Ol= e's comments about the difference
>=C2=A0 =C2=A0 =C2=A0between address
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0assignment and delegat= ion, I have another problem following the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0reasoning below.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Yes, the proposal for = using shorter prefixes to enable UE to
>=C2=A0 =C2=A0 =C2=A0perform
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0delegation will requir= e changes to the UE.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 Gyan> Agreed.=C2= =A0 So that change would be to RFC 4291 64 bit
>=C2=A0 =C2=A0 =C2=A0boundary
>=C2=A0 =C2=A0 =C2=A0 >> to allow for longer prefix.=C2=A0 Do you = agree?
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> If you don=E2=80=99t agree what do think = the change would be to allow
>=C2=A0 =C2=A0 =C2=A0the UE to
>=C2=A0 =C2=A0 =C2=A0 >> accept shorter prefix from the 3GPP gatew= ay?
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0But I do not see how t= hat is relevant to any choice we are
>=C2=A0 =C2=A0 =C2=A0trying to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0make.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Any solution that enab= les UE to delegate addresses (in the
>=C2=A0 =C2=A0 =C2=A0sense that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0they lack the capabili= ty now) willr equire changes to the UE.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan> If the UE rec= eives a /56 via RA it could delegate /64 to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0downstream devices.=C2= =A0 No change needed to delegate =C2=A0/64,
>=C2=A0 =C2=A0 =C2=A0however a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0change is needed to ac= cept /56 via RA.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 If 3GPP gateway suppo= rted PD - problem solved but that=E2=80=99s
>=C2=A0 =C2=A0 =C2=A0not the
>=C2=A0 =C2=A0 =C2=A0 >> case and that does not sound like it will= ever change even with 5G.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan> The UE needs = to be able to accept shorter prefix.
>=C2=A0 =C2=A0 =C2=A0That=E2=80=99s the
>=C2=A0 =C2=A0 =C2=A0 >> IPV6 specification change that requires r= emoval of the 64 bit
>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Yoru
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0proposed change to the= SLAAC length if anything does more
>=C2=A0 =C2=A0 =C2=A0violence to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0the software (dependin= g upon the exact software architecture.)
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan> What violence= to software.=C2=A0 There would be more
>=C2=A0 =C2=A0 =C2=A0violence to
>=C2=A0 =C2=A0 =C2=A0 >> software if we removed the 64 bit boundar= y and allowed slaac to
>=C2=A0 =C2=A0 =C2=A0support
>=C2=A0 =C2=A0 =C2=A0 >> any vlsm prefix lengths.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> My /80 proposal would just shift the boun= dary 16 bits to /80.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Hosts on the same subnet with two differe= nt masks would not be
>=C2=A0 =C2=A0 =C2=A0on-net to
>=C2=A0 =C2=A0 =C2=A0 >> each other as on different subnets.=C2=A0= The router would be
>=C2=A0 =C2=A0 =C2=A0configured with
>=C2=A0 =C2=A0 =C2=A0 >> the two subnets /64 and /80 subnet to sup= port the two device types.
>=C2=A0 =C2=A0 =C2=A0 >> The solution would be a simple RA PIO fla= g that is set and older
>=C2=A0 =C2=A0 =C2=A0hosts
>=C2=A0 =C2=A0 =C2=A0 >> not upgraded would be backwards compatibl= e and so would only
>=C2=A0 =C2=A0 =C2=A0support 64
>=C2=A0 =C2=A0 =C2=A0 >> bit boundary by ignoring flag. Hosts upgr= aded to support would
>=C2=A0 =C2=A0 =C2=A0 >> understand the flag and be able to suppor= t longer mask up to /80.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0So I do not follow how= you got to your conclusion.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Joel
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0On 11/20/2020 5:27 PM,= Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > (top posting) >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As I would like = to clear the air as well as get to the
>=C2=A0 =C2=A0 =C2=A0crux of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0the v6ops
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > presentation dev= elopment results as well as next steps
>=C2=A0 =C2=A0 =C2=A0for this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0draft
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > and the 6man var= iable slaac solutions draft:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This thread was = in light of Lorenzo kindly pointing out that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0upgrading
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 3GPP is not all = that needs be done for Cameron=E2=80=99s 64share
>=C2=A0 =C2=A0 =C2=A0v2 to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0work - as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > all mobile devic= es would stop working- as slaac would not
>=C2=A0 =C2=A0 =C2=A0would be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > effectively brok= en.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The mobile devic= e would receive a shorter prefix let=E2=80=99s
>=C2=A0 =C2=A0 =C2=A0say /56
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0but not
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > know what to do = with it since it=E2=80=99s expecting a /64.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > So that a major = gap and the only solution is updating RFC
>=C2=A0 =C2=A0 =C2=A04291
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0removing
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > the 64 bit bound= ary allowing for shorter prefix and now
>=C2=A0 =C2=A0 =C2=A0as well
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0longer
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > prefixes to work= and in that respect now provide the much
>=C2=A0 =C2=A0 =C2=A0needed
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0parity
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > with static and = DHCPv6 which can do any prefix length.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > So that is a dra= stic change to RFC 4291.=C2=A0 However, in
>=C2=A0 =C2=A0 =C2=A0light of this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > development on t= he v6ops 109 call, my balancing act of
>=C2=A0 =C2=A0 =C2=A0best of both
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > worlds and also = to keep everyone happy to make this a WG
>=C2=A0 =C2=A0 =C2=A0effort
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0for this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > change by propos= ing in the subject heading /80 fixed
>=C2=A0 =C2=A0 =C2=A0boundary and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0not a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > variable slaac c= hange allowing all bits vlsm.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Basically steali= ng 16 bits for network prefix out of the
>=C2=A0 =C2=A0 =C2=A0IID, still
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > keeping the fixe= d boundary so longer than 80 would NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be allowed.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > A /64 would now = be equivalent to a /48 with now 64k /80=E2=80=99s.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This /80 would k= eep the operators and law enforcement
>=C2=A0 =C2=A0 =C2=A0happy as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0now 16
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > bits less helps = traceability but is still long enough for
>=C2=A0 =C2=A0 =C2=A048 bits of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > privacy to IP co= rrelation by attackers.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This /80 would b= e a nice optimal balance as it would keep
>=C2=A0 =C2=A0 =C2=A0wired
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > broadband and mo= bile handset customers happy respecting their
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0privacy as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > the 16 bits less= of heuristics is minimal change that
>=C2=A0 =C2=A0 =C2=A0will impact IP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > correlation by a= ttackers.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The IID as it=E2= =80=99s less than the current 64 bit cannot use
>=C2=A0 =C2=A0 =C2=A0MAC based
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0EUI64
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > IID, which is no= t a problem as Mac based IID is not
>=C2=A0 =C2=A0 =C2=A0recommended
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0as most
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > all manufacturer= s use RFC 4941 and I believe Linux
>=C2=A0 =C2=A0 =C2=A0flavors some use
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > stable IID RFC 7= 217.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > So now the 48 bi= t IID would require a random IID generation
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0schema so
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > can use either R= FC 4941 privacy extension or RFC 7217
>=C2=A0 =C2=A0 =C2=A0stable IID to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > generate the 48 = bit IID.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 3GPP subtending = would now work issue mentioned in the problem
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0statement
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > draft without ev= en having to use 64share as now longer
>=C2=A0 =C2=A0 =C2=A0prefixes
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0up to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /80 would be sup= ported allowing for further segmentation of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0downstream
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > devices.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This also would = help wired broadband and soon fixed 5G
>=C2=A0 =C2=A0 =C2=A0broadband
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > proliferation wh= ere operators in light of BCP RIPE-690,
>=C2=A0 =C2=A0 =C2=A0are sill
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > allocation via B= NG gateways a /64, now operators =C2=A0can
>=C2=A0 =C2=A0 =C2=A0stay as-is,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0as the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /64 would now be= allowed to be further segmented
>=C2=A0 =C2=A0 =C2=A0supporting 64k
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/80s,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > way more then en= ough for SOHO.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This would allow= 64share if used by 3GPP operators to
>=C2=A0 =C2=A0 =C2=A0work and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0would not
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > require the 3GPP= specification to be updated.=C2=A0 We don=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0know even
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0if the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 3GPP architectur= e specification can be updated to support
>=C2=A0 =C2=A0 =C2=A0shorter
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > prefixes and if = the 3GPP consortium of operators would
>=C2=A0 =C2=A0 =C2=A0agree to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 So
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > that is all theo= retical of that change is possible.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As with 5G with = Enhanced VPN framework SR steering of
>=C2=A0 =C2=A0 =C2=A0high priority
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > traffic, traffic= isolation and Network slicing
>=C2=A0 =C2=A0 =C2=A0capabilities becomes
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > mainstream and w= ill soon be a real world reality and as
>=C2=A0 =C2=A0 =C2=A0fixed 5G
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > broadband prolif= eration takes off and mobile 5G =3D=3D the
>=C2=A0 =C2=A0 =C2=A0idea of a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > wearable /48 wil= l really be many /48s.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As this paradigm= shift takes place, operators around the
>=C2=A0 =C2=A0 =C2=A0world
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0will be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > clamoring after = the RIR for massive blocks, I would say
>=C2=A0 =C2=A0 =C2=A0less than /8
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > more like a /5 o= r /4.=C2=A0 If you do the math on the way high
>=C2=A0 =C2=A0 =C2=A0side a /10
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > yields 7 bits so= 128 divided by 5 RIRs yields 24 ISPs per RIR
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0which is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > tiny number with= the number of large size operators
>=C2=A0 =C2=A0 =C2=A0worldwide.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > With the massive= proliferation of IOT devices and just about
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0every home
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > or office applia= nce on 5G, the problem now gets way
>=C2=A0 =C2=A0 =C2=A0exacerbated.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As this evolutio= n unfolds IANA will be scrambling to
>=C2=A0 =C2=A0 =C2=A0release all
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > remaining /3 as = well as all unallocated blocks to subvert
>=C2=A0 =C2=A0 =C2=A0RIR IPv6
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > address space de= pletion.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Playing Monday n= ight quarterbacking in hindsight we would
>=C2=A0 =C2=A0 =C2=A0never
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0think
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > this would happe= n in a million years, but we would see
>=C2=A0 =C2=A0 =C2=A0IPv6 on
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0the verge
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > of address space= depletion.=C2=A0 Unheard of but it can happen
>=C2=A0 =C2=A0 =C2=A0as the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0saying
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > goes =E2=80=9Cwh= en you build - they will come=E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > It is true as hi= story has taught that very important lesson.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The answer to th= is real world problem is in the subject
>=C2=A0 =C2=A0 =C2=A0heading
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0of this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > thread.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This would also = fix the day 1 issue I mentioned allowing
>=C2=A0 =C2=A0 =C2=A0mix of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > devices with sta= tic and DHCPv6 up to /80.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The variable sla= ac solution draft proposes a new =C2=A0RA PIO flag
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0that would
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > be used to signa= l longer prefixes, and would provide
>=C2=A0 =C2=A0 =C2=A0backwards
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > compatibility so= that devices not supporting woud ignore
>=C2=A0 =C2=A0 =C2=A0the flag
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > devices on newer= code supporting would use the flag.=C2=A0 We
>=C2=A0 =C2=A0 =C2=A0definitely
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t wa= nt to impact any existing devices on the existing
>=C2=A0 =C2=A0 =C2=A064 bit
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > boundary standar= d.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Dmytro has teste= d the solution on Linux kernel signaling
>=C2=A0 =C2=A0 =C2=A0RA PIO
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0flag and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > was able to succ= essfully test any length mask and random IID
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0generation
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > both RFC 4941 pr= ivacy extension as well as stable IID RFC
>=C2=A0 =C2=A0 =C2=A07217.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0https://da= tatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>=C2=A0 =C2=A0 =C2=A0<https:= //datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <= ;https://datatracker.ietf.org/doc/= draft-mishra-6man-variable-slaac/>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <= ;https://datatracker.ietf.org/doc/= draft-mishra-6man-variable-slaac/>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <= ;https://datatracker.ietf.org/doc/= draft-mishra-6man-variable-slaac/>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > If everyone is i= n agreement with what I have stated on this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0thread, I
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > would like to as= k the chairs for WG adoption as this is a
>=C2=A0 =C2=A0 =C2=A0WG effort.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > I would like to = garner support from all 6MAN members with
>=C2=A0 =C2=A0 =C2=A0full
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0consensus
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > to change the ex= isting RFC 4941 /64 fixed boundary to /80
>=C2=A0 =C2=A0 =C2=A0fixed
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Kind Regards
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Gyan
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, = 2020 at 5:14 PM Joel M. Halpern
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com= >
>=C2=A0 =C2=A0 =C2=A0<mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com= <mailto:jmh@jo= elhalpern.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>> w= rote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0I am missing something in your reasoning.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0You seem to say at one point that (to paraphrase) "we
>=C2=A0 =C2=A0 =C2=A0can't
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0do this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0because it does not work with the existing UE software".
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Any new solution where a UE delegates based on any
>=C2=A0 =C2=A0 =C2=A0change of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0any kind
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0(including lengthening the prefix, shortening the
>=C2=A0 =C2=A0 =C2=A0prefix, or
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0magically
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0incanting new prefixes) requires that the UE be
>=C2=A0 =C2=A0 =C2=A0upgraded to know
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0what to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0do with the information.=C2=A0 I do not see how that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0differentiates any of<= br> >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0the solutions. (Except "don't do anything", which I
>=C2=A0 =C2=A0 =C2=A0think we
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0do not
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0want
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0to take.)
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Yours,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Joel
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > On Thu, Nov 19, 2020 at 10:33 AM
>=C2=A0 =C2=A0 =C2=A0<otroan@employees.org <mailto:otroan@employees.org>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <= ;mailto:otroan@em= ployees.org>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:otr= oan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org> <mailto:otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > <mailto:otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org> <mailto:otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <= ;mailto:otroan@em= ployees.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailto:otroan@employees.org>>>&g= t;> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at 14:58, Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<hayabusag= sm@gmail.com <mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com &= lt;mailto:hayabu= sagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com &= lt;mailto:hayabu= sagsm@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:ha= yabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 > You would need a new option. It would lik= ely be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0useful for the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0requesting router to indicate interest in the >=C2=A0 =C2=A0 =C2=A0option. Even
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0hinting
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0at what prefix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 > Now can you explain to me again the reaso= ns
>=C2=A0 =C2=A0 =C2=A0why this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0approach is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0better than using the existing DHPCv6 protocol<= br> >=C2=A0 =C2=A0 =C2=A0packets?
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not = support DHCPv6
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't support new option. >=C2=A0 =C2=A0 =C2=A0What's your
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0point?
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 The point of the v6ops presentation and this >=C2=A0 =C2=A0 =C2=A0email
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0thread is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0how to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2=A0in slide= 1 of the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0deck you
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0compiled
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > a list of options and of the two I had highlighted
>=C2=A0 =C2=A0 =C2=A0in red
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0were the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 64share v2 Cameron=E2=80=99s option and the variable slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0option.=C2=A0 So on >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > call this morning Lorenzo shot down 64share v2
>=C2=A0 =C2=A0 =C2=A0shorter prefix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0option as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > even if the 3GPP architecture was updated to
>=C2=A0 =C2=A0 =C2=A0support longer
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0prefixes and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > even is the 3GPP gateway was able to send a
>=C2=A0 =C2=A0 =C2=A0shorter prefix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0with A
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0flag
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > not set, all mobile devices per Lorenzo=E2=80=99s point
>=C2=A0 =C2=A0 =C2=A0would be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0broken
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0as they
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > would not accept the shorter let=E2=80=99s say /56 prefix
>=C2=A0 =C2=A0 =C2=A0to build the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0slaac 128
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > bit address.=C2=A0 So the bottom line is the 64share v2
>=C2=A0 =C2=A0 =C2=A0won=E2=80=99t work
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0unless we
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > update RFC 4291 and remove the 64 bit boundary.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0So we are back to square uno - no viable solution
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0So now we had thrown out the longer >64 due to
>=C2=A0 =C2=A0 =C2=A0race to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0bottom
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0worries
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > which I and others believe is Fud and as described in
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slide 10 of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > So a happy medium /80 fixed boundary I came up
>=C2=A0 =C2=A0 =C2=A0with that I
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0think
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0solves
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > a lot of the issue and not just the 3GPP initial
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0segmentation of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > downstream devices problem statement.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Since we have to update RFC 4291 for 64share v2 to
>=C2=A0 =C2=A0 =C2=A0work
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0anyways
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0to allow
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > for shorter prefixes, why not instead create a new
>=C2=A0 =C2=A0 =C2=A0bottom
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0at /80
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0giving
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 16 bits more of prefix length and shrinking the
>=C2=A0 =C2=A0 =C2=A0IID down
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0to 48 bits.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Doing so you would not even have to update the 3GPP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0architecture
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0as I
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > don=E2=80=99t know if that would fly or not.=C2=A0 Also this
>=C2=A0 =C2=A0 =C2=A0solves a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0few other
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > problems at the same time.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > As I mentioned in the v6ops deck presented that
>=C2=A0 =C2=A0 =C2=A0vlsm 0 to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0128 is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > mainstream for operators for static addressing on
>=C2=A0 =C2=A0 =C2=A0router
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0and switch
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > infrastructure and dhcpv6 subnets longer prefixes
>=C2=A0 =C2=A0 =C2=A0for network
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > infrastructure appliance clusters, NFV/VNF
>=C2=A0 =C2=A0 =C2=A0virtualization
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0and server
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > farms.=C2=A0 On host subnets where there is a chance of
>=C2=A0 =C2=A0 =C2=A0mix of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0hosts
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > with dhcpv6 =C2=A0devices the prefix length is stuck at
>=C2=A0 =C2=A0 =C2=A0/64.=C2=A0 So on
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0these mix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > addressing host subnets we cannot do longer
>=C2=A0 =C2=A0 =C2=A0prefixes following
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0our ND
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > cache hard limit mantra to prevent ND cache exhaustion
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0issues as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > described in RFC 6164.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > So with the /80 new fixed boundary shifting prefix
>=C2=A0 =C2=A0 =C2=A0length
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A016 bits
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0longer
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > and shortening the IID by 16 bits gives resolved
>=C2=A0 =C2=A0 =C2=A0the 3GPP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0issue
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0which
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 64share can work as is and subtending to downstream
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0devices will now
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > work as a /64 is now equivalent to a /48 with 64k
>=C2=A0 =C2=A0 =C2=A0/80s.=C2=A0 Also
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0BCP-690
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > for broadband not all operators have adopted the
>=C2=A0 =C2=A0 =C2=A0shorter
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0prefix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0lengths
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /56 or /48 recommendations =C2=A0and now that=E2=80=99s not an
>=C2=A0 =C2=A0 =C2=A0issue as the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0/64 would
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > now suffice.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 From an operators perspective that gain allows at
>=C2=A0 =C2=A0 =C2=A0least
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0for 3GPP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > massive growth and subtending with a single /64
>=C2=A0 =C2=A0 =C2=A0allows the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0operators
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > such as Verizon with massive subscriber base
>=C2=A0 =C2=A0 =C2=A0worldwide can
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0stay with
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > current allocations and don=E2=80=99t have to ask
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/sea= rch/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=3Dgmail&source= =3Dg <https://www.google.com/maps/search/ent+allocations+an= d+don%E2%80%99t+have+to+ask?entry=3Dgmail&source=3Dg>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0for /10.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > As 5G gets rolled out with Enhanced VPN framework
>=C2=A0 =C2=A0 =C2=A0and Network
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0slicing
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > paradigm, the demand for shorter blocks and wearable
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0multiple /48
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0will
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > be our new reality.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Making that 16 bit shift now to /80 making a /64
>=C2=A0 =C2=A0 =C2=A0the new
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/48 will
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0give
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > broadband and 3GPP subscribers a ton of space to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0subtending their
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > networks we would be set for the future.
>=C2=A0 =C2=A0 =C2=A0Especially with
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0IOT the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0demand
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > for subtending will continue to grow astronomically.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Also IANA does not have to get start in allocating the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0other /3 and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > other available blocks.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Lots of problems being solved here with a fixed
>=C2=A0 =C2=A0 =C2=A0/80 new
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Also with the existing random IID generation
>=C2=A0 =C2=A0 =C2=A0schemes which
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0we have
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > tested on Linux kernel can do longer p
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/tes= ted+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg <= https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?e= ntry=3Dgmail&source=3Dg> <https://www.google.com/maps/sear= ch/tested+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg = <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+long= er+p?entry=3Dgmail&source=3Dg>>>refixes
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0using RFC 4941 privacy
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > extension or RFC 7217 stable IID.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Win-Win for all.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0Ole
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > --
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > <http://www.verizon.com/ <http://www.verizon.com/> >=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.c= om/ <http://www.verizon.com/>
>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > _______________________________________________
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > v6ops@ietf.org= <mailto:v6ops@i= etf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > https://www.ietf.org/mailman/listinfo/v6ops<= br> >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<= https://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<https://www.ietf.org/mailman/listinfo/v6ops >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<= https://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > <http://www.ver= izon.com/ <http://www.verizon.com/>
>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra* >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /Network Solutio= ns A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347<= br> >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia P= ike
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, = MD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> --
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> <http://www.verizon.com/ <http://ww= w.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 >> 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 >> /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailma= n/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0= ipv6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://w= ww.ietf.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/l= istinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--000000000000cb4f1205b4c07a2d-- From nobody Sun Nov 22 22:55:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420EF3A1511; Sun, 22 Nov 2020 22:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R42C9PpIMNCN; Sun, 22 Nov 2020 22:55:16 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEAB3A1503; Sun, 22 Nov 2020 22:55:16 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id l11so8393164plt.1; Sun, 22 Nov 2020 22:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p1GcOxn0ZzilSWes1dL2cBXcpzucgzQeyf/dYc5/SYg=; b=m8nRzyddkORaOg0u5oIEzcw7RewEkVNAWNPfcgvjTi5cOPONYdvRZIS7JtumeqIzl0 DW70sHR2E9Fduz3SW05EKbPQyHJcPlAQ4CT8M0lyr6pnrw06sGaPh6owEURhNQNMTxZq 6b8wEflNqGdQHbuKqc/EZwhQ44EabYCJJntQuApPOBC5zAUQeEfSqfxY8ETnhXdkg3PX XdfCfMBCV2YjDhR7VKiFGYSYHHpN9Jq6cFyZWAb0Y42hTSe/Wr1/B6wYmErMPBJ4Lj+E uVZ53gJm+zxeqEBE7+8W1xO/zpmQwQsHn433dCfIQXpifU2WViijxCD4fN1CTEj9x6qU 7/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p1GcOxn0ZzilSWes1dL2cBXcpzucgzQeyf/dYc5/SYg=; b=pMG5kO0ZFschmae9NZcQCkaBR5D8hUJguHXBu7j66IznY6kwup4e1oO2jpuisgZOm3 Ao3FXqd3N9QrjXoEcBZT6Dxe3mWCpev1IUQ486UGSpbtqBA5mCBOf5BUdxeZ0o7xA8a1 DgPfEWB2nzvdxY1uXEtX1ht2vK7oPNfxxetXiMmAZF1JSp9wsaRTk/d/7lKJ7KQEMAIl 3p7tqNrbiH0gPmN7CN9Sf72MV1K0drsoka9HlJ6LnikSBurqq3HHZW72Go3/H7zH5ljV 8Ce7z5vmC9DwZzfEG7VFTU3vO3UNi+idrwBs+3XAs6iZUha6naG8gD8Rj2sElGmp1V8K Li8w== X-Gm-Message-State: AOAM53227GpxZCTNi/RL1EEjUH34tKXAvCtO8eETLpNOUz8Z7IioHHDd 0Ds+zZigwws/i2oftW+soRpCtFnJmXnWqrdmUWF1EMuxNJA= X-Google-Smtp-Source: ABdhPJyshnk6V/FtkKsrRW6HbtSo9qx7uLAFE0O/YIzREVfaw7of7lWXHv2mclhSLxm9/LZM1ZNg/L0n2FBvmdkN5yE= X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr23825631pll.22.1606114515552; Sun, 22 Nov 2020 22:55:15 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> <24b3cb7e-989f-2b99-f019-74b6d39c424b@joelhalpern.com> In-Reply-To: From: Gyan Mishra Date: Mon, 23 Nov 2020 01:55:04 -0500 Message-ID: To: "Joel M. Halpern" Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000002b0b4205b4c0ad7d" Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 06:55:21 -0000 --0000000000002b0b4205b4c0ad7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2020 at 1:41 AM Gyan Mishra wrote: > > > On Sat, Nov 21, 2020 at 10:26 AM Joel M. Halpern > wrote: > >> As I understand it, the situation is not that 3GPP has not defined use >> of DHCP. But rather than operators have uniformly declined to deploy >> it. (3GPP has defined DHCP for 5G for fixed access. We have heard here >> that even that is not what the operators want.) As such, asking 3GPP >> why they didn't deploy it seems a bit odd. > > > Gyan> One possible non technical factor is that Android which as of > 2019 statistical data below holds 87% of the global mobile market share a= nd > Apple 13% and Android is continuing to climb in 2020. Android adamantly > refuses to change its position on support of DHCPv6. I think that really > shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all > mobile handsets won=E2=80=99t support it. > > > https://www.statista.com/statistics/272307/market-share-forecast-for-smar= tphone-operating-systems/ > > Gyan> I have spoken with executives at Google and in talks related to Chromebook DHCPv6 support, they said that their development platform is a common platform for both Android and Chromebook and that for mobile handsets they cannot change and gave their technical justifications. Based on that feedback, 3GPP operators are really stuck between a rock and hard place and cannot change to support DHCPv6 as close to 90% of the market share is Android.Their maybe some other technical reasons as well on the operator gateway side which I would have to research if one exist as well why they won=E2=80=99t adopt PD. > > >> >> Yours, >> Joel >> >> On 11/20/2020 11:19 PM, Mark Smith wrote: >> > >> > >> > On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, >> > > >> wrote: >> > >> > Joel, >> > >> > It seems to me that it's high time to draft a liaison statement to >> 3GPP, >> > observing that: >> > >> > (1) There is a serious problem for the design and implementation o= f >> > 5G-based IPv6 "hot spots" and CEs [which is where this conversatio= n >> > started]; >> > >> > >> > I think it is also important to find out why they haven't deployed >> > DHCPv6 to solve this problem. >> > >> > Don't they think DHCPv6 infrastructure will scale? Is it just that the= y >> > don't know how to scale it? >> > >> > Is it a vendor / mobile operator / handset developer DHCPv6 >> > capability chicken-and-egg problem? >> > >> > Is there an overriding business or industry reason? >> > >> > The mobile industry has been resistant to tethering over the years, an= d >> > probably only came to begrudgingly accept it because they couldn't >> > prevent phone vendors from implementing Wifi and NAT, and couldn't ver= y >> > effectively stop their customers from using that capability (One trick >> > I've heard of to prevent tethering working was to check if an IPv4 >> > packet's TTL value was 64 when it arrived at the network, meaning it >> > originated from the directly attached handset. Packets from tethered >> > devices had a TTL of 63 so were dropped. Of course, you could set the >> > default TTL on a tethered PC to 65 to get around that.) >> > >> > I guess there might be a fairly strong mindset that there must be a fe= e >> > per device attached to the network in addition to a fee for network >> > utilisation. Providing multiple /64s would be formally acknowledging >> > that multiple devices can be attached and a fee per device isn't and >> > can't ever be charged, counter to the mindset. >> > >> > Regards, >> > Mark. >> > >> > >> > (2) Although the best solution is not yet obvious, defining and >> > standardizing it will require a joint effort by the IETF and 3GPP. >> > >> > Followed by a proposal to form an ad hoc joint design team. >> > >> > Regards >> > Brian Carpenter >> > On 21-Nov-20 14:46, Joel M. Halpern wrote: >> > > The nesting got me lost, so I will top post my take on the answ= er >> > to the >> > > one quesiton I could understand. >> > > >> > > I believe you asked what I think would need to be changed to >> > permit the >> > > delegation. >> > > As with anything, the real things that need to change are the >> > devices in >> > > the network. >> > > >> > > With regard to IETF standards, what is proposed is a change to >> RA. >> > > There are several possible changes. None of them require a >> > change to >> > > the IPv6 addressing archtiecture, as the addressing structure >> > remains as >> > > it is. >> > > As for the exact mechanism, at the moment I lean towards Ole's >> > proposal >> > > of using a new option in his generic option mechanism. But I a= m >> not >> > > wedded to that answer. >> > > >> > > And of course, to get this supported in mobile environments we >> > will have >> > > to work with 3GPP and make sure there are no other hidden issue= s. >> > > That's the way we do things. Work together. >> > > >> > > Changing the prefix length to /80 is technically also possible. >> > It does >> > > a lot more violence to my understanding of the architecture and >> > software >> > > structures that go with it, and is a very limited and narrow >> > solution to >> > > the problem. >> > > >> > > Yours, >> > > Joel >> > > >> > > On 11/20/2020 7:58 PM, Gyan Mishra wrote: >> > >> Hi Joel >> > >> >> > >> In-line >> > >> >> > >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern >> > >> > >> >> >> wrote: >> > >> >> > >> Gyan, separate from Ole's comments about the difference >> > between address >> > >> assignment and delegation, I have another problem followin= g >> the >> > >> reasoning below. >> > >> >> > >> Yes, the proposal for using shorter prefixes to enable UE = to >> > perform >> > >> delegation will require changes to the UE. >> > >> >> > >> Gyan> Agreed. So that change would be to RFC 4291 64 bit >> > boundary >> > >> to allow for longer prefix. Do you agree? >> > >> >> > >> If you don=E2=80=99t agree what do think the change would be t= o allow >> > the UE to >> > >> accept shorter prefix from the 3GPP gateway? >> > >> >> > >> >> > >> But I do not see how that is relevant to any choice we are >> > trying to >> > >> make. >> > >> Any solution that enables UE to delegate addresses (in the >> > sense that >> > >> they lack the capability now) willr equire changes to the >> UE. >> > >> >> > >> >> > >> >> > >> Gyan> If the UE receives a /56 via RA it could delegate /6= 4 >> to >> > >> downstream devices. No change needed to delegate /64, >> > however a >> > >> change is needed to accept /56 via RA. >> > >> >> > >> >> > >> If 3GPP gateway supported PD - problem solved but that=E2= =80=99s >> > not the >> > >> case and that does not sound like it will ever change even wit= h >> 5G. >> > >> >> > >> Gyan> The UE needs to be able to accept shorter prefix. >> > That=E2=80=99s the >> > >> IPV6 specification change that requires removal of the 64 bit >> > boundary. >> > >> >> > >> Yoru >> > >> proposed change to the SLAAC length if anything does more >> > violence to >> > >> the software (depending upon the exact software >> architecture.) >> > >> >> > >> >> > >> Gyan> What violence to software. There would be more >> > violence to >> > >> software if we removed the 64 bit boundary and allowed slaac t= o >> > support >> > >> any vlsm prefix lengths. >> > >> >> > >> My /80 proposal would just shift the boundary 16 bits to /80. >> > >> >> > >> Hosts on the same subnet with two different masks would not be >> > on-net to >> > >> each other as on different subnets. The router would be >> > configured with >> > >> the two subnets /64 and /80 subnet to support the two device >> types. >> > >> The solution would be a simple RA PIO flag that is set and old= er >> > hosts >> > >> not upgraded would be backwards compatible and so would only >> > support 64 >> > >> bit boundary by ignoring flag. Hosts upgraded to support would >> > >> understand the flag and be able to support longer mask up to >> /80. >> > >> >> > >> >> > >> >> > >> So I do not follow how you got to your conclusion. >> > >> >> > >> Yours, >> > >> Joel >> > >> >> > >> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >> > >> > >> > >> > (top posting) >> > >> > >> > >> > As I would like to clear the air as well as get to the >> > crux of >> > >> the v6ops >> > >> > presentation development results as well as next steps >> > for this >> > >> draft >> > >> > and the 6man variable slaac solutions draft: >> > >> > >> > >> > >> > >> > This thread was in light of Lorenzo kindly pointing out >> that >> > >> upgrading >> > >> > 3GPP is not all that needs be done for Cameron=E2=80=99= s 64share >> > v2 to >> > >> work - as >> > >> > all mobile devices would stop working- as slaac would n= ot >> > would be >> > >> > effectively broken. >> > >> > >> > >> > The mobile device would receive a shorter prefix let=E2= =80=99s >> > say /56 >> > >> but not >> > >> > know what to do with it since it=E2=80=99s expecting a = /64. >> > >> > >> > >> > So that a major gap and the only solution is updating R= FC >> > 4291 >> > >> removing >> > >> > the 64 bit boundary allowing for shorter prefix and now >> > as well >> > >> longer >> > >> > prefixes to work and in that respect now provide the mu= ch >> > needed >> > >> parity >> > >> > with static and DHCPv6 which can do any prefix length. >> > >> > >> > >> > So that is a drastic change to RFC 4291. However, in >> > light of this >> > >> > development on the v6ops 109 call, my balancing act of >> > best of both >> > >> > worlds and also to keep everyone happy to make this a W= G >> > effort >> > >> for this >> > >> > change by proposing in the subject heading /80 fixed >> > boundary and >> > >> not a >> > >> > variable slaac change allowing all bits vlsm. >> > >> > >> > >> > Basically stealing 16 bits for network prefix out of th= e >> > IID, still >> > >> > keeping the fixed boundary so longer than 80 would NOT >> > be allowed. >> > >> > >> > >> > A /64 would now be equivalent to a /48 with now 64k >> /80=E2=80=99s. >> > >> > >> > >> > This /80 would keep the operators and law enforcement >> > happy as >> > >> now 16 >> > >> > bits less helps traceability but is still long enough f= or >> > 48 bits of >> > >> > privacy to IP correlation by attackers. >> > >> > >> > >> > This /80 would be a nice optimal balance as it would ke= ep >> > wired >> > >> > broadband and mobile handset customers happy respecting >> their >> > >> privacy as >> > >> > the 16 bits less of heuristics is minimal change that >> > will impact IP >> > >> > correlation by attackers. >> > >> > >> > >> > The IID as it=E2=80=99s less than the current 64 bit ca= nnot use >> > MAC based >> > >> EUI64 >> > >> > IID, which is not a problem as Mac based IID is not >> > recommended >> > >> as most >> > >> > all manufacturers use RFC 4941 and I believe Linux >> > flavors some use >> > >> > stable IID RFC 7217. >> > >> > >> > >> > So now the 48 bit IID would require a random IID >> generation >> > >> schema so >> > >> > can use either RFC 4941 privacy extension or RFC 7217 >> > stable IID to >> > >> > generate the 48 bit IID. >> > >> > >> > >> > 3GPP subtending would now work issue mentioned in the >> problem >> > >> statement >> > >> > draft without even having to use 64share as now longer >> > prefixes >> > >> up to >> > >> > /80 would be supported allowing for further segmentatio= n >> of >> > >> downstream >> > >> > devices. >> > >> > >> > >> > This also would help wired broadband and soon fixed 5G >> > broadband >> > >> > proliferation where operators in light of BCP RIPE-690, >> > are sill >> > >> > allocation via BNG gateways a /64, now operators can >> > stay as-is, >> > >> as the >> > >> > /64 would now be allowed to be further segmented >> > supporting 64k >> > >> /80s, >> > >> > way more then enough for SOHO. >> > >> > >> > >> > This would allow 64share if used by 3GPP operators to >> > work and >> > >> would not >> > >> > require the 3GPP specification to be updated. We don= =E2=80=99t >> > know even >> > >> if the >> > >> > 3GPP architecture specification can be updated to suppo= rt >> > shorter >> > >> > prefixes and if the 3GPP consortium of operators would >> > agree to >> > >> it. So >> > >> > that is all theoretical of that change is possible. >> > >> > >> > >> > As with 5G with Enhanced VPN framework SR steering of >> > high priority >> > >> > traffic, traffic isolation and Network slicing >> > capabilities becomes >> > >> > mainstream and will soon be a real world reality and as >> > fixed 5G >> > >> > broadband proliferation takes off and mobile 5G =3D=3D = the >> > idea of a >> > >> > wearable /48 will really be many /48s. >> > >> > >> > >> > As this paradigm shift takes place, operators around th= e >> > world >> > >> will be >> > >> > clamoring after the RIR for massive blocks, I would say >> > less than /8 >> > >> > more like a /5 or /4. If you do the math on the way hi= gh >> > side a /10 >> > >> > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs >> per RIR >> > >> which is >> > >> > tiny number with the number of large size operators >> > worldwide. >> > >> > >> > >> > With the massive proliferation of IOT devices and just >> about >> > >> every home >> > >> > or office appliance on 5G, the problem now gets way >> > exacerbated. >> > >> > >> > >> > As this evolution unfolds IANA will be scrambling to >> > release all >> > >> > remaining /3 as well as all unallocated blocks to subve= rt >> > RIR IPv6 >> > >> > address space depletion. >> > >> > >> > >> > Playing Monday night quarterbacking in hindsight we wou= ld >> > never >> > >> think >> > >> > this would happen in a million years, but we would see >> > IPv6 on >> > >> the verge >> > >> > of address space depletion. Unheard of but it can happ= en >> > as the >> > >> saying >> > >> > goes =E2=80=9Cwhen you build - they will come=E2=80=9D. >> > >> > >> > >> > It is true as history has taught that very important >> lesson. >> > >> > >> > >> > The answer to this real world problem is in the subject >> > heading >> > >> of this >> > >> > thread. >> > >> > >> > >> > This would also fix the day 1 issue I mentioned allowin= g >> > mix of >> > >> slaac >> > >> > devices with static and DHCPv6 up to /80. >> > >> > >> > >> > The variable slaac solution draft proposes a new RA PI= O >> flag >> > >> that would >> > >> > be used to signal longer prefixes, and would provide >> > backwards >> > >> > compatibility so that devices not supporting woud ignor= e >> > the flag >> > >> and >> > >> > devices on newer code supporting would use the flag. W= e >> > definitely >> > >> > don=E2=80=99t want to impact any existing devices on th= e existing >> > 64 bit >> > >> slaac >> > >> > boundary standard. >> > >> > >> > >> > Dmytro has tested the solution on Linux kernel signalin= g >> > RA PIO >> > >> flag and >> > >> > was able to successfully test any length mask and rando= m >> IID >> > >> generation >> > >> > both RFC 4941 privacy extension as well as stable IID R= FC >> > 7217. >> > >> > >> > >> > >> > >> >> > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ >> > > > >> > >> >> > < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>> >> > >> > >> > >> >> > < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/> >> > >> >> > < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ < >> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>> >> > >> > >> > >> > If everyone is in agreement with what I have stated on >> this >> > >> thread, I >> > >> > would like to ask the chairs for WG adoption as this is= a >> > WG effort. >> > >> > >> > >> > I would like to garner support from all 6MAN members wi= th >> > full >> > >> consensus >> > >> > to change the existing RFC 4941 /64 fixed boundary to /= 80 >> > fixed >> > >> boundary. >> > >> > >> > >> > Kind Regards >> > >> > >> > >> > Gyan >> > >> > >> > >> > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >> > >> >> > > >> > >> > >> > >>> wrote: >> > >> > >> > >> > I am missing something in your reasoning. >> > >> > You seem to say at one point that (to paraphrase) "= we >> > can't >> > >> do this >> > >> > because it does not work with the existing UE >> software". >> > >> > Any new solution where a UE delegates based on any >> > change of >> > >> any kind >> > >> > (including lengthening the prefix, shortening the >> > prefix, or >> > >> magically >> > >> > incanting new prefixes) requires that the UE be >> > upgraded to know >> > >> > what to >> > >> > do with the information. I do not see how that >> > >> differentiates any of >> > >> > the solutions. (Except "don't do anything", which I >> > think we >> > >> do not >> > >> > want >> > >> > to take.) >> > >> > >> > >> > Yours, >> > >> > Joel >> > >> > >> > >> > On 11/19/2020 5:03 PM, Gyan Mishra wrote: >> > >> > > >> > >> > > >> > >> > > On Thu, Nov 19, 2020 at 10:33 AM >> > >> > >> = > >> > >> > > > > > >> >> > >> > > > > > > > >> > >> >> > >>>> >> wrote: >> > >> > > >> > >> > > >> > >> > > >> > >> > > > On 19 Nov 2020, at 14:58, Gyan Mishra >> > >> > > > >> > > >> > >> > > >> > >> >> > >> > > > > >> > >> > >> >> > >> > > > >> > >> > > >>>> wrote: >> > >> > > > >> > >> > > > You would need a new option. It would >> likely be >> > >> useful for the >> > >> > > requesting router to indicate interest in th= e >> > option. Even >> > >> > hinting >> > >> > > at what prefix size it was expecting. >> > >> > > > Now can you explain to me again the reaso= ns >> > why this >> > >> > approach is >> > >> > > better than using the existing DHPCv6 protoc= ol >> > packets? >> > >> > > > >> > >> > > > 3GPP gateway does not support DHCPv6 >> > >> > > >> > >> > > 3GPP gateway doesn't support new option. >> > What's your >> > >> point? >> > >> > > >> > >> > > >> > >> > > >> > >> > > The point of the v6ops presentation and thi= s >> > email >> > >> thread is >> > >> > how to >> > >> > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use c= ase in slide 1 >> of the >> > >> deck you >> > >> > compiled >> > >> > > a list of options and of the two I had highlight= ed >> > in red >> > >> were the >> > >> > > 64share v2 Cameron=E2=80=99s option and the vari= able slaac >> > >> option. So on >> > >> > the >> > >> > > call this morning Lorenzo shot down 64share v2 >> > shorter prefix >> > >> > option as >> > >> > > even if the 3GPP architecture was updated to >> > support longer >> > >> > prefixes and >> > >> > > even is the 3GPP gateway was able to send a >> > shorter prefix >> > >> with A >> > >> > flag >> > >> > > not set, all mobile devices per Lorenzo=E2=80=99= s point >> > would be >> > >> broken >> > >> > as they >> > >> > > would not accept the shorter let=E2=80=99s say /= 56 prefix >> > to build the >> > >> > slaac 128 >> > >> > > bit address. So the bottom line is the 64share = v2 >> > won=E2=80=99t work >> > >> > unless we >> > >> > > update RFC 4291 and remove the 64 bit boundary. >> > >> > > >> > >> > > So we are back to square uno - no viable >> solution >> > >> > > >> > >> > > So now we had thrown out the longer >64 due to >> > race to >> > >> bottom >> > >> > worries >> > >> > > which I and others believe is Fud and as >> described in >> > >> slide 10 of >> > >> > the >> > >> > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D= . >> > >> > > >> > >> > > So a happy medium /80 fixed boundary I came up >> > with that I >> > >> think >> > >> > solves >> > >> > > a lot of the issue and not just the 3GPP initial >> > >> segmentation of >> > >> > > downstream devices problem statement. >> > >> > > >> > >> > > Since we have to update RFC 4291 for 64share v2 = to >> > work >> > >> anyways >> > >> > to allow >> > >> > > for shorter prefixes, why not instead create a n= ew >> > bottom >> > >> at /80 >> > >> > giving >> > >> > > 16 bits more of prefix length and shrinking the >> > IID down >> > >> to 48 bits. >> > >> > > Doing so you would not even have to update the >> 3GPP >> > >> architecture >> > >> > as I >> > >> > > don=E2=80=99t know if that would fly or not. Al= so this >> > solves a >> > >> few other >> > >> > > problems at the same time. >> > >> > > >> > >> > > >> > >> > > As I mentioned in the v6ops deck presented that >> > vlsm 0 to >> > >> 128 is >> > >> > > mainstream for operators for static addressing o= n >> > router >> > >> and switch >> > >> > > infrastructure and dhcpv6 subnets longer prefixe= s >> > for network >> > >> > > infrastructure appliance clusters, NFV/VNF >> > virtualization >> > >> and server >> > >> > > farms. On host subnets where there is a chance = of >> > mix of >> > >> slaac >> > >> > hosts >> > >> > > with dhcpv6 devices the prefix length is stuck = at >> > /64. So on >> > >> > these mix >> > >> > > addressing host subnets we cannot do longer >> > prefixes following >> > >> > our ND >> > >> > > cache hard limit mantra to prevent ND cache >> exhaustion >> > >> issues as >> > >> > > described in RFC 6164. >> > >> > > >> > >> > > So with the /80 new fixed boundary shifting pref= ix >> > length >> > >> 16 bits >> > >> > longer >> > >> > > and shortening the IID by 16 bits gives resolved >> > the 3GPP >> > >> issue >> > >> > which >> > >> > > 64share can work as is and subtending to >> downstream >> > >> devices will now >> > >> > > work as a /64 is now equivalent to a /48 with 64= k >> > /80s. Also >> > >> > BCP-690 >> > >> > > for broadband not all operators have adopted the >> > shorter >> > >> prefix >> > >> > lengths >> > >> > > /56 or /48 recommendations and now that=E2=80= =99s not an >> > issue as the >> > >> > /64 would >> > >> > > now suffice. >> > >> > > >> > >> > > From an operators perspective that gain allows = at >> > least >> > >> for 3GPP >> > >> > > massive growth and subtending with a single /64 >> > allows the >> > >> operators >> > >> > > such as Verizon with massive subscriber base >> > worldwide can >> > >> stay with >> > >> > > current allocations and don=E2=80=99t have to as= k >> > >> >> > < >> https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+hav= e+to+ask?entry=3Dgmail&source=3Dg >> < >> https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+hav= e+to+ask?entry=3Dgmail&source=3Dg >> >> >> > >> for /10. >> > >> > > >> > >> > > As 5G gets rolled out with Enhanced VPN framewor= k >> > and Network >> > >> > slicing >> > >> > > paradigm, the demand for shorter blocks and >> wearable >> > >> multiple /48 >> > >> > will >> > >> > > be our new reality. >> > >> > > >> > >> > > Making that 16 bit shift now to /80 making a /64 >> > the new >> > >> /48 will >> > >> > give >> > >> > > broadband and 3GPP subscribers a ton of space to >> > >> subtending their >> > >> > > networks we would be set for the future. >> > Especially with >> > >> IOT the >> > >> > demand >> > >> > > for subtending will continue to grow >> astronomically. >> > >> > > >> > >> > > Also IANA does not have to get start in >> allocating the >> > >> other /3 and >> > >> > > other available blocks. >> > >> > > >> > >> > > Lots of problems being solved here with a fixed >> > /80 new >> > >> boundary. >> > >> > > >> > >> > > Also with the existing random IID generation >> > schemes which >> > >> we have >> > >> > > tested on Linux kernel can do longer p >> > >> > >> > >> >> > < >> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+= p?entry=3Dgmail&source=3Dg >> < >> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+= p?entry=3Dgmail&source=3Dg> >> < >> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+= p?entry=3Dgmail&source=3Dg >> < >> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+= p?entry=3Dgmail&source=3Dg >> >>>refixes >> > >> > using RFC 4941 privacy >> > >> > > extension or RFC 7217 stable IID. >> > >> > > >> > >> > > Win-Win for all. >> > >> > > >> > >> > > Ole >> > >> > > >> > >> > > -- >> > >> > > >> > >> > > > > >> > > >> > >> >> > >>> >> > >> > > >> > >> > > *Gyan Mishra* >> > >> > > >> > >> > > /Network Solutions A//rchitect / >> > >> > > >> > >> > > /M 301 502-1347 >> > >> > > 13101 Columbia Pike >> >> >> >> > >> >> >> >> >> > >> > >> /Silver Spring, MD >> >> > >> > > >> > >> > > >> > >> > > >> > >> > > _______________________________________________ >> > >> > > v6ops mailing list >> > >> > > v6ops@ietf.org >> > > >> > >> >> > >> >> > >> > > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > >> > > > >> > >> > > > >> > >> > > >> >> > >> > > >> > >> > >> > >> > -- >> > >> > >> > >> > >> > >> >> > >> > >> > >> > *Gyan Mishra* >> > >> > >> > >> > /Network Solutions A//rchitect / >> > >> > >> > >> > /M 301 502-1347 >> > >> > 13101 Columbia Pike >> >> >> >> > >> >> >> >> > >> /Silver Spring, MD >> >> > >> > >> > >> > >> > >> >> > >> -- >> > >> >> > >> > >> > >> >> > >> *Gyan Mishra* >> > >> >> > >> /Network Solutions A//rchitect / >> > >> >> > >> /M 301 502-1347 >> > >> 13101 Columbia Pike >> >> >> >> > >> >> >> /Silver Spring, MD >> >> > >> >> > >> >> > > >> > > _______________________________________________ >> > > v6ops mailing list >> > > v6ops@ietf.org >> > > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > > >> > >> > ------------------------------------------------------------------= -- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >> > >> > ------------------------------------------------------------------= -- >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike > *Silver > Spring, MD > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002b0b4205b4c0ad7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 23, 2020 at 1:41 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:


On Sat, Nov 21, 2020 at 10:26= AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
As I understand it, the situation is not that 3GPP has not defined us= e
of DHCP.=C2=A0 But rather than operators have uniformly declined to deploy =
it.=C2=A0 (3GPP has defined DHCP for 5G for fixed access.=C2=A0 We have hea= rd here
that even that is not what the operators want.)=C2=A0 As such, asking 3GPP =
why they didn't deploy it seems a bit odd.

=C2=A0 =C2=A0 Gyan> One possible non techn= ical factor is that Android which as of 2019 statistical data below holds 8= 7% of the global mobile market share and Apple 13% and Android is continuin= g to climb in 2020. =C2=A0 Android adamantly refuses to change its position= on support of DHCPv6.=C2=A0 I think that really shackles 3GPP carriers fro= m supporting DHCPv6 is close to 100% of all mobile handsets won=E2=80=99t s= upport it.

=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0Gyan= > I have spoken with executives at Google and in talks related to Chrome= book DHCPv6 support, they said that their development platform is a common = platform for both Android and Chromebook and that for mobile handsets they = cannot change and gave their technical justifications.=C2=A0 Based on that = feedback, 3GPP operators are really stuck between a rock and hard place and= cannot change to support DHCPv6 as close to 90% of the market share is And= roid.Their maybe some other technical reasons as well on the operator gatew= ay side which I would have to research if one exist as well why they won=E2= =80=99t adopt PD.



Yours,
Joel

On 11/20/2020 11:19 PM, Mark Smith wrote:
>
>
> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter,
> <b= rian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wro= te:
>
>=C2=A0 =C2=A0 =C2=A0Joel,
>
>=C2=A0 =C2=A0 =C2=A0It seems to me that it's high time to draft a l= iaison statement to 3GPP,
>=C2=A0 =C2=A0 =C2=A0observing that:
>
>=C2=A0 =C2=A0 =C2=A0(1) There is a serious problem for the design and i= mplementation of
>=C2=A0 =C2=A0 =C2=A05G-based IPv6 "hot spots" and CEs [which = is where this conversation
>=C2=A0 =C2=A0 =C2=A0started];
>
>
> I think it is also important to find out why they haven't deployed=
> DHCPv6 to solve this=C2=A0problem.
>
> Don't they think DHCPv6 infrastructure will scale? Is it just that= they
> don't know how to scale it?
>
> Is it a vendor / mobile operator / handset developer DHCPv6
> capability=C2=A0chicken-and-egg problem?
>
> Is there an overriding business or industry reason?
>
> The mobile industry has been resistant to tethering over the years, an= d
> probably only came to begrudgingly accept it because they couldn't=
> prevent phone vendors from implementing Wifi and NAT, and couldn't= very
> effectively stop their customers from using that capability (One trick=
> I've heard of to prevent tethering working was to check if an IPv4=
> packet's=C2=A0TTL value was 64 when it arrived at the network, mea= ning it
> originated from the directly attached handset. Packets from tethered <= br> > devices had a TTL of 63 so were dropped. Of course, you could set the =
> default TTL on a tethered=C2=A0PC to 65 to get around that.)
>
> I guess there might be a fairly strong mindset that there must be a fe= e
> per device attached to the network in addition to a fee for network > utilisation. Providing multiple /64s would be formally acknowledging <= br> > that multiple devices can be attached and a fee per device isn't a= nd
> can't ever be charged, counter to the mindset.
>
> Regards,
> Mark.
>
>
>=C2=A0 =C2=A0 =C2=A0(2) Although the best solution is not yet obvious, = defining and
>=C2=A0 =C2=A0 =C2=A0standardizing it will require a joint effort by the= IETF and 3GPP.
>
>=C2=A0 =C2=A0 =C2=A0Followed by a proposal to form an ad hoc joint desi= gn team.
>
>=C2=A0 =C2=A0 =C2=A0Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Brian Carpenter
>=C2=A0 =C2=A0 =C2=A0On 21-Nov-20 14:46, Joel M. Halpern wrote:
>=C2=A0 =C2=A0 =C2=A0 > The nesting got me lost, so I will top post m= y take on the answer
>=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 > one quesiton I could understand.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I believe you asked what I think would need t= o be changed to
>=C2=A0 =C2=A0 =C2=A0permit the
>=C2=A0 =C2=A0 =C2=A0 > delegation.
>=C2=A0 =C2=A0 =C2=A0 > As with anything, the real things that need t= o change are the
>=C2=A0 =C2=A0 =C2=A0devices in
>=C2=A0 =C2=A0 =C2=A0 > the network.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > With regard to IETF standards, what is propos= ed is a change to RA.
>=C2=A0 =C2=A0 =C2=A0 > There are several possible changes.=C2=A0 Non= e of them require a
>=C2=A0 =C2=A0 =C2=A0change to
>=C2=A0 =C2=A0 =C2=A0 > the IPv6 addressing archtiecture, as the addr= essing structure
>=C2=A0 =C2=A0 =C2=A0remains as
>=C2=A0 =C2=A0 =C2=A0 > it is.
>=C2=A0 =C2=A0 =C2=A0 > As for the exact mechanism, at the moment I l= ean towards Ole's
>=C2=A0 =C2=A0 =C2=A0proposal
>=C2=A0 =C2=A0 =C2=A0 > of using a new option in his generic option m= echanism.=C2=A0 But I am not
>=C2=A0 =C2=A0 =C2=A0 > wedded to that answer.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > And of course, to get this supported in mobil= e environments we
>=C2=A0 =C2=A0 =C2=A0will have
>=C2=A0 =C2=A0 =C2=A0 > to work with 3GPP and make sure there are no = other hidden issues.
>=C2=A0 =C2=A0 =C2=A0 > That's the way we do things.=C2=A0 Work t= ogether.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Changing the prefix length to /80 is technica= lly also possible.
>=C2=A0 =C2=A0 =C2=A0It does
>=C2=A0 =C2=A0 =C2=A0 > a lot more violence to my understanding of th= e architecture and
>=C2=A0 =C2=A0 =C2=A0software
>=C2=A0 =C2=A0 =C2=A0 > structures that go with it, and is a very lim= ited and narrow
>=C2=A0 =C2=A0 =C2=A0solution to
>=C2=A0 =C2=A0 =C2=A0 > the problem.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Yours,
>=C2=A0 =C2=A0 =C2=A0 > Joel
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On 11/20/2020 7:58 PM, Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >> Hi Joel
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> In-line
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. H= alpern
>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>=C2=A0 =C2=A0 =C2=A0 >> <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>= > wrote:
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan, separate from Ol= e's comments about the difference
>=C2=A0 =C2=A0 =C2=A0between address
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0assignment and delegat= ion, I have another problem following the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0reasoning below.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Yes, the proposal for = using shorter prefixes to enable UE to
>=C2=A0 =C2=A0 =C2=A0perform
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0delegation will requir= e changes to the UE.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 Gyan> Agreed.=C2= =A0 So that change would be to RFC 4291 64 bit
>=C2=A0 =C2=A0 =C2=A0boundary
>=C2=A0 =C2=A0 =C2=A0 >> to allow for longer prefix.=C2=A0 Do you = agree?
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> If you don=E2=80=99t agree what do think = the change would be to allow
>=C2=A0 =C2=A0 =C2=A0the UE to
>=C2=A0 =C2=A0 =C2=A0 >> accept shorter prefix from the 3GPP gatew= ay?
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0But I do not see how t= hat is relevant to any choice we are
>=C2=A0 =C2=A0 =C2=A0trying to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0make.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Any solution that enab= les UE to delegate addresses (in the
>=C2=A0 =C2=A0 =C2=A0sense that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0they lack the capabili= ty now) willr equire changes to the UE.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan> If the UE rec= eives a /56 via RA it could delegate /64 to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0downstream devices.=C2= =A0 No change needed to delegate =C2=A0/64,
>=C2=A0 =C2=A0 =C2=A0however a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0change is needed to ac= cept /56 via RA.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 If 3GPP gateway suppo= rted PD - problem solved but that=E2=80=99s
>=C2=A0 =C2=A0 =C2=A0not the
>=C2=A0 =C2=A0 =C2=A0 >> case and that does not sound like it will= ever change even with 5G.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan> The UE needs = to be able to accept shorter prefix.
>=C2=A0 =C2=A0 =C2=A0That=E2=80=99s the
>=C2=A0 =C2=A0 =C2=A0 >> IPV6 specification change that requires r= emoval of the 64 bit
>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Yoru
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0proposed change to the= SLAAC length if anything does more
>=C2=A0 =C2=A0 =C2=A0violence to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0the software (dependin= g upon the exact software architecture.)
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan> What violence= to software.=C2=A0 There would be more
>=C2=A0 =C2=A0 =C2=A0violence to
>=C2=A0 =C2=A0 =C2=A0 >> software if we removed the 64 bit boundar= y and allowed slaac to
>=C2=A0 =C2=A0 =C2=A0support
>=C2=A0 =C2=A0 =C2=A0 >> any vlsm prefix lengths.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> My /80 proposal would just shift the boun= dary 16 bits to /80.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Hosts on the same subnet with two differe= nt masks would not be
>=C2=A0 =C2=A0 =C2=A0on-net to
>=C2=A0 =C2=A0 =C2=A0 >> each other as on different subnets.=C2=A0= The router would be
>=C2=A0 =C2=A0 =C2=A0configured with
>=C2=A0 =C2=A0 =C2=A0 >> the two subnets /64 and /80 subnet to sup= port the two device types.
>=C2=A0 =C2=A0 =C2=A0 >> The solution would be a simple RA PIO fla= g that is set and older
>=C2=A0 =C2=A0 =C2=A0hosts
>=C2=A0 =C2=A0 =C2=A0 >> not upgraded would be backwards compatibl= e and so would only
>=C2=A0 =C2=A0 =C2=A0support 64
>=C2=A0 =C2=A0 =C2=A0 >> bit boundary by ignoring flag. Hosts upgr= aded to support would
>=C2=A0 =C2=A0 =C2=A0 >> understand the flag and be able to suppor= t longer mask up to /80.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0So I do not follow how= you got to your conclusion.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Joel
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0On 11/20/2020 5:27 PM,= Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > (top posting) >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As I would like = to clear the air as well as get to the
>=C2=A0 =C2=A0 =C2=A0crux of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0the v6ops
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > presentation dev= elopment results as well as next steps
>=C2=A0 =C2=A0 =C2=A0for this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0draft
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > and the 6man var= iable slaac solutions draft:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This thread was = in light of Lorenzo kindly pointing out that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0upgrading
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 3GPP is not all = that needs be done for Cameron=E2=80=99s 64share
>=C2=A0 =C2=A0 =C2=A0v2 to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0work - as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > all mobile devic= es would stop working- as slaac would not
>=C2=A0 =C2=A0 =C2=A0would be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > effectively brok= en.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The mobile devic= e would receive a shorter prefix let=E2=80=99s
>=C2=A0 =C2=A0 =C2=A0say /56
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0but not
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > know what to do = with it since it=E2=80=99s expecting a /64.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > So that a major = gap and the only solution is updating RFC
>=C2=A0 =C2=A0 =C2=A04291
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0removing
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > the 64 bit bound= ary allowing for shorter prefix and now
>=C2=A0 =C2=A0 =C2=A0as well
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0longer
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > prefixes to work= and in that respect now provide the much
>=C2=A0 =C2=A0 =C2=A0needed
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0parity
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > with static and = DHCPv6 which can do any prefix length.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > So that is a dra= stic change to RFC 4291.=C2=A0 However, in
>=C2=A0 =C2=A0 =C2=A0light of this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > development on t= he v6ops 109 call, my balancing act of
>=C2=A0 =C2=A0 =C2=A0best of both
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > worlds and also = to keep everyone happy to make this a WG
>=C2=A0 =C2=A0 =C2=A0effort
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0for this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > change by propos= ing in the subject heading /80 fixed
>=C2=A0 =C2=A0 =C2=A0boundary and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0not a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > variable slaac c= hange allowing all bits vlsm.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Basically steali= ng 16 bits for network prefix out of the
>=C2=A0 =C2=A0 =C2=A0IID, still
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > keeping the fixe= d boundary so longer than 80 would NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be allowed.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > A /64 would now = be equivalent to a /48 with now 64k /80=E2=80=99s.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This /80 would k= eep the operators and law enforcement
>=C2=A0 =C2=A0 =C2=A0happy as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0now 16
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > bits less helps = traceability but is still long enough for
>=C2=A0 =C2=A0 =C2=A048 bits of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > privacy to IP co= rrelation by attackers.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This /80 would b= e a nice optimal balance as it would keep
>=C2=A0 =C2=A0 =C2=A0wired
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > broadband and mo= bile handset customers happy respecting their
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0privacy as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > the 16 bits less= of heuristics is minimal change that
>=C2=A0 =C2=A0 =C2=A0will impact IP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > correlation by a= ttackers.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The IID as it=E2= =80=99s less than the current 64 bit cannot use
>=C2=A0 =C2=A0 =C2=A0MAC based
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0EUI64
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > IID, which is no= t a problem as Mac based IID is not
>=C2=A0 =C2=A0 =C2=A0recommended
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0as most
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > all manufacturer= s use RFC 4941 and I believe Linux
>=C2=A0 =C2=A0 =C2=A0flavors some use
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > stable IID RFC 7= 217.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > So now the 48 bi= t IID would require a random IID generation
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0schema so
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > can use either R= FC 4941 privacy extension or RFC 7217
>=C2=A0 =C2=A0 =C2=A0stable IID to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > generate the 48 = bit IID.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 3GPP subtending = would now work issue mentioned in the problem
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0statement
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > draft without ev= en having to use 64share as now longer
>=C2=A0 =C2=A0 =C2=A0prefixes
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0up to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /80 would be sup= ported allowing for further segmentation of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0downstream
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > devices.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This also would = help wired broadband and soon fixed 5G
>=C2=A0 =C2=A0 =C2=A0broadband
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > proliferation wh= ere operators in light of BCP RIPE-690,
>=C2=A0 =C2=A0 =C2=A0are sill
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > allocation via B= NG gateways a /64, now operators =C2=A0can
>=C2=A0 =C2=A0 =C2=A0stay as-is,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0as the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /64 would now be= allowed to be further segmented
>=C2=A0 =C2=A0 =C2=A0supporting 64k
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/80s,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > way more then en= ough for SOHO.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This would allow= 64share if used by 3GPP operators to
>=C2=A0 =C2=A0 =C2=A0work and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0would not
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > require the 3GPP= specification to be updated.=C2=A0 We don=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0know even
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0if the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 3GPP architectur= e specification can be updated to support
>=C2=A0 =C2=A0 =C2=A0shorter
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > prefixes and if = the 3GPP consortium of operators would
>=C2=A0 =C2=A0 =C2=A0agree to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0it.=C2=A0 So
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > that is all theo= retical of that change is possible.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As with 5G with = Enhanced VPN framework SR steering of
>=C2=A0 =C2=A0 =C2=A0high priority
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > traffic, traffic= isolation and Network slicing
>=C2=A0 =C2=A0 =C2=A0capabilities becomes
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > mainstream and w= ill soon be a real world reality and as
>=C2=A0 =C2=A0 =C2=A0fixed 5G
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > broadband prolif= eration takes off and mobile 5G =3D=3D the
>=C2=A0 =C2=A0 =C2=A0idea of a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > wearable /48 wil= l really be many /48s.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As this paradigm= shift takes place, operators around the
>=C2=A0 =C2=A0 =C2=A0world
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0will be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > clamoring after = the RIR for massive blocks, I would say
>=C2=A0 =C2=A0 =C2=A0less than /8
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > more like a /5 o= r /4.=C2=A0 If you do the math on the way high
>=C2=A0 =C2=A0 =C2=A0side a /10
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > yields 7 bits so= 128 divided by 5 RIRs yields 24 ISPs per RIR
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0which is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > tiny number with= the number of large size operators
>=C2=A0 =C2=A0 =C2=A0worldwide.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > With the massive= proliferation of IOT devices and just about
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0every home
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > or office applia= nce on 5G, the problem now gets way
>=C2=A0 =C2=A0 =C2=A0exacerbated.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > As this evolutio= n unfolds IANA will be scrambling to
>=C2=A0 =C2=A0 =C2=A0release all
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > remaining /3 as = well as all unallocated blocks to subvert
>=C2=A0 =C2=A0 =C2=A0RIR IPv6
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > address space de= pletion.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Playing Monday n= ight quarterbacking in hindsight we would
>=C2=A0 =C2=A0 =C2=A0never
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0think
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > this would happe= n in a million years, but we would see
>=C2=A0 =C2=A0 =C2=A0IPv6 on
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0the verge
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > of address space= depletion.=C2=A0 Unheard of but it can happen
>=C2=A0 =C2=A0 =C2=A0as the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0saying
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > goes =E2=80=9Cwh= en you build - they will come=E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > It is true as hi= story has taught that very important lesson.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The answer to th= is real world problem is in the subject
>=C2=A0 =C2=A0 =C2=A0heading
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0of this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > thread.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > This would also = fix the day 1 issue I mentioned allowing
>=C2=A0 =C2=A0 =C2=A0mix of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > devices with sta= tic and DHCPv6 up to /80.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > The variable sla= ac solution draft proposes a new =C2=A0RA PIO flag
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0that would
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > be used to signa= l longer prefixes, and would provide
>=C2=A0 =C2=A0 =C2=A0backwards
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > compatibility so= that devices not supporting woud ignore
>=C2=A0 =C2=A0 =C2=A0the flag
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > devices on newer= code supporting would use the flag.=C2=A0 We
>=C2=A0 =C2=A0 =C2=A0definitely
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > don=E2=80=99t wa= nt to impact any existing devices on the existing
>=C2=A0 =C2=A0 =C2=A064 bit
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > boundary standar= d.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Dmytro has teste= d the solution on Linux kernel signaling
>=C2=A0 =C2=A0 =C2=A0RA PIO
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0flag and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > was able to succ= essfully test any length mask and random IID
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0generation
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > both RFC 4941 pr= ivacy extension as well as stable IID RFC
>=C2=A0 =C2=A0 =C2=A07217.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0https://da= tatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>=C2=A0 =C2=A0 =C2=A0<https:= //datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <= ;https://datatracker.ietf.org/doc/= draft-mishra-6man-variable-slaac/>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <= ;https://datatracker.ietf.org/doc/= draft-mishra-6man-variable-slaac/>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <= ;https://datatracker.ietf.org/doc/= draft-mishra-6man-variable-slaac/>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > If everyone is i= n agreement with what I have stated on this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0thread, I
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > would like to as= k the chairs for WG adoption as this is a
>=C2=A0 =C2=A0 =C2=A0WG effort.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > I would like to = garner support from all 6MAN members with
>=C2=A0 =C2=A0 =C2=A0full
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0consensus
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > to change the ex= isting RFC 4941 /64 fixed boundary to /80
>=C2=A0 =C2=A0 =C2=A0fixed
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Kind Regards
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > Gyan
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > On Thu, Nov 19, = 2020 at 5:14 PM Joel M. Halpern
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com= >
>=C2=A0 =C2=A0 =C2=A0<mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com= <mailto:jmh@jo= elhalpern.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>> w= rote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0I am missing something in your reasoning.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0You seem to say at one point that (to paraphrase) "we
>=C2=A0 =C2=A0 =C2=A0can't
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0do this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0because it does not work with the existing UE software".
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Any new solution where a UE delegates based on any
>=C2=A0 =C2=A0 =C2=A0change of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0any kind
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0(including lengthening the prefix, shortening the
>=C2=A0 =C2=A0 =C2=A0prefix, or
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0magically
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0incanting new prefixes) requires that the UE be
>=C2=A0 =C2=A0 =C2=A0upgraded to know
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0what to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0do with the information.=C2=A0 I do not see how that
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0differentiates any of<= br> >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0the solutions. (Except "don't do anything", which I
>=C2=A0 =C2=A0 =C2=A0think we
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0do not
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0want
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0to take.)
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Yours,
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0Joel
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > On Thu, Nov 19, 2020 at 10:33 AM
>=C2=A0 =C2=A0 =C2=A0<otroan@employees.org <mailto:otroan@employees.org>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <= ;mailto:otroan@em= ployees.org>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:otr= oan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org> <mailto:otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > <mailto:otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org> <mailto:otroan@employees.org
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <= ;mailto:otroan@em= ployees.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:otroan@employees.org <mailto:otroan@employees.org>>>&g= t;> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 > On 19 Nov 2020, at 14:58, Gyan Mishra
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<hayabusag= sm@gmail.com <mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>> >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com &= lt;mailto:hayabu= sagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com &= lt;mailto:hayabu= sagsm@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<mailto:ha= yabusagsm@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com >=C2=A0 =C2=A0 =C2=A0<mailto:hayabusagsm@gmail.com>>>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 > You would need a new option. It would lik= ely be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0useful for the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0requesting router to indicate interest in the >=C2=A0 =C2=A0 =C2=A0option. Even
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0hinting
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0at what prefix size it was expecting.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 > Now can you explain to me again the reaso= ns
>=C2=A0 =C2=A0 =C2=A0why this
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0approach is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0better than using the existing DHPCv6 protocol<= br> >=C2=A0 =C2=A0 =C2=A0packets?
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway does not = support DHCPv6
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A03GPP gateway doesn't support new option. >=C2=A0 =C2=A0 =C2=A0What's your
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0point?
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0 The point of the v6ops presentation and this >=C2=A0 =C2=A0 =C2=A0email
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0thread is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0how to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2=A0in slide= 1 of the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0deck you
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0compiled
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > a list of options and of the two I had highlighted
>=C2=A0 =C2=A0 =C2=A0in red
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0were the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 64share v2 Cameron=E2=80=99s option and the variable slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0option.=C2=A0 So on >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > call this morning Lorenzo shot down 64share v2
>=C2=A0 =C2=A0 =C2=A0shorter prefix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0option as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > even if the 3GPP architecture was updated to
>=C2=A0 =C2=A0 =C2=A0support longer
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0prefixes and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > even is the 3GPP gateway was able to send a
>=C2=A0 =C2=A0 =C2=A0shorter prefix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0with A
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0flag
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > not set, all mobile devices per Lorenzo=E2=80=99s point
>=C2=A0 =C2=A0 =C2=A0would be
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0broken
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0as they
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > would not accept the shorter let=E2=80=99s say /56 prefix
>=C2=A0 =C2=A0 =C2=A0to build the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0slaac 128
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > bit address.=C2=A0 So the bottom line is the 64share v2
>=C2=A0 =C2=A0 =C2=A0won=E2=80=99t work
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0unless we
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > update RFC 4291 and remove the 64 bit boundary.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0So we are back to square uno - no viable solution
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0So now we had thrown out the longer >64 due to
>=C2=A0 =C2=A0 =C2=A0race to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0bottom
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0worries
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > which I and others believe is Fud and as described in
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slide 10 of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > So a happy medium /80 fixed boundary I came up
>=C2=A0 =C2=A0 =C2=A0with that I
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0think
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0solves
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > a lot of the issue and not just the 3GPP initial
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0segmentation of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > downstream devices problem statement.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Since we have to update RFC 4291 for 64share v2 to
>=C2=A0 =C2=A0 =C2=A0work
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0anyways
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0to allow
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > for shorter prefixes, why not instead create a new
>=C2=A0 =C2=A0 =C2=A0bottom
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0at /80
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0giving
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 16 bits more of prefix length and shrinking the
>=C2=A0 =C2=A0 =C2=A0IID down
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0to 48 bits.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Doing so you would not even have to update the 3GPP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0architecture
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0as I
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > don=E2=80=99t know if that would fly or not.=C2=A0 Also this
>=C2=A0 =C2=A0 =C2=A0solves a
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0few other
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > problems at the same time.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > As I mentioned in the v6ops deck presented that
>=C2=A0 =C2=A0 =C2=A0vlsm 0 to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0128 is
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > mainstream for operators for static addressing on
>=C2=A0 =C2=A0 =C2=A0router
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0and switch
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > infrastructure and dhcpv6 subnets longer prefixes
>=C2=A0 =C2=A0 =C2=A0for network
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > infrastructure appliance clusters, NFV/VNF
>=C2=A0 =C2=A0 =C2=A0virtualization
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0and server
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > farms.=C2=A0 On host subnets where there is a chance of
>=C2=A0 =C2=A0 =C2=A0mix of
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0slaac
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0hosts
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > with dhcpv6 =C2=A0devices the prefix length is stuck at
>=C2=A0 =C2=A0 =C2=A0/64.=C2=A0 So on
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0these mix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > addressing host subnets we cannot do longer
>=C2=A0 =C2=A0 =C2=A0prefixes following
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0our ND
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > cache hard limit mantra to prevent ND cache exhaustion
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0issues as
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > described in RFC 6164.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > So with the /80 new fixed boundary shifting prefix
>=C2=A0 =C2=A0 =C2=A0length
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A016 bits
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0longer
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > and shortening the IID by 16 bits gives resolved
>=C2=A0 =C2=A0 =C2=A0the 3GPP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0issue
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0which
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 64share can work as is and subtending to downstream
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0devices will now
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > work as a /64 is now equivalent to a /48 with 64k
>=C2=A0 =C2=A0 =C2=A0/80s.=C2=A0 Also
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0BCP-690
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > for broadband not all operators have adopted the
>=C2=A0 =C2=A0 =C2=A0shorter
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0prefix
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0lengths
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /56 or /48 recommendations =C2=A0and now that=E2=80=99s not an
>=C2=A0 =C2=A0 =C2=A0issue as the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0/64 would
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > now suffice.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 From an operators perspective that gain allows at
>=C2=A0 =C2=A0 =C2=A0least
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0for 3GPP
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > massive growth and subtending with a single /64
>=C2=A0 =C2=A0 =C2=A0allows the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0operators
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > such as Verizon with massive subscriber base
>=C2=A0 =C2=A0 =C2=A0worldwide can
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0stay with
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > current allocations and don=E2=80=99t have to ask
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/sea= rch/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=3Dgmail&source= =3Dg <https://www.google.com/maps/search/ent+allocations+an= d+don%E2%80%99t+have+to+ask?entry=3Dgmail&source=3Dg>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0for /10.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > As 5G gets rolled out with Enhanced VPN framework
>=C2=A0 =C2=A0 =C2=A0and Network
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0slicing
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > paradigm, the demand for shorter blocks and wearable
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0multiple /48
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0will
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > be our new reality.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Making that 16 bit shift now to /80 making a /64
>=C2=A0 =C2=A0 =C2=A0the new
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0/48 will
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0give
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > broadband and 3GPP subscribers a ton of space to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0subtending their
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > networks we would be set for the future.
>=C2=A0 =C2=A0 =C2=A0Especially with
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0IOT the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0demand
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > for subtending will continue to grow astronomically.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Also IANA does not have to get start in allocating the
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0other /3 and
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > other available blocks.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Lots of problems being solved here with a fixed
>=C2=A0 =C2=A0 =C2=A0/80 new
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0boundary.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Also with the existing random IID generation
>=C2=A0 =C2=A0 =C2=A0schemes which
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0we have
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > tested on Linux kernel can do longer p
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.google.com/maps/search/tes= ted+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg <= https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?e= ntry=3Dgmail&source=3Dg> <https://www.google.com/maps/sear= ch/tested+on+Linux+kernel+can+do+longer+p?entry=3Dgmail&source=3Dg = <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+long= er+p?entry=3Dgmail&source=3Dg>>>refixes
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0using RFC 4941 privacy
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > extension or RFC 7217 stable IID.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > Win-Win for all.
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0Ole
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > --
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > <http://www.verizon.com/ <http://www.verizon.com/> >=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.c= om/ <http://www.verizon.com/>
>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > 13101 Columbia Pike >=C2=A0 =C2=A0 =C2=A0 &g= t;>=C2=A0 =C2=A0 =C2=A0 >= =C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > _______________________________________________
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > v6ops@ietf.org= <mailto:v6ops@i= etf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:v6ops@ietf.org <mailto:v6ops@ietf.org>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > https://www.ietf.org/mailman/listinfo/v6ops<= br> >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<= https://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0<https://www.ietf.org/mailman/listinfo/v6ops >=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<= https://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > <http://www.ver= izon.com/ <http://www.verizon.com/>
>=C2=A0 =C2=A0 =C2=A0<http://www.verizon.com/ <http://www.verizon.= com/>>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > *Gyan Mishra* >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /Network Solutio= ns A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347<= br> >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 > /Silver Spring, MD >=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> --
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> <http://www.verizon.com/ <http://ww= w.verizon.com/>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> *Gyan Mishra*
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> /Network Solutions A//rchitect /
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> /M 301 502-1347
>=C2=A0 =C2=A0 =C2=A0 >> 13101 Columbia Pike
>=C2=A0 =C2=A0 =C2=A0 >> /Silver Spring, MD
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > _____________________________________________= __
>=C2=A0 =C2=A0 =C2=A0 > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailma= n/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/= listinfo/v6ops>
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 =C2=A0= ipv6@ietf.org <mailto:ipv6@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://w= ww.ietf.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/l= istinfo/ipv6>
>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


<= /div>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--
--0000000000002b0b4205b4c0ad7d-- From nobody Sun Nov 22 22:58:53 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D843A152D; Sun, 22 Nov 2020 22:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OygNYVuNPrjf; Sun, 22 Nov 2020 22:58:44 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C643A151E; Sun, 22 Nov 2020 22:58:44 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id y7so14004351pfq.11; Sun, 22 Nov 2020 22:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EsHiThXwSo5ZS3k6sglAfyDaeLJ9Z+0Ta5LvXQUBS5U=; b=U4Xh8sMAxDIpXS0jrc4hiiycKvGg2N6yi49226QVp+JkTNbweHXZdfoMAhsq53jeBr WBHIAxfetq1lnXGnkLjWw5CvLnI176v5ERnbW16Nn9+BIEM7MjpiyAEVbFoPUdPxUyx0 +OzOQNKgOh6+/ITPM++DiYuoNL9dQfGOKewRrgnIwEG4x3LVnf8R+eEBerC4WsdGOYHM twAh9bO1o2szz/+iqyFuIzmToZxy+Ad3YQB+dxAdThsdUDtgrs5FNQDy//VzqSh/U6kt QEYz0YQ3+Ju1L6J0qse6Od4+8bRdaZcd8+Boi+6DDOmkDRvBLvpE7XI1sJbwuZYsNs0o 5gBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EsHiThXwSo5ZS3k6sglAfyDaeLJ9Z+0Ta5LvXQUBS5U=; b=MB9eYuLALSkxktCBDQ8s7Y/XGMlLcPK/ixva+/0h73IjqPFc+ISwTSHP7vOK6QTDwb ScTQ9crbhIM9gwLFMgsN+eC9UBI27P7KamJCoxycqfHm2QMVS9WfDzgma1IGKA9Q5xzD gcmEJMUKg8RH+tRn7kfQohoSnhxFZLbJN0ZrbKIIWfzmXNu//hE3ZAK2OigWcytzPNsb DBk5zUpyXx3yiP9otptQP6kxYy6KN9NCcAw0wCCruTQm+LJQIv9tNiIU+tbFIpCg5bWW NPyhfCtYE6PO+Z4tdwuLsDOMqivOjWJFGNqK2nRTNzS1G5nLwe5V29pu4AYsPsD1raMX pkpg== X-Gm-Message-State: AOAM532amQrD4zsJGTYAf7V9XYLT3bo9H3bsIoK4t87X5EIwSOzPhhR3 3efJqyUCOP6JaKH8qpmleq6zkF5ZqLvQzPWQQl4= X-Google-Smtp-Source: ABdhPJza9z54htkhQugHiP+C5lJJ8l8z5m/WFiHtWcXY1bw3XaNZsOkf8Ykk1SBtMJfv0SVjXGSPTLQQlTv3vjWDTZE= X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr23192669pjx.112.1606114723923; Sun, 22 Nov 2020 22:58:43 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <92CD1CEE-4453-4739-8418-34D20F350244@gmail.com> In-Reply-To: <92CD1CEE-4453-4739-8418-34D20F350244@gmail.com> From: Gyan Mishra Date: Mon, 23 Nov 2020 01:58:33 -0500 Message-ID: To: Bob Hinden Cc: 6MAN <6man@ietf.org>, Brian Carpenter , IPv6 Operations , JORDI PALET MARTINEZ , =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary="0000000000009689b805b4c0b9eb" Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 06:58:48 -0000 --0000000000009689b805b4c0b9eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2020 at 6:02 PM Bob Hinden wrote: > Brian, > > > On Nov 19, 2020, at 2:49 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > And if we had left the boundary at /80, as it was in 1995 (RFC1884), > would you now be arguing for /96, since in that case 3GPP would have > settled on /80? > > > > Sorry, but this is exactly and precisely a 16-bit jump in the race to > the bottom. And it breaks all existing SLAAC hosts on the way. > > > > The problem here is caused by 3GPP, but a solution like Cameron's shoul= d > work for everybody with minimal changes. > > +100 > > Either something like Cameron=E2=80=99s draft or a very minimal DHCPv6 PD > implementation that can run in a 3GPP environment. It doesn=E2=80=99t n= eed to be > a full DHCPv6 server. > > Bob Gyan> One possible non technical factor is that Android which as of 2019 statistical data below holds 87% of the global mobile market share and Apple 13% and Android is continuing to climb in 2020. Android adamantly refuses to change its position on support of DHCPv6. I think that really shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all mobile handsets won=E2=80=99t support it. https://www.statista.com/statistics/272307/market-share-forecast-for-smartp= hone-operating-systems/ > > > > > > > Regards > > Brian > > > > On 20-Nov-20 11:03, Gyan Mishra wrote: > >> > >> > >> On Thu, Nov 19, 2020 at 10:33 AM otroan@employees.org>> wrote: > >> > >> > >> > >>> On 19 Nov 2020, at 14:58, Gyan Mishra hayabusagsm@gmail.com>> wrote: > >>> > >>> You would need a new option. It would likely be useful for the > requesting router to indicate interest in the option. Even hinting at wha= t > prefix size it was expecting. > >>> Now can you explain to me again the reasons why this approach is > better than using the existing DHPCv6 protocol packets? > >>> > >>> 3GPP gateway does not support DHCPv6 > >> > >> 3GPP gateway doesn't support new option. What's your point? > >> > >> > >> > >> The point of the v6ops presentation and this email thread is how t= o > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of the de= ck you compiled a > list of options and of the two I had highlighted in red were the 64share = v2 > Cameron=E2=80=99s option and the variable slaac option. So on the call t= his > morning Lorenzo shot down 64share v2 shorter prefix option as even if the > 3GPP architecture was updated to support longer prefixes and even is the > 3GPP gateway was able to send a shorter prefix with A flag not set, all > mobile devices per Lorenzo=E2=80=99s point would be broken as they would = not accept > the shorter let=E2=80=99s say /56 prefix to build the slaac 128 bit addre= ss. So > the bottom line is the 64share v2 won=E2=80=99t work unless we update RFC= 4291 and > remove the 64 bit boundary. > >> > >> So we are back to square uno - no viable solution > >> > >> So now we had thrown out the longer >64 due to race to bottom worries > which I and others believe is Fud and as described in slide 10 of the v6o= ps > =E2=80=9Crace to the bottom slide=E2=80=9D. > >> > >> So a happy medium /80 fixed boundary I came up with that I think solve= s > a lot of the issue and not just the 3GPP initial segmentation of downstre= am > devices problem statement. > >> > >> Since we have to update RFC 4291 for 64share v2 to work anyways to > allow for shorter prefixes, why not instead create a new bottom at /80 > giving 16 bits more of prefix length and shrinking the IID down to 48 > bits. Doing so you would not even have to update the 3GPP architecture a= s > I don=E2=80=99t know if that would fly or not. Also this solves a few ot= her > problems at the same time. > >> > >> > >> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > mainstream for operators for static addressing on router and switch > infrastructure and dhcpv6 subnets longer prefixes for network > infrastructure appliance clusters, NFV/VNF virtualization and server > farms. On host subnets where there is a chance of mix of slaac hosts wit= h > dhcpv6 devices the prefix length is stuck at /64. So on these mix > addressing host subnets we cannot do longer prefixes following our ND cac= he > hard limit mantra to prevent ND cache exhaustion issues as described in R= FC > 6164. > >> > >> So with the /80 new fixed boundary shifting prefix length 16 bits > longer and shortening the IID by 16 bits gives resolved the 3GPP issue > which 64share can work as is and subtending to downstream devices will no= w > work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 for > broadband not all operators have adopted the shorter prefix lengths /56 o= r > /48 recommendations and now that=E2=80=99s not an issue as the /64 would= now > suffice. > >> > >> From an operators perspective that gain allows at least for 3GPP > massive growth and subtending with a single /64 allows the operators such > as Verizon with massive subscriber base worldwide can stay with current > allocations and don=E2=80=99t have to ask for /10. > >> > >> As 5G gets rolled out with Enhanced VPN framework and Network slicing > paradigm, the demand for shorter blocks and wearable multiple /48 will be > our new reality. > >> > >> Making that 16 bit shift now to /80 making a /64 the new /48 will give > broadband and 3GPP subscribers a ton of space to subtending their network= s > we would be set for the future. Especially with IOT the demand for > subtending will continue to grow astronomically. > >> > >> Also IANA does not have to get start in allocating the other /3 and > other available blocks. > >> > >> Lots of problems being solved here with a fixed /80 new boundary. > >> > >> Also with the existing random IID generation schemes which we have > tested on Linux kernel can do longer prefixes using RFC 4941 privacy > extension or RFC 7217 stable IID. > > >> > >> Win-Win for all. > >> > >> Ole > >> > >> -- > >> > >> > >> > >> *Gyan Mishra* > >> > >> /Network Solutions A//rchitect / > >> > >> /M 301 502-1347 > >> 13101 Columbia Pike > >> /Silver Spring, MD > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000009689b805b4c0b9eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 19, 2020 at 6:02 PM Bob Hinden <bob.hinden@gmail.com> wrote:
Brian,

> On Nov 19, 2020, at 2:49 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> And if we had left the boundary at /80, as it was in 1995 (RFC1884), w= ould you now be arguing for /96, since in that case 3GPP would have settled= on /80?
>
> Sorry, but this is exactly and precisely a 16-bit jump in the race to = the bottom. And it breaks all existing SLAAC hosts on the way.
>
> The problem here is caused by 3GPP, but a solution like Cameron's = should work for everybody with minimal changes.

+100

Either something like Cameron=E2=80=99s draft or a very minimal DHCPv6 PD i= mplementation that can run in a 3GPP environment.=C2=A0 =C2=A0It doesn=E2= =80=99t need to be a full DHCPv6 server.

Bob

=C2=A0 =C2=A0= =C2=A0G= yan> One possible non technical factor is that Android which as of 2019 = statistical data below holds 87% of the global mobile market share and Appl= e 13% and Android is continuing to climb in 2020. =C2=A0 Android adamantly = refuses to change its position on support of DHCPv6.=C2=A0 I think that rea= lly shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all m= obile handsets won=E2=80=99t support it.

https://www.statista.com/sta= tistics/272307/market-share-forecast-for-smartphone-operating-systems/<= /div>



>
> Regards
>=C2=A0 =C2=A0Brian
>
> On 20-Nov-20 11:03, Gyan Mishra wrote:
>>
>>
>> On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org <mailto:otroan@employees.org>= ;> wrote:
>>
>>
>>
>>> On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.com <mailto= :hayabusagsm@gma= il.com>> wrote:
>>>
>>> You would need a new option. It would likely be useful for the= requesting router to indicate interest in the option. Even hinting at what= prefix size it was expecting.
>>> Now can you explain to me again the reasons why this approach = is better than using the existing DHPCv6 protocol packets?
>>>
>>>=C2=A0 =C2=A0 =C2=A0 3GPP gateway does not support DHCPv6
>>
>>=C2=A0 =C2=A0 3GPP gateway doesn't support new option. What'= ;s your point?
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0The point of the v6ops presentation and this em= ail thread is how to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case=C2= =A0 in slide 1 of the deck you compiled a list of options and of the two I = had highlighted in red were the 64share v2 Cameron=E2=80=99s option and the= variable slaac option.=C2=A0 So on the call this morning Lorenzo shot down= 64share v2 shorter prefix option as even if the 3GPP architecture was upda= ted to support longer prefixes and even is the 3GPP gateway was able to sen= d a shorter prefix with A flag not set, all mobile devices per Lorenzo=E2= =80=99s point would be broken as they would not accept the shorter let=E2= =80=99s say /56 prefix to build the slaac 128 bit address.=C2=A0 So the bot= tom line is the 64share v2 won=E2=80=99t work unless we update RFC 4291 and= remove the 64 bit boundary.
>>
>>=C2=A0 So we are back to square uno - no viable solution
>>
>>=C2=A0 So now we had thrown out the longer >64 due to race to bo= ttom worries which I and others believe is Fud and as described in slide 10= of the v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>>
>> So a happy medium /80 fixed boundary I came up with that I think s= olves a lot of the issue and not just the 3GPP initial segmentation of down= stream devices problem statement.
>>
>> Since we have to update RFC 4291 for 64share v2 to work anyways to= allow for shorter prefixes, why not instead create a new bottom at /80 giv= ing 16 bits more of prefix length and shrinking the IID down to 48 bits.=C2= =A0 Doing so you would not even have to update the 3GPP architecture as I d= on=E2=80=99t know if that would fly or not.=C2=A0 Also this solves a few ot= her problems at the same time.
>>
>>
>> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is m= ainstream for operators for static addressing on router and switch infrastr= ucture and dhcpv6 subnets longer prefixes for network infrastructure applia= nce clusters, NFV/VNF virtualization and server farms.=C2=A0 On host subnet= s where there is a chance of mix of slaac hosts with dhcpv6=C2=A0 devices t= he prefix length is stuck at /64.=C2=A0 So on these mix addressing host sub= nets we cannot do longer prefixes following our ND cache hard limit mantra = to prevent ND cache exhaustion issues as described in RFC 6164.
>>
>> So with the /80 new fixed boundary shifting prefix length 16 bits = longer and shortening the IID by 16 bits gives resolved the 3GPP issue whic= h 64share can work as is and subtending to downstream devices will now work= as a /64 is now equivalent to a /48 with 64k /80s.=C2=A0 Also BCP-690 for = broadband not all operators have adopted the shorter prefix lengths /56 or = /48 recommendations=C2=A0 and now that=E2=80=99s not an issue as the /64 wo= uld now suffice.
>>
>> From an operators perspective that gain allows at least for 3GPP m= assive growth and subtending with a single /64 allows the operators such as= Verizon with massive subscriber base worldwide can stay with current alloc= ations and don=E2=80=99t have to ask for /10.
>>
>> As 5G gets rolled out with Enhanced VPN framework and Network slic= ing paradigm, the demand for shorter blocks and wearable multiple /48 will = be our new reality.
>>
>> Making that 16 bit shift now to /80 making a /64 the new /48 will = give broadband and 3GPP subscribers a ton of space to subtending their netw= orks we would be set for the future.=C2=A0 Especially with IOT the demand f= or subtending will continue to grow astronomically.
>>
>> Also IANA does not have to get start in allocating the other /3 an= d other available blocks.
>>
>> Lots of problems being solved here with a fixed /80 new boundary.<= br> >>
>> Also with the existing random IID generation schemes which we have= tested on Linux kernel can do longer prefixes using RFC 4941 privacy extension or RFC 7217 stable IID. >>
>> Win-Win for all.
>>
>>=C2=A0 =C2=A0 Ole
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> /Network Solutions A//rchitect /
>>
>> /M 301 502-1347
>> 13101 Columbia Pike
>> /Silver Spring, MD
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

--
--0000000000009689b805b4c0b9eb-- From nobody Sun Nov 22 23:27:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977983A1668; Sun, 22 Nov 2020 23:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMnHNt72PrNs; Sun, 22 Nov 2020 23:27:30 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FFB3A1665; Sun, 22 Nov 2020 23:27:29 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id s2so8412470plr.9; Sun, 22 Nov 2020 23:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kDIQumpu7dwv2d/vWgO/0c5pp1J05GshTiqoySmk5Fc=; b=EM+2lsQt9FMDtK+Sp9O0oJKGKkEzV+Xc/1cx8v55MVbdJHJg0Hq1kbKyFIefuDdAtX k12d0+cp3HHlXjQratYUtczKuehkerRhLpem2xXUdIvHLF6pybeQbzCGAsVqGkeZj2Se dV4XzDpzTjUzrVaew4XVmp9D82XRzylkMXM8pclwvU7xpi9cp/0zIdXitsP7NZaKB3G3 +U9BMc3CZ9Mh18RZbuBd0ANo9HrX7UIInlZpPEIEEIP/FZS3wB1yMt9CUhyIjvzWAKDj MZ/Hzwks3mGODBIf2P9VrWpuixRLx+fVgW1s/xOnzq5HwiOV3O/KbCeQ0huIbdBrbX+D m+Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kDIQumpu7dwv2d/vWgO/0c5pp1J05GshTiqoySmk5Fc=; b=VYKHr1TC2XyTCmsa07zZZLAryIldR/Ddi8vDn6lEoipqHXHV1oG6oQVio1cWKI77Pi RibQmTdRYu6T0xU+690fppHKm/uY5tuGDW4yPltKHXJosGJeRipPMlkxX4K96CIV2faY FVlaZo/NswsYTsYV9acpmBdozcQKlBYf5fEF2PrgPwaJ6dAXRVffr1dKCrcLEZeuxNEj L9JWx7066E+zKoOCBG4IhLbDYom5WweFJgs0yRHGAbrvSUAInjVt6wx5L2rBItF/MPyc wAY3+yiv63PXCo8ca+yTafpBg/XK1ELsfQpLlQrPao1MslhOpOikat8HYaCfZgTzc2j2 PZug== X-Gm-Message-State: AOAM533u/d53rkQEQpenYIfAnshDoHydliQhC1B554K8iptoZykEBYCp tEU6+2A9YrfIzC0KFDUTEEix4a2yxGrIofjje/M= X-Google-Smtp-Source: ABdhPJwue4304NbecABtV2eLIUIvRU1g52lMj7FKprkOIr82p3IV/7N2Mc7V0Ec8BY0067NDe14JIqB+O1aWAS+gMYs= X-Received: by 2002:a17:902:b717:b029:d9:e816:fd0b with SMTP id d23-20020a170902b717b02900d9e816fd0bmr11636739pls.50.1606116449244; Sun, 22 Nov 2020 23:27:29 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <92CD1CEE-4453-4739-8418-34D20F350244@gmail.com> In-Reply-To: From: Gyan Mishra Date: Mon, 23 Nov 2020 02:27:17 -0500 Message-ID: To: Bob Hinden Cc: 6MAN <6man@ietf.org>, Brian Carpenter , IPv6 Operations , JORDI PALET MARTINEZ , =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary="0000000000006cdbf205b4c12018" Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 07:27:33 -0000 --0000000000006cdbf205b4c12018 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2020 at 1:58 AM Gyan Mishra wrote: > > > On Thu, Nov 19, 2020 at 6:02 PM Bob Hinden wrote: > >> Brian, >> >> > On Nov 19, 2020, at 2:49 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> > >> > And if we had left the boundary at /80, as it was in 1995 (RFC1884), >> would you now be arguing for /96, since in that case 3GPP would have >> settled on /80? >> > >> > Sorry, but this is exactly and precisely a 16-bit jump in the race to >> the bottom. And it breaks all existing SLAAC hosts on the way. >> > >> > The problem here is caused by 3GPP, but a solution like Cameron's >> should work for everybody with minimal changes. >> >> +100 >> >> Either something like Cameron=E2=80=99s draft or a very minimal DHCPv6 P= D >> implementation that can run in a 3GPP environment. It doesn=E2=80=99t = need to be >> a full DHCPv6 server. >> >> Bob > > > Gyan> One possible non technical factor is that Android which as of > 2019 statistical data below holds 87% of the global mobile market share a= nd > Apple 13% and Android is continuing to climb in 2020. Android adamantly > refuses to change its position on support of DHCPv6. I think that really > shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all > mobile handsets won=E2=80=99t support it. > > > https://www.statista.com/statistics/272307/market-share-forecast-for-smar= tphone-operating-systems/ > >> >> Gyan> How do you propose to solve this issue if Android holds 90% of the >> market and is growing and Google adamantly stated they will not support >> DHCPv6 or PD. > > So the problem is 2 fold and I am not sure 100% if one has a dependency on the other. 3GPP architecture for PD support has been around for over 10 years. Operators have chosen to NOT support PD. I am thinking there is some underlying technical issue but they plan to not support for 5G as well. I don=E2=80=99t think that is changing any time soon or ever. What does make the solution more complicated is my post above that Android hold 90% of the mobile market share so even if the operators were willing to support PD, 90% of handsets would not work. I am not sure if Apple iOS supports DHCPv6 or PD? I did google and does not look like Apple iOS supports DHCPv6 or PD. I am not just throwing our fluff to change change to a new bottom /80. I don=E2=80=99t think we have a lot of options as we have a lot of forces goi= ng against us that our out of the IETF=E2=80=99s control. Hypothetically if we moved to /80 being the new fixed IID boundary, how is that any different then our current /64 in the context that you believe that a new /96 or /112 or /128 boundary will magically form if we changed the fixed boundary to /80. Please explain how our current /64 boundary has stayed a /64 boundary and has not magically changed to /80 or /96 ...??? We would of course have to make the /80 change so it backwards compatible so existing devices are not impacted. As far as I can tell from all the threads the /80 fixed boundary proposal is the only real viable solution. If we think 16 bits is way too much I am OK with shrinking way down as for SOHO or tethering I think a few bits would do the trick. How about a /68 as the new fixed boundary. That would yield 16 /64s or maybe even a /72 8 extra bits yielding 255 /64s would still be way plenty. Any takers?? >> >> > >> > Regards >> > Brian >> > >> > On 20-Nov-20 11:03, Gyan Mishra wrote: >> >> >> >> >> >> On Thu, Nov 19, 2020 at 10:33 AM > otroan@employees.org>> wrote: >> >> >> >> >> >> >> >>> On 19 Nov 2020, at 14:58, Gyan Mishra > hayabusagsm@gmail.com>> wrote: >> >>> >> >>> You would need a new option. It would likely be useful for the >> requesting router to indicate interest in the option. Even hinting at wh= at >> prefix size it was expecting. >> >>> Now can you explain to me again the reasons why this approach is >> better than using the existing DHPCv6 protocol packets? >> >>> >> >>> 3GPP gateway does not support DHCPv6 >> >> >> >> 3GPP gateway doesn't support new option. What's your point? >> >> >> >> >> >> >> >> The point of the v6ops presentation and this email thread is how >> to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of th= e deck you compiled >> a list of options and of the two I had highlighted in red were the 64sha= re >> v2 Cameron=E2=80=99s option and the variable slaac option. So on the ca= ll this >> morning Lorenzo shot down 64share v2 shorter prefix option as even if th= e >> 3GPP architecture was updated to support longer prefixes and even is the >> 3GPP gateway was able to send a shorter prefix with A flag not set, all >> mobile devices per Lorenzo=E2=80=99s point would be broken as they would= not accept >> the shorter let=E2=80=99s say /56 prefix to build the slaac 128 bit addr= ess. So >> the bottom line is the 64share v2 won=E2=80=99t work unless we update RF= C 4291 and >> remove the 64 bit boundary. >> >> >> >> So we are back to square uno - no viable solution >> >> >> >> So now we had thrown out the longer >64 due to race to bottom worrie= s >> which I and others believe is Fud and as described in slide 10 of the v6= ops >> =E2=80=9Crace to the bottom slide=E2=80=9D. >> >> >> >> So a happy medium /80 fixed boundary I came up with that I think >> solves a lot of the issue and not just the 3GPP initial segmentation of >> downstream devices problem statement. >> >> >> >> Since we have to update RFC 4291 for 64share v2 to work anyways to >> allow for shorter prefixes, why not instead create a new bottom at /80 >> giving 16 bits more of prefix length and shrinking the IID down to 48 >> bits. Doing so you would not even have to update the 3GPP architecture = as >> I don=E2=80=99t know if that would fly or not. Also this solves a few o= ther >> problems at the same time. >> >> >> >> >> >> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is >> mainstream for operators for static addressing on router and switch >> infrastructure and dhcpv6 subnets longer prefixes for network >> infrastructure appliance clusters, NFV/VNF virtualization and server >> farms. On host subnets where there is a chance of mix of slaac hosts wi= th >> dhcpv6 devices the prefix length is stuck at /64. So on these mix >> addressing host subnets we cannot do longer prefixes following our ND ca= che >> hard limit mantra to prevent ND cache exhaustion issues as described in = RFC >> 6164. >> >> >> >> So with the /80 new fixed boundary shifting prefix length 16 bits >> longer and shortening the IID by 16 bits gives resolved the 3GPP issue >> which 64share can work as is and subtending to downstream devices will n= ow >> work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 fo= r >> broadband not all operators have adopted the shorter prefix lengths /56 = or >> /48 recommendations and now that=E2=80=99s not an issue as the /64 woul= d now >> suffice. >> >> >> >> From an operators perspective that gain allows at least for 3GPP >> massive growth and subtending with a single /64 allows the operators suc= h >> as Verizon with massive subscriber base worldwide can stay with current >> allocations and don=E2=80=99t have to ask for /10. >> >> >> >> As 5G gets rolled out with Enhanced VPN framework and Network slicing >> paradigm, the demand for shorter blocks and wearable multiple /48 will b= e >> our new reality. >> >> >> >> Making that 16 bit shift now to /80 making a /64 the new /48 will giv= e >> broadband and 3GPP subscribers a ton of space to subtending their networ= ks >> we would be set for the future. Especially with IOT the demand for >> subtending will continue to grow astronomically. >> >> >> >> Also IANA does not have to get start in allocating the other /3 and >> other available blocks. >> >> >> >> Lots of problems being solved here with a fixed /80 new boundary. >> >> >> >> Also with the existing random IID generation schemes which we have >> tested on Linux kernel can do longer prefixes using RFC 4941 privacy >> extension or RFC 7217 stable IID. >> >> >> >> >> Win-Win for all. >> >> >> >> Ole >> >> >> >> -- >> >> >> >> >> >> >> >> *Gyan Mishra* >> >> >> >> /Network Solutions A//rchitect / >> >> >> >> /M 301 502-1347 >> >> 13101 Columbia Pike >> >> /Silver Spring, MD >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000006cdbf205b4c12018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 23, 2020 at 1:58 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:


On Thu, Nov 19, 2020 at 6:02 PM Bob Hinden = <bob.hinden@gm= ail.com> wrote:
Brian,

> On Nov 19, 2020, at 2:49 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> And if we had left the boundary at /80, as it was in 1995 (RFC1884), w= ould you now be arguing for /96, since in that case 3GPP would have settled= on /80?
>
> Sorry, but this is exactly and precisely a 16-bit jump in the race to = the bottom. And it breaks all existing SLAAC hosts on the way.
>
> The problem here is caused by 3GPP, but a solution like Cameron's = should work for everybody with minimal changes.

+100

Either something like Cameron=E2=80=99s draft or a very minimal DHCPv6 PD i= mplementation that can run in a 3GPP environment.=C2=A0 =C2=A0It doesn=E2= =80=99t need to be a full DHCPv6 server.

Bob



Gyan> How do you propose to solve this issue if Android holds 90% of the= market and is growing and Google adamantly stated they will not support DH= CPv6 or PD. =C2=A0
<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 So the problem is 2 = fold and I am not sure 100% if one has a dependency on the other. =C2=A0

=C2=A0 =C2=A03GPP architec= ture for PD support has been around =C2=A0for over 10 years.=C2=A0 Operator= s have chosen to NOT support PD.=C2=A0 I am thinking there is some underlyi= ng technical issue but they plan to not support for 5G as well.=C2=A0 I don= =E2=80=99t think that is changing any time soon or ever.

What does make the solution more complicat= ed is my post above that Android hold 90% of the mobile market share so eve= n if the operators were willing to support PD, 90% of handsets would not wo= rk. =C2=A0

I am not sure= if Apple iOS supports DHCPv6 or PD?

I did google and does not look like Apple iOS supports DHCPv6 = or PD.

I am not just thr= owing our fluff to change change to a new bottom /80.=C2=A0 I don=E2=80=99t= think we have a lot of options as we have a lot of forces going against us= that our out of the IETF=E2=80=99s control. =C2=A0
=
Hypothetically if we moved to /80 being the new= fixed IID boundary, how is that any different then our current /64 in the = context that you believe that a new /96 or /112 or /128 boundary will magic= ally form if we changed the fixed boundary to /80.
<= br>
Please explain how our current /64 boundary has = stayed a /64 boundary and has not magically changed to /80 or /96 ...???

We would of course have to= make the /80 change so it backwards compatible so existing devices are not= impacted.

As far as I c= an tell from all the threads the /80 fixed boundary proposal is the only re= al viable solution.

If w= e think 16 bits is way too much I am OK with shrinking way down as for SOHO= or tethering I think a few bits would do the trick. =C2=A0

How about a /68 as the new fixed boun= dary.=C2=A0 That would yield 16 /64s or maybe even a /72 8 extra bits yield= ing 255 /64s would still be way plenty.

Any takers??=C2=A0


>
> Regards
>=C2=A0 =C2=A0Brian
>
> On 20-Nov-20 11:03, Gyan Mishra wrote:
>>
>>
>> On Thu, Nov 19, 2020 at 10:33 AM <otroan@employees.org <mailto:otroan@employees.org>= ;> wrote:
>>
>>
>>
>>> On 19 Nov 2020, at 14:58, Gyan Mishra <hayabusagsm@gmail.com <mailto= :hayabusagsm@gma= il.com>> wrote:
>>>
>>> You would need a new option. It would likely be useful for the= requesting router to indicate interest in the option. Even hinting at what= prefix size it was expecting.
>>> Now can you explain to me again the reasons why this approach = is better than using the existing DHPCv6 protocol packets?
>>>
>>>=C2=A0 =C2=A0 =C2=A0 3GPP gateway does not support DHCPv6
>>
>>=C2=A0 =C2=A0 3GPP gateway doesn't support new option. What'= ;s your point?
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0The point of the v6ops presentation and this em= ail thread is how to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case=C2= =A0 in slide 1 of the deck you compiled a list of options and of the two I = had highlighted in red were the 64share v2 Cameron=E2=80=99s option and the= variable slaac option.=C2=A0 So on the call this morning Lorenzo shot down= 64share v2 shorter prefix option as even if the 3GPP architecture was upda= ted to support longer prefixes and even is the 3GPP gateway was able to sen= d a shorter prefix with A flag not set, all mobile devices per Lorenzo=E2= =80=99s point would be broken as they would not accept the shorter let=E2= =80=99s say /56 prefix to build the slaac 128 bit address.=C2=A0 So the bot= tom line is the 64share v2 won=E2=80=99t work unless we update RFC 4291 and= remove the 64 bit boundary.
>>
>>=C2=A0 So we are back to square uno - no viable solution
>>
>>=C2=A0 So now we had thrown out the longer >64 due to race to bo= ttom worries which I and others believe is Fud and as described in slide 10= of the v6ops =E2=80=9Crace to the bottom slide=E2=80=9D.
>>
>> So a happy medium /80 fixed boundary I came up with that I think s= olves a lot of the issue and not just the 3GPP initial segmentation of down= stream devices problem statement.
>>
>> Since we have to update RFC 4291 for 64share v2 to work anyways to= allow for shorter prefixes, why not instead create a new bottom at /80 giv= ing 16 bits more of prefix length and shrinking the IID down to 48 bits.=C2= =A0 Doing so you would not even have to update the 3GPP architecture as I d= on=E2=80=99t know if that would fly or not.=C2=A0 Also this solves a few ot= her problems at the same time.
>>
>>
>> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is m= ainstream for operators for static addressing on router and switch infrastr= ucture and dhcpv6 subnets longer prefixes for network infrastructure applia= nce clusters, NFV/VNF virtualization and server farms.=C2=A0 On host subnet= s where there is a chance of mix of slaac hosts with dhcpv6=C2=A0 devices t= he prefix length is stuck at /64.=C2=A0 So on these mix addressing host sub= nets we cannot do longer prefixes following our ND cache hard limit mantra = to prevent ND cache exhaustion issues as described in RFC 6164.
>>
>> So with the /80 new fixed boundary shifting prefix length 16 bits = longer and shortening the IID by 16 bits gives resolved the 3GPP issue whic= h 64share can work as is and subtending to downstream devices will now work= as a /64 is now equivalent to a /48 with 64k /80s.=C2=A0 Also BCP-690 for = broadband not all operators have adopted the shorter prefix lengths /56 or = /48 recommendations=C2=A0 and now that=E2=80=99s not an issue as the /64 wo= uld now suffice.
>>
>> From an operators perspective that gain allows at least for 3GPP m= assive growth and subtending with a single /64 allows the operators such as= Verizon with massive subscriber base worldwide can stay with current alloc= ations and don=E2=80=99t have to ask for /10.
>>
>> As 5G gets rolled out with Enhanced VPN framework and Network slic= ing paradigm, the demand for shorter blocks and wearable multiple /48 will = be our new reality.
>>
>> Making that 16 bit shift now to /80 making a /64 the new /48 will = give broadband and 3GPP subscribers a ton of space to subtending their netw= orks we would be set for the future.=C2=A0 Especially with IOT the demand f= or subtending will continue to grow astronomically.
>>
>> Also IANA does not have to get start in allocating the other /3 an= d other available blocks.
>>
>> Lots of problems being solved here with a fixed /80 new boundary.<= br> >>
>> Also with the existing random IID generation schemes which we have= tested on Linux kernel can do longer prefixes using RFC 4941 privacy extension or RFC 7217= stable IID.
>>
>> Win-Win for all.
>>
>>=C2=A0 =C2=A0 Ole
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> /Network Solutions A//rchitect /
>>
>> /M 301 502-1347
>> 13101 Columbia Pike
>> /Silver Spring, MD
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

--


G= yan Mishra

Network Solutio= ns Architect=C2= =A0

M 301 502-1347
13101 Columbia Pike=C2=A0
= Silver Spring, MD


--
--0000000000006cdbf205b4c12018-- From nobody Sun Nov 22 23:44:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69DB3A1493; Sun, 22 Nov 2020 23:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.841 X-Spam-Level: X-Spam-Status: No, score=0.841 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_20=0.7, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.328, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSMORkceqLUO; Sun, 22 Nov 2020 23:44:06 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4403A168D; Sun, 22 Nov 2020 23:44:06 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id v21so7176269plo.12; Sun, 22 Nov 2020 23:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YHEhHJ5750XlPAl/6ZDvKDzuJzaCDlmfwwLRj+g4Yuo=; b=IJ28//oFjRc6AzGzpqYfCEo0FR16Xiw/szJ9uKyWiA3jsY8uYJD6ePOZqntiCFMjcM IvK0OHD1mDJgSCcEyudW25xv/eq6M7bbCMnkG9NPCYziV+iuB5Nr5/JX+wza/dX5Q/vR SJOYXfysrwSUnGsJMpCc1xr60mRcKInLZv8vwAglAyEpxUm/gtyamQMrGMTR3O0lBtJ4 bn55JMyoLqX2RMNBgAqCqi1pBr32YJPNN4w1+gsfZCqDBvh0Y4hwyDnRtiOzfKZszEkd 4WGWtvJddQomUhY7quXqCFQfUMXDnvm/f8BzzzKWIPIX+eQ0DU/K8HCR3o4Ytr8bQ26U 8YRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YHEhHJ5750XlPAl/6ZDvKDzuJzaCDlmfwwLRj+g4Yuo=; b=R1vaIMOBz/afn5xclISd2Y+p3Ic2kbosQsW+v09iBPecvgjD8UN7i4vWeUdp73dBG5 u/JWGiNNnm5m+TMiPl+L1vknzrPFcpplnAe2qK690cvo868GjI4cVaA6eiRm1XH4SqPg gjTkKg5msVrV/4u1U6sP68ZUom3/hmBJlRL1FEih/AJwNYFZAHNrFM3CSEU1FtHNGfjj 1ofqRhEfsl0UGw61vVOHJIM71hOTgC7je/N0oi0PzVd8tGzziczoPF6ninLT8EOFHTnn 4Bkcqj2bQukvUuSADCD13F8x1/lNrGIX84/vJ2SKho529MTB43L349socTgnPR/ycyNz U2cw== X-Gm-Message-State: AOAM533XvppDxVjidHefRM3dJnb4zGBhH8/jr7LRak4uDfmPss3MqZYE U2WQumpi7i0Q0KwlDta6HTmhU0bwh7C+5ROsu+evCxhU+7E= X-Google-Smtp-Source: ABdhPJw2mcQ0VPBfn6zkHaELCoQI+ccWdS4NpkMsKDqps99tSg0dKQL6MZ5aPzL4wvBm/VN1bEX/uprOvcdCfX2B/cY= X-Received: by 2002:a17:902:6905:b029:d9:9114:280d with SMTP id j5-20020a1709026905b02900d99114280dmr15492146plk.74.1606117445427; Sun, 22 Nov 2020 23:44:05 -0800 (PST) MIME-Version: 1.0 From: Gyan Mishra Date: Mon, 23 Nov 2020 02:43:54 -0500 Message-ID: To: 6MAN <6man@ietf.org>, Alexandre Petrescu , IPv6 Operations , "draft-mishra-6man-variable-slaac@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cd64c105b4c15bf4" Archived-At: Subject: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 07:44:08 -0000 --000000000000cd64c105b4c15bf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How do we propose to solve this problem if operators don=E2=80=99t support = PD even though the 3GPP standard has supported PD for over 10 years. Another twist to this puzzle is Android has 90% of the mobile handset marketplace worldwide and adamantly states they will NOT support DHCPv6 or PD. I researched Apple which has 10% of the market and they also do not support PD. Whats the solution now? --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000cd64c105b4c15bf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

How do we propose to solve th= is problem if operators don=E2=80=99t support PD even though the =C2=A03GPP= standard has supported PD for over 10 years.

Another twist to this puzzle is Android has 90% of th= e mobile handset marketplace worldwide and adamantly states they will NOT s= upport DHCPv6 or PD.

I r= esearched Apple which has 10% of the market and they also do not support PD= .

Whats the solution now= ?
--
--000000000000cd64c105b4c15bf4-- From nobody Mon Nov 23 01:03:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47863A165D; Mon, 23 Nov 2020 01:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.72 X-Spam-Level: X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gcCA+sqE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZbmTGUcb Received: 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-0w2wUk5Tle; Mon, 23 Nov 2020 01:03:50 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B4F3A1450; Mon, 23 Nov 2020 01:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9336; q=dns/txt; s=iport; t=1606122230; x=1607331830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A4UOZ15d3Oowtb9yJvx6Rt39ydOtPHPFoCWGF/sLAL8=; b=gcCA+sqEtmFZwBZ731h2NUbnCrAdXSYqTy8cgCp0Rv7U+nlJO57EF+Kl CGimX99jpfelACOerzH/h7F9f8q7xiB06lyQl/xQte1J23D6NT6g7l9iL jYfObT2gu8Q7LoqdjHlfH30Trxj1lQOp8gn9cGBMNaP0Mr7B09cT6ICKq 8=; X-IPAS-Result: =?us-ascii?q?A0CHBwC7eLtffY9dJa1fAx0BAQEBCQESAQUFAUCBT4FSK?= =?us-ascii?q?Sh7WS8uCoQzg0kDjVqKFY5vgUKBEQNUCwEBAQ0BARgLCgIEAQGESgIXghQCJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDAQEQEREMAQEqA?= =?us-ascii?q?gIGAwELBAIBCAcKAQMBAQECAiMDAgICHwYLFAECBggCBAENBQgTAwEDgwWCV?= =?us-ascii?q?QMuAQ6fBQKBPIhodoEygwQBAQWBMwGDdA0LghAJgQ4qgnOCZk5CgQaFURuBQ?= =?us-ascii?q?T+BEUOCTz6CG0IBAQKBKAEMBgEJGhUKJoJQM4Isk3GkBFUKgm6WC4U1gxqKG?= =?us-ascii?q?ZRSk1yCAYtyjjaENwIEAgQFAg4BAQWBayFpcHAVO4JpCUcXAg2OHwwFEoECA?= =?us-ascii?q?Q2CPoUUhUR0AgE0AgYBCQEBAwl8iweBNAGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3Ak+1m/BSV/hg7Y5OChknFd5iPq9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,361,1599523200"; d="scan'208";a="612917608" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Nov 2020 09:03:48 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AN93mYM004070 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2020 09:03:48 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 03:03:48 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 03:03:47 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 23 Nov 2020 03:03:47 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hoti23TXaFfMGlpuv7JvLu8vr4Ub9W5So6ulRhr0ag3Pv9mzJAU9aH0GZ777bj1ENhKLquKw/wYns17/I/etn1+iGobd5G72RvPHq/sRiUrf0sLzVdpOD36OH0pDKjpurQukFYroKK/fZRTCcdrDRfkihLM20DiTDWnjTh/1prA1PtbAtw43IktyHsu994SmmAjAxbL2KvV4/XmeuIwfdUQzhgqbkaLTKM2TM3vgLZ+CrUkEAoSO5jFZ2XuNhQShnQOZhkwb+vHa02X/9brmZVz2N/gO79IS8lAIV/AMXWPYdDIrgpsxKejae520rDlp3ZZhlLrsqnZio2vYTnuhpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A4UOZ15d3Oowtb9yJvx6Rt39ydOtPHPFoCWGF/sLAL8=; b=O67vzFAlUz6KcsqX5xtTI1xpghXANa2Wr05roE/9RTLKZEbFlY14PVSCejFMnBZOhjJvaurgx4dPyluRj87AZV5Bp7Jr+XC9lg60lKYeVQTrSsWGGT7MptvlyPCAWCtVoFiLMIHIrVZswRE+KC7kZNMLkPT9wG5TE7PQSuq0oghCZVWRKHfq3Mc66zhgPhXWb8h8WDgdVmVWr5JMZcTJQ2OEr55/Yjy4cUovBcgieVuNWWjEqWEPHTdUYMzk3vALetUAwG5hHZ2MLHPTa5BDSODvHqiOAPZOCubCVI+OFQZXHXQZUojs9qRuzmgL/JrUj7pTiaYR1RN3eInRyEaeiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A4UOZ15d3Oowtb9yJvx6Rt39ydOtPHPFoCWGF/sLAL8=; b=ZbmTGUcbBHVbiI95kyXK4Unz15NDX4hLNAiS6r3NIvF96vbL+XDaSLTJZAT0KbCfrkrP+j1htz3xzBhedB8KX7uVDap8Isp6mzy36SDFokElYyU4DxsTX+5doYzEgSrLMKHZgs8oM2azKtI/iseHEpL/ntPdS8i4MHfgJpjw0/Y= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4585.namprd11.prod.outlook.com (2603:10b6:303:52::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Mon, 23 Nov 2020 09:03:46 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Mon, 23 Nov 2020 09:03:46 +0000 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , Gyan Mishra , "otroan@employees.org" CC: IPv6 Operations , 6MAN <6man@ietf.org>, "JORDI PALET MARTINEZ" Thread-Topic: [v6ops] The bottom is /112 Thread-Index: AQHWvsaGXsDvNQUAW0OOJ7Lq2qz76anVa8aw Date: Mon, 23 Nov 2020 09:03:29 +0000 Deferred-Delivery: Mon, 23 Nov 2020 09:02:53 +0000 Message-ID: References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.38] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57d9db55-fa72-4bdb-de4f-08d88f8eaf4f x-ms-traffictypediagnostic: MW3PR11MB4585: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: teFUU+4HnZ/3PaOKAcRIZCZm4lFopjZ/q6cCDNjbk+Nu4b4d3f6RRT/+CbeKI170k9rf/QX9uMppfQV9PM2EMR54QynOAgy6iYcWd+uubZ48NJB4JKBDRn50TrOjjr6lJX4ASo3G6DX0uNuLAeyymn00p5lAnBspLTGhtutP13Dr3xwUiqSeNGd6j6KGmhMT8M+BMRRP7H+nbB8J7BoJCZcDVVBaaN0HRu5dUf9vFhMTpkCarA7R20KReGAi8Q0t88Bd+y5fhFWEg5uooBjpFRPCjkoWPx8Mh645r1NxRIJq8Ixpn6Jmz/LbIbRpdflDKY/0Sw+JFf+5WNI5eRDw6jeIXifjEnAIuFf7o158NkrwWPu/DPrAabjY32PTih+9Q6BMkZcDbdFoTdnWAGwgVg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(346002)(376002)(396003)(55016002)(52536014)(110136005)(66946007)(54906003)(478600001)(83380400001)(8676002)(53546011)(6506007)(186003)(66476007)(9686003)(64756008)(66556008)(26005)(316002)(66446008)(86362001)(76116006)(6666004)(66574015)(4326008)(33656002)(966005)(71200400001)(5660300002)(8936002)(2906002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: m3mw28mK/rjhdCJHzO3vfjMo7UUncGBtcUDWojiqG3X262bWm9ETAfSt6sFK8W/MTKaKGjh5HB34APJ50rqi1rlXEraN9c7aTxH1KpDUFLxhlUmuBgnLGYBc/Y2vHtK7l8LF+BTqDmgSjKkxKXijChh+l4o4YWsPPdxqtAZTZQ7LqFFA3xDopM1alzeBIwuxwiw24kX2aJ74zjO7jJNEbG83qCDOGud6L8dHxC9qVR6lgejlkEdv55NorLJq4kax+gfAcR8vkghtUUnmgmSUj02HQjo99lCc7dT4oPIRLgspoB70IIFMOVmgT/hRbtpyrCm7s7CqxCcQzCfoXeAOR+W44NHN993cmTSeiNNb1fQLW/XE2d5lF17VvMtfuvtHdrvJBRHDfbEyurCNm0jUa1tmSCEcivKmQveX0bilKE494chjMjwMEPS5WDPe7JXdjoLBF8Is56NypzZXHCQjZP/nQLRIhbB7HzweG9ZLt2t42QiglpZRUebxALuDiy2x3WGTDkUemnDuELXBRIwH2rKEXev70nEz7jkJNzPtH9tcwiIBKJ0Jf7KhhWKos9C1niln7racKKWN7ELaTg8iIENsPJA4lPkT/WusryjVkMAxIgNvJ+ihnU4pw8srjHDWRKa4q+lt+2clqd/V9FmDA0iYU/jfAdMjsOCv7MifJFpwLhndUxrdzI9f9mJJhn+BVTc9oL32F7EiW3VEj2YX5aH53NKvhN8xdpNNn1gzUrnnGqj5x0wu4J8eMVvRTU1gr+dCrmwdjTt2HwVEzAe/A4b2o0wvPP+eHTHi8X9MzybDQggjrklbBIyWjB3x9odJ+CUdaios3tNiTs11jvIa6okZUCygnaX8kE3wE+mZb0pZZgn08nSmB9K/AJyZWPmFVTaoXjbukYLUxFzeC5na5w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57d9db55-fa72-4bdb-de4f-08d88f8eaf4f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 09:03:46.1344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MVyTFkRuF7QsosrMe1Ew/YH15db3s4O+dxfEUPycKZQVMIWT/SBDu5U029SZNFr9Q0WZZZZwh6tiIN9G5CHzxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4585 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 09:03:53 -0000 SGVsbG8gQnJpYW4NCg0KUGxlYXNlIG5vdGUgdGhhdCBSRkMgODkyOSB3b3VsZCB3b3JrIHRoZXJl IHRvbyAtdGhhdCdzIHByb3h5IE5EIHdpdGggdGhlIGJhY2tib25lIG9uIHRoZSBXaS1GaSBsaW5r IGFuZCB0aGUgd2lyZWxlc3MgYWNjZXNzIG9uIHRoZSAzR1BQIGxpbmstLCB1c2VkIGluIHRoZSBy b3V0aW5nIHByb3h5IG1vZGUgLSB0aGF0J3Mgd2hlbiB0aGUgbGlua3MgYXJlIG5vdCBicmlkZ2Vh YmxlLS4uDQpCYXNpY2FsbHkgdGhlIHBob25lIGFzIGEgcm91dGluZyBwcm94eSBpbnN0YWxscyBo b3N0IChjb25uZWN0ZWQpIHJvdXRlcyB0b3dhcmRzIHRoZSAzR1BQIGxpbmsgZm9yIHRoZSBhZGRy ZXNzZXMgcHJlc2VudCB0aGVyZSwgYW5kIGRlZmVuZHMgdGhvc2UgYWRkcmVzc2VzIG92ZXIgdGhl IFdpLUZpIExpbmsuDQpPbiBwYXBlciB0aGUgcmVzdWx0IGlzIHNpbWlsYXIgdG8gUkZDIDcyNzgs IGJ1dCB0aGUgbWV0aG9kIGlzIGEgYml0IGRpZmZlcmVudCBzaW5jZSBpbnRlcm5hbGx5IGl0IHJl bGllcyBvbiBORCBwcm94eSBhcyBvcHBvc2VkIHRvIGFueWNhc3QuIEFyZ3VhYmx5IHRoZSBwaG9u ZSB3b3VsZCBzZWxmLWFzc2lnbiBhbm90aGVyIGdsb2JhbCBhZGRyZXNzIG9uIHRoZSBXaS1GaSBs aW5rLCBpZiBpdCBjYXJlcyB0byBoYXZlIG9uZSBhdCBhbGwgb24gdGhhdCBsaW5rLg0KQm90dG9t IGxpbmUgaXMgeWVzLCBJIGFncmVlIHdlIHNob3VsZCBjb25zaWRlciB0aGUgYXBwbGljYWJpbGl0 eSBvZiB3aGF0IHdlIGhhdmUgYmVmb3JlIHdlIHN0YXJ0IGJyZWFraW5nIHRoaW5ncyBkb3duLg0K DQpLZWVwIHNhZmU7DQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4g RSBDYXJwZW50ZXINCj4gU2VudDogamV1ZGkgMTkgbm92ZW1icmUgMjAyMCAyMzo1MA0KPiBUbzog R3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT47IG90cm9hbkBlbXBsb3llZXMub3Jn DQo+IENjOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPjsgNk1BTiA8Nm1hbkBpZXRm Lm9yZz47IEpPUkRJIFBBTEVUDQo+IE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1bGludGVs LmVzQGRtYXJjLmlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBUaGUgYm90dG9tIGlz IC8xMTINCj4gDQo+IEFuZCBpZiB3ZSBoYWQgbGVmdCB0aGUgYm91bmRhcnkgYXQgLzgwLCBhcyBp dCB3YXMgaW4gMTk5NSAoUkZDMTg4NCksIHdvdWxkIHlvdQ0KPiBub3cgYmUgYXJndWluZyBmb3Ig Lzk2LCBzaW5jZSBpbiB0aGF0IGNhc2UgM0dQUCB3b3VsZCBoYXZlIHNldHRsZWQgb24gLzgwPw0K PiANCj4gU29ycnksIGJ1dCB0aGlzIGlzIGV4YWN0bHkgYW5kIHByZWNpc2VseSBhIDE2LWJpdCBq dW1wIGluIHRoZSByYWNlIHRvIHRoZSBib3R0b20uDQo+IEFuZCBpdCBicmVha3MgYWxsIGV4aXN0 aW5nIFNMQUFDIGhvc3RzIG9uIHRoZSB3YXkuDQo+IA0KPiBUaGUgcHJvYmxlbSBoZXJlIGlzIGNh dXNlZCBieSAzR1BQLCBidXQgYSBzb2x1dGlvbiBsaWtlIENhbWVyb24ncyBzaG91bGQgd29yaw0K PiBmb3IgZXZlcnlib2R5IHdpdGggbWluaW1hbCBjaGFuZ2VzLg0KPiANCj4gUmVnYXJkcw0KPiAg ICBCcmlhbg0KPiANCj4gT24gMjAtTm92LTIwIDExOjAzLCBHeWFuIE1pc2hyYSB3cm90ZToNCj4g Pg0KPiA+DQo+ID4gT24gVGh1LCBOb3YgMTksIDIwMjAgYXQgMTA6MzMgQU0gPG90cm9hbkBlbXBs b3llZXMub3JnDQo+IDxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmc+PiB3cm90ZToNCj4gPg0K PiA+DQo+ID4NCj4gPiAgICAgPiBPbiAxOSBOb3YgMjAyMCwgYXQgMTQ6NTgsIEd5YW4gTWlzaHJh IDxoYXlhYnVzYWdzbUBnbWFpbC5jb20NCj4gPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+ PiB3cm90ZToNCj4gPiAgICAgPg0KPiA+ICAgICA+IFlvdSB3b3VsZCBuZWVkIGEgbmV3IG9wdGlv bi4gSXQgd291bGQgbGlrZWx5IGJlIHVzZWZ1bCBmb3IgdGhlIHJlcXVlc3RpbmcNCj4gcm91dGVy IHRvIGluZGljYXRlIGludGVyZXN0IGluIHRoZSBvcHRpb24uIEV2ZW4gaGludGluZyBhdCB3aGF0 IHByZWZpeCBzaXplIGl0IHdhcw0KPiBleHBlY3RpbmcuDQo+ID4gICAgID4gTm93IGNhbiB5b3Ug ZXhwbGFpbiB0byBtZSBhZ2FpbiB0aGUgcmVhc29ucyB3aHkgdGhpcyBhcHByb2FjaCBpcyBiZXR0 ZXINCj4gdGhhbiB1c2luZyB0aGUgZXhpc3RpbmcgREhQQ3Y2IHByb3RvY29sIHBhY2tldHM/DQo+ ID4gICAgID4NCj4gPiAgICAgPsKgIMKgIMKgM0dQUCBnYXRld2F5IGRvZXMgbm90IHN1cHBvcnQg REhDUHY2DQo+ID4NCj4gPiAgICAgM0dQUCBnYXRld2F5IGRvZXNuJ3Qgc3VwcG9ydCBuZXcgb3B0 aW9uLiBXaGF0J3MgeW91ciBwb2ludD8NCj4gPg0KPiA+DQo+ID4NCj4gPiDCoCDCoCBUaGUgcG9p bnQgb2YgdGhlIHY2b3BzIHByZXNlbnRhdGlvbiBhbmQgdGhpcyBlbWFpbCB0aHJlYWQgaXMgaG93 IHRvIOKAnGV4dGVuZA0KPiBhIC82NOKAnSBpbiB0aGUgM0dQUCB1c2UgY2FzZSDCoGluIHNsaWRl IDEgb2YgdGhlIGRlY2sgeW91IGNvbXBpbGVkIGEgbGlzdCBvZiBvcHRpb25zDQo+IGFuZCBvZiB0 aGUgdHdvIEkgaGFkIGhpZ2hsaWdodGVkIGluIHJlZCB3ZXJlIHRoZSA2NHNoYXJlIHYyIENhbWVy b27igJlzIG9wdGlvbg0KPiBhbmQgdGhlIHZhcmlhYmxlIHNsYWFjIG9wdGlvbi7CoCBTbyBvbiB0 aGUgY2FsbCB0aGlzIG1vcm5pbmcgTG9yZW56byBzaG90IGRvd24NCj4gNjRzaGFyZSB2MiBzaG9y dGVyIHByZWZpeCBvcHRpb24gYXMgZXZlbiBpZiB0aGUgM0dQUCBhcmNoaXRlY3R1cmUgd2FzIHVw ZGF0ZWQNCj4gdG8gc3VwcG9ydCBsb25nZXIgcHJlZml4ZXMgYW5kIGV2ZW4gaXMgdGhlIDNHUFAg Z2F0ZXdheSB3YXMgYWJsZSB0byBzZW5kIGENCj4gc2hvcnRlciBwcmVmaXggd2l0aCBBIGZsYWcg bm90IHNldCwgYWxsIG1vYmlsZSBkZXZpY2VzIHBlciBMb3Jlbnpv4oCZcyBwb2ludCB3b3VsZA0K PiBiZSBicm9rZW4gYXMgdGhleSB3b3VsZCBub3QgYWNjZXB0IHRoZSBzaG9ydGVyIGxldOKAmXMg c2F5IC81NiBwcmVmaXggdG8gYnVpbGQgdGhlDQo+IHNsYWFjIDEyOCBiaXQgYWRkcmVzcy7CoCBT byB0aGUgYm90dG9tIGxpbmUgaXMgdGhlIDY0c2hhcmUgdjIgd29u4oCZdCB3b3JrIHVubGVzcw0K PiB3ZSB1cGRhdGUgUkZDIDQyOTEgYW5kIHJlbW92ZSB0aGUgNjQgYml0IGJvdW5kYXJ5Lg0KPiA+ DQo+ID4gwqBTbyB3ZSBhcmUgYmFjayB0byBzcXVhcmUgdW5vIC0gbm8gdmlhYmxlIHNvbHV0aW9u DQo+ID4NCj4gPiDCoFNvIG5vdyB3ZSBoYWQgdGhyb3duIG91dCB0aGUgbG9uZ2VyID42NCBkdWUg dG8gcmFjZSB0byBib3R0b20gd29ycmllcw0KPiB3aGljaCBJIGFuZCBvdGhlcnMgYmVsaWV2ZSBp cyBGdWQgYW5kIGFzIGRlc2NyaWJlZCBpbiBzbGlkZSAxMCBvZiB0aGUgdjZvcHMg4oCccmFjZQ0K PiB0byB0aGUgYm90dG9tIHNsaWRl4oCdLg0KPiA+DQo+ID4gU28gYSBoYXBweSBtZWRpdW0gLzgw IGZpeGVkIGJvdW5kYXJ5IEkgY2FtZSB1cCB3aXRoIHRoYXQgSSB0aGluayBzb2x2ZXMgYSBsb3QN Cj4gb2YgdGhlIGlzc3VlIGFuZCBub3QganVzdCB0aGUgM0dQUCBpbml0aWFsIHNlZ21lbnRhdGlv biBvZiBkb3duc3RyZWFtIGRldmljZXMNCj4gcHJvYmxlbSBzdGF0ZW1lbnQuDQo+ID4NCj4gPiBT aW5jZSB3ZSBoYXZlIHRvIHVwZGF0ZSBSRkMgNDI5MSBmb3IgNjRzaGFyZSB2MiB0byB3b3JrIGFu eXdheXMgdG8gYWxsb3cNCj4gZm9yIHNob3J0ZXIgcHJlZml4ZXMsIHdoeSBub3QgaW5zdGVhZCBj cmVhdGUgYSBuZXcgYm90dG9tIGF0IC84MCBnaXZpbmcgMTYgYml0cw0KPiBtb3JlIG9mIHByZWZp eCBsZW5ndGggYW5kIHNocmlua2luZyB0aGUgSUlEIGRvd24gdG8gNDggYml0cy7CoCBEb2luZyBz byB5b3Ugd291bGQNCj4gbm90IGV2ZW4gaGF2ZSB0byB1cGRhdGUgdGhlIDNHUFAgYXJjaGl0ZWN0 dXJlIGFzIEkgZG9u4oCZdCBrbm93IGlmIHRoYXQgd291bGQgZmx5DQo+IG9yIG5vdC7CoCBBbHNv IHRoaXMgc29sdmVzIGEgZmV3IG90aGVyIHByb2JsZW1zIGF0IHRoZSBzYW1lIHRpbWUuDQo+ID4N Cj4gPg0KPiA+IEFzIEkgbWVudGlvbmVkIGluIHRoZSB2Nm9wcyBkZWNrIHByZXNlbnRlZCB0aGF0 IHZsc20gMCB0byAxMjggaXMgbWFpbnN0cmVhbQ0KPiBmb3Igb3BlcmF0b3JzIGZvciBzdGF0aWMg YWRkcmVzc2luZyBvbiByb3V0ZXIgYW5kIHN3aXRjaCBpbmZyYXN0cnVjdHVyZSBhbmQNCj4gZGhj cHY2IHN1Ym5ldHMgbG9uZ2VyIHByZWZpeGVzIGZvciBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFw cGxpYW5jZSBjbHVzdGVycywNCj4gTkZWL1ZORiB2aXJ0dWFsaXphdGlvbiBhbmQgc2VydmVyIGZh cm1zLsKgIE9uIGhvc3Qgc3VibmV0cyB3aGVyZSB0aGVyZSBpcyBhDQo+IGNoYW5jZSBvZiBtaXgg b2Ygc2xhYWMgaG9zdHMgd2l0aCBkaGNwdjYgwqBkZXZpY2VzIHRoZSBwcmVmaXggbGVuZ3RoIGlz IHN0dWNrIGF0DQo+IC82NC7CoCBTbyBvbiB0aGVzZSBtaXggYWRkcmVzc2luZyBob3N0IHN1Ym5l dHMgd2UgY2Fubm90IGRvIGxvbmdlciBwcmVmaXhlcw0KPiBmb2xsb3dpbmcgb3VyIE5EIGNhY2hl IGhhcmQgbGltaXQgbWFudHJhIHRvIHByZXZlbnQgTkQgY2FjaGUgZXhoYXVzdGlvbiBpc3N1ZXMN Cj4gYXMgZGVzY3JpYmVkIGluIFJGQyA2MTY0Lg0KPiA+DQo+ID4gU28gd2l0aCB0aGUgLzgwIG5l dyBmaXhlZCBib3VuZGFyeSBzaGlmdGluZyBwcmVmaXggbGVuZ3RoIDE2IGJpdHMgbG9uZ2VyIGFu ZA0KPiBzaG9ydGVuaW5nIHRoZSBJSUQgYnkgMTYgYml0cyBnaXZlcyByZXNvbHZlZCB0aGUgM0dQ UCBpc3N1ZSB3aGljaCA2NHNoYXJlIGNhbg0KPiB3b3JrIGFzIGlzIGFuZCBzdWJ0ZW5kaW5nIHRv IGRvd25zdHJlYW0gZGV2aWNlcyB3aWxsIG5vdyB3b3JrIGFzIGEgLzY0IGlzIG5vdw0KPiBlcXVp dmFsZW50IHRvIGEgLzQ4IHdpdGggNjRrIC84MHMuwqAgQWxzbyBCQ1AtNjkwIGZvciBicm9hZGJh bmQgbm90IGFsbA0KPiBvcGVyYXRvcnMgaGF2ZSBhZG9wdGVkIHRoZSBzaG9ydGVyIHByZWZpeCBs ZW5ndGhzIC81NiBvciAvNDgNCj4gcmVjb21tZW5kYXRpb25zIMKgYW5kIG5vdyB0aGF04oCZcyBu b3QgYW4gaXNzdWUgYXMgdGhlIC82NCB3b3VsZCBub3cgc3VmZmljZS4NCj4gPg0KPiA+IEZyb20g YW4gb3BlcmF0b3JzIHBlcnNwZWN0aXZlIHRoYXQgZ2FpbiBhbGxvd3MgYXQgbGVhc3QgZm9yIDNH UFAgbWFzc2l2ZQ0KPiBncm93dGggYW5kIHN1YnRlbmRpbmcgd2l0aCBhIHNpbmdsZSAvNjQgYWxs b3dzIHRoZSBvcGVyYXRvcnMgc3VjaCBhcyBWZXJpem9uDQo+IHdpdGggbWFzc2l2ZSBzdWJzY3Jp YmVyIGJhc2Ugd29ybGR3aWRlIGNhbiBzdGF5IHdpdGggY3VycmVudCBhbGxvY2F0aW9ucyBhbmQN Cj4gZG9u4oCZdCBoYXZlIHRvIGFzayBmb3IgLzEwLg0KPiA+DQo+ID4gQXMgNUcgZ2V0cyByb2xs ZWQgb3V0IHdpdGggRW5oYW5jZWQgVlBOIGZyYW1ld29yayBhbmQgTmV0d29yayBzbGljaW5nDQo+ IHBhcmFkaWdtLCB0aGUgZGVtYW5kIGZvciBzaG9ydGVyIGJsb2NrcyBhbmQgd2VhcmFibGUgbXVs dGlwbGUgLzQ4IHdpbGwgYmUgb3VyDQo+IG5ldyByZWFsaXR5Lg0KPiA+DQo+ID4gTWFraW5nIHRo YXQgMTYgYml0IHNoaWZ0IG5vdyB0byAvODAgbWFraW5nIGEgLzY0IHRoZSBuZXcgLzQ4IHdpbGwg Z2l2ZQ0KPiBicm9hZGJhbmQgYW5kIDNHUFAgc3Vic2NyaWJlcnMgYSB0b24gb2Ygc3BhY2UgdG8g c3VidGVuZGluZyB0aGVpciBuZXR3b3Jrcw0KPiB3ZSB3b3VsZCBiZSBzZXQgZm9yIHRoZSBmdXR1 cmUuwqAgRXNwZWNpYWxseSB3aXRoIElPVCB0aGUgZGVtYW5kIGZvciBzdWJ0ZW5kaW5nDQo+IHdp bGwgY29udGludWUgdG8gZ3JvdyBhc3Ryb25vbWljYWxseS4NCj4gPg0KPiA+IEFsc28gSUFOQSBk b2VzIG5vdCBoYXZlIHRvIGdldCBzdGFydCBpbiBhbGxvY2F0aW5nIHRoZSBvdGhlciAvMyBhbmQg b3RoZXINCj4gYXZhaWxhYmxlIGJsb2Nrcy4NCj4gPg0KPiA+IExvdHMgb2YgcHJvYmxlbXMgYmVp bmcgc29sdmVkIGhlcmUgd2l0aCBhIGZpeGVkIC84MCBuZXcgYm91bmRhcnkuDQo+ID4NCj4gPiBB bHNvIHdpdGggdGhlIGV4aXN0aW5nIHJhbmRvbSBJSUQgZ2VuZXJhdGlvbiBzY2hlbWVzIHdoaWNo IHdlIGhhdmUgdGVzdGVkDQo+IG9uIExpbnV4IGtlcm5lbCBjYW4gZG8gbG9uZ2VyIHByZWZpeGVz IHVzaW5nIFJGQyA0OTQxIHByaXZhY3kgZXh0ZW5zaW9uIG9yIFJGQw0KPiA3MjE3IHN0YWJsZSBJ SUQuDQo+ID4NCj4gPiBXaW4tV2luIGZvciBhbGwuDQo+ID4NCj4gPiAgICAgT2xlDQo+ID4NCj4g PiAtLQ0KPiA+DQo+ID4gPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KPiA+DQo+ID4gKkd5YW4g TWlzaHJhKg0KPiA+DQo+ID4gL05ldHdvcmsgU29sdXRpb25zIEEvL3JjaGl0ZWN0wqAvDQo+ID4N Cj4gPiAvTSAzMDEgNTAyLTEzNDcNCj4gPiAxMzEwMSBDb2x1bWJpYSBQaWtlDQo+ID4gL1NpbHZl ciBTcHJpbmcsIE1EDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9w c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHMNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Mon Nov 23 01:14:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8003A174D; Mon, 23 Nov 2020 01:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EsjbLjC8ejDI; Mon, 23 Nov 2020 01:14:02 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680E73A174A; Mon, 23 Nov 2020 01:14:01 -0800 (PST) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CfhH96rPwz67Gl1; Mon, 23 Nov 2020 17:11:49 +0800 (CST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Mon, 23 Nov 2020 10:13:51 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 23 Nov 2020 12:13:50 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2106.002; Mon, 23 Nov 2020 12:13:50 +0300 From: Vasilenko Eduard To: Mark Smith , Brian E Carpenter CC: 6MAN <6man@ietf.org>, IPv6 Operations Thread-Topic: Next step? [Re: [v6ops] The bottom is /112] Thread-Index: AQHWv7KLTRNS27tcwk2MzCUIfaGGdqnRyVoAgAOoVHA= Date: Mon, 23 Nov 2020 09:13:50 +0000 Message-ID: <9d13e7549f844e14b3be8661aee3e516@huawei.com> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.134] Content-Type: multipart/alternative; boundary="_000_9d13e7549f844e14b3be8661aee3e516huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 09:14:06 -0000 --_000_9d13e7549f844e14b3be8661aee3e516huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gTWFyaw0KVGV0aGVyaW5nIHdhcyBuZXZlciBpbiB0aGUgYnVzaW5lc3MgbW9kZWwgb2Yg TW9iaWxlIG1hcmtldC4gTmVpdGhlciBmb3IgY2FycmllcnMgdGhlbXNlbHZlcyBub3IgZm9yIHZl bmRvcnMuDQpJbiBnZW5lcmFsIHRoaXMgZGlzY3Vzc2lvbiBpcyDigJxob3cgdG8gZW5mb3JjZSBz b21lYm9keSB0byBhY3QgYWdhaW5zdCBoaXMgYnVzaW5lc3MgaW50ZXJlc3Rz4oCdIGxldmVyYWdp bmcgc29tZSB0ZWNobm9sb2d5IHRvb2xzLg0KRWQvDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyayBTbWl0aA0KU2VudDogMjEg0L3QvtGP 0LHRgNGPIDIwMjAg0LMuIDc6MjANClRvOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tPg0KQ2M6IDZNQU4gPDZtYW5AaWV0Zi5vcmc+OyBJUHY2IE9wZXJhdGlv bnMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IE5leHQgc3RlcD8gW1JlOiBbdjZvcHNd IFRoZSBib3R0b20gaXMgLzExMl0NCg0KDQpPbiBTYXQsIDIxIE5vdiAyMDIwLCAxNDowMCBCcmlh biBFIENhcnBlbnRlciwgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWlsdG86YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPj4gd3JvdGU6DQpKb2VsLA0KDQpJdCBzZWVtcyB0byBtZSB0 aGF0IGl0J3MgaGlnaCB0aW1lIHRvIGRyYWZ0IGEgbGlhaXNvbiBzdGF0ZW1lbnQgdG8gM0dQUCwN Cm9ic2VydmluZyB0aGF0Og0KDQooMSkgVGhlcmUgaXMgYSBzZXJpb3VzIHByb2JsZW0gZm9yIHRo ZSBkZXNpZ24gYW5kIGltcGxlbWVudGF0aW9uIG9mDQo1Ry1iYXNlZCBJUHY2ICJob3Qgc3BvdHMi IGFuZCBDRXMgW3doaWNoIGlzIHdoZXJlIHRoaXMgY29udmVyc2F0aW9uIHN0YXJ0ZWRdOw0KDQpJ IHRoaW5rIGl0IGlzIGFsc28gaW1wb3J0YW50IHRvIGZpbmQgb3V0IHdoeSB0aGV5IGhhdmVuJ3Qg ZGVwbG95ZWQgREhDUHY2IHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4NCg0KRG9uJ3QgdGhleSB0aGlu ayBESENQdjYgaW5mcmFzdHJ1Y3R1cmUgd2lsbCBzY2FsZT8gSXMgaXQganVzdCB0aGF0IHRoZXkg ZG9uJ3Qga25vdyBob3cgdG8gc2NhbGUgaXQ/DQoNCklzIGl0IGEgdmVuZG9yIC8gbW9iaWxlIG9w ZXJhdG9yIC8gaGFuZHNldCBkZXZlbG9wZXIgREhDUHY2IGNhcGFiaWxpdHkgY2hpY2tlbi1hbmQt ZWdnIHByb2JsZW0/DQoNCklzIHRoZXJlIGFuIG92ZXJyaWRpbmcgYnVzaW5lc3Mgb3IgaW5kdXN0 cnkgcmVhc29uPw0KDQpUaGUgbW9iaWxlIGluZHVzdHJ5IGhhcyBiZWVuIHJlc2lzdGFudCB0byB0 ZXRoZXJpbmcgb3ZlciB0aGUgeWVhcnMsIGFuZCBwcm9iYWJseSBvbmx5IGNhbWUgdG8gYmVncnVk Z2luZ2x5IGFjY2VwdCBpdCBiZWNhdXNlIHRoZXkgY291bGRuJ3QgcHJldmVudCBwaG9uZSB2ZW5k b3JzIGZyb20gaW1wbGVtZW50aW5nIFdpZmkgYW5kIE5BVCwgYW5kIGNvdWxkbid0IHZlcnkgZWZm ZWN0aXZlbHkgc3RvcCB0aGVpciBjdXN0b21lcnMgZnJvbSB1c2luZyB0aGF0IGNhcGFiaWxpdHkg KE9uZSB0cmljayBJJ3ZlIGhlYXJkIG9mIHRvIHByZXZlbnQgdGV0aGVyaW5nIHdvcmtpbmcgd2Fz IHRvIGNoZWNrIGlmIGFuIElQdjQgcGFja2V0J3MgVFRMIHZhbHVlIHdhcyA2NCB3aGVuIGl0IGFy cml2ZWQgYXQgdGhlIG5ldHdvcmssIG1lYW5pbmcgaXQgb3JpZ2luYXRlZCBmcm9tIHRoZSBkaXJl Y3RseSBhdHRhY2hlZCBoYW5kc2V0LiBQYWNrZXRzIGZyb20gdGV0aGVyZWQgZGV2aWNlcyBoYWQg YSBUVEwgb2YgNjMgc28gd2VyZSBkcm9wcGVkLiBPZiBjb3Vyc2UsIHlvdSBjb3VsZCBzZXQgdGhl IGRlZmF1bHQgVFRMIG9uIGEgdGV0aGVyZWQgUEMgdG8gNjUgdG8gZ2V0IGFyb3VuZCB0aGF0LikN Cg0KSSBndWVzcyB0aGVyZSBtaWdodCBiZSBhIGZhaXJseSBzdHJvbmcgbWluZHNldCB0aGF0IHRo ZXJlIG11c3QgYmUgYSBmZWUgcGVyIGRldmljZSBhdHRhY2hlZCB0byB0aGUgbmV0d29yayBpbiBh ZGRpdGlvbiB0byBhIGZlZSBmb3IgbmV0d29yayB1dGlsaXNhdGlvbi4gUHJvdmlkaW5nIG11bHRp cGxlIC82NHMgd291bGQgYmUgZm9ybWFsbHkgYWNrbm93bGVkZ2luZyB0aGF0IG11bHRpcGxlIGRl dmljZXMgY2FuIGJlIGF0dGFjaGVkIGFuZCBhIGZlZSBwZXIgZGV2aWNlIGlzbid0IGFuZCBjYW4n dCBldmVyIGJlIGNoYXJnZWQsIGNvdW50ZXIgdG8gdGhlIG1pbmRzZXQuDQoNClJlZ2FyZHMsDQpN YXJrLg0KDQoNCigyKSBBbHRob3VnaCB0aGUgYmVzdCBzb2x1dGlvbiBpcyBub3QgeWV0IG9idmlv dXMsIGRlZmluaW5nIGFuZA0Kc3RhbmRhcmRpemluZyBpdCB3aWxsIHJlcXVpcmUgYSBqb2ludCBl ZmZvcnQgYnkgdGhlIElFVEYgYW5kIDNHUFAuDQoNCkZvbGxvd2VkIGJ5IGEgcHJvcG9zYWwgdG8g Zm9ybSBhbiBhZCBob2Mgam9pbnQgZGVzaWduIHRlYW0uDQoNClJlZ2FyZHMNCiAgIEJyaWFuIENh cnBlbnRlcg0KT24gMjEtTm92LTIwIDE0OjQ2LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+IFRo ZSBuZXN0aW5nIGdvdCBtZSBsb3N0LCBzbyBJIHdpbGwgdG9wIHBvc3QgbXkgdGFrZSBvbiB0aGUg YW5zd2VyIHRvIHRoZQ0KPiBvbmUgcXVlc2l0b24gSSBjb3VsZCB1bmRlcnN0YW5kLg0KPg0KPiBJ IGJlbGlldmUgeW91IGFza2VkIHdoYXQgSSB0aGluayB3b3VsZCBuZWVkIHRvIGJlIGNoYW5nZWQg dG8gcGVybWl0IHRoZQ0KPiBkZWxlZ2F0aW9uLg0KPiBBcyB3aXRoIGFueXRoaW5nLCB0aGUgcmVh bCB0aGluZ3MgdGhhdCBuZWVkIHRvIGNoYW5nZSBhcmUgdGhlIGRldmljZXMgaW4NCj4gdGhlIG5l dHdvcmsuDQo+DQo+IFdpdGggcmVnYXJkIHRvIElFVEYgc3RhbmRhcmRzLCB3aGF0IGlzIHByb3Bv c2VkIGlzIGEgY2hhbmdlIHRvIFJBLg0KPiBUaGVyZSBhcmUgc2V2ZXJhbCBwb3NzaWJsZSBjaGFu Z2VzLiAgTm9uZSBvZiB0aGVtIHJlcXVpcmUgYSBjaGFuZ2UgdG8NCj4gdGhlIElQdjYgYWRkcmVz c2luZyBhcmNodGllY3R1cmUsIGFzIHRoZSBhZGRyZXNzaW5nIHN0cnVjdHVyZSByZW1haW5zIGFz DQo+IGl0IGlzLg0KPiBBcyBmb3IgdGhlIGV4YWN0IG1lY2hhbmlzbSwgYXQgdGhlIG1vbWVudCBJ IGxlYW4gdG93YXJkcyBPbGUncyBwcm9wb3NhbA0KPiBvZiB1c2luZyBhIG5ldyBvcHRpb24gaW4g aGlzIGdlbmVyaWMgb3B0aW9uIG1lY2hhbmlzbS4gIEJ1dCBJIGFtIG5vdA0KPiB3ZWRkZWQgdG8g dGhhdCBhbnN3ZXIuDQo+DQo+IEFuZCBvZiBjb3Vyc2UsIHRvIGdldCB0aGlzIHN1cHBvcnRlZCBp biBtb2JpbGUgZW52aXJvbm1lbnRzIHdlIHdpbGwgaGF2ZQ0KPiB0byB3b3JrIHdpdGggM0dQUCBh bmQgbWFrZSBzdXJlIHRoZXJlIGFyZSBubyBvdGhlciBoaWRkZW4gaXNzdWVzLg0KPiBUaGF0J3Mg dGhlIHdheSB3ZSBkbyB0aGluZ3MuICBXb3JrIHRvZ2V0aGVyLg0KPg0KPiBDaGFuZ2luZyB0aGUg cHJlZml4IGxlbmd0aCB0byAvODAgaXMgdGVjaG5pY2FsbHkgYWxzbyBwb3NzaWJsZS4gIEl0IGRv ZXMNCj4gYSBsb3QgbW9yZSB2aW9sZW5jZSB0byBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBhcmNo aXRlY3R1cmUgYW5kIHNvZnR3YXJlDQo+IHN0cnVjdHVyZXMgdGhhdCBnbyB3aXRoIGl0LCBhbmQg aXMgYSB2ZXJ5IGxpbWl0ZWQgYW5kIG5hcnJvdyBzb2x1dGlvbiB0bw0KPiB0aGUgcHJvYmxlbS4N Cj4NCj4gWW91cnMsDQo+IEpvZWwNCj4NCj4gT24gMTEvMjAvMjAyMCA3OjU4IFBNLCBHeWFuIE1p c2hyYSB3cm90ZToNCj4+IEhpIEpvZWwNCj4+DQo+PiBJbi1saW5lDQo+Pg0KPj4gT24gRnJpLCBO b3YgMjAsIDIwMjAgYXQgNjowMiBQTSBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5j b208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+DQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pj4gd3JvdGU6DQo+Pg0KPj4gICAgIEd5 YW4sIHNlcGFyYXRlIGZyb20gT2xlJ3MgY29tbWVudHMgYWJvdXQgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBhZGRyZXNzDQo+PiAgICAgYXNzaWdubWVudCBhbmQgZGVsZWdhdGlvbiwgSSBoYXZlIGFu b3RoZXIgcHJvYmxlbSBmb2xsb3dpbmcgdGhlDQo+PiAgICAgcmVhc29uaW5nIGJlbG93Lg0KPj4N Cj4+ICAgICBZZXMsIHRoZSBwcm9wb3NhbCBmb3IgdXNpbmcgc2hvcnRlciBwcmVmaXhlcyB0byBl bmFibGUgVUUgdG8gcGVyZm9ybQ0KPj4gICAgIGRlbGVnYXRpb24gd2lsbCByZXF1aXJlIGNoYW5n ZXMgdG8gdGhlIFVFLg0KPj4NCj4+ICAgICAgR3lhbj4gQWdyZWVkLiAgU28gdGhhdCBjaGFuZ2Ug d291bGQgYmUgdG8gUkZDIDQyOTEgNjQgYml0IGJvdW5kYXJ5DQo+PiB0byBhbGxvdyBmb3IgbG9u Z2VyIHByZWZpeC4gIERvIHlvdSBhZ3JlZT8NCj4+DQo+PiBJZiB5b3UgZG9u4oCZdCBhZ3JlZSB3 aGF0IGRvIHRoaW5rIHRoZSBjaGFuZ2Ugd291bGQgYmUgdG8gYWxsb3cgdGhlIFVFIHRvDQo+PiBh Y2NlcHQgc2hvcnRlciBwcmVmaXggZnJvbSB0aGUgM0dQUCBnYXRld2F5Pw0KPj4NCj4+DQo+PiAg ICAgQnV0IEkgZG8gbm90IHNlZSBob3cgdGhhdCBpcyByZWxldmFudCB0byBhbnkgY2hvaWNlIHdl IGFyZSB0cnlpbmcgdG8NCj4+ICAgICBtYWtlLg0KPj4gICAgIEFueSBzb2x1dGlvbiB0aGF0IGVu YWJsZXMgVUUgdG8gZGVsZWdhdGUgYWRkcmVzc2VzIChpbiB0aGUgc2Vuc2UgdGhhdA0KPj4gICAg IHRoZXkgbGFjayB0aGUgY2FwYWJpbGl0eSBub3cpIHdpbGxyIGVxdWlyZSBjaGFuZ2VzIHRvIHRo ZSBVRS4NCj4+DQo+Pg0KPj4NCj4+ICAgICBHeWFuPiBJZiB0aGUgVUUgcmVjZWl2ZXMgYSAvNTYg dmlhIFJBIGl0IGNvdWxkIGRlbGVnYXRlIC82NCB0bw0KPj4gICAgIGRvd25zdHJlYW0gZGV2aWNl cy4gIE5vIGNoYW5nZSBuZWVkZWQgdG8gZGVsZWdhdGUgIC82NCwgaG93ZXZlciBhDQo+PiAgICAg Y2hhbmdlIGlzIG5lZWRlZCB0byBhY2NlcHQgLzU2IHZpYSBSQS4NCj4+DQo+Pg0KPj4gICAgICBJ ZiAzR1BQIGdhdGV3YXkgc3VwcG9ydGVkIFBEIC0gcHJvYmxlbSBzb2x2ZWQgYnV0IHRoYXTigJlz IG5vdCB0aGUNCj4+IGNhc2UgYW5kIHRoYXQgZG9lcyBub3Qgc291bmQgbGlrZSBpdCB3aWxsIGV2 ZXIgY2hhbmdlIGV2ZW4gd2l0aCA1Ry4NCj4+DQo+PiAgICAgR3lhbj4gVGhlIFVFIG5lZWRzIHRv IGJlIGFibGUgdG8gYWNjZXB0IHNob3J0ZXIgcHJlZml4LiAgVGhhdOKAmXMgdGhlDQo+PiBJUFY2 IHNwZWNpZmljYXRpb24gY2hhbmdlIHRoYXQgcmVxdWlyZXMgcmVtb3ZhbCBvZiB0aGUgNjQgYml0 IGJvdW5kYXJ5Lg0KPj4NCj4+ICAgICBZb3J1DQo+PiAgICAgcHJvcG9zZWQgY2hhbmdlIHRvIHRo ZSBTTEFBQyBsZW5ndGggaWYgYW55dGhpbmcgZG9lcyBtb3JlIHZpb2xlbmNlIHRvDQo+PiAgICAg dGhlIHNvZnR3YXJlIChkZXBlbmRpbmcgdXBvbiB0aGUgZXhhY3Qgc29mdHdhcmUgYXJjaGl0ZWN0 dXJlLikNCj4+DQo+Pg0KPj4gICAgIEd5YW4+IFdoYXQgdmlvbGVuY2UgdG8gc29mdHdhcmUuICBU aGVyZSB3b3VsZCBiZSBtb3JlIHZpb2xlbmNlIHRvDQo+PiBzb2Z0d2FyZSBpZiB3ZSByZW1vdmVk IHRoZSA2NCBiaXQgYm91bmRhcnkgYW5kIGFsbG93ZWQgc2xhYWMgdG8gc3VwcG9ydA0KPj4gYW55 IHZsc20gcHJlZml4IGxlbmd0aHMuDQo+Pg0KPj4gTXkgLzgwIHByb3Bvc2FsIHdvdWxkIGp1c3Qg c2hpZnQgdGhlIGJvdW5kYXJ5IDE2IGJpdHMgdG8gLzgwLg0KPj4NCj4+IEhvc3RzIG9uIHRoZSBz YW1lIHN1Ym5ldCB3aXRoIHR3byBkaWZmZXJlbnQgbWFza3Mgd291bGQgbm90IGJlIG9uLW5ldCB0 bw0KPj4gZWFjaCBvdGhlciBhcyBvbiBkaWZmZXJlbnQgc3VibmV0cy4gIFRoZSByb3V0ZXIgd291 bGQgYmUgY29uZmlndXJlZCB3aXRoDQo+PiB0aGUgdHdvIHN1Ym5ldHMgLzY0IGFuZCAvODAgc3Vi bmV0IHRvIHN1cHBvcnQgdGhlIHR3byBkZXZpY2UgdHlwZXMuDQo+PiBUaGUgc29sdXRpb24gd291 bGQgYmUgYSBzaW1wbGUgUkEgUElPIGZsYWcgdGhhdCBpcyBzZXQgYW5kIG9sZGVyIGhvc3RzDQo+ PiBub3QgdXBncmFkZWQgd291bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgYW5kIHNvIHdvdWxk IG9ubHkgc3VwcG9ydCA2NA0KPj4gYml0IGJvdW5kYXJ5IGJ5IGlnbm9yaW5nIGZsYWcuIEhvc3Rz IHVwZ3JhZGVkIHRvIHN1cHBvcnQgd291bGQNCj4+IHVuZGVyc3RhbmQgdGhlIGZsYWcgYW5kIGJl IGFibGUgdG8gc3VwcG9ydCBsb25nZXIgbWFzayB1cCB0byAvODAuDQo+Pg0KPj4NCj4+DQo+PiAg ICAgU28gSSBkbyBub3QgZm9sbG93IGhvdyB5b3UgZ290IHRvIHlvdXIgY29uY2x1c2lvbi4NCj4+ DQo+PiAgICAgWW91cnMsDQo+PiAgICAgSm9lbA0KPj4NCj4+ICAgICBPbiAxMS8yMC8yMDIwIDU6 MjcgUE0sIEd5YW4gTWlzaHJhIHdyb3RlOg0KPj4gICAgICA+DQo+PiAgICAgID4gKHRvcCBwb3N0 aW5nKQ0KPj4gICAgICA+DQo+PiAgICAgID4gQXMgSSB3b3VsZCBsaWtlIHRvIGNsZWFyIHRoZSBh aXIgYXMgd2VsbCBhcyBnZXQgdG8gdGhlIGNydXggb2YNCj4+ICAgICB0aGUgdjZvcHMNCj4+ICAg ICAgPiBwcmVzZW50YXRpb24gZGV2ZWxvcG1lbnQgcmVzdWx0cyBhcyB3ZWxsIGFzIG5leHQgc3Rl cHMgZm9yIHRoaXMNCj4+ICAgICBkcmFmdA0KPj4gICAgICA+IGFuZCB0aGUgNm1hbiB2YXJpYWJs ZSBzbGFhYyBzb2x1dGlvbnMgZHJhZnQ6DQo+PiAgICAgID4NCj4+ICAgICAgPg0KPj4gICAgICA+ IFRoaXMgdGhyZWFkIHdhcyBpbiBsaWdodCBvZiBMb3JlbnpvIGtpbmRseSBwb2ludGluZyBvdXQg dGhhdA0KPj4gICAgIHVwZ3JhZGluZw0KPj4gICAgICA+IDNHUFAgaXMgbm90IGFsbCB0aGF0IG5l ZWRzIGJlIGRvbmUgZm9yIENhbWVyb27igJlzIDY0c2hhcmUgdjIgdG8NCj4+ICAgICB3b3JrIC0g YXMNCj4+ICAgICAgPiBhbGwgbW9iaWxlIGRldmljZXMgd291bGQgc3RvcCB3b3JraW5nLSBhcyBz bGFhYyB3b3VsZCBub3Qgd291bGQgYmUNCj4+ICAgICAgPiBlZmZlY3RpdmVseSBicm9rZW4uDQo+ PiAgICAgID4NCj4+ICAgICAgPiBUaGUgbW9iaWxlIGRldmljZSB3b3VsZCByZWNlaXZlIGEgc2hv cnRlciBwcmVmaXggbGV04oCZcyBzYXkgLzU2DQo+PiAgICAgYnV0IG5vdA0KPj4gICAgICA+IGtu b3cgd2hhdCB0byBkbyB3aXRoIGl0IHNpbmNlIGl04oCZcyBleHBlY3RpbmcgYSAvNjQuDQo+PiAg ICAgID4NCj4+ICAgICAgPiBTbyB0aGF0IGEgbWFqb3IgZ2FwIGFuZCB0aGUgb25seSBzb2x1dGlv biBpcyB1cGRhdGluZyBSRkMgNDI5MQ0KPj4gICAgIHJlbW92aW5nDQo+PiAgICAgID4gdGhlIDY0 IGJpdCBib3VuZGFyeSBhbGxvd2luZyBmb3Igc2hvcnRlciBwcmVmaXggYW5kIG5vdyBhcyB3ZWxs DQo+PiAgICAgbG9uZ2VyDQo+PiAgICAgID4gcHJlZml4ZXMgdG8gd29yayBhbmQgaW4gdGhhdCBy ZXNwZWN0IG5vdyBwcm92aWRlIHRoZSBtdWNoIG5lZWRlZA0KPj4gICAgIHBhcml0eQ0KPj4gICAg ICA+IHdpdGggc3RhdGljIGFuZCBESENQdjYgd2hpY2ggY2FuIGRvIGFueSBwcmVmaXggbGVuZ3Ro Lg0KPj4gICAgICA+DQo+PiAgICAgID4gU28gdGhhdCBpcyBhIGRyYXN0aWMgY2hhbmdlIHRvIFJG QyA0MjkxLiAgSG93ZXZlciwgaW4gbGlnaHQgb2YgdGhpcw0KPj4gICAgICA+IGRldmVsb3BtZW50 IG9uIHRoZSB2Nm9wcyAxMDkgY2FsbCwgbXkgYmFsYW5jaW5nIGFjdCBvZiBiZXN0IG9mIGJvdGgN Cj4+ICAgICAgPiB3b3JsZHMgYW5kIGFsc28gdG8ga2VlcCBldmVyeW9uZSBoYXBweSB0byBtYWtl IHRoaXMgYSBXRyBlZmZvcnQNCj4+ICAgICBmb3IgdGhpcw0KPj4gICAgICA+IGNoYW5nZSBieSBw cm9wb3NpbmcgaW4gdGhlIHN1YmplY3QgaGVhZGluZyAvODAgZml4ZWQgYm91bmRhcnkgYW5kDQo+ PiAgICAgbm90IGENCj4+ICAgICAgPiB2YXJpYWJsZSBzbGFhYyBjaGFuZ2UgYWxsb3dpbmcgYWxs IGJpdHMgdmxzbS4NCj4+ICAgICAgPg0KPj4gICAgICA+IEJhc2ljYWxseSBzdGVhbGluZyAxNiBi aXRzIGZvciBuZXR3b3JrIHByZWZpeCBvdXQgb2YgdGhlIElJRCwgc3RpbGwNCj4+ICAgICAgPiBr ZWVwaW5nIHRoZSBmaXhlZCBib3VuZGFyeSBzbyBsb25nZXIgdGhhbiA4MCB3b3VsZCBOT1QgIGJl IGFsbG93ZWQuDQo+PiAgICAgID4NCj4+ICAgICAgPiBBIC82NCB3b3VsZCBub3cgYmUgZXF1aXZh bGVudCB0byBhIC80OCB3aXRoIG5vdyA2NGsgLzgw4oCZcy4NCj4+ICAgICAgPg0KPj4gICAgICA+ IFRoaXMgLzgwIHdvdWxkIGtlZXAgdGhlIG9wZXJhdG9ycyBhbmQgbGF3IGVuZm9yY2VtZW50IGhh cHB5IGFzDQo+PiAgICAgbm93IDE2DQo+PiAgICAgID4gYml0cyBsZXNzIGhlbHBzIHRyYWNlYWJp bGl0eSBidXQgaXMgc3RpbGwgbG9uZyBlbm91Z2ggZm9yIDQ4IGJpdHMgb2YNCj4+ICAgICAgPiBw cml2YWN5IHRvIElQIGNvcnJlbGF0aW9uIGJ5IGF0dGFja2Vycy4NCj4+ICAgICAgPg0KPj4gICAg ICA+IFRoaXMgLzgwIHdvdWxkIGJlIGEgbmljZSBvcHRpbWFsIGJhbGFuY2UgYXMgaXQgd291bGQg a2VlcCB3aXJlZA0KPj4gICAgICA+IGJyb2FkYmFuZCBhbmQgbW9iaWxlIGhhbmRzZXQgY3VzdG9t ZXJzIGhhcHB5IHJlc3BlY3RpbmcgdGhlaXINCj4+ICAgICBwcml2YWN5IGFzDQo+PiAgICAgID4g dGhlIDE2IGJpdHMgbGVzcyBvZiBoZXVyaXN0aWNzIGlzIG1pbmltYWwgY2hhbmdlIHRoYXQgd2ls bCBpbXBhY3QgSVANCj4+ICAgICAgPiBjb3JyZWxhdGlvbiBieSBhdHRhY2tlcnMuDQo+PiAgICAg ID4NCj4+ICAgICAgPiBUaGUgSUlEIGFzIGl04oCZcyBsZXNzIHRoYW4gdGhlIGN1cnJlbnQgNjQg Yml0IGNhbm5vdCB1c2UgTUFDIGJhc2VkDQo+PiAgICAgRVVJNjQNCj4+ICAgICAgPiBJSUQsIHdo aWNoIGlzIG5vdCBhIHByb2JsZW0gYXMgTWFjIGJhc2VkIElJRCBpcyBub3QgcmVjb21tZW5kZWQN Cj4+ICAgICBhcyBtb3N0DQo+PiAgICAgID4gYWxsIG1hbnVmYWN0dXJlcnMgdXNlIFJGQyA0OTQx IGFuZCBJIGJlbGlldmUgTGludXggZmxhdm9ycyBzb21lIHVzZQ0KPj4gICAgICA+IHN0YWJsZSBJ SUQgUkZDIDcyMTcuDQo+PiAgICAgID4NCj4+ICAgICAgPiBTbyBub3cgdGhlIDQ4IGJpdCBJSUQg d291bGQgcmVxdWlyZSBhIHJhbmRvbSBJSUQgZ2VuZXJhdGlvbg0KPj4gICAgIHNjaGVtYSBzbw0K Pj4gICAgICA+IGNhbiB1c2UgZWl0aGVyIFJGQyA0OTQxIHByaXZhY3kgZXh0ZW5zaW9uIG9yIFJG QyA3MjE3IHN0YWJsZSBJSUQgdG8NCj4+ICAgICAgPiBnZW5lcmF0ZSB0aGUgNDggYml0IElJRC4N Cj4+ICAgICAgPg0KPj4gICAgICA+IDNHUFAgc3VidGVuZGluZyB3b3VsZCBub3cgd29yayBpc3N1 ZSBtZW50aW9uZWQgaW4gdGhlIHByb2JsZW0NCj4+ICAgICBzdGF0ZW1lbnQNCj4+ICAgICAgPiBk cmFmdCB3aXRob3V0IGV2ZW4gaGF2aW5nIHRvIHVzZSA2NHNoYXJlIGFzIG5vdyBsb25nZXIgcHJl Zml4ZXMNCj4+ICAgICB1cCB0bw0KPj4gICAgICA+IC84MCB3b3VsZCBiZSBzdXBwb3J0ZWQgYWxs b3dpbmcgZm9yIGZ1cnRoZXIgc2VnbWVudGF0aW9uIG9mDQo+PiAgICAgZG93bnN0cmVhbQ0KPj4g ICAgICA+IGRldmljZXMuDQo+PiAgICAgID4NCj4+ICAgICAgPiBUaGlzIGFsc28gd291bGQgaGVs cCB3aXJlZCBicm9hZGJhbmQgYW5kIHNvb24gZml4ZWQgNUcgYnJvYWRiYW5kDQo+PiAgICAgID4g cHJvbGlmZXJhdGlvbiB3aGVyZSBvcGVyYXRvcnMgaW4gbGlnaHQgb2YgQkNQIFJJUEUtNjkwLCBh cmUgc2lsbA0KPj4gICAgICA+IGFsbG9jYXRpb24gdmlhIEJORyBnYXRld2F5cyBhIC82NCwgbm93 IG9wZXJhdG9ycyAgY2FuIHN0YXkgYXMtaXMsDQo+PiAgICAgYXMgdGhlDQo+PiAgICAgID4gLzY0 IHdvdWxkIG5vdyBiZSBhbGxvd2VkIHRvIGJlIGZ1cnRoZXIgc2VnbWVudGVkIHN1cHBvcnRpbmcg NjRrDQo+PiAgICAgLzgwcywNCj4+ICAgICAgPiB3YXkgbW9yZSB0aGVuIGVub3VnaCBmb3IgU09I Ty4NCj4+ICAgICAgPg0KPj4gICAgICA+IFRoaXMgd291bGQgYWxsb3cgNjRzaGFyZSBpZiB1c2Vk IGJ5IDNHUFAgb3BlcmF0b3JzIHRvIHdvcmsgYW5kDQo+PiAgICAgd291bGQgbm90DQo+PiAgICAg ID4gcmVxdWlyZSB0aGUgM0dQUCBzcGVjaWZpY2F0aW9uIHRvIGJlIHVwZGF0ZWQuICBXZSBkb27i gJl0IGtub3cgZXZlbg0KPj4gICAgIGlmIHRoZQ0KPj4gICAgICA+IDNHUFAgYXJjaGl0ZWN0dXJl IHNwZWNpZmljYXRpb24gY2FuIGJlIHVwZGF0ZWQgdG8gc3VwcG9ydCBzaG9ydGVyDQo+PiAgICAg ID4gcHJlZml4ZXMgYW5kIGlmIHRoZSAzR1BQIGNvbnNvcnRpdW0gb2Ygb3BlcmF0b3JzIHdvdWxk IGFncmVlIHRvDQo+PiAgICAgaXQuICBTbw0KPj4gICAgICA+IHRoYXQgaXMgYWxsIHRoZW9yZXRp Y2FsIG9mIHRoYXQgY2hhbmdlIGlzIHBvc3NpYmxlLg0KPj4gICAgICA+DQo+PiAgICAgID4gQXMg d2l0aCA1RyB3aXRoIEVuaGFuY2VkIFZQTiBmcmFtZXdvcmsgU1Igc3RlZXJpbmcgb2YgaGlnaCBw cmlvcml0eQ0KPj4gICAgICA+IHRyYWZmaWMsIHRyYWZmaWMgaXNvbGF0aW9uIGFuZCBOZXR3b3Jr IHNsaWNpbmcgY2FwYWJpbGl0aWVzIGJlY29tZXMNCj4+ICAgICAgPiBtYWluc3RyZWFtIGFuZCB3 aWxsIHNvb24gYmUgYSByZWFsIHdvcmxkIHJlYWxpdHkgYW5kIGFzIGZpeGVkIDVHDQo+PiAgICAg ID4gYnJvYWRiYW5kIHByb2xpZmVyYXRpb24gdGFrZXMgb2ZmIGFuZCBtb2JpbGUgNUcgPT0gdGhl IGlkZWEgb2YgYQ0KPj4gICAgICA+IHdlYXJhYmxlIC80OCB3aWxsIHJlYWxseSBiZSBtYW55IC80 OHMuDQo+PiAgICAgID4NCj4+ICAgICAgPiBBcyB0aGlzIHBhcmFkaWdtIHNoaWZ0IHRha2VzIHBs YWNlLCBvcGVyYXRvcnMgYXJvdW5kIHRoZSB3b3JsZA0KPj4gICAgIHdpbGwgYmUNCj4+ICAgICAg PiBjbGFtb3JpbmcgYWZ0ZXIgdGhlIFJJUiBmb3IgbWFzc2l2ZSBibG9ja3MsIEkgd291bGQgc2F5 IGxlc3MgdGhhbiAvOA0KPj4gICAgICA+IG1vcmUgbGlrZSBhIC81IG9yIC80LiAgSWYgeW91IGRv IHRoZSBtYXRoIG9uIHRoZSB3YXkgaGlnaCBzaWRlIGEgLzEwDQo+PiAgICAgID4geWllbGRzIDcg Yml0cyBzbyAxMjggZGl2aWRlZCBieSA1IFJJUnMgeWllbGRzIDI0IElTUHMgcGVyIFJJUg0KPj4g ICAgIHdoaWNoIGlzDQo+PiAgICAgID4gdGlueSBudW1iZXIgd2l0aCB0aGUgbnVtYmVyIG9mIGxh cmdlIHNpemUgb3BlcmF0b3JzIHdvcmxkd2lkZS4NCj4+ICAgICAgPg0KPj4gICAgICA+IFdpdGgg dGhlIG1hc3NpdmUgcHJvbGlmZXJhdGlvbiBvZiBJT1QgZGV2aWNlcyBhbmQganVzdCBhYm91dA0K Pj4gICAgIGV2ZXJ5IGhvbWUNCj4+ICAgICAgPiBvciBvZmZpY2UgYXBwbGlhbmNlIG9uIDVHLCB0 aGUgcHJvYmxlbSBub3cgZ2V0cyB3YXkgZXhhY2VyYmF0ZWQuDQo+PiAgICAgID4NCj4+ICAgICAg PiBBcyB0aGlzIGV2b2x1dGlvbiB1bmZvbGRzIElBTkEgd2lsbCBiZSBzY3JhbWJsaW5nIHRvIHJl bGVhc2UgYWxsDQo+PiAgICAgID4gcmVtYWluaW5nIC8zIGFzIHdlbGwgYXMgYWxsIHVuYWxsb2Nh dGVkIGJsb2NrcyB0byBzdWJ2ZXJ0IFJJUiBJUHY2DQo+PiAgICAgID4gYWRkcmVzcyBzcGFjZSBk ZXBsZXRpb24uDQo+PiAgICAgID4NCj4+ICAgICAgPiBQbGF5aW5nIE1vbmRheSBuaWdodCBxdWFy dGVyYmFja2luZyBpbiBoaW5kc2lnaHQgd2Ugd291bGQgbmV2ZXINCj4+ICAgICB0aGluaw0KPj4g ICAgICA+IHRoaXMgd291bGQgaGFwcGVuIGluIGEgbWlsbGlvbiB5ZWFycywgYnV0IHdlIHdvdWxk IHNlZSBJUHY2IG9uDQo+PiAgICAgdGhlIHZlcmdlDQo+PiAgICAgID4gb2YgYWRkcmVzcyBzcGFj ZSBkZXBsZXRpb24uICBVbmhlYXJkIG9mIGJ1dCBpdCBjYW4gaGFwcGVuIGFzIHRoZQ0KPj4gICAg IHNheWluZw0KPj4gICAgICA+IGdvZXMg4oCcd2hlbiB5b3UgYnVpbGQgLSB0aGV5IHdpbGwgY29t ZeKAnS4NCj4+ICAgICAgPg0KPj4gICAgICA+IEl0IGlzIHRydWUgYXMgaGlzdG9yeSBoYXMgdGF1 Z2h0IHRoYXQgdmVyeSBpbXBvcnRhbnQgbGVzc29uLg0KPj4gICAgICA+DQo+PiAgICAgID4gVGhl IGFuc3dlciB0byB0aGlzIHJlYWwgd29ybGQgcHJvYmxlbSBpcyBpbiB0aGUgc3ViamVjdCBoZWFk aW5nDQo+PiAgICAgb2YgdGhpcw0KPj4gICAgICA+IHRocmVhZC4NCj4+ICAgICAgPg0KPj4gICAg ICA+IFRoaXMgd291bGQgYWxzbyBmaXggdGhlIGRheSAxIGlzc3VlIEkgbWVudGlvbmVkIGFsbG93 aW5nIG1peCBvZg0KPj4gICAgIHNsYWFjDQo+PiAgICAgID4gZGV2aWNlcyB3aXRoIHN0YXRpYyBh bmQgREhDUHY2IHVwIHRvIC84MC4NCj4+ICAgICAgPg0KPj4gICAgICA+IFRoZSB2YXJpYWJsZSBz bGFhYyBzb2x1dGlvbiBkcmFmdCBwcm9wb3NlcyBhIG5ldyAgUkEgUElPIGZsYWcNCj4+ICAgICB0 aGF0IHdvdWxkDQo+PiAgICAgID4gYmUgdXNlZCB0byBzaWduYWwgbG9uZ2VyIHByZWZpeGVzLCBh bmQgd291bGQgcHJvdmlkZSBiYWNrd2FyZHMNCj4+ICAgICAgPiBjb21wYXRpYmlsaXR5IHNvIHRo YXQgZGV2aWNlcyBub3Qgc3VwcG9ydGluZyB3b3VkIGlnbm9yZSB0aGUgZmxhZw0KPj4gICAgICAg YW5kDQo+PiAgICAgID4gZGV2aWNlcyBvbiBuZXdlciBjb2RlIHN1cHBvcnRpbmcgd291bGQgdXNl IHRoZSBmbGFnLiAgV2UgZGVmaW5pdGVseQ0KPj4gICAgICA+IGRvbuKAmXQgd2FudCB0byBpbXBh Y3QgYW55IGV4aXN0aW5nIGRldmljZXMgb24gdGhlIGV4aXN0aW5nIDY0IGJpdA0KPj4gICAgIHNs YWFjDQo+PiAgICAgID4gYm91bmRhcnkgc3RhbmRhcmQuDQo+PiAgICAgID4NCj4+ICAgICAgPiBE bXl0cm8gaGFzIHRlc3RlZCB0aGUgc29sdXRpb24gb24gTGludXgga2VybmVsIHNpZ25hbGluZyBS QSBQSU8NCj4+ICAgICBmbGFnIGFuZA0KPj4gICAgICA+IHdhcyBhYmxlIHRvIHN1Y2Nlc3NmdWxs eSB0ZXN0IGFueSBsZW5ndGggbWFzayBhbmQgcmFuZG9tIElJRA0KPj4gICAgIGdlbmVyYXRpb24N Cj4+ICAgICAgPiBib3RoIFJGQyA0OTQxIHByaXZhY3kgZXh0ZW5zaW9uIGFzIHdlbGwgYXMgc3Rh YmxlIElJRCBSRkMgNzIxNy4NCj4+ICAgICAgPg0KPj4gICAgICA+DQo+PiAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlzaHJhLTZtYW4tdmFyaWFibGUtc2xhYWMv DQo+PiAgICAgPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1pc2hyYS02 bWFuLXZhcmlhYmxlLXNsYWFjLz4NCj4+ICAgICAgPg0KPj4gICAgIDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXNocmEtNm1hbi12YXJpYWJsZS1zbGFhYy8NCj4+ICAg ICA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlzaHJhLTZtYW4tdmFy aWFibGUtc2xhYWMvPj4NCj4+ICAgICAgPg0KPj4gICAgICA+IElmIGV2ZXJ5b25lIGlzIGluIGFn cmVlbWVudCB3aXRoIHdoYXQgSSBoYXZlIHN0YXRlZCBvbiB0aGlzDQo+PiAgICAgdGhyZWFkLCBJ DQo+PiAgICAgID4gd291bGQgbGlrZSB0byBhc2sgdGhlIGNoYWlycyBmb3IgV0cgYWRvcHRpb24g YXMgdGhpcyBpcyBhIFdHIGVmZm9ydC4NCj4+ICAgICAgPg0KPj4gICAgICA+IEkgd291bGQgbGlr ZSB0byBnYXJuZXIgc3VwcG9ydCBmcm9tIGFsbCA2TUFOIG1lbWJlcnMgd2l0aCBmdWxsDQo+PiAg ICAgY29uc2Vuc3VzDQo+PiAgICAgID4gdG8gY2hhbmdlIHRoZSBleGlzdGluZyBSRkMgNDk0MSAv NjQgZml4ZWQgYm91bmRhcnkgdG8gLzgwIGZpeGVkDQo+PiAgICAgYm91bmRhcnkuDQo+PiAgICAg ID4NCj4+ICAgICAgPiBLaW5kIFJlZ2FyZHMNCj4+ICAgICAgPg0KPj4gICAgICA+IEd5YW4NCj4+ ICAgICAgPg0KPj4gICAgICA+IE9uIFRodSwgTm92IDE5LCAyMDIwIGF0IDU6MTQgUE0gSm9lbCBN LiBIYWxwZXJuDQo+PiAgICAgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+IDxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4+DQo+PiAgICAgID4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tPiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmpt aEBqb2VsaGFscGVybi5jb20+Pj4+IHdyb3RlOg0KPj4gICAgICA+DQo+PiAgICAgID4gICAgIEkg YW0gbWlzc2luZyBzb21ldGhpbmcgaW4geW91ciByZWFzb25pbmcuDQo+PiAgICAgID4gICAgIFlv dSBzZWVtIHRvIHNheSBhdCBvbmUgcG9pbnQgdGhhdCAodG8gcGFyYXBocmFzZSkgIndlIGNhbid0 DQo+PiAgICAgZG8gdGhpcw0KPj4gICAgICA+ICAgICBiZWNhdXNlIGl0IGRvZXMgbm90IHdvcmsg d2l0aCB0aGUgZXhpc3RpbmcgVUUgc29mdHdhcmUiLg0KPj4gICAgICA+ICAgICBBbnkgbmV3IHNv bHV0aW9uIHdoZXJlIGEgVUUgZGVsZWdhdGVzIGJhc2VkIG9uIGFueSBjaGFuZ2Ugb2YNCj4+ICAg ICBhbnkga2luZA0KPj4gICAgICA+ICAgICAoaW5jbHVkaW5nIGxlbmd0aGVuaW5nIHRoZSBwcmVm aXgsIHNob3J0ZW5pbmcgdGhlIHByZWZpeCwgb3INCj4+ICAgICBtYWdpY2FsbHkNCj4+ICAgICAg PiAgICAgaW5jYW50aW5nIG5ldyBwcmVmaXhlcykgcmVxdWlyZXMgdGhhdCB0aGUgVUUgYmUgdXBn cmFkZWQgdG8ga25vdw0KPj4gICAgICA+ICAgICB3aGF0IHRvDQo+PiAgICAgID4gICAgIGRvIHdp dGggdGhlIGluZm9ybWF0aW9uLiAgSSBkbyBub3Qgc2VlIGhvdyB0aGF0DQo+PiAgICAgZGlmZmVy ZW50aWF0ZXMgYW55IG9mDQo+PiAgICAgID4gICAgIHRoZSBzb2x1dGlvbnMuIChFeGNlcHQgImRv bid0IGRvIGFueXRoaW5nIiwgd2hpY2ggSSB0aGluayB3ZQ0KPj4gICAgIGRvIG5vdA0KPj4gICAg ICA+ICAgICB3YW50DQo+PiAgICAgID4gICAgIHRvIHRha2UuKQ0KPj4gICAgICA+DQo+PiAgICAg ID4gICAgIFlvdXJzLA0KPj4gICAgICA+ICAgICBKb2VsDQo+PiAgICAgID4NCj4+ICAgICAgPiAg ICAgT24gMTEvMTkvMjAyMCA1OjAzIFBNLCBHeWFuIE1pc2hyYSB3cm90ZToNCj4+ICAgICAgPiAg ICAgID4NCj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gT24gVGh1LCBOb3YgMTks IDIwMjAgYXQgMTA6MzMgQU0gPG90cm9hbkBlbXBsb3llZXMub3JnPG1haWx0bzpvdHJvYW5AZW1w bG95ZWVzLm9yZz4NCj4+ICAgICA8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPG1haWx0bzpv dHJvYW5AZW1wbG95ZWVzLm9yZz4+DQo+PiAgICAgID4gICAgIDxtYWlsdG86b3Ryb2FuQGVtcGxv eWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPiA8bWFpbHRvOm90cm9hbkBlbXBs b3llZXMub3JnPG1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZz4+Pg0KPj4gICAgICA+ICAgICAg PiA8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPG1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9y Zz4gPG1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5v cmc+Pg0KPj4gICAgIDxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBl bXBsb3llZXMub3JnPiA8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPG1haWx0bzpvdHJvYW5A ZW1wbG95ZWVzLm9yZz4+Pj4+IHdyb3RlOg0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAg ICAgPg0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiAgICAgID4gT24gMTkgTm92 IDIwMjAsIGF0IDE0OjU4LCBHeWFuIE1pc2hyYQ0KPj4gICAgICA+ICAgICA8aGF5YWJ1c2Fnc21A Z21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+IDxtYWlsdG86aGF5YWJ1c2Fn c21AZ21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+Pg0KPj4gICAgIDxtYWls dG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+IDxt YWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+ Pj4NCj4+ICAgICAgPiAgICAgID4gICAgIDxtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPG1h aWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+DQo+PiAgICAgPG1haWx0bzpoYXlhYnVzYWdzbUBn bWFpbC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+DQo+PiAgICAgID4gICAgIDxt YWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+ DQo+PiAgICAgPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb208bWFpbHRvOmhheWFidXNhZ3Nt QGdtYWlsLmNvbT4+Pj4+IHdyb3RlOg0KPj4gICAgICA+ICAgICAgPiAgICAgID4NCj4+ICAgICAg PiAgICAgID4gICAgICA+IFlvdSB3b3VsZCBuZWVkIGEgbmV3IG9wdGlvbi4gSXQgd291bGQgbGlr ZWx5IGJlDQo+PiAgICAgdXNlZnVsIGZvciB0aGUNCj4+ICAgICAgPiAgICAgID4gICAgIHJlcXVl c3Rpbmcgcm91dGVyIHRvIGluZGljYXRlIGludGVyZXN0IGluIHRoZSBvcHRpb24uIEV2ZW4NCj4+ ICAgICAgPiAgICAgaGludGluZw0KPj4gICAgICA+ICAgICAgPiAgICAgYXQgd2hhdCBwcmVmaXgg c2l6ZSBpdCB3YXMgZXhwZWN0aW5nLg0KPj4gICAgICA+ICAgICAgPiAgICAgID4gTm93IGNhbiB5 b3UgZXhwbGFpbiB0byBtZSBhZ2FpbiB0aGUgcmVhc29ucyB3aHkgdGhpcw0KPj4gICAgICA+ICAg ICBhcHByb2FjaCBpcw0KPj4gICAgICA+ICAgICAgPiAgICAgYmV0dGVyIHRoYW4gdXNpbmcgdGhl IGV4aXN0aW5nIERIUEN2NiBwcm90b2NvbCBwYWNrZXRzPw0KPj4gICAgICA+ICAgICAgPiAgICAg ID4NCj4+ICAgICAgPiAgICAgID4gICAgICA+ICAgICAzR1BQIGdhdGV3YXkgZG9lcyBub3Qgc3Vw cG9ydCBESENQdjYNCj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gICAgIDNHUFAg Z2F0ZXdheSBkb2Vzbid0IHN1cHBvcnQgbmV3IG9wdGlvbi4gV2hhdCdzIHlvdXINCj4+ICAgICBw b2ludD8NCj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAg ID4NCj4+ICAgICAgPiAgICAgID4gICAgICBUaGUgcG9pbnQgb2YgdGhlIHY2b3BzIHByZXNlbnRh dGlvbiBhbmQgdGhpcyBlbWFpbA0KPj4gICAgIHRocmVhZCBpcw0KPj4gICAgICA+ICAgICBob3cg dG8NCj4+ICAgICAgPiAgICAgID4g4oCcZXh0ZW5kIGEgLzY04oCdIGluIHRoZSAzR1BQIHVzZSBj YXNlICBpbiBzbGlkZSAxIG9mIHRoZQ0KPj4gICAgIGRlY2sgeW91DQo+PiAgICAgID4gICAgIGNv bXBpbGVkDQo+PiAgICAgID4gICAgICA+IGEgbGlzdCBvZiBvcHRpb25zIGFuZCBvZiB0aGUgdHdv IEkgaGFkIGhpZ2hsaWdodGVkIGluIHJlZA0KPj4gICAgIHdlcmUgdGhlDQo+PiAgICAgID4gICAg ICA+IDY0c2hhcmUgdjIgQ2FtZXJvbuKAmXMgb3B0aW9uIGFuZCB0aGUgdmFyaWFibGUgc2xhYWMN Cj4+ICAgICBvcHRpb24uICBTbyBvbg0KPj4gICAgICA+ICAgICB0aGUNCj4+ICAgICAgPiAgICAg ID4gY2FsbCB0aGlzIG1vcm5pbmcgTG9yZW56byBzaG90IGRvd24gNjRzaGFyZSB2MiBzaG9ydGVy IHByZWZpeA0KPj4gICAgICA+ICAgICBvcHRpb24gYXMNCj4+ICAgICAgPiAgICAgID4gZXZlbiBp ZiB0aGUgM0dQUCBhcmNoaXRlY3R1cmUgd2FzIHVwZGF0ZWQgdG8gc3VwcG9ydCBsb25nZXINCj4+ ICAgICAgPiAgICAgcHJlZml4ZXMgYW5kDQo+PiAgICAgID4gICAgICA+IGV2ZW4gaXMgdGhlIDNH UFAgZ2F0ZXdheSB3YXMgYWJsZSB0byBzZW5kIGEgc2hvcnRlciBwcmVmaXgNCj4+ICAgICB3aXRo IEENCj4+ICAgICAgPiAgICAgZmxhZw0KPj4gICAgICA+ICAgICAgPiBub3Qgc2V0LCBhbGwgbW9i aWxlIGRldmljZXMgcGVyIExvcmVuem/igJlzIHBvaW50IHdvdWxkIGJlDQo+PiAgICAgYnJva2Vu DQo+PiAgICAgID4gICAgIGFzIHRoZXkNCj4+ICAgICAgPiAgICAgID4gd291bGQgbm90IGFjY2Vw dCB0aGUgc2hvcnRlciBsZXTigJlzIHNheSAvNTYgcHJlZml4IHRvIGJ1aWxkIHRoZQ0KPj4gICAg ICA+ICAgICBzbGFhYyAxMjgNCj4+ICAgICAgPiAgICAgID4gYml0IGFkZHJlc3MuICBTbyB0aGUg Ym90dG9tIGxpbmUgaXMgdGhlIDY0c2hhcmUgdjIgd29u4oCZdCB3b3JrDQo+PiAgICAgID4gICAg IHVubGVzcyB3ZQ0KPj4gICAgICA+ICAgICAgPiB1cGRhdGUgUkZDIDQyOTEgYW5kIHJlbW92ZSB0 aGUgNjQgYml0IGJvdW5kYXJ5Lg0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiAg IFNvIHdlIGFyZSBiYWNrIHRvIHNxdWFyZSB1bm8gLSBubyB2aWFibGUgc29sdXRpb24NCj4+ICAg ICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gICBTbyBub3cgd2UgaGFkIHRocm93biBvdXQg dGhlIGxvbmdlciA+NjQgZHVlIHRvIHJhY2UgdG8NCj4+ICAgICBib3R0b20NCj4+ICAgICAgPiAg ICAgd29ycmllcw0KPj4gICAgICA+ICAgICAgPiB3aGljaCBJIGFuZCBvdGhlcnMgYmVsaWV2ZSBp cyBGdWQgYW5kIGFzIGRlc2NyaWJlZCBpbg0KPj4gICAgIHNsaWRlIDEwIG9mDQo+PiAgICAgID4g ICAgIHRoZQ0KPj4gICAgICA+ICAgICAgPiB2Nm9wcyDigJxyYWNlIHRvIHRoZSBib3R0b20gc2xp ZGXigJ0uDQo+PiAgICAgID4gICAgICA+DQo+PiAgICAgID4gICAgICA+IFNvIGEgaGFwcHkgbWVk aXVtIC84MCBmaXhlZCBib3VuZGFyeSBJIGNhbWUgdXAgd2l0aCB0aGF0IEkNCj4+ICAgICB0aGlu aw0KPj4gICAgICA+ICAgICBzb2x2ZXMNCj4+ICAgICAgPiAgICAgID4gYSBsb3Qgb2YgdGhlIGlz c3VlIGFuZCBub3QganVzdCB0aGUgM0dQUCBpbml0aWFsDQo+PiAgICAgc2VnbWVudGF0aW9uIG9m DQo+PiAgICAgID4gICAgICA+IGRvd25zdHJlYW0gZGV2aWNlcyBwcm9ibGVtIHN0YXRlbWVudC4N Cj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gU2luY2Ugd2UgaGF2ZSB0byB1cGRh dGUgUkZDIDQyOTEgZm9yIDY0c2hhcmUgdjIgdG8gd29yaw0KPj4gICAgIGFueXdheXMNCj4+ICAg ICAgPiAgICAgdG8gYWxsb3cNCj4+ICAgICAgPiAgICAgID4gZm9yIHNob3J0ZXIgcHJlZml4ZXMs IHdoeSBub3QgaW5zdGVhZCBjcmVhdGUgYSBuZXcgYm90dG9tDQo+PiAgICAgYXQgLzgwDQo+PiAg ICAgID4gICAgIGdpdmluZw0KPj4gICAgICA+ICAgICAgPiAxNiBiaXRzIG1vcmUgb2YgcHJlZml4 IGxlbmd0aCBhbmQgc2hyaW5raW5nIHRoZSBJSUQgZG93bg0KPj4gICAgIHRvIDQ4IGJpdHMuDQo+ PiAgICAgID4gICAgICA+IERvaW5nIHNvIHlvdSB3b3VsZCBub3QgZXZlbiBoYXZlIHRvIHVwZGF0 ZSB0aGUgM0dQUA0KPj4gICAgIGFyY2hpdGVjdHVyZQ0KPj4gICAgICA+ICAgICBhcyBJDQo+PiAg ICAgID4gICAgICA+IGRvbuKAmXQga25vdyBpZiB0aGF0IHdvdWxkIGZseSBvciBub3QuICBBbHNv IHRoaXMgc29sdmVzIGENCj4+ICAgICBmZXcgb3RoZXINCj4+ICAgICAgPiAgICAgID4gcHJvYmxl bXMgYXQgdGhlIHNhbWUgdGltZS4NCj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4N Cj4+ICAgICAgPiAgICAgID4gQXMgSSBtZW50aW9uZWQgaW4gdGhlIHY2b3BzIGRlY2sgcHJlc2Vu dGVkIHRoYXQgdmxzbSAwIHRvDQo+PiAgICAgMTI4IGlzDQo+PiAgICAgID4gICAgICA+IG1haW5z dHJlYW0gZm9yIG9wZXJhdG9ycyBmb3Igc3RhdGljIGFkZHJlc3Npbmcgb24gcm91dGVyDQo+PiAg ICAgYW5kIHN3aXRjaA0KPj4gICAgICA+ICAgICAgPiBpbmZyYXN0cnVjdHVyZSBhbmQgZGhjcHY2 IHN1Ym5ldHMgbG9uZ2VyIHByZWZpeGVzIGZvciBuZXR3b3JrDQo+PiAgICAgID4gICAgICA+IGlu ZnJhc3RydWN0dXJlIGFwcGxpYW5jZSBjbHVzdGVycywgTkZWL1ZORiB2aXJ0dWFsaXphdGlvbg0K Pj4gICAgIGFuZCBzZXJ2ZXINCj4+ICAgICAgPiAgICAgID4gZmFybXMuICBPbiBob3N0IHN1Ym5l dHMgd2hlcmUgdGhlcmUgaXMgYSBjaGFuY2Ugb2YgbWl4IG9mDQo+PiAgICAgc2xhYWMNCj4+ICAg ICAgPiAgICAgaG9zdHMNCj4+ICAgICAgPiAgICAgID4gd2l0aCBkaGNwdjYgIGRldmljZXMgdGhl IHByZWZpeCBsZW5ndGggaXMgc3R1Y2sgYXQgLzY0LiAgU28gb24NCj4+ICAgICAgPiAgICAgdGhl c2UgbWl4DQo+PiAgICAgID4gICAgICA+IGFkZHJlc3NpbmcgaG9zdCBzdWJuZXRzIHdlIGNhbm5v dCBkbyBsb25nZXIgcHJlZml4ZXMgZm9sbG93aW5nDQo+PiAgICAgID4gICAgIG91ciBORA0KPj4g ICAgICA+ICAgICAgPiBjYWNoZSBoYXJkIGxpbWl0IG1hbnRyYSB0byBwcmV2ZW50IE5EIGNhY2hl IGV4aGF1c3Rpb24NCj4+ICAgICBpc3N1ZXMgYXMNCj4+ICAgICAgPiAgICAgID4gZGVzY3JpYmVk IGluIFJGQyA2MTY0Lg0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiBTbyB3aXRo IHRoZSAvODAgbmV3IGZpeGVkIGJvdW5kYXJ5IHNoaWZ0aW5nIHByZWZpeCBsZW5ndGgNCj4+ICAg ICAxNiBiaXRzDQo+PiAgICAgID4gICAgIGxvbmdlcg0KPj4gICAgICA+ICAgICAgPiBhbmQgc2hv cnRlbmluZyB0aGUgSUlEIGJ5IDE2IGJpdHMgZ2l2ZXMgcmVzb2x2ZWQgdGhlIDNHUFANCj4+ICAg ICBpc3N1ZQ0KPj4gICAgICA+ICAgICB3aGljaA0KPj4gICAgICA+ICAgICAgPiA2NHNoYXJlIGNh biB3b3JrIGFzIGlzIGFuZCBzdWJ0ZW5kaW5nIHRvIGRvd25zdHJlYW0NCj4+ICAgICBkZXZpY2Vz IHdpbGwgbm93DQo+PiAgICAgID4gICAgICA+IHdvcmsgYXMgYSAvNjQgaXMgbm93IGVxdWl2YWxl bnQgdG8gYSAvNDggd2l0aCA2NGsgLzgwcy4gIEFsc28NCj4+ICAgICAgPiAgICAgQkNQLTY5MA0K Pj4gICAgICA+ICAgICAgPiBmb3IgYnJvYWRiYW5kIG5vdCBhbGwgb3BlcmF0b3JzIGhhdmUgYWRv cHRlZCB0aGUgc2hvcnRlcg0KPj4gICAgIHByZWZpeA0KPj4gICAgICA+ICAgICBsZW5ndGhzDQo+ PiAgICAgID4gICAgICA+IC81NiBvciAvNDggcmVjb21tZW5kYXRpb25zICBhbmQgbm93IHRoYXTi gJlzIG5vdCBhbiBpc3N1ZSBhcyB0aGUNCj4+ICAgICAgPiAgICAgLzY0IHdvdWxkDQo+PiAgICAg ID4gICAgICA+IG5vdyBzdWZmaWNlLg0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAgICAg PiAgRnJvbSBhbiBvcGVyYXRvcnMgcGVyc3BlY3RpdmUgdGhhdCBnYWluIGFsbG93cyBhdCBsZWFz dA0KPj4gICAgIGZvciAzR1BQDQo+PiAgICAgID4gICAgICA+IG1hc3NpdmUgZ3Jvd3RoIGFuZCBz dWJ0ZW5kaW5nIHdpdGggYSBzaW5nbGUgLzY0IGFsbG93cyB0aGUNCj4+ICAgICBvcGVyYXRvcnMN Cj4+ICAgICAgPiAgICAgID4gc3VjaCBhcyBWZXJpem9uIHdpdGggbWFzc2l2ZSBzdWJzY3JpYmVy IGJhc2Ugd29ybGR3aWRlIGNhbg0KPj4gICAgIHN0YXkgd2l0aA0KPj4gICAgICA+ICAgICAgPiBj dXJyZW50IGFsbG9jYXRpb25zIGFuZCBkb27igJl0IGhhdmUgdG8gYXNrDQo+PiAgICAgPGh0dHBz Oi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvZW50K2FsbG9jYXRpb25zK2FuZCtkb24lRTIl ODAlOTl0K2hhdmUrdG8rYXNrP2VudHJ5PWdtYWlsJnNvdXJjZT1nPg0KPj4gICAgIGZvciAvMTAu DQo+PiAgICAgID4gICAgICA+DQo+PiAgICAgID4gICAgICA+IEFzIDVHIGdldHMgcm9sbGVkIG91 dCB3aXRoIEVuaGFuY2VkIFZQTiBmcmFtZXdvcmsgYW5kIE5ldHdvcmsNCj4+ICAgICAgPiAgICAg c2xpY2luZw0KPj4gICAgICA+ICAgICAgPiBwYXJhZGlnbSwgdGhlIGRlbWFuZCBmb3Igc2hvcnRl ciBibG9ja3MgYW5kIHdlYXJhYmxlDQo+PiAgICAgbXVsdGlwbGUgLzQ4DQo+PiAgICAgID4gICAg IHdpbGwNCj4+ICAgICAgPiAgICAgID4gYmUgb3VyIG5ldyByZWFsaXR5Lg0KPj4gICAgICA+ICAg ICAgPg0KPj4gICAgICA+ICAgICAgPiBNYWtpbmcgdGhhdCAxNiBiaXQgc2hpZnQgbm93IHRvIC84 MCBtYWtpbmcgYSAvNjQgdGhlIG5ldw0KPj4gICAgIC80OCB3aWxsDQo+PiAgICAgID4gICAgIGdp dmUNCj4+ICAgICAgPiAgICAgID4gYnJvYWRiYW5kIGFuZCAzR1BQIHN1YnNjcmliZXJzIGEgdG9u IG9mIHNwYWNlIHRvDQo+PiAgICAgc3VidGVuZGluZyB0aGVpcg0KPj4gICAgICA+ICAgICAgPiBu ZXR3b3JrcyB3ZSB3b3VsZCBiZSBzZXQgZm9yIHRoZSBmdXR1cmUuICBFc3BlY2lhbGx5IHdpdGgN Cj4+ICAgICBJT1QgdGhlDQo+PiAgICAgID4gICAgIGRlbWFuZA0KPj4gICAgICA+ICAgICAgPiBm b3Igc3VidGVuZGluZyB3aWxsIGNvbnRpbnVlIHRvIGdyb3cgYXN0cm9ub21pY2FsbHkuDQo+PiAg ICAgID4gICAgICA+DQo+PiAgICAgID4gICAgICA+IEFsc28gSUFOQSBkb2VzIG5vdCBoYXZlIHRv IGdldCBzdGFydCBpbiBhbGxvY2F0aW5nIHRoZQ0KPj4gICAgIG90aGVyIC8zIGFuZA0KPj4gICAg ICA+ICAgICAgPiBvdGhlciBhdmFpbGFibGUgYmxvY2tzLg0KPj4gICAgICA+ICAgICAgPg0KPj4g ICAgICA+ICAgICAgPiBMb3RzIG9mIHByb2JsZW1zIGJlaW5nIHNvbHZlZCBoZXJlIHdpdGggYSBm aXhlZCAvODAgbmV3DQo+PiAgICAgYm91bmRhcnkuDQo+PiAgICAgID4gICAgICA+DQo+PiAgICAg ID4gICAgICA+IEFsc28gd2l0aCB0aGUgZXhpc3RpbmcgcmFuZG9tIElJRCBnZW5lcmF0aW9uIHNj aGVtZXMgd2hpY2gNCj4+ICAgICB3ZSBoYXZlDQo+PiAgICAgID4gICAgICA+IHRlc3RlZCBvbiBM aW51eCBrZXJuZWwgY2FuIGRvIGxvbmdlciBwDQo+PiAgICAgID4NCj4+ICAgICAgIDxodHRwczov L3d3dy5nb29nbGUuY29tL21hcHMvc2VhcmNoL3Rlc3RlZCtvbitMaW51eCtrZXJuZWwrY2FuK2Rv K2xvbmdlcitwP2VudHJ5PWdtYWlsJnNvdXJjZT1nIDxodHRwczovL3d3dy5nb29nbGUuY29tL21h cHMvc2VhcmNoL3Rlc3RlZCtvbitMaW51eCtrZXJuZWwrY2FuK2RvK2xvbmdlcitwP2VudHJ5PWdt YWlsJnNvdXJjZT1nPj5yZWZpeGVzDQo+PiAgICAgID4gICAgIHVzaW5nIFJGQyA0OTQxIHByaXZh Y3kNCj4+ICAgICAgPiAgICAgID4gZXh0ZW5zaW9uIG9yIFJGQyA3MjE3IHN0YWJsZSBJSUQuDQo+ PiAgICAgID4gICAgICA+DQo+PiAgICAgID4gICAgICA+IFdpbi1XaW4gZm9yIGFsbC4NCj4+ICAg ICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gICAgIE9sZQ0KPj4gICAgICA+ICAgICAgPg0K Pj4gICAgICA+ICAgICAgPiAtLQ0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiA8 aHR0cDovL3d3dy52ZXJpem9uLmNvbS8gPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KPj4gICAg IDxodHRwOi8vd3d3LnZlcml6b24uY29tLyA8aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+Pj4NCj4+ ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gKkd5YW4gTWlzaHJhKg0KPj4gICAgICA+ ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiAvTmV0d29yayBTb2x1dGlvbnMgQS8vcmNoaXRlY3Qg Lw0KPj4gICAgICA+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiAvTSAzMDEgNTAyLTEzNDcNCj4+ ICAgICAgPiAgICAgID4gMTMxMDEgQ29sdW1iaWEgUGlrZQ0KPj4gICAgICA+ICAgICAgPiAvU2ls dmVyIFNwcmluZywgTUQNCj4+ICAgICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4NCj4+ICAg ICAgPiAgICAgID4NCj4+ICAgICAgPiAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ICAgICAgPiAgICAgID4gdjZvcHMgbWFpbGluZyBsaXN0 DQo+PiAgICAgID4gICAgICA+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4g PG1haWx0bzp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KPj4gICAgIDxt YWlsdG86djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiA8bWFpbHRvOnY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+Pg0KPj4gICAgICA+ICAgICAgPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+PiAgICAgPGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM+DQo+PiAgICAgID4gICAgIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+PiAgICAgPGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM+Pg0KPj4gICAgICA+ICAgICAgPg0K Pj4gICAgICA+DQo+PiAgICAgID4gLS0NCj4+ICAgICAgPg0KPj4gICAgICA+IDxodHRwOi8vd3d3 LnZlcml6b24uY29tLyA8aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+Pg0KPj4gICAgICA+DQo+PiAg ICAgID4gKkd5YW4gTWlzaHJhKg0KPj4gICAgICA+DQo+PiAgICAgID4gL05ldHdvcmsgU29sdXRp b25zIEEvL3JjaGl0ZWN0IC8NCj4+ICAgICAgPg0KPj4gICAgICA+IC9NIDMwMSA1MDItMTM0Nw0K Pj4gICAgICA+IDEzMTAxIENvbHVtYmlhIFBpa2UNCj4+ICAgICAgPiAvU2lsdmVyIFNwcmluZywg TUQNCj4+ICAgICAgPg0KPj4gICAgICA+DQo+Pg0KPj4gLS0NCj4+DQo+PiA8aHR0cDovL3d3dy52 ZXJpem9uLmNvbS8+DQo+Pg0KPj4gKkd5YW4gTWlzaHJhKg0KPj4NCj4+IC9OZXR3b3JrIFNvbHV0 aW9ucyBBLy9yY2hpdGVjdCAvDQo+Pg0KPj4gL00gMzAxIDUwMi0xMzQ3DQo+PiAxMzEwMSBDb2x1 bWJpYSBQaWtlDQo+PiAvU2lsdmVyIFNwcmluZywgTUQNCj4+DQo+Pg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4gdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlw djZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_9d13e7549f844e14b3be8661aee3e516huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+JiM0MzsxIHRvIE1hcms8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGV0aGVyaW5nIHdhcyBuZXZlciBpbiB0aGUgYnVzaW5lc3MgbW9kZWwgb2YgTW9iaWxl IG1hcmtldC4gTmVpdGhlciBmb3IgY2FycmllcnMgdGhlbXNlbHZlcyBub3IgZm9yIHZlbmRvcnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkluIGdlbmVyYWwgdGhpcyBkaXNjdXNzaW9uIGlzIOKAnGhvdyB0 byBlbmZvcmNlIHNvbWVib2R5IHRvIGFjdCBhZ2FpbnN0IGhpcyBidXNpbmVzcyBpbnRlcmVzdHPi gJ0gbGV2ZXJhZ2luZyBzb21lIHRlY2hub2xvZ3kgdG9vbHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVk LzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gaXB2NiBbbWFpbHRv OmlwdjYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFyayBTbWl0aDxi cj4NCjxiPlNlbnQ6PC9iPiAyMSDQvdC+0Y/QsdGA0Y8gMjAyMCDQsy4gNzoyMDxicj4NCjxiPlRv OjwvYj4gQnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IDZNQU4gJmx0OzZtYW5AaWV0Zi5vcmcmZ3Q7OyBJUHY2IE9wZXJh dGlvbnMgJmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV4 dCBzdGVwPyBbUmU6IFt2Nm9wc10gVGhlIGJvdHRvbSBpcyAvMTEyXTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgMjEgTm92IDIwMjAsIDE0OjAwIEJyaWFu IEUgQ2FycGVudGVyLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Sm9lbCw8YnI+DQo8YnI+DQpJdCBzZWVtcyB0byBtZSB0aGF0IGl0J3MgaGlnaCB0 aW1lIHRvIGRyYWZ0IGEgbGlhaXNvbiBzdGF0ZW1lbnQgdG8gM0dQUCw8YnI+DQpvYnNlcnZpbmcg dGhhdDo8YnI+DQo8YnI+DQooMSkgVGhlcmUgaXMgYSBzZXJpb3VzIHByb2JsZW0gZm9yIHRoZSBk ZXNpZ24gYW5kIGltcGxlbWVudGF0aW9uIG9mPGJyPg0KNUctYmFzZWQgSVB2NiAmcXVvdDtob3Qg c3BvdHMmcXVvdDsgYW5kIENFcyBbd2hpY2ggaXMgd2hlcmUgdGhpcyBjb252ZXJzYXRpb24gc3Rh cnRlZF07PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBpcyBhbHNvIGltcG9ydGFudCB0 byBmaW5kIG91dCB3aHkgdGhleSBoYXZlbid0IGRlcGxveWVkIERIQ1B2NiB0byBzb2x2ZSB0aGlz Jm5ic3A7cHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RG9uJ3QgdGhleSB0aGluayBESENQdjYgaW5mcmFzdHJ1Y3R1cmUgd2lsbCBz Y2FsZT8gSXMgaXQganVzdCB0aGF0IHRoZXkgZG9uJ3Qga25vdyBob3cgdG8gc2NhbGUgaXQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGl0 IGEgdmVuZG9yIC8gbW9iaWxlIG9wZXJhdG9yIC8gaGFuZHNldCBkZXZlbG9wZXIgREhDUHY2IGNh cGFiaWxpdHkmbmJzcDtjaGlja2VuLWFuZC1lZ2cgcHJvYmxlbT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlcmUgYW4gb3ZlcnJpZGlu ZyBidXNpbmVzcyBvciBpbmR1c3RyeSByZWFzb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBtb2JpbGUgaW5kdXN0cnkgaGFzIGJlZW4g cmVzaXN0YW50IHRvIHRldGhlcmluZyBvdmVyIHRoZSB5ZWFycywgYW5kIHByb2JhYmx5IG9ubHkg Y2FtZSB0byBiZWdydWRnaW5nbHkgYWNjZXB0IGl0IGJlY2F1c2UgdGhleSBjb3VsZG4ndCBwcmV2 ZW50IHBob25lIHZlbmRvcnMgZnJvbSBpbXBsZW1lbnRpbmcgV2lmaSBhbmQgTkFULCBhbmQgY291 bGRuJ3QgdmVyeSBlZmZlY3RpdmVseSBzdG9wIHRoZWlyIGN1c3RvbWVycw0KIGZyb20gdXNpbmcg dGhhdCBjYXBhYmlsaXR5IChPbmUgdHJpY2sgSSd2ZSBoZWFyZCBvZiB0byBwcmV2ZW50IHRldGhl cmluZyB3b3JraW5nIHdhcyB0byBjaGVjayBpZiBhbiBJUHY0IHBhY2tldCdzJm5ic3A7VFRMIHZh bHVlIHdhcyA2NCB3aGVuIGl0IGFycml2ZWQgYXQgdGhlIG5ldHdvcmssIG1lYW5pbmcgaXQgb3Jp Z2luYXRlZCBmcm9tIHRoZSBkaXJlY3RseSBhdHRhY2hlZCBoYW5kc2V0LiBQYWNrZXRzIGZyb20g dGV0aGVyZWQgZGV2aWNlcyBoYWQgYQ0KIFRUTCBvZiA2MyBzbyB3ZXJlIGRyb3BwZWQuIE9mIGNv dXJzZSwgeW91IGNvdWxkIHNldCB0aGUgZGVmYXVsdCBUVEwgb24gYSB0ZXRoZXJlZCZuYnNwO1BD IHRvIDY1IHRvIGdldCBhcm91bmQgdGhhdC4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhlcmUgbWlnaHQgYmUgYSBmYWlybHkg c3Ryb25nIG1pbmRzZXQgdGhhdCB0aGVyZSBtdXN0IGJlIGEgZmVlIHBlciBkZXZpY2UgYXR0YWNo ZWQgdG8gdGhlIG5ldHdvcmsgaW4gYWRkaXRpb24gdG8gYSBmZWUgZm9yIG5ldHdvcmsgdXRpbGlz YXRpb24uIFByb3ZpZGluZyBtdWx0aXBsZSAvNjRzIHdvdWxkIGJlIGZvcm1hbGx5IGFja25vd2xl ZGdpbmcgdGhhdCBtdWx0aXBsZSBkZXZpY2VzIGNhbiBiZQ0KIGF0dGFjaGVkIGFuZCBhIGZlZSBw ZXIgZGV2aWNlIGlzbid0IGFuZCBjYW4ndCBldmVyIGJlIGNoYXJnZWQsIGNvdW50ZXIgdG8gdGhl IG1pbmRzZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NYXJrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCigyKSBBbHRob3VnaCB0aGUg YmVzdCBzb2x1dGlvbiBpcyBub3QgeWV0IG9idmlvdXMsIGRlZmluaW5nIGFuZDxicj4NCnN0YW5k YXJkaXppbmcgaXQgd2lsbCByZXF1aXJlIGEgam9pbnQgZWZmb3J0IGJ5IHRoZSBJRVRGIGFuZCAz R1BQLjxicj4NCjxicj4NCkZvbGxvd2VkIGJ5IGEgcHJvcG9zYWwgdG8gZm9ybSBhbiBhZCBob2Mg am9pbnQgZGVzaWduIHRlYW0uPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCiZuYnNwOyAmbmJzcDtC cmlhbiBDYXJwZW50ZXI8YnI+DQpPbiAyMS1Ob3YtMjAgMTQ6NDYsIEpvZWwgTS4gSGFscGVybiB3 cm90ZTo8YnI+DQomZ3Q7IFRoZSBuZXN0aW5nIGdvdCBtZSBsb3N0LCBzbyBJIHdpbGwgdG9wIHBv c3QgbXkgdGFrZSBvbiB0aGUgYW5zd2VyIHRvIHRoZSA8YnI+DQomZ3Q7IG9uZSBxdWVzaXRvbiBJ IGNvdWxkIHVuZGVyc3RhbmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYmVsaWV2ZSB5b3UgYXNr ZWQgd2hhdCBJIHRoaW5rIHdvdWxkIG5lZWQgdG8gYmUgY2hhbmdlZCB0byBwZXJtaXQgdGhlIDxi cj4NCiZndDsgZGVsZWdhdGlvbi48YnI+DQomZ3Q7IEFzIHdpdGggYW55dGhpbmcsIHRoZSByZWFs IHRoaW5ncyB0aGF0IG5lZWQgdG8gY2hhbmdlIGFyZSB0aGUgZGV2aWNlcyBpbiA8YnI+DQomZ3Q7 IHRoZSBuZXR3b3JrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaXRoIHJlZ2FyZCB0byBJRVRGIHN0 YW5kYXJkcywgd2hhdCBpcyBwcm9wb3NlZCBpcyBhIGNoYW5nZSB0byBSQS4gPGJyPg0KJmd0OyBU aGVyZSBhcmUgc2V2ZXJhbCBwb3NzaWJsZSBjaGFuZ2VzLiZuYnNwOyBOb25lIG9mIHRoZW0gcmVx dWlyZSBhIGNoYW5nZSB0byA8YnI+DQomZ3Q7IHRoZSBJUHY2IGFkZHJlc3NpbmcgYXJjaHRpZWN0 dXJlLCBhcyB0aGUgYWRkcmVzc2luZyBzdHJ1Y3R1cmUgcmVtYWlucyBhcyA8YnI+DQomZ3Q7IGl0 IGlzLjxicj4NCiZndDsgQXMgZm9yIHRoZSBleGFjdCBtZWNoYW5pc20sIGF0IHRoZSBtb21lbnQg SSBsZWFuIHRvd2FyZHMgT2xlJ3MgcHJvcG9zYWwgPGJyPg0KJmd0OyBvZiB1c2luZyBhIG5ldyBv cHRpb24gaW4gaGlzIGdlbmVyaWMgb3B0aW9uIG1lY2hhbmlzbS4mbmJzcDsgQnV0IEkgYW0gbm90 IDxicj4NCiZndDsgd2VkZGVkIHRvIHRoYXQgYW5zd2VyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBB bmQgb2YgY291cnNlLCB0byBnZXQgdGhpcyBzdXBwb3J0ZWQgaW4gbW9iaWxlIGVudmlyb25tZW50 cyB3ZSB3aWxsIGhhdmUgPGJyPg0KJmd0OyB0byB3b3JrIHdpdGggM0dQUCBhbmQgbWFrZSBzdXJl IHRoZXJlIGFyZSBubyBvdGhlciBoaWRkZW4gaXNzdWVzLiA8YnI+DQomZ3Q7IFRoYXQncyB0aGUg d2F5IHdlIGRvIHRoaW5ncy4mbmJzcDsgV29yayB0b2dldGhlci48YnI+DQomZ3Q7IDxicj4NCiZn dDsgQ2hhbmdpbmcgdGhlIHByZWZpeCBsZW5ndGggdG8gLzgwIGlzIHRlY2huaWNhbGx5IGFsc28g cG9zc2libGUuJm5ic3A7IEl0IGRvZXMgPGJyPg0KJmd0OyBhIGxvdCBtb3JlIHZpb2xlbmNlIHRv IG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGFyY2hpdGVjdHVyZSBhbmQgc29mdHdhcmUgPGJyPg0K Jmd0OyBzdHJ1Y3R1cmVzIHRoYXQgZ28gd2l0aCBpdCwgYW5kIGlzIGEgdmVyeSBsaW1pdGVkIGFu ZCBuYXJyb3cgc29sdXRpb24gdG8gPGJyPg0KJmd0OyB0aGUgcHJvYmxlbS48YnI+DQomZ3Q7IDxi cj4NCiZndDsgWW91cnMsPGJyPg0KJmd0OyBKb2VsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDEx LzIwLzIwMjAgNzo1OCBQTSwgR3lhbiBNaXNocmEgd3JvdGU6PGJyPg0KJmd0OyZndDsgSGkgSm9l bDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4tbGluZTxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgT24gRnJpLCBOb3YgMjAsIDIwMjAgYXQgNjowMiBQTSBKb2VsIE0uIEhhbHBlcm4g Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+ am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4NCjxicj4NCiZndDsmZ3Q7ICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhh bHBlcm4uY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO0d5YW4sIHNlcGFyYXRlIGZyb20gT2xlJ3MgY29tbWVudHMgYWJv dXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhZGRyZXNzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO2Fzc2lnbm1lbnQgYW5kIGRlbGVnYXRpb24sIEkgaGF2ZSBhbm90aGVyIHByb2Js ZW0gZm9sbG93aW5nIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZWFzb25p bmcgYmVsb3cuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 WWVzLCB0aGUgcHJvcG9zYWwgZm9yIHVzaW5nIHNob3J0ZXIgcHJlZml4ZXMgdG8gZW5hYmxlIFVF IHRvIHBlcmZvcm08YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVsZWdhdGlvbiB3 aWxsIHJlcXVpcmUgY2hhbmdlcyB0byB0aGUgVUUuIDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBHeWFuJmd0OyBBZ3JlZWQuJm5ic3A7IFNvIHRoYXQgY2hh bmdlIHdvdWxkIGJlIHRvIFJGQyA0MjkxIDY0IGJpdCBib3VuZGFyeSA8YnI+DQomZ3Q7Jmd0OyB0 byBhbGxvdyBmb3IgbG9uZ2VyIHByZWZpeC4mbmJzcDsgRG8geW91IGFncmVlPzxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgSWYgeW91IGRvbuKAmXQgYWdyZWUgd2hhdCBkbyB0aGluayB0aGUg Y2hhbmdlIHdvdWxkIGJlIHRvIGFsbG93IHRoZSBVRSB0byA8YnI+DQomZ3Q7Jmd0OyBhY2NlcHQg c2hvcnRlciBwcmVmaXggZnJvbSB0aGUgM0dQUCBnYXRld2F5Pzxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7QnV0IEkgZG8gbm90IHNl ZSBob3cgdGhhdCBpcyByZWxldmFudCB0byBhbnkgY2hvaWNlIHdlIGFyZSB0cnlpbmcgdG88YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bWFrZS48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7QW55IHNvbHV0aW9uIHRoYXQgZW5hYmxlcyBVRSB0byBkZWxlZ2F0ZSBhZGRy ZXNzZXMgKGluIHRoZSBzZW5zZSB0aGF0PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O3RoZXkgbGFjayB0aGUgY2FwYWJpbGl0eSBub3cpIHdpbGxyIGVxdWlyZSBjaGFuZ2VzIHRvIHRo ZSBVRS4gPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0d5YW4mZ3Q7IElmIHRoZSBVRSByZWNlaXZlcyBhIC81 NiB2aWEgUkEgaXQgY291bGQgZGVsZWdhdGUgLzY0IHRvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO2Rvd25zdHJlYW0gZGV2aWNlcy4mbmJzcDsgTm8gY2hhbmdlIG5lZWRlZCB0byBk ZWxlZ2F0ZSAmbmJzcDsvNjQsIGhvd2V2ZXIgYTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtjaGFuZ2UgaXMgbmVlZGVkIHRvIGFjY2VwdCAvNTYgdmlhIFJBLiA8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiAzR1BQ IGdhdGV3YXkgc3VwcG9ydGVkIFBEIC0gcHJvYmxlbSBzb2x2ZWQgYnV0IHRoYXTigJlzIG5vdCB0 aGUgPGJyPg0KJmd0OyZndDsgY2FzZSBhbmQgdGhhdCBkb2VzIG5vdCBzb3VuZCBsaWtlIGl0IHdp bGwgZXZlciBjaGFuZ2UgZXZlbiB3aXRoIDVHLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO0d5YW4mZ3Q7IFRoZSBVRSBuZWVkcyB0byBiZSBhYmxlIHRvIGFj Y2VwdCBzaG9ydGVyIHByZWZpeC4mbmJzcDsgVGhhdOKAmXMgdGhlIDxicj4NCiZndDsmZ3Q7IElQ VjYgc3BlY2lmaWNhdGlvbiBjaGFuZ2UgdGhhdCByZXF1aXJlcyByZW1vdmFsIG9mIHRoZSA2NCBi aXQgYm91bmRhcnkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7WW9ydTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtwcm9wb3NlZCBjaGFuZ2Ug dG8gdGhlIFNMQUFDIGxlbmd0aCBpZiBhbnl0aGluZyBkb2VzIG1vcmUgdmlvbGVuY2UgdG88YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHNvZnR3YXJlIChkZXBlbmRpbmcgdXBv biB0aGUgZXhhY3Qgc29mdHdhcmUgYXJjaGl0ZWN0dXJlLik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0d5YW4mZ3Q7IFdoYXQgdmlv bGVuY2UgdG8gc29mdHdhcmUuJm5ic3A7IFRoZXJlIHdvdWxkIGJlIG1vcmUgdmlvbGVuY2UgdG8g PGJyPg0KJmd0OyZndDsgc29mdHdhcmUgaWYgd2UgcmVtb3ZlZCB0aGUgNjQgYml0IGJvdW5kYXJ5 IGFuZCBhbGxvd2VkIHNsYWFjIHRvIHN1cHBvcnQgPGJyPg0KJmd0OyZndDsgYW55IHZsc20gcHJl Zml4IGxlbmd0aHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBNeSAvODAgcHJvcG9zYWwg d291bGQganVzdCBzaGlmdCB0aGUgYm91bmRhcnkgMTYgYml0cyB0byAvODAuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBIb3N0cyBvbiB0aGUgc2FtZSBzdWJuZXQgd2l0aCB0d28gZGlmZmVy ZW50IG1hc2tzIHdvdWxkIG5vdCBiZSBvbi1uZXQgdG8gPGJyPg0KJmd0OyZndDsgZWFjaCBvdGhl ciBhcyBvbiBkaWZmZXJlbnQgc3VibmV0cy4mbmJzcDsgVGhlIHJvdXRlciB3b3VsZCBiZSBjb25m aWd1cmVkIHdpdGggPGJyPg0KJmd0OyZndDsgdGhlIHR3byBzdWJuZXRzIC82NCBhbmQgLzgwIHN1 Ym5ldCB0byBzdXBwb3J0IHRoZSB0d28gZGV2aWNlIHR5cGVzLjxicj4NCiZndDsmZ3Q7IFRoZSBz b2x1dGlvbiB3b3VsZCBiZSBhIHNpbXBsZSBSQSBQSU8gZmxhZyB0aGF0IGlzIHNldCBhbmQgb2xk ZXIgaG9zdHMgPGJyPg0KJmd0OyZndDsgbm90IHVwZ3JhZGVkIHdvdWxkIGJlIGJhY2t3YXJkcyBj b21wYXRpYmxlIGFuZCBzbyB3b3VsZCBvbmx5IHN1cHBvcnQgNjQgPGJyPg0KJmd0OyZndDsgYml0 IGJvdW5kYXJ5IGJ5IGlnbm9yaW5nIGZsYWcuIEhvc3RzIHVwZ3JhZGVkIHRvIHN1cHBvcnQgd291 bGQgPGJyPg0KJmd0OyZndDsgdW5kZXJzdGFuZCB0aGUgZmxhZyBhbmQgYmUgYWJsZSB0byBzdXBw b3J0IGxvbmdlciBtYXNrIHVwIHRvIC84MC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7U28gSSBkbyBub3Qg Zm9sbG93IGhvdyB5b3UgZ290IHRvIHlvdXIgY29uY2x1c2lvbi48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtZb3Vycyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7Sm9lbDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO09uIDExLzIwLzIwMjAgNToyNyBQTSwgR3lhbiBNaXNocmEgd3JvdGU6PGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7ICh0b3AgcG9zdGluZyk8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgQXMgSSB3b3Vs ZCBsaWtlIHRvIGNsZWFyIHRoZSBhaXIgYXMgd2VsbCBhcyBnZXQgdG8gdGhlIGNydXggb2Y8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHY2b3BzPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IHByZXNlbnRhdGlvbiBkZXZlbG9wbWVudCByZXN1bHRzIGFz IHdlbGwgYXMgbmV4dCBzdGVwcyBmb3IgdGhpczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtkcmFmdDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBhbmQgdGhl IDZtYW4gdmFyaWFibGUgc2xhYWMgc29sdXRpb25zIGRyYWZ0Ojxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBUaGlzIHRocmVhZCB3YXMg aW4gbGlnaHQgb2YgTG9yZW56byBraW5kbHkgcG9pbnRpbmcgb3V0IHRoYXQ8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7dXBncmFkaW5nPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7IDNHUFAgaXMgbm90IGFsbCB0aGF0IG5lZWRzIGJlIGRvbmUgZm9yIENhbWVy b27igJlzIDY0c2hhcmUgdjIgdG88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7d29y ayAtIGFzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGFsbCBtb2JpbGUg ZGV2aWNlcyB3b3VsZCBzdG9wIHdvcmtpbmctIGFzIHNsYWFjIHdvdWxkIG5vdCB3b3VsZCBiZTxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBlZmZlY3RpdmVseSBicm9rZW4u PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZSBtb2JpbGUgZGV2aWNlIHdvdWxkIHJlY2VpdmUgYSBz aG9ydGVyIHByZWZpeCBsZXTigJlzIHNheSAvNTY8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7YnV0IG5vdDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBrbm93 IHdoYXQgdG8gZG8gd2l0aCBpdCBzaW5jZSBpdOKAmXMgZXhwZWN0aW5nIGEgLzY0Ljxicj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyBTbyB0aGF0IGEgbWFqb3IgZ2FwIGFuZCB0aGUgb25seSBzb2x1dGlvbiBp cyB1cGRhdGluZyBSRkMgNDI5MTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZW1v dmluZzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyB0aGUgNjQgYml0IGJv dW5kYXJ5IGFsbG93aW5nIGZvciBzaG9ydGVyIHByZWZpeCBhbmQgbm93IGFzIHdlbGw8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bG9uZ2VyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IHByZWZpeGVzIHRvIHdvcmsgYW5kIGluIHRoYXQgcmVzcGVjdCBub3cg cHJvdmlkZSB0aGUgbXVjaCBuZWVkZWQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 cGFyaXR5PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IHdpdGggc3RhdGlj IGFuZCBESENQdjYgd2hpY2ggY2FuIGRvIGFueSBwcmVmaXggbGVuZ3RoLjxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyBTbyB0aGF0IGlzIGEgZHJhc3RpYyBjaGFuZ2UgdG8gUkZDIDQyOTEuJm5ic3A7IEhv d2V2ZXIsIGluIGxpZ2h0IG9mIHRoaXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsgZGV2ZWxvcG1lbnQgb24gdGhlIHY2b3BzIDEwOSBjYWxsLCBteSBiYWxhbmNpbmcgYWN0 IG9mIGJlc3Qgb2YgYm90aDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyB3 b3JsZHMgYW5kIGFsc28gdG8ga2VlcCBldmVyeW9uZSBoYXBweSB0byBtYWtlIHRoaXMgYSBXRyBl ZmZvcnQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yIHRoaXM8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgY2hhbmdlIGJ5IHByb3Bvc2luZyBpbiB0aGUg c3ViamVjdCBoZWFkaW5nIC84MCBmaXhlZCBib3VuZGFyeSBhbmQ8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7bm90IGE8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgdmFyaWFibGUgc2xhYWMgY2hhbmdlIGFsbG93aW5nIGFsbCBiaXRzIHZsc20uPGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7IEJhc2ljYWxseSBzdGVhbGluZyAxNiBiaXRzIGZvciBuZXR3b3JrIHByZWZp eCBvdXQgb2YgdGhlIElJRCwgc3RpbGw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsga2VlcGluZyB0aGUgZml4ZWQgYm91bmRhcnkgc28gbG9uZ2VyIHRoYW4gODAgd291bGQg Tk9UICZuYnNwO2JlIGFsbG93ZWQuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IEEgLzY0IHdvdWxkIG5v dyBiZSBlcXVpdmFsZW50IHRvIGEgLzQ4IHdpdGggbm93IDY0ayAvODDigJlzLjxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyBUaGlzIC84MCB3b3VsZCBrZWVwIHRoZSBvcGVyYXRvcnMgYW5kIGxhdyBlbmZv cmNlbWVudCBoYXBweSBhczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtub3cgMTY8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgYml0cyBsZXNzIGhlbHBzIHRy YWNlYWJpbGl0eSBidXQgaXMgc3RpbGwgbG9uZyBlbm91Z2ggZm9yIDQ4IGJpdHMgb2Y8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgcHJpdmFjeSB0byBJUCBjb3JyZWxhdGlv biBieSBhdHRhY2tlcnMuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoaXMgLzgwIHdvdWxkIGJlIGEg bmljZSBvcHRpbWFsIGJhbGFuY2UgYXMgaXQgd291bGQga2VlcCB3aXJlZDxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBicm9hZGJhbmQgYW5kIG1vYmlsZSBoYW5kc2V0IGN1 c3RvbWVycyBoYXBweSByZXNwZWN0aW5nIHRoZWlyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO3ByaXZhY3kgYXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsg dGhlIDE2IGJpdHMgbGVzcyBvZiBoZXVyaXN0aWNzIGlzIG1pbmltYWwgY2hhbmdlIHRoYXQgd2ls bCBpbXBhY3QgSVA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgY29ycmVs YXRpb24gYnkgYXR0YWNrZXJzLjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBUaGUgSUlEIGFzIGl04oCZ cyBsZXNzIHRoYW4gdGhlIGN1cnJlbnQgNjQgYml0IGNhbm5vdCB1c2UgTUFDIGJhc2VkPGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0VVSTY0PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IElJRCwgd2hpY2ggaXMgbm90IGEgcHJvYmxlbSBhcyBNYWMgYmFzZWQg SUlEIGlzIG5vdCByZWNvbW1lbmRlZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDth cyBtb3N0PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGFsbCBtYW51ZmFj dHVyZXJzIHVzZSBSRkMgNDk0MSBhbmQgSSBiZWxpZXZlIExpbnV4IGZsYXZvcnMgc29tZSB1c2U8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgc3RhYmxlIElJRCBSRkMgNzIx Ny48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgU28gbm93IHRoZSA0OCBiaXQgSUlEIHdvdWxkIHJlcXVp cmUgYSByYW5kb20gSUlEIGdlbmVyYXRpb248YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7c2NoZW1hIHNvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGNhbiB1 c2UgZWl0aGVyIFJGQyA0OTQxIHByaXZhY3kgZXh0ZW5zaW9uIG9yIFJGQyA3MjE3IHN0YWJsZSBJ SUQgdG88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgZ2VuZXJhdGUgdGhl IDQ4IGJpdCBJSUQuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IDNHUFAgc3VidGVuZGluZyB3b3VsZCBu b3cgd29yayBpc3N1ZSBtZW50aW9uZWQgaW4gdGhlIHByb2JsZW08YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7c3RhdGVtZW50PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IGRyYWZ0IHdpdGhvdXQgZXZlbiBoYXZpbmcgdG8gdXNlIDY0c2hhcmUgYXMgbm93IGxv bmdlciBwcmVmaXhlczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt1cCB0bzxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvODAgd291bGQgYmUgc3VwcG9ydGVk IGFsbG93aW5nIGZvciBmdXJ0aGVyIHNlZ21lbnRhdGlvbiBvZjxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtkb3duc3RyZWFtPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IGRldmljZXMuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoaXMgYWxzbyB3b3VsZCBoZWxw IHdpcmVkIGJyb2FkYmFuZCBhbmQgc29vbiBmaXhlZCA1RyBicm9hZGJhbmQ8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgcHJvbGlmZXJhdGlvbiB3aGVyZSBvcGVyYXRvcnMg aW4gbGlnaHQgb2YgQkNQIFJJUEUtNjkwLCBhcmUgc2lsbDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyBhbGxvY2F0aW9uIHZpYSBCTkcgZ2F0ZXdheXMgYSAvNjQsIG5vdyBv cGVyYXRvcnMgJm5ic3A7Y2FuIHN0YXkgYXMtaXMsPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO2FzIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvNjQg d291bGQgbm93IGJlIGFsbG93ZWQgdG8gYmUgZnVydGhlciBzZWdtZW50ZWQgc3VwcG9ydGluZyA2 NGs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Lzgwcyw8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgd2F5IG1vcmUgdGhlbiBlbm91Z2ggZm9yIFNPSE8uPGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7IFRoaXMgd291bGQgYWxsb3cgNjRzaGFyZSBpZiB1c2VkIGJ5IDNH UFAgb3BlcmF0b3JzIHRvIHdvcmsgYW5kPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O3dvdWxkIG5vdDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyByZXF1aXJl IHRoZSAzR1BQIHNwZWNpZmljYXRpb24gdG8gYmUgdXBkYXRlZC4mbmJzcDsgV2UgZG9u4oCZdCBr bm93IGV2ZW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aWYgdGhlPGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IDNHUFAgYXJjaGl0ZWN0dXJlIHNwZWNpZmlj YXRpb24gY2FuIGJlIHVwZGF0ZWQgdG8gc3VwcG9ydCBzaG9ydGVyPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IHByZWZpeGVzIGFuZCBpZiB0aGUgM0dQUCBjb25zb3J0aXVt IG9mIG9wZXJhdG9ycyB3b3VsZCBhZ3JlZSB0bzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtpdC4mbmJzcDsgU288YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsg dGhhdCBpcyBhbGwgdGhlb3JldGljYWwgb2YgdGhhdCBjaGFuZ2UgaXMgcG9zc2libGUuPGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IEFzIHdpdGggNUcgd2l0aCBFbmhhbmNlZCBWUE4gZnJhbWV3b3JrIFNS IHN0ZWVyaW5nIG9mIGhpZ2ggcHJpb3JpdHk8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsgdHJhZmZpYywgdHJhZmZpYyBpc29sYXRpb24gYW5kIE5ldHdvcmsgc2xpY2luZyBj YXBhYmlsaXRpZXMgYmVjb21lczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyBtYWluc3RyZWFtIGFuZCB3aWxsIHNvb24gYmUgYSByZWFsIHdvcmxkIHJlYWxpdHkgYW5kIGFz IGZpeGVkIDVHPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGJyb2FkYmFu ZCBwcm9saWZlcmF0aW9uIHRha2VzIG9mZiBhbmQgbW9iaWxlIDVHID09IHRoZSBpZGVhIG9mIGE8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgd2VhcmFibGUgLzQ4IHdpbGwg cmVhbGx5IGJlIG1hbnkgLzQ4cy48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgQXMgdGhpcyBwYXJhZGln bSBzaGlmdCB0YWtlcyBwbGFjZSwgb3BlcmF0b3JzIGFyb3VuZCB0aGUgd29ybGQ8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7d2lsbCBiZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyBjbGFtb3JpbmcgYWZ0ZXIgdGhlIFJJUiBmb3IgbWFzc2l2ZSBibG9ja3Ms IEkgd291bGQgc2F5IGxlc3MgdGhhbiAvODxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyBtb3JlIGxpa2UgYSAvNSBvciAvNC4mbmJzcDsgSWYgeW91IGRvIHRoZSBtYXRoIG9u IHRoZSB3YXkgaGlnaCBzaWRlIGEgLzEwPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IHlpZWxkcyA3IGJpdHMgc28gMTI4IGRpdmlkZWQgYnkgNSBSSVJzIHlpZWxkcyAyNCBJ U1BzIHBlciBSSVI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7d2hpY2ggaXM8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgdGlueSBudW1iZXIgd2l0aCB0aGUg bnVtYmVyIG9mIGxhcmdlIHNpemUgb3BlcmF0b3JzIHdvcmxkd2lkZS48YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsgV2l0aCB0aGUgbWFzc2l2ZSBwcm9saWZlcmF0aW9uIG9mIElPVCBkZXZpY2VzIGFuZCBq dXN0IGFib3V0PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2V2ZXJ5IGhvbWU8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgb3Igb2ZmaWNlIGFwcGxpYW5jZSBv biA1RywgdGhlIHByb2JsZW0gbm93IGdldHMgd2F5IGV4YWNlcmJhdGVkLjxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyBBcyB0aGlzIGV2b2x1dGlvbiB1bmZvbGRzIElBTkEgd2lsbCBiZSBzY3JhbWJsaW5n IHRvIHJlbGVhc2UgYWxsPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IHJl bWFpbmluZyAvMyBhcyB3ZWxsIGFzIGFsbCB1bmFsbG9jYXRlZCBibG9ja3MgdG8gc3VidmVydCBS SVIgSVB2Njxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBhZGRyZXNzIHNw YWNlIGRlcGxldGlvbi48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgUGxheWluZyBNb25kYXkgbmlnaHQg cXVhcnRlcmJhY2tpbmcgaW4gaGluZHNpZ2h0IHdlIHdvdWxkIG5ldmVyPGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO3RoaW5rPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IHRoaXMgd291bGQgaGFwcGVuIGluIGEgbWlsbGlvbiB5ZWFycywgYnV0IHdlIHdvdWxk IHNlZSBJUHY2IG9uPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSB2ZXJnZTxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBvZiBhZGRyZXNzIHNwYWNlIGRl cGxldGlvbi4mbmJzcDsgVW5oZWFyZCBvZiBidXQgaXQgY2FuIGhhcHBlbiBhcyB0aGU8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c2F5aW5nPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IGdvZXMg4oCcd2hlbiB5b3UgYnVpbGQgLSB0aGV5IHdpbGwgY29tZeKA nS48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgSXQgaXMgdHJ1ZSBhcyBoaXN0b3J5IGhhcyB0YXVnaHQg dGhhdCB2ZXJ5IGltcG9ydGFudCBsZXNzb24uPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZSBhbnN3 ZXIgdG8gdGhpcyByZWFsIHdvcmxkIHByb2JsZW0gaXMgaW4gdGhlIHN1YmplY3QgaGVhZGluZzxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvZiB0aGlzPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IHRocmVhZC48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgVGhpcyB3 b3VsZCBhbHNvIGZpeCB0aGUgZGF5IDEgaXNzdWUgSSBtZW50aW9uZWQgYWxsb3dpbmcgbWl4IG9m PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3NsYWFjPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGRldmljZXMgd2l0aCBzdGF0aWMgYW5kIERIQ1B2NiB1cCB0 byAvODAuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZSB2YXJpYWJsZSBzbGFhYyBzb2x1dGlvbiBk cmFmdCBwcm9wb3NlcyBhIG5ldyAmbmJzcDtSQSBQSU8gZmxhZzxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDt0aGF0IHdvdWxkPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IGJlIHVzZWQgdG8gc2lnbmFsIGxvbmdlciBwcmVmaXhlcywgYW5kIHdvdWxkIHByb3Zp ZGUgYmFja3dhcmRzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGNvbXBh dGliaWxpdHkgc28gdGhhdCBkZXZpY2VzIG5vdCBzdXBwb3J0aW5nIHdvdWQgaWdub3JlIHRoZSBm bGFnPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbmQ8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgZGV2aWNlcyBvbiBuZXdlciBjb2RlIHN1cHBv cnRpbmcgd291bGQgdXNlIHRoZSBmbGFnLiZuYnNwOyBXZSBkZWZpbml0ZWx5PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGRvbuKAmXQgd2FudCB0byBpbXBhY3QgYW55IGV4 aXN0aW5nIGRldmljZXMgb24gdGhlIGV4aXN0aW5nIDY0IGJpdDxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtzbGFhYzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyBib3VuZGFyeSBzdGFuZGFyZC48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgRG15dHJvIGhhcyB0ZXN0 ZWQgdGhlIHNvbHV0aW9uIG9uIExpbnV4IGtlcm5lbCBzaWduYWxpbmcgUkEgUElPPGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZsYWcgYW5kPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IHdhcyBhYmxlIHRvIHN1Y2Nlc3NmdWxseSB0ZXN0IGFueSBsZW5ndGgg bWFzayBhbmQgcmFuZG9tIElJRDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtnZW5l cmF0aW9uPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGJvdGggUkZDIDQ5 NDEgcHJpdmFjeSBleHRlbnNpb24gYXMgd2VsbCBhcyBzdGFibGUgSUlEIFJGQyA3MjE3Ljxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXNocmEtNm1hbi12YXJp YWJsZS1zbGFhYy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1taXNocmEtNm1hbi12YXJpYWJsZS1zbGFhYy88L2E+PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1taXNocmEtNm1hbi12YXJpYWJsZS1zbGFhYy8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1taXNocmEtNm1hbi12YXJp YWJsZS1zbGFhYy88L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlzaHJhLTZtYW4tdmFyaWFibGUtc2xhYWMv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bWlzaHJhLTZtYW4tdmFyaWFibGUtc2xhYWMvPC9hPjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbWlzaHJhLTZtYW4tdmFyaWFibGUtc2xhYWMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlzaHJhLTZtYW4tdmFyaWFibGUtc2xhYWMv PC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IElmIGV2ZXJ5b25lIGlzIGluIGFncmVl bWVudCB3aXRoIHdoYXQgSSBoYXZlIHN0YXRlZCBvbiB0aGlzPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO3RocmVhZCwgSTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyB3b3VsZCBsaWtlIHRvIGFzayB0aGUgY2hhaXJzIGZvciBXRyBhZG9wdGlvbiBhcyB0aGlz IGlzIGEgV0cgZWZmb3J0Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBJIHdvdWxkIGxpa2UgdG8gZ2Fy bmVyIHN1cHBvcnQgZnJvbSBhbGwgNk1BTiBtZW1iZXJzIHdpdGggZnVsbDxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb25zZW5zdXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsgdG8gY2hhbmdlIHRoZSBleGlzdGluZyBSRkMgNDk0MSAvNjQgZml4ZWQgYm91 bmRhcnkgdG8gLzgwIGZpeGVkPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2JvdW5k YXJ5Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBLaW5kIFJlZ2FyZHM8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgR3lhbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBPbiBUaHUsIE5vdiAxOSwgMjAyMCBhdCA1OjE0 IFBNIEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBl cm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t IiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0OyZndDsgd3Jv dGU6PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIGFtIG1pc3Npbmcg c29tZXRoaW5nIGluIHlvdXIgcmVhc29uaW5nLjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7WW91IHNlZW0gdG8gc2F5IGF0IG9uZSBwb2lu dCB0aGF0ICh0byBwYXJhcGhyYXNlKSAmcXVvdDt3ZSBjYW4ndDxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtkbyB0aGlzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtiZWNhdXNlIGl0IGRvZXMgbm90IHdvcmsgd2l0aCB0aGUg ZXhpc3RpbmcgVUUgc29mdHdhcmUmcXVvdDsuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtBbnkgbmV3IHNvbHV0aW9uIHdoZXJlIGEgVUUg ZGVsZWdhdGVzIGJhc2VkIG9uIGFueSBjaGFuZ2Ugb2Y8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7YW55IGtpbmQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyhpbmNsdWRpbmcgbGVuZ3RoZW5pbmcgdGhlIHByZWZpeCwgc2hv cnRlbmluZyB0aGUgcHJlZml4LCBvcjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtt YWdpY2FsbHk8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO2luY2FudGluZyBuZXcgcHJlZml4ZXMpIHJlcXVpcmVzIHRoYXQgdGhlIFVFIGJl IHVwZ3JhZGVkIHRvIGtub3c8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO3doYXQgdG88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2RvIHdpdGggdGhlIGluZm9ybWF0aW9uLiZuYnNw OyBJIGRvIG5vdCBzZWUgaG93IHRoYXQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ZGlmZmVyZW50aWF0ZXMgYW55IG9mPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgc29sdXRpb25zLiAoRXhjZXB0ICZxdW90O2Rvbid0 IGRvIGFueXRoaW5nJnF1b3Q7LCB3aGljaCBJIHRoaW5rIHdlPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO2RvIG5vdDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7d2FudDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dG8gdGFrZS4pPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtZb3Vycyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0pvZWw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO09uIDExLzE5LzIwMjAgNTowMyBQTSwgR3lhbiBNaXNocmEgd3JvdGU6 PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIFRodSwgTm92IDE5LCAyMDIwIGF0IDEwOjMzIEFNICZs dDs8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciIHRhcmdldD0iX2JsYW5rIj5v dHJvYW5AZW1wbG95ZWVzLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciIHRhcmdldD0i X2JsYW5rIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm90cm9hbkBlbXBs b3llZXMub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVz Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm90cm9hbkBlbXBsb3llZXMub3JnPC9hPiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm90cm9hbkBlbXBsb3llZXMub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm90cm9hbkBlbXBs b3llZXMub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciIHRhcmdldD0iX2JsYW5r Ij5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86b3Ry b2FuQGVtcGxveWVlcy5vcmciIHRhcmdldD0iX2JsYW5rIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwv YT4mZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIDE5IE5vdiAyMDIwLCBhdCAxNDo1OCwgR3lhbiBNaXNo cmE8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDs8YSBocmVmPSJtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5oYXlhYnVzYWdzbUBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5o YXlhYnVzYWdzbUBnbWFpbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmhheWFi dXNhZ3NtQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhheWFidXNhZ3NtQGdtYWlsLmNvbTwv YT4mZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhheWFidXNhZ3Nt QGdtYWlsLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmhheWFidXNhZ3NtQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhheWFidXNhZ3NtQGdtYWls LmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aGF5YWJ1 c2Fnc21AZ21haWwuY29tPC9hPiZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBZb3Ugd291 bGQgbmVlZCBhIG5ldyBvcHRpb24uIEl0IHdvdWxkIGxpa2VseSBiZTxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDt1c2VmdWwgZm9yIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O3JlcXVlc3Rpbmcgcm91dGVyIHRvIGluZGljYXRlIGludGVyZXN0IGluIHRoZSBvcHRpb24uIEV2 ZW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO2hpbnRpbmc8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDthdCB3aGF0IHByZWZpeCBzaXpl IGl0IHdhcyBleHBlY3RpbmcuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgTm93IGNh biB5b3UgZXhwbGFpbiB0byBtZSBhZ2FpbiB0aGUgcmVhc29ucyB3aHkgdGhpczxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YXBwcm9hY2gg aXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtiZXR0ZXIgdGhhbiB1c2luZyB0aGUgZXhpc3Rp bmcgREhQQ3Y2IHByb3RvY29sIHBhY2tldHM/PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7M0dQ UCBnYXRld2F5IGRvZXMgbm90IHN1cHBvcnQgREhDUHY2PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOzNHUFAgZ2F0ZXdheSBkb2Vzbid0IHN1cHBvcnQgbmV3IG9wdGlvbi4gV2hhdCdz IHlvdXI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7cG9pbnQ/PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBwb2ludCBvZiB0aGUgdjZv cHMgcHJlc2VudGF0aW9uIGFuZCB0aGlzIGVtYWlsPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO3RocmVhZCBpczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7aG93IHRvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyDigJxleHRlbmQgYSAvNjTigJ0gaW4gdGhl IDNHUFAgdXNlIGNhc2UgJm5ic3A7aW4gc2xpZGUgMSBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ZGVjayB5b3U8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbXBpbGVkPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBhIGxpc3Qgb2Ygb3B0aW9u cyBhbmQgb2YgdGhlIHR3byBJIGhhZCBoaWdobGlnaHRlZCBpbiByZWQ8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7d2VyZSB0aGU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IDY0c2hhcmUgdjIgQ2FtZXJvbuKAmXMg b3B0aW9uIGFuZCB0aGUgdmFyaWFibGUgc2xhYWM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7b3B0aW9uLiZuYnNwOyBTbyBvbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBjYWxsIHRoaXMgbW9ybmluZyBM b3JlbnpvIHNob3QgZG93biA2NHNoYXJlIHYyIHNob3J0ZXIgcHJlZml4PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvcHRpb24gYXM8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7IGV2ZW4gaWYgdGhlIDNHUFAgYXJjaGl0ZWN0dXJlIHdhcyB1cGRhdGVkIHRvIHN1cHBvcnQg bG9uZ2VyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDtwcmVmaXhlcyBhbmQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGV2ZW4gaXMgdGhlIDNHUFAgZ2F0ZXdheSB3YXMg YWJsZSB0byBzZW5kIGEgc2hvcnRlciBwcmVmaXg8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7d2l0aCBBPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtmbGFnPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBub3Qgc2V0LCBhbGwgbW9iaWxlIGRldmljZXMgcGVy IExvcmVuem/igJlzIHBvaW50IHdvdWxkIGJlPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO2Jyb2tlbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7YXMgdGhleTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgd291bGQgbm90IGFjY2VwdCB0aGUgc2hvcnRlciBs ZXTigJlzIHNheSAvNTYgcHJlZml4IHRvIGJ1aWxkIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c2xhYWMgMTI4PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBiaXQg YWRkcmVzcy4mbmJzcDsgU28gdGhlIGJvdHRvbSBsaW5lIGlzIHRoZSA2NHNoYXJlIHYyIHdvbuKA mXQgd29yazxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7dW5sZXNzIHdlPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyB1cGRhdGUgUkZDIDQyOTEgYW5kIHJlbW92ZSB0aGUg NjQgYml0IGJvdW5kYXJ5Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO1NvIHdlIGFyZSBiYWNr IHRvIHNxdWFyZSB1bm8gLSBubyB2aWFibGUgc29sdXRpb248YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDtTbyBub3cgd2UgaGFkIHRocm93biBvdXQgdGhlIGxvbmdlciAmZ3Q7NjQgZHVlIHRvIHJh Y2UgdG88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Ym90dG9tPGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt3b3JyaWVzPGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyB3aGljaCBJIGFuZCBvdGhlcnMgYmVsaWV2ZSBpcyBGdWQgYW5kIGFzIGRlc2NyaWJlZCBp bjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzbGlkZSAxMCBvZjxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlPGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyB2Nm9wcyDigJxyYWNlIHRvIHRoZSBib3R0b20gc2xpZGXigJ0uPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgU28g YSBoYXBweSBtZWRpdW0gLzgwIGZpeGVkIGJvdW5kYXJ5IEkgY2FtZSB1cCB3aXRoIHRoYXQgSTxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0aGluazxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c29sdmVzPGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBhIGxv dCBvZiB0aGUgaXNzdWUgYW5kIG5vdCBqdXN0IHRoZSAzR1BQIGluaXRpYWw8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7c2VnbWVudGF0aW9uIG9mPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBkb3duc3RyZWFtIGRl dmljZXMgcHJvYmxlbSBzdGF0ZW1lbnQuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgU2luY2Ugd2UgaGF2ZSB0byB1 cGRhdGUgUkZDIDQyOTEgZm9yIDY0c2hhcmUgdjIgdG8gd29yazxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDthbnl3YXlzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0byBhbGxvdzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgZm9yIHNob3J0ZXIgcHJlZml4 ZXMsIHdoeSBub3QgaW5zdGVhZCBjcmVhdGUgYSBuZXcgYm90dG9tPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO2F0IC84MDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Z2l2aW5nPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAxNiBiaXRzIG1vcmUgb2YgcHJl Zml4IGxlbmd0aCBhbmQgc2hyaW5raW5nIHRoZSBJSUQgZG93bjxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDt0byA0OCBiaXRzLjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgRG9pbmcgc28geW91IHdvdWxkIG5vdCBl dmVuIGhhdmUgdG8gdXBkYXRlIHRoZSAzR1BQPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO2FyY2hpdGVjdHVyZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7YXMgSTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgZG9u4oCZdCBrbm93IGlmIHRoYXQgd291bGQg Zmx5IG9yIG5vdC4mbmJzcDsgQWxzbyB0aGlzIHNvbHZlcyBhPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO2ZldyBvdGhlcjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgcHJvYmxlbXMgYXQgdGhlIHNhbWUgdGltZS48 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDsgQXMgSSBtZW50aW9uZWQgaW4gdGhlIHY2b3BzIGRlY2sgcHJl c2VudGVkIHRoYXQgdmxzbSAwIHRvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOzEy OCBpczxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsgbWFpbnN0cmVhbSBmb3Igb3BlcmF0b3JzIGZvciBzdGF0aWMgYWRkcmVzc2lu ZyBvbiByb3V0ZXI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kIHN3aXRjaDxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsgaW5mcmFzdHJ1Y3R1cmUgYW5kIGRoY3B2NiBzdWJuZXRzIGxvbmdlciBwcmVmaXhlcyBm b3IgbmV0d29yazxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsgaW5mcmFzdHJ1Y3R1cmUgYXBwbGlhbmNlIGNsdXN0ZXJzLCBORlYv Vk5GIHZpcnR1YWxpemF0aW9uPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FuZCBz ZXJ2ZXI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7IGZhcm1zLiZuYnNwOyBPbiBob3N0IHN1Ym5ldHMgd2hlcmUgdGhlcmUgaXMg YSBjaGFuY2Ugb2YgbWl4IG9mPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3NsYWFj PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDtob3N0czxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsgd2l0aCBkaGNwdjYgJm5ic3A7ZGV2aWNlcyB0aGUgcHJlZml4IGxlbmd0 aCBpcyBzdHVjayBhdCAvNjQuJm5ic3A7IFNvIG9uPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0aGVzZSBtaXg8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGFkZHJlc3Np bmcgaG9zdCBzdWJuZXRzIHdlIGNhbm5vdCBkbyBsb25nZXIgcHJlZml4ZXMgZm9sbG93aW5nPGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtv dXIgTkQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7IGNhY2hlIGhhcmQgbGltaXQgbWFudHJhIHRvIHByZXZlbnQgTkQgY2FjaGUg ZXhoYXVzdGlvbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtpc3N1ZXMgYXM8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7IGRlc2NyaWJlZCBpbiBSRkMgNjE2NC48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBTbyB3aXRoIHRoZSAvODAg bmV3IGZpeGVkIGJvdW5kYXJ5IHNoaWZ0aW5nIHByZWZpeCBsZW5ndGg8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7MTYgYml0czxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bG9uZ2VyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBhbmQgc2hvcnRlbmluZyB0 aGUgSUlEIGJ5IDE2IGJpdHMgZ2l2ZXMgcmVzb2x2ZWQgdGhlIDNHUFA8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7aXNzdWU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3doaWNoPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyA2NHNoYXJlIGNhbiB3b3JrIGFz IGlzIGFuZCBzdWJ0ZW5kaW5nIHRvIGRvd25zdHJlYW08YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ZGV2aWNlcyB3aWxsIG5vdzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgd29yayBhcyBhIC82NCBpcyBub3cgZXF1 aXZhbGVudCB0byBhIC80OCB3aXRoIDY0ayAvODBzLiZuYnNwOyBBbHNvPGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtCQ1AtNjkwPGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyBmb3IgYnJvYWRiYW5kIG5vdCBhbGwgb3BlcmF0b3JzIGhhdmUgYWRvcHRlZCB0aGUgc2hvcnRl cjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtwcmVmaXg8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2xlbmd0aHM8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 IC81NiBvciAvNDggcmVjb21tZW5kYXRpb25zICZuYnNwO2FuZCBub3cgdGhhdOKAmXMgbm90IGFu IGlzc3VlIGFzIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7LzY0IHdvdWxkPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBub3cgc3VmZmljZS48YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyBGcm9tIGFuIG9wZXJhdG9ycyBwZXJzcGVjdGl2ZSB0aGF0IGdhaW4gYWxsb3dzIGF0 IGxlYXN0PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZvciAzR1BQPGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBt YXNzaXZlIGdyb3d0aCBhbmQgc3VidGVuZGluZyB3aXRoIGEgc2luZ2xlIC82NCBhbGxvd3MgdGhl PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO29wZXJhdG9yczxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgc3VjaCBh cyBWZXJpem9uIHdpdGggbWFzc2l2ZSBzdWJzY3JpYmVyIGJhc2Ugd29ybGR3aWRlIGNhbjxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzdGF5IHdpdGg8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGN1cnJlbnQgYWxs b2NhdGlvbnMgYW5kIGRvbuKAmXQgaGF2ZSB0byBhc2s8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gv ZW50JiM0MzthbGxvY2F0aW9ucyYjNDM7YW5kJiM0Mztkb24lRTIlODAlOTl0JiM0MztoYXZlJiM0 Mzt0byYjNDM7YXNrP2VudHJ5PWdtYWlsJmFtcDtzb3VyY2U9ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvZW50JiM0MzthbGxvY2F0aW9ucyYjNDM7 YW5kJiM0Mztkb24lRTIlODAlOTl0JiM0MztoYXZlJiM0Mzt0byYjNDM7YXNrP2VudHJ5PWdtYWls JmFtcDtzb3VyY2U9ZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Zv ciAvMTAuPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDsgQXMgNUcgZ2V0cyByb2xsZWQgb3V0IHdpdGggRW5oYW5jZWQg VlBOIGZyYW1ld29yayBhbmQgTmV0d29yazxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c2xpY2luZzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgcGFyYWRpZ20sIHRoZSBk ZW1hbmQgZm9yIHNob3J0ZXIgYmxvY2tzIGFuZCB3ZWFyYWJsZTxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDttdWx0aXBsZSAvNDg8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3dpbGw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGJlIG91ciBuZXcgcmVhbGl0 eS48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyBNYWtpbmcgdGhhdCAxNiBiaXQgc2hpZnQgbm93IHRvIC84MCBtYWtp bmcgYSAvNjQgdGhlIG5ldzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsvNDggd2ls bDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7Z2l2ZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsgYnJvYWRiYW5kIGFuZCAzR1BQIHN1YnNjcmliZXJzIGEgdG9uIG9mIHNw YWNlIHRvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3N1YnRlbmRpbmcgdGhlaXI8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7IG5ldHdvcmtzIHdlIHdvdWxkIGJlIHNldCBmb3IgdGhlIGZ1dHVyZS4mbmJzcDsgRXNw ZWNpYWxseSB3aXRoPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0lPVCB0aGU8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Rl bWFuZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsgZm9yIHN1YnRlbmRpbmcgd2lsbCBjb250aW51ZSB0byBncm93IGFzdHJvbm9t aWNhbGx5Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IEFsc28gSUFOQSBkb2VzIG5vdCBoYXZlIHRvIGdldCBzdGFy dCBpbiBhbGxvY2F0aW5nIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvdGhl ciAvMyBhbmQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IG90aGVyIGF2YWlsYWJsZSBibG9ja3MuPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgTG90 cyBvZiBwcm9ibGVtcyBiZWluZyBzb2x2ZWQgaGVyZSB3aXRoIGEgZml4ZWQgLzgwIG5ldzxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtib3VuZGFyeS48YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBBbHNv IHdpdGggdGhlIGV4aXN0aW5nIHJhbmRvbSBJSUQgZ2VuZXJhdGlvbiBzY2hlbWVzIHdoaWNoPGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3dlIGhhdmU8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IHRlc3RlZCBvbiBM aW51eCBrZXJuZWwgY2FuIGRvIGxvbmdlciBwPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvdGVz dGVkJiM0MztvbiYjNDM7TGludXgmIzQzO2tlcm5lbCYjNDM7Y2FuJiM0MztkbyYjNDM7bG9uZ2Vy JiM0MztwP2VudHJ5PWdtYWlsJmFtcDtzb3VyY2U9ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvdGVzdGVkJiM0MztvbiYjNDM7TGludXgmIzQzO2tl cm5lbCYjNDM7Y2FuJiM0MztkbyYjNDM7bG9uZ2VyJiM0MztwP2VudHJ5PWdtYWlsJmFtcDtzb3Vy Y2U9ZzwvYT4gJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gv dGVzdGVkJiM0MztvbiYjNDM7TGludXgmIzQzO2tlcm5lbCYjNDM7Y2FuJiM0MztkbyYjNDM7bG9u Z2VyJiM0MztwP2VudHJ5PWdtYWlsJmFtcDtzb3VyY2U9ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvdGVzdGVkJiM0MztvbiYjNDM7TGludXgmIzQz O2tlcm5lbCYjNDM7Y2FuJiM0MztkbyYjNDM7bG9uZ2VyJiM0MztwP2VudHJ5PWdtYWlsJmFtcDtz b3VyY2U9ZzwvYT4mZ3Q7Jmd0O3JlZml4ZXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3VzaW5nIFJGQyA0OTQxIHByaXZhY3k8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 IGV4dGVuc2lvbiBvciBSRkMgNzIxNyBzdGFibGUgSUlELjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFdpbi1XaW4g Zm9yIGFsbC48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7T2xlPGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgLS08YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy52ZXJpem9uLmNvbS8i IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnZlcml6b24uY29tLzwvYT4gJmx0OzxhIGhyZWY9 Imh0dHA6Ly93d3cudmVyaXpvbi5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy52ZXJp em9uLmNvbS88L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEg aHJlZj0iaHR0cDovL3d3dy52ZXJpem9uLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3 LnZlcml6b24uY29tLzwvYT4gJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20vIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy52ZXJpem9uLmNvbS88L2E+Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsgKkd5YW4gTWlzaHJhKjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IC9OZXR3b3JrIFNvbHV0aW9u cyBBLy9yY2hpdGVjdCAvPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgL00gMzAxIDUwMi0xMzQ3PGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAxMzEw MSBDb2x1bWJpYSBQaWtlPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvU2lsdmVyIFNwcmluZywgTUQ8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGll dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0Bp ZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyAtLTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cDov L3d3dy52ZXJpem9uLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnZlcml6b24uY29t LzwvYT4gJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3d3dy52ZXJpem9uLmNvbS88L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgKkd5YW4gTWlzaHJhKjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvTmV0d29yayBTb2x1dGlvbnMg QS8vcmNoaXRlY3QgLzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvTSAzMDEgNTAyLTEzNDc8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgMTMxMDEgQ29sdW1iaWEgUGlrZTxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAvU2lsdmVyIFNwcmluZywgTUQ8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tIDxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20v IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy52ZXJpem9uLmNvbS88L2E+Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgKkd5YW4gTWlzaHJhKjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgL05ldHdvcmsgU29sdXRpb25zIEEvL3JjaGl0ZWN0IC88YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IC9NIDMwMSA1MDItMTM0Nzxicj4NCiZndDsmZ3Q7IDEzMTAxIENvbHVtYmlhIFBp a2U8YnI+DQomZ3Q7Jmd0OyAvU2lsdmVyIFNwcmluZywgTUQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KJmd0OyA8YnI+DQo8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzppcHY2QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48 YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9d13e7549f844e14b3be8661aee3e516huaweicom_-- From nobody Mon Nov 23 04:10:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635BA3A0994 for ; Mon, 23 Nov 2020 04:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyoqk4KO8Kz7 for ; Mon, 23 Nov 2020 04:10:38 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 AD9D73A09A8 for ; Mon, 23 Nov 2020 04:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1606133437; x=1637669437; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=DotajoNrA5/aaT7KD6LkT6SWkhyhLKlG44yDXz7wj9k=; b=FRl7pHweLpDVjYd/kJSBSZStZ24EJUW+x0wku56X2Zmj34dYguolpP8E aDusUe9Lf27WOsXS0fTCAJSdpKZYp1ooMJKxIxdNcaByIHWM2wBMKCcgr P7SOs3uKbQ6nMbUT1GTZkhcv9nfJkMHux5MAVcFOedFYjmEymUF2Dj/kS t+y7nFNn7CftP8EgxP+2YdIIQ/8045I+CibjGsBAARaWcxOttuCbrphY4 J1PkCegdrQV8VBOMimUHpTKwxuhc2NEYNvLOYggupATAdfy/1CjDuKEyU ak2DcG2FulNVv+ZK7+yEXg/zDyGeGgwcsLLQZr2WYQIDi5o8QSu+pQF9E w==; IronPort-SDR: +mCT1SPA0ER4OSGqeeVQX462Euei4WfbDLugoM2yawaLWWClztX7hCB8giNkLIoUDxDcgBw29w XZCJEKRep8Rla8k/d6G8uoUd272lvtmfHKIPQiDcSW7h2sfKR3nEEq6ZEi6IEXZrOlNiU6/SEw 37Mlnb2xrfuWjzRoUBJSYUkvboD1614/bNkvbEZKaoDYdI/9N8EbPYFl3Wn0qPSoFP7ZIkdrQL N7b3E+Lf1XiaWnNCunVd79ry/FnZRW1W4JaRZEH+rI8EJeeOKc38pLELzO8rrxtAN2i7aAO++5 Q94= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2020 13:10:34 +0100 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E451842A4A for ; Mon, 23 Nov 2020 13:10:33 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id ACA9E427F5; Mon, 23 Nov 2020 13:10:33 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id A57D511145; Mon, 23 Nov 2020 13:10:33 +0100 (CET) Date: Mon, 23 Nov 2020 13:10:33 +0100 From: Gert Doering To: Gyan Mishra Cc: Bob Hinden , IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ Message-ID: <20201123121033.GD13005@Space.Net> References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <92CD1CEE-4453-4739-8418-34D20F350244@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 12:10:40 -0000 Hi, On Mon, Nov 23, 2020 at 01:58:33AM -0500, Gyan Mishra wrote: > Gyan> One possible non technical factor is that Android which as of > 2019 statistical data below holds 87% of the global mobile market share and > Apple 13% and Android is continuing to climb in 2020. Android adamantly > refuses to change its position on support of DHCPv6. I think that really > shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all > mobile handsets won???t support it. Lorenzo is the man to talk to, what "The Android Camp" thinks is the way forward... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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 Mon Nov 23 04:24:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603D23A09E9; Mon, 23 Nov 2020 04:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2a6Aao9PaUh; Mon, 23 Nov 2020 04:24:46 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 669573A09E5; Mon, 23 Nov 2020 04:24:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C2547B3; Mon, 23 Nov 2020 13:24:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1606134283; bh=nhc7tYUPtfukyW2dL9N2St8V04GQwkiVQz1LFVeCfc8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yxD2v9b5H0Jsl53Gzrs+JZNNVamHl2J0b1iurkXbPZKipZtCn/PJmqnKXDnSx8pbc QEnz10xANFIN1bh/1M7kvuAEgSclVdVkXAtrDLuS5+YUEusQNiKm3PAEAxUEgJiuYU ZJOUJtM0T86sPHh5/ROzVYcPLP2Qm1hsd980lsTc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BE7E7B0; Mon, 23 Nov 2020 13:24:43 +0100 (CET) Date: Mon, 23 Nov 2020 13:24:43 +0100 (CET) From: Mikael Abrahamsson To: Gyan Mishra cc: 6MAN <6man@ietf.org>, IPv6 Operations , "draft-mishra-6man-variable-slaac@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1662771661-1606134283=:26384" Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 12:24:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1662771661-1606134283=:26384 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 23 Nov 2020, Gyan Mishra wrote: > How do we propose to solve this problem if operators don’t support PD even > though the 3GPP standard has supported PD for over 10 years. > > Another twist to this puzzle is Android has 90% of the mobile handset > marketplace worldwide and adamantly states they will NOT support DHCPv6 or > PD. > > I researched Apple which has 10% of the market and they also do not support > PD. > > Whats the solution now? The obvious use-case for PD is the "LTE router" fixed-wireless use-case. There the problem of getting a DHCPv6-PD client into the UE isn't the same as on handsets. A lot of those platforms already support DHCPv6-PD for their wired versions (some have both LTE and wired WAN). So this brings us back to the mobile core. Why doesn't this today, 8 years after DHCPv6-PD was introduced in 3GPP standards, still not support PD? I don't know but I know staff at operators who claim to have tried (more than 5 years ago). I do not know why their efforts failed. Perhaps the mobile core vendors successfully managed to divide the customer base so there was no critical mass. I can only speculate. I just find it weird that there are now demands to change *everything* downstream from the 3GPP bearer to handle smaller subnets instead of enabling PD in mobile core. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1662771661-1606134283=:26384-- From nobody Mon Nov 23 08:24:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBC3A098A; Mon, 23 Nov 2020 08:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omYq1aOLmvx8; Mon, 23 Nov 2020 08:24:37 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 5D9CE3A0989; Mon, 23 Nov 2020 08:24:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0ANGOWZX007131; Mon, 23 Nov 2020 11:24:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606148674; bh=Uv47T3t/4XIhtm/GgOx0hRIwhZckvZRlUnvbDwr2iZ0=; h=From:To:CC:Subject:Date:From; b=NO7u9Y+FY1C0EAttivy1F5aBZ6L/sKQjD6ZCZS5qTglLv3sJt+V1Dlm7OVUkxB7Ht 5ymf0Q2SYbopOpC2IlxsW03tkCPZM0uaqcuhHl+Ub/1rKrhrhaCrlmtqaefXiDse7h 0g0ZIqUt0zj8nYkFkS2mPRB/mG1fZBwvH2Cu3btaqvFLMQlgIyailxTuxResCPs3wE EKAPTxKN6ud2+AynhunlHxAs9kem3ZsTh6KDgF/xiuLuxNHZXmImPw7x77omBf0KfB ReYqH/OOW7P54m5fVEGoNrD23WADbPMtx5H0hMoOUVAmFErPmeTxYii8dFVdM2Z1G4 Z4pwGOedgMf6A== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0ANGOKNO006986 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 23 Nov 2020 11:24:20 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 23 Nov 2020 08:24:18 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 23 Nov 2020 08:24:18 -0800 From: "Templin (US), Fred L" To: Mark Smith CC: Ca By , Brian E Carpenter , IPv6 Operations , 6MAN <6man@ietf.org> Thread-Topic: [v6ops] Next step? [Re: The bottom is /112] Thread-Index: AdbBs7DABd4VOkfZTvWrxcKqAP+vAg== Date: Mon, 23 Nov 2020 16:24:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 847C8425E398F9A135BC47C9001614344AF737243A057B537A43C4A55C8D2BA32000:8 Content-Type: multipart/alternative; boundary="_000_fe44a5687f864e24a10f917fa9015156boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 16:24:39 -0000 --_000_fe44a5687f864e24a10f917fa9015156boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaywgbXkgaW5pdGlhbCBkZXNjcmlwdGlvbiB3YXMgcHVycG9zZWZ1bGx5IGxpZ2h0IG9uIGRl dGFpbHMgYnV0IHRvIGdldCB0aGUgZnVsbCBwaWN0dXJlDQp5b3UgY2FuIGhhdmUgYSBsb29rIGF0 IHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXRlbXBsaW4tNm1hbi1sbGEtdHlwZS8NCg0KVGhlIGlkZWEgZm9yIHRoaXMgTExBLWJh c2VkIFBEIHNjaGVtZSBpcyBhcyBmb2xsb3dzOg0KDQoxKSBUaGUgcmVxdWVzdGluZyByb3V0ZXIg Y3JlYXRlcyBhIHRlbXBvcmFyeSBMTEEgdXNpbmcgUkZDNDk0MShiaXMpIGFuZCBzZXRzIGEgcHJl Zml4IGxlbmd0aA0KaW5kaWNhdGlvbiBpbnNpZGUgdGhlIExMQSBpdHNlbGYuIFRoZSBSUiB0aGVu IHVzZXMgdGhlIExMQSBhcyB0aGUgSVB2NiBzb3VyY2UgYWRkcmVzcyBvZiBhbiBSUw0KbWVzc2Fn ZSB0byBzZW5kIHRvIHRoZSBkZWxlZ2F0aW5nIHJvdXRlci4NCg0KMikgV2hlbiB0aGUgZGVsZWdh dGluZyByb3V0ZXIgcmVjZWl2ZXMgdGhlIFJTLCBpdCBzZWVzIHRoYXQgdGhlIElQdjYgc291cmNl IGlzIGFuIFJGQzQ5NDEoYmlzKQ0KYWRkcmVzcyB3aXRoIGEgbm9uLXplcm8gcHJlZml4IGxlbmd0 aCBpbmRpY2F0aW9uLiBUaGUgRFIgdGhlbiBjb29yZGluYXRlcyB3aXRoIHRoZSBESENQdjYNCnNl cnZlciB0byByZXF1ZXN0IGEgUEQgb2YgdGhlIGxlbmd0aCBpbmRpY2F0ZWQgYnkgdGhlIFJSLg0K DQozKSBXaGVuIHRoZSBEUiByZWNlaXZlcyB0aGUgUEQgZnJvbSB0aGUgREhDUHY2IHNlcnZlciwg aXQgY3JlYXRlcyBhbiBPTU5JIExMQSBieQ0KZW1iZWRkaW5nIHRoZSBkZWxlZ2F0ZWQgcHJlZml4 IGluIHRoZSBJSUQgb2YgZmU4MDo6LzY0LCBlLmcuLCBhcyBmZTgwOjoyMDAxOmRiODoxOjIuDQpU aGUgRFIgdGhlbiBzZXRzIGEgcHJlZml4IGxlbmd0aCBpbmRpY2F0aW9uIGluIHRoZSBPTU5JIExM QSwgYW5kIHNldHMgdGhlIExMQSBhcyB0aGUNCmRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgYW4gUkEg bWVzc2FnZSB0byBzZW5kIGJhY2sgdG8gdGhlIFJSLg0KDQo0KSBXaGVuIHRoZSBSUiByZWNlaXZl cyB0aGUgUkEgbWVzc2FnZSwgaXQgc2VlcyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBpcyBhbiBPTU5J IExMQQ0Kd2l0aCBhIG5vbi16ZXJvIHByZWZpeCBsZW5ndGguIFRoZSBSUiB0aGVuIHVzZXMgdGhl IGVtYmVkZGVkIHByZWZpeCB3aXRoaW4gdGhlIE9NTkkNCkxMQSBhcyBpdHMgZGVsZWdhdGVkIHBy ZWZpeCwgYW5kIHJlZ2FyZHMgdGhlIFJvdXRlciBMaWZldGltZSBhcyB0aGUgdGltZSBhdCB3aGlj aCB0aGUNCmRlbGVnYXRlZCBwcmVmaXggbmVlZHMgdG8gYmUgcmVuZXdlZC4NCg0KWW91IGFsc28g YXNrZWQgYWJvdXQgdGhlIGxvbmctbGl2ZWQgdXNhZ2Ugb2YgdW5pcXVlIExMQXMsIGFuZCBJIHRo aW5rIHdoYXQgd2UgbmVlZA0KdG8gY29uc2lkZXIgaXMgdGhhdCBJUHY2IGludGVyZmFjZXMgbWF5 IGNvbmZpZ3VyZSBtdWx0aXBsZSBMTEFzIG9mIG11bHRpcGxlIGRpZmZlcmVudA0KdHlwZXMuIFRo ZSB0eXBlcyBuZWVkIHRvIGJlIGNvb3JkaW5hdGVkIHNvIHRoYXQgdGhleSBkbyBub3QgY29sbGlk ZSB3aXRoIG9uZSBhbm90aGVyDQphbmQgY2F1c2UgZHVwbGljYXRpb24uIEFsbCBvZiB0aGlzIGlz IGV4cGxhaW5lZCBpbiB0aGUgZHJhZnQgY2l0ZWQgYWJvdmUuDQoNClRoYW5rcyAtIEZyZWQNCg0K DQpGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NClNlbnQ6 IFN1bmRheSwgTm92ZW1iZXIgMjIsIDIwMjAgMTI6MTAgUE0NClRvOiBUZW1wbGluIChVUyksIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBDYSBCeSA8Y2IubGlzdDZAZ21h aWwuY29tPjsgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT47 IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyA2TUFOIDw2bWFuQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtFWFRFUk5BTF0gUmU6IFt2Nm9wc10gTmV4dCBzdGVwPyBbUmU6IFRoZSBi b3R0b20gaXMgLzExMl0NCg0KDQpUaGlzIG1lc3NhZ2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9m IEJvZWluZy4gUGxlYXNlIGRvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVu bGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhhdCB0aGUgY29udGVudCBp cyBzYWZlLg0KDQoNCg0KDQoNCk9uIE1vbiwgMjMgTm92IDIwMjAsIDAxOjU5IFRlbXBsaW4gKFVT KSwgRnJlZCBMLCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGksIEkgYmVsaWV2ZSB0aGUgQUVSTy9PTU5JIGFwcHJv YWNoIHRvIHByZWZpeCBkZWxlZ2F0aW9uIHdvdWxkIGJlIGdvb2QgZm9yIHRoZSAzR1BQDQpjYXNl IGFsc28uIFRoZSBhcHByb2FjaCBpcyBwcmVkaWNhdGVkIG9uIHRoZSByb3V0ZXIgcmV0dXJuaW5n IGFuIFJBIHdpdGggYW4gSVB2NiBsaW5rLWxvY2FsDQpkZXN0aW5hdGlvbiBhZGRyZXNzIGRldGVy bWluZWQgYnkgdGhlIGRlbGVnYXRlZCBwcmVmaXguIFRoZSBsaW5rLWxvY2FsIGFkZHJlc3MgaXMg Zm9ybWVkDQpieSB3cml0aW5nIHRoZSBtb3N0IHNpZ25pZmljYW50IDY0IGJpdHMgb2YgdGhlIGRl bGVnYXRlZCBwcmVmaXggaW50byB0aGUgaW50ZXJmYWNlIElEIG9mIHRoZQ0KcHJlZml4IGZlODA6 Oi82NC4NCg0KRm9yIGV4YW1wbGUsIGlmIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHdlcmUgMjAwMTpk Yjg6MTowOjovNTYgdGhlbiB0aGUgSVB2NiBsaW5rLWxvY2FsDQpkZXN0aW5hdGlvbiBhZGRyZXNz IGlzIGZlODA6OjIwMDE6ZGI4OjE6MC4gVGhpcyBwcm92aWRlcyBhdCBsZWFzdCB0d28gaW1wb3J0 YW50DQpvcGVyYXRpb25hbCBhZHZhbnRhZ2VzLg0KDQoxKSBJdCBjb252ZXlzIHRoZSBkZWxlZ2F0 ZWQgcHJlZml4IGluIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIFJBIHNvIHRo YXQNCm5vIFBJT3MgaW5zaWRlIHRoZSBSQSBuZWVkIHRvIGJlIHVzZWQgZm9yIHByZWZpeCBkZWxl Z2F0aW9uLg0KDQpJbiBteSBvcGVyYXRpb25hbCBleHBlcmllbmNlIGl0IGlzIGZhciBiZXR0ZXIg dG8gbWFrZSB0aGluZ3MgZXhwbGljaXQgaW4gcGFja2V0cyByYXRoZXIgdGhhbiBpbXBsaWNpdC4N Cg0KU2VlIFJGQzg0NjkgZm9yIGFuIGV4YW1wbGUgb2Ygd2hlcmUgd2hhdCB3YXMgaW1wbGljaXQg aW4gcGFja2V0cyBoYXMgY2F1c2VkIHNvIG1hbnkgcHJvYmxlbXMgdGhhdCBub3cgYmVpbmcgZXhw bGljaXQgaGFzIGJlY29tZSB0aGUgcmVjb21tZW5kYXRpb24uIChBYnNlbmNlIG9mIHRoaXMgaW4g YSB3aG9sZXNhbGVyJ3MgbmV0d29yayBjYXVzZWQgdXMgYW5kIGEgY3VzdG9tZXIgbW9udGhzIG9m IHRyb3VibGVzaG9vdGluZyBmb3IgdW51c3VhbCBwZXJmb3JtYW5jZSBwcm9ibGVtcywgYW5kIGlz IG5vdyBjb3N0aW5nIHVzIHNlcnZpY2Ugb3V0YWdlcyBmb3IgbWFueSBjdXN0b21lcnMgYXQgb25j ZSB3aGlsZSB0aGV5IHB1dCBpdCBpbiBwbGFjZS4pDQoNCg0KDQoyKSBJdCBzdXBwbGllcyB0aGUg bW9iaWxlIG5vZGUgd2l0aCBhIGd1YXJhbnRlZWQtdW5pcXVlIGxpbmstbG9jYWwgYWRkcmVzcyB0 aGF0DQppdCBjYW4gdXNlIGZvciBmdXR1cmUgY29tbXVuaWNhdGlvbnMgd2l0aG91dCB0aGUgbmVl ZCB0byBwZXJmb3JtIERBRC4NCg0KDQpTbyB0aGUgUkEgREEgaXMgY2FycmllcyBib3RoIGRlbGVn YXRlZCBwcmVmaXggaW5mb3JtYXRpb24gYW5kIHdpdGggbGluay1sb2NhbCBhZGRyZXNzIGNvbmZp Z3VyYXRpb24gdG9vPyBIb3cgZG9lcyBhIG5vZGUga25vdyB0byB1c2UgdGhlIFJBIERBIGFzIGl0 cyBsaW5rLWxvY2FsIGFkZHJlc3M/DQoNCldpdGggdGhlIHJpc2Ugb2Ygd2lyZWxlc3Mgd2UgbmVl ZCB0byBjYXJlIGFib3V0IHRoZSBnbG9iYWwgdHJhY2VhYmlsaXR5IG9mIGxpbmstbG9jYWwgYWRk cmVzc2VzIHRvby4gUGVyc2lzdGVudCwgZ2xvYmFsbHkgdW5pcXVlIGxpbmstbG9jYWwgSUlEcyBo YXZlIHRoZSBzYW1lIHByaXZhY3kgaW1wbGljYXRpb25zIGFzIHBlcnNpc3RlbnQgZ2xvYmFsbHkg dW5pcXVlIFdpRmkgTUFDIGFkZHJlc3NlcyBhbmQgQmx1ZXRvb3RoIE1BQyBhZGRyZXNzZXMuDQoN CkhhdmUgYSBsb29rIGF0IGh0dHBzOi8vd2lnbGUubmV0IGFuZCB0aGUgQW5kcm9pZCBhcHAgZm9y IGNvbGxlY3RpbmcgdGhlIGRhdGEuDQoNCkEgc2ltaWxhciBhcHAgZm9jdXNlZCBvbiBCbHVldG9v dGggaXMgUmFtYmxlLg0KDQpOZWl0aGVyIG9mIHRoZXNlIGFwcHMgcmVxdWlyZSBhIGhhY2tlZCBw aG9uZSwgdGhlIGNhbiBqdXN0IGJlIGluc3RhbGxlZCBhbmQgcnVuIGJ5IGFueWJvZHkgZnJvbSB0 aGUgR29vZ2xlIGFwcCBzdG9yZS4NCg0KDQpBZ2FpbiwgdGhlIHByb3Bvc2FsIGNvbWVzIGZyb20g dGhlIEFFUk8vT01OSSB1c2UgY2FzZSwgYnV0IEkgYmVsaWV2ZSBpcyBhbHNvDQpnb29kIGZvciAz R1BQIGFuZCByZWFsbHkgYW55IG90aGVyIHdpcmVsZXNzIHVzZSBjYXNlIHdoZXJlIGEgbGlnaHR3 ZWlnaHQNCnByZWZpeCBkZWxlZ2F0aW9uIGNhcGFiaWxpdHkgaXMgZGVzaXJlZC4NCg0KRnJlZA0K --_000_fe44a5687f864e24a10f917fa9015156boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYXJrLCBteSBpbml0aWFsIGRl c2NyaXB0aW9uIHdhcyBwdXJwb3NlZnVsbHkgbGlnaHQgb24gZGV0YWlscyBidXQgdG8gZ2V0IHRo ZSBmdWxsIHBpY3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+eW91IGNhbiBoYXZlIGEgbG9vayBhdCB0 aGUgZm9sbG93aW5nIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVt cGxpbi02bWFuLWxsYS10eXBlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtdGVtcGxpbi02bWFuLWxsYS10eXBlLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoZSBpZGVhIGZvciB0aGlzIExMQS1iYXNlZCBQRCBzY2hlbWUgaXMg YXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjEp IFRoZSByZXF1ZXN0aW5nIHJvdXRlciBjcmVhdGVzIGEgdGVtcG9yYXJ5IExMQSB1c2luZyBSRkM0 OTQxKGJpcykgYW5kIHNldHMgYSBwcmVmaXggbGVuZ3RoPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmluZGlj YXRpb24gaW5zaWRlIHRoZSBMTEEgaXRzZWxmLiBUaGUgUlIgdGhlbiB1c2VzIHRoZSBMTEEgYXMg dGhlIElQdjYgc291cmNlIGFkZHJlc3Mgb2YgYW4gUlM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bWVzc2Fn ZSB0byBzZW5kIHRvIHRoZSBkZWxlZ2F0aW5nIHJvdXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIpIFdoZW4gdGhlIGRlbGVnYXRpbmcgcm91dGVyIHJlY2Vp dmVzIHRoZSBSUywgaXQgc2VlcyB0aGF0IHRoZSBJUHY2IHNvdXJjZSBpcyBhbiBSRkM0OTQxKGJp cyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+YWRkcmVzcyB3aXRoIGEgbm9uLXplcm8gcHJlZml4IGxlbmd0 aCBpbmRpY2F0aW9uLiBUaGUgRFIgdGhlbiBjb29yZGluYXRlcyB3aXRoIHRoZSBESENQdjY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+c2VydmVyIHRvIHJlcXVlc3QgYSBQRCBvZiB0aGUgbGVuZ3RoIGluZGlj YXRlZCBieSB0aGUgUlIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4zKSBXaGVuIHRoZSBEUiByZWNlaXZlcyB0aGUgUEQgZnJvbSB0aGUgREhDUHY2IHNlcnZlciwg aXQgY3JlYXRlcyBhbiBPTU5JIExMQSBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5lbWJlZGRpbmcgdGhl IGRlbGVnYXRlZCBwcmVmaXggaW4gdGhlIElJRCBvZiBmZTgwOjovNjQsIGUuZy4sIGFzIGZlODA6 OjIwMDE6ZGI4OjE6Mi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERSIHRoZW4gc2V0cyBhIHByZWZp eCBsZW5ndGggaW5kaWNhdGlvbiBpbiB0aGUgT01OSSBMTEEsIGFuZCBzZXRzIHRoZSBMTEEgYXMg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgYW4gUkEgbWVzc2Fn ZSB0byBzZW5kIGJhY2sgdG8gdGhlIFJSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+NCkgV2hlbiB0aGUgUlIgcmVjZWl2ZXMgdGhlIFJBIG1lc3NhZ2UsIGl0IHNl ZXMgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMgYW4gT01OSSBMTEE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ d2l0aCBhIG5vbi16ZXJvIHByZWZpeCBsZW5ndGguIFRoZSBSUiB0aGVuIHVzZXMgdGhlIGVtYmVk ZGVkIHByZWZpeCB3aXRoaW4gdGhlIE9NTkk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TExBIGFzIGl0cyBk ZWxlZ2F0ZWQgcHJlZml4LCBhbmQgcmVnYXJkcyB0aGUgUm91dGVyIExpZmV0aW1lIGFzIHRoZSB0 aW1lIGF0IHdoaWNoIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kZWxlZ2F0ZWQgcHJlZml4IG5lZWRz IHRvIGJlIHJlbmV3ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Zb3UgYWxzbyBhc2tlZCBhYm91dCB0aGUgbG9uZy1saXZlZCB1c2FnZSBvZiB1bmlxdWUgTExB cywgYW5kIEkgdGhpbmsgd2hhdCB3ZSBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvIGNvbnNpZGVy IGlzIHRoYXQgSVB2NiBpbnRlcmZhY2VzIG1heSBjb25maWd1cmUgbXVsdGlwbGUgTExBcyBvZiBt dWx0aXBsZSBkaWZmZXJlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dHlwZXMuIFRoZSB0eXBlcyBuZWVk IHRvIGJlIGNvb3JkaW5hdGVkIHNvIHRoYXQgdGhleSBkbyBub3QgY29sbGlkZSB3aXRoIG9uZSBh bm90aGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFuZCBjYXVzZSBkdXBsaWNhdGlvbi4gQWxsIG9mIHRo aXMgaXMgZXhwbGFpbmVkIGluIHRoZSBkcmFmdCBjaXRlZCBhYm92ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gTWFyayBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBOb3ZlbWJlciAyMiwgMjAyMCAxMjox MCBQTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1w bGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDYSBCeSAmbHQ7Y2IubGlzdDZAZ21h aWwuY29tJmd0OzsgQnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbSZndDs7IElQdjYgT3BlcmF0aW9ucyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyA2TUFOICZs dDs2bWFuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0VYVEVSTkFMXSBS ZTogW3Y2b3BzXSBOZXh0IHN0ZXA/IFtSZTogVGhlIGJvdHRvbSBpcyAvMTEyXTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFs aWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJTttYXJnaW4tbGVmdDou NzVwdDttYXJnaW4tcmlnaHQ6Ljc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJiYWNr Z3JvdW5kOiM5MTBBMTk7cGFkZGluZzo1LjI1cHQgMS41cHQgNS4yNXB0IDEuNXB0Ij48L3RkPg0K PHRkIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO2JhY2tncm91bmQ6I0ZERjJGNDtw YWRkaW5nOjUuMjVwdCAzLjc1cHQgNS4yNXB0IDExLjI1cHQ7d29yZC13cmFwOmJyZWFrLXdvcmQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjEyMTIxIj5UaGlzIG1lc3NhZ2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9mIEJvZWluZy4g UGxlYXNlIGRvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3Ug cmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhhdCB0aGUgY29udGVudCBpcyBzYWZlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE1vbiwgMjMgTm92 IDIwMjAsIDAxOjU5IFRlbXBsaW4gKFVTKSwgRnJlZCBMLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSwgSSBi ZWxpZXZlIHRoZSBBRVJPL09NTkkgYXBwcm9hY2ggdG8gcHJlZml4IGRlbGVnYXRpb24gd291bGQg YmUgZ29vZCBmb3IgdGhlIDNHUFA8YnI+DQpjYXNlIGFsc28uIFRoZSBhcHByb2FjaCBpcyBwcmVk aWNhdGVkIG9uIHRoZSByb3V0ZXIgcmV0dXJuaW5nIGFuIFJBIHdpdGggYW4gSVB2NiBsaW5rLWxv Y2FsPGJyPg0KZGVzdGluYXRpb24gYWRkcmVzcyBkZXRlcm1pbmVkIGJ5IHRoZSBkZWxlZ2F0ZWQg cHJlZml4LiBUaGUgbGluay1sb2NhbCBhZGRyZXNzIGlzIGZvcm1lZDxicj4NCmJ5IHdyaXRpbmcg dGhlIG1vc3Qgc2lnbmlmaWNhbnQgNjQgYml0cyBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbnRv IHRoZSBpbnRlcmZhY2UgSUQgb2YgdGhlPGJyPg0KcHJlZml4IGZlODA6Oi82NC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQpGb3IgZXhhbXBsZSwgaWYgdGhlIGRlbGVnYXRlZCBwcmVmaXggd2VyZSAyMDAxOmRiODoxOjA6 Oi81NiB0aGVuIHRoZSBJUHY2IGxpbmstbG9jYWw8YnI+DQpkZXN0aW5hdGlvbiBhZGRyZXNzIGlz IGZlODA6OjIwMDE6ZGI4OjE6MC4gVGhpcyBwcm92aWRlcyBhdCBsZWFzdCB0d28gaW1wb3J0YW50 PGJyPg0Kb3BlcmF0aW9uYWwgYWR2YW50YWdlcy48YnI+DQo8YnI+DQoxKSBJdCBjb252ZXlzIHRo ZSBkZWxlZ2F0ZWQgcHJlZml4IGluIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhl IFJBIHNvIHRoYXQ8YnI+DQpubyBQSU9zIGluc2lkZSB0aGUgUkEgbmVlZCB0byBiZSB1c2VkIGZv ciBwcmVmaXggZGVsZWdhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiBteSBvcGVyYXRpb25hbCBleHBlcmll bmNlIGl0IGlzIGZhciBiZXR0ZXIgdG8gbWFrZSB0aGluZ3MgZXhwbGljaXQgaW4gcGFja2V0cyBy YXRoZXIgdGhhbiBpbXBsaWNpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+U2VlIFJGQzg0NjkgZm9yIGFuIGV4YW1wbGUgb2Ygd2hlcmUgd2hhdCB3YXMgaW1w bGljaXQgaW4gcGFja2V0cyBoYXMgY2F1c2VkIHNvIG1hbnkgcHJvYmxlbXMgdGhhdCBub3cgYmVp bmcgZXhwbGljaXQgaGFzIGJlY29tZSB0aGUgcmVjb21tZW5kYXRpb24uIChBYnNlbmNlIG9mIHRo aXMgaW4gYSB3aG9sZXNhbGVyJ3MNCiBuZXR3b3JrIGNhdXNlZCB1cyBhbmQgYSBjdXN0b21lciBt b250aHMgb2YgdHJvdWJsZXNob290aW5nIGZvciB1bnVzdWFsIHBlcmZvcm1hbmNlIHByb2JsZW1z LCBhbmQgaXMgbm93IGNvc3RpbmcgdXMgc2VydmljZSBvdXRhZ2VzIGZvciBtYW55IGN1c3RvbWVy cyBhdCBvbmNlIHdoaWxlIHRoZXkgcHV0IGl0IGluIHBsYWNlLik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjIpIEl0IHN1cHBsaWVzIHRoZSBtb2JpbGUgbm9kZSB3aXRo IGEgZ3VhcmFudGVlZC11bmlxdWUgbGluay1sb2NhbCBhZGRyZXNzIHRoYXQ8YnI+DQppdCBjYW4g dXNlIGZvciBmdXR1cmUgY29tbXVuaWNhdGlvbnMgd2l0aG91dCB0aGUgbmVlZCB0byBwZXJmb3Jt IERBRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIHRoZSBSQSBEQSBp cyBjYXJyaWVzIGJvdGggZGVsZWdhdGVkIHByZWZpeCBpbmZvcm1hdGlvbiBhbmQgd2l0aCBsaW5r LWxvY2FsIGFkZHJlc3MgY29uZmlndXJhdGlvbiB0b28/IEhvdyBkb2VzIGEgbm9kZSBrbm93IHRv IHVzZSB0aGUgUkEgREEgYXMgaXRzIGxpbmstbG9jYWwgYWRkcmVzcz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2l0aCB0aGUgcmlzZSBvZiB3aXJlbGVzcyB3 ZSBuZWVkIHRvIGNhcmUgYWJvdXQgdGhlIGdsb2JhbCB0cmFjZWFiaWxpdHkgb2YgbGluay1sb2Nh bCBhZGRyZXNzZXMgdG9vLiBQZXJzaXN0ZW50LCBnbG9iYWxseSB1bmlxdWUgbGluay1sb2NhbCBJ SURzIGhhdmUgdGhlIHNhbWUgcHJpdmFjeSBpbXBsaWNhdGlvbnMNCiBhcyBwZXJzaXN0ZW50IGds b2JhbGx5IHVuaXF1ZSBXaUZpIE1BQyBhZGRyZXNzZXMgYW5kIEJsdWV0b290aCBNQUMgYWRkcmVz c2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IYXZlIGEg bG9vayBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93aWdsZS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3dpZ2xlLm5ldDwvYT4gYW5kIHRoZSBBbmRyb2lkIGFwcCBmb3IgY29sbGVjdGluZyB0aGUg ZGF0YS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ QSBzaW1pbGFyIGFwcCBmb2N1c2VkIG9uIEJsdWV0b290aCBpcyBSYW1ibGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5laXRoZXIgb2YgdGhlc2UgYXBwcyBy ZXF1aXJlIGEgaGFja2VkIHBob25lLCB0aGUgY2FuIGp1c3QgYmUgaW5zdGFsbGVkIGFuZCBydW4g YnkgYW55Ym9keSBmcm9tIHRoZSBHb29nbGUgYXBwIHN0b3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkFnYWlu LCB0aGUgcHJvcG9zYWwgY29tZXMgZnJvbSB0aGUgQUVSTy9PTU5JIHVzZSBjYXNlLCBidXQgSSBi ZWxpZXZlIGlzIGFsc288YnI+DQpnb29kIGZvciAzR1BQIGFuZCByZWFsbHkgYW55IG90aGVyIHdp cmVsZXNzIHVzZSBjYXNlIHdoZXJlIGEgbGlnaHR3ZWlnaHQ8YnI+DQpwcmVmaXggZGVsZWdhdGlv biBjYXBhYmlsaXR5IGlzIGRlc2lyZWQuPGJyPg0KPGJyPg0KRnJlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_fe44a5687f864e24a10f917fa9015156boeingcom_-- From nobody Mon Nov 23 09:05:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199253A0B1C; Mon, 23 Nov 2020 09:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVEXx6FuFFzt; Mon, 23 Nov 2020 09:05:50 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCF23A0B18; Mon, 23 Nov 2020 09:05:50 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id s2so9141243plr.9; Mon, 23 Nov 2020 09:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9IpAu/GbRWQEeLs/05ExUvxSKAymrp1bYWgp5gifPrg=; b=hO+EwiTg79un+E7FsRl8zZf7dpE2QaXqlGSUbcjjRxOs+i0JXsSjT3uge49Kywh7X/ huWrSImv3thyYWL2gjzwLxVZHGdIPWs9PdcQGEO0KiTArEqVstGOofCxkEbu9o7D1AEH lDqFHHajiaryXZnzGv7+maMGbib22nKjgn9zA67QciteYJ/J7ggORrrti1yts2L5Cl5E L/vP+UB0pRH1dG63QU9doyBWmO1QiqPGWEL94aKRIHnkkAkcj5ll+5V4zJOcMGna/oxu p+bcNg68Pm+QTTFkSnIMqECWe8ZtsOrSU+9rkRxjK/uevqojeAwdfTT/79o+i0Euw0cI uhLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9IpAu/GbRWQEeLs/05ExUvxSKAymrp1bYWgp5gifPrg=; b=WZ3py08SLP977JuhwVR9/rdRtLhCt6WC87QikT8RFikSA/9274RQmWzkO5PXmfiRI4 FsiqVr83rJIjbVH8tVTXCju3b7Bq/G1F4JwOttA4+Y9f6pbhoxUNNtZXynzb12CBVKY5 6azE6cUWkJDgiy7HngC4ciGvijvqwEJAZvzZpYtHsYWwkcvZ6+j0xWdiX017CvxeROFp NiPoX4Xr8emYYtVGWCQCt/B4wAiWrMIsex+smYVMx4e1yU5zi1t1SvQu5+19H9pNeyea e+0HURIou25NnUXbwzGlPkkLBTzXQxj7kKuEQWZQe9uNqAZd1f46qTuzAJ0i5BlLVfSp qEtw== X-Gm-Message-State: AOAM531HWV1fCkLkHAE0j+wFH5Q4BfPBK4ggCbnqPv+Yo8vyY4hg2ZOf sjfBWewtPyStg5AAgtI5F7ZKcdHMMaqe6aOoZVY= X-Google-Smtp-Source: ABdhPJwXlpgxOAS+Il0Y+6lVQ6uktSEAcpW2uf3GlukSu6aDvoInUwbDWduDoq+op+ffJygLxWRVt5bEqQXHNzfDlF8= X-Received: by 2002:a17:902:7c01:b029:d8:ee2a:ce88 with SMTP id x1-20020a1709027c01b02900d8ee2ace88mr401636pll.22.1606151149581; Mon, 23 Nov 2020 09:05:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Mon, 23 Nov 2020 12:05:39 -0500 Message-ID: To: Alexandre Petrescu , Mikael Abrahamsson Cc: 6MAN <6man@ietf.org>, IPv6 Operations , "draft-mishra-6man-variable-slaac@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b9f85f05b4c934d9" Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 17:05:52 -0000 --000000000000b9f85f05b4c934d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2020 at 7:24 AM Mikael Abrahamsson wrote= : > On Mon, 23 Nov 2020, Gyan Mishra wrote: > > > How do we propose to solve this problem if operators don=E2=80=99t supp= ort PD > even > > though the 3GPP standard has supported PD for over 10 years. > > > > Another twist to this puzzle is Android has 90% of the mobile handset > > marketplace worldwide and adamantly states they will NOT support DHCPv6 > or > > PD. > > > > I researched Apple which has 10% of the market and they also do not > support > > PD. > > > > Whats the solution now? > > The obvious use-case for PD is the "LTE router" fixed-wireless use-case. > There the problem of getting a DHCPv6-PD client into the UE isn't the sam= e > as on handsets. A lot of those platforms already support DHCPv6-PD for > their wired versions (some have both LTE and wired WAN). Gyan>Agreed the obvious PD use case is for wired LTE but this particular use case brought up in slaac problem statement draft is for handsets. > > > So this brings us back to the mobile core. Why doesn't this today, 8 year= s > after DHCPv6-PD was introduced in 3GPP standards, still not support PD? > > I don't know but I know staff at operators who claim to have tried (more > than 5 years ago). I do not know why their efforts failed. Perhaps the > mobile core vendors successfully managed to divide the customer base so > there was no critical mass. I can only speculate. I just find it weird > that there are now demands to change *everything* downstream from the 3GP= P > bearer to handle smaller subnets instead of enabling PD in mobile core. Gyan> I have to research technical reasons why > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000b9f85f05b4c934d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div>
On Mon, Nov 23, 2020 at 7:24 AM M= ikael Abrahamsson <swmike@swm.pp.se> wrote:
On Mon, 23 Nov 2= 020, Gyan Mishra wrote:

> How do we propose to solve this problem if operators don=E2=80=99t sup= port PD even
> though the=C2=A0 3GPP standard has supported PD for over 10 years.
>
> Another twist to this puzzle is Android has 90% of the mobile handset<= br> > marketplace worldwide and adamantly states they will NOT support DHCPv= 6 or
> PD.
>
> I researched Apple which has 10% of the market and they also do not su= pport
> PD.
>
> Whats the solution now?

The obvious use-case for PD is the "LTE router" fixed-wireless us= e-case.
There the problem of getting a DHCPv6-PD client into the UE isn't the s= ame
as on handsets. A lot of those platforms already support DHCPv6-PD for
their wired versions (some have both LTE and wired WAN).

=C2=A0 =C2=A0 Gyan>Ag= reed the obvious PD use case is for wired LTE but this particular use case = brought up in slaac problem statement draft is for handsets.=C2=A0


So this brings us back to the mobile core. Why doesn't this today, 8 ye= ars
after DHCPv6-PD was introduced in 3GPP standards, still not support PD?


I don't know but I know staff at operators who claim to have tried (mor= e
than 5 years ago). I do not know why their efforts failed. Perhaps the
mobile core vendors successfully managed to divide the customer base so there was no critical mass. I can only speculate. I just find it weird
that there are now demands to change *everything* downstream from the 3GPP =
bearer to handle smaller subnets instead of enabling PD in mobile core.

=C2=A0 =C2=A0 Gyan&g= t; I have to research technical reasons why=C2=A0


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
--

=

Gyan Mishra

Network Solutions Architect=C2=A0<= /p>

M 301 502-1347
13101 Columbia Pike=C2=A0
= Silver Spring, MD


--000000000000b9f85f05b4c934d9-- From nobody Mon Nov 23 09:52:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148B23A0C01 for ; Mon, 23 Nov 2020 09:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.155 X-Spam-Level: *** X-Spam-Status: No, score=3.155 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 gyFL8JPQ89at for ; Mon, 23 Nov 2020 09:51:59 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 1E4223A0B95 for ; Mon, 23 Nov 2020 09:51:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0ANHpuxn014495 for ; Mon, 23 Nov 2020 18:51:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D373208F99 for ; Mon, 23 Nov 2020 18:51:56 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 60F872072E7 for ; Mon, 23 Nov 2020 18:51:56 +0100 (CET) Received: from [10.11.240.70] ([10.11.240.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0ANHptDS024098 for ; Mon, 23 Nov 2020 18:51:55 +0100 To: v6ops@ietf.org References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <9ff71dd2-4901-0d61-b41c-0f65118c8dda@joelhalpern.com> <83cb8c2d-d2eb-2cd4-eb8d-466daa59ac75@joelhalpern.com> <7a15b2d2-f4bd-b6f1-0825-1f86e46ef4ce@gmail.com> <24b3cb7e-989f-2b99-f019-74b6d39c424b@joelhalpern.com> From: Alexandre Petrescu Message-ID: <476bce25-99c4-c271-9b59-06fd9da35423@gmail.com> Date: Mon, 23 Nov 2020 18:51:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 17:52:07 -0000 Le 23/11/2020 à 07:40, Gyan Mishra a écrit : > > > On Sat, Nov 21, 2020 at 10:26 AM Joel M. Halpern > wrote: > > As I understand it, the situation is not that 3GPP has not defined > use of DHCP. But rather than operators have uniformly declined to > deploy it. (3GPP has defined DHCP for 5G for fixed access. We have > heard here that even that is not what the operators want.) As such, > asking 3GPP why they didn't deploy it seems a bit odd. > > > Gyan> One possible non technical factor is that Android which as of > 2019 statistical data below holds 87% of the global mobile market > share and Apple 13% and Android is continuing to climb in 2020. > Android adamantly refuses to change its position on support of > DHCPv6. At which point, one can wonder why Android refuses to support DHCPv6. This has also been discussed other time. There have been given reasons. If I remember correctly, some of the reasons had to do with the difficulty put on a user to manually configure some matters exclusively related to DHCP; or maybe the difficulty of syncing between data received on RA vs DHCP; but I am not sure I remember ok. Alex PS: a colleague here ported a couple of open source DHCPv6(-PD) clients to Android. We stopped short from submitting these clients to the respective store, because it required payment to accept them. The business model at the store assumes that an initial small investment would be later covered by numerous paying uses of a DHCP app. That problem (have to pay for acceptance) adds to the other problem of blocking in the modem. One could still use a DHCP client on the wifi interface; or could use DHCP client on the 3gpp iface with a https tunnel drilled through the modem (provided, of course, that PGW mounts a SSL tunnel for DHCP purpose, or listens to 443 for DHCP - neither of these is acceptable at operator, even if the DHCP-PD server software, and https software, and SSL tunnel software are all present in that PGW.) I think > that really shackles 3GPP carriers from supporting DHCPv6 is close to > 100% of all mobile handsets won’t support it. > > https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/ > > > > > > > > Yours, Joel > > On 11/20/2020 11:19 PM, Mark Smith wrote: >> >> >> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, >> > >> wrote: >> >> Joel, >> >> It seems to me that it's high time to draft a liaison > statement to 3GPP, >> observing that: >> >> (1) There is a serious problem for the design and > implementation of >> 5G-based IPv6 "hot spots" and CEs [which is where this > conversation >> started]; >> >> >> I think it is also important to find out why they haven't deployed >> DHCPv6 to solve this problem. >> >> Don't they think DHCPv6 infrastructure will scale? Is it just > that they >> don't know how to scale it? >> >> Is it a vendor / mobile operator / handset developer DHCPv6 >> capability chicken-and-egg problem? >> >> Is there an overriding business or industry reason? >> >> The mobile industry has been resistant to tethering over the > years, and >> probably only came to begrudgingly accept it because they couldn't >> prevent phone vendors from implementing Wifi and NAT, and > couldn't very >> effectively stop their customers from using that capability (One > trick >> I've heard of to prevent tethering working was to check if an IPv4 >> packet's TTL value was 64 when it arrived at the network, meaning >> it originated from the directly attached handset. Packets from >> tethered devices had a TTL of 63 so were dropped. Of course, you >> could set > the >> default TTL on a tethered PC to 65 to get around that.) >> >> I guess there might be a fairly strong mindset that there must be > a fee >> per device attached to the network in addition to a fee for >> network utilisation. Providing multiple /64s would be formally >> acknowledging that multiple devices can be attached and a fee per >> device isn't and can't ever be charged, counter to the mindset. >> >> Regards, Mark. >> >> >> (2) Although the best solution is not yet obvious, defining and >> standardizing it will require a joint effort by the IETF and > 3GPP. >> >> Followed by a proposal to form an ad hoc joint design team. >> >> Regards Brian Carpenter On 21-Nov-20 14:46, Joel M. Halpern wrote: >>> The nesting got me lost, so I will top post my take on the > answer >> to the >>> one quesiton I could understand. >>> >>> I believe you asked what I think would need to be changed to >> permit the >>> delegation. As with anything, the real things that need to change >>> are the >> devices in >>> the network. >>> >>> With regard to IETF standards, what is proposed is a > change to RA. >>> There are several possible changes. None of them require a >> change to >>> the IPv6 addressing archtiecture, as the addressing structure >> remains as >>> it is. As for the exact mechanism, at the moment I lean towards >>> Ole's >> proposal >>> of using a new option in his generic option mechanism. > But I am not >>> wedded to that answer. >>> >>> And of course, to get this supported in mobile environments we >> will have >>> to work with 3GPP and make sure there are no other hidden > issues. >>> That's the way we do things. Work together. >>> >>> Changing the prefix length to /80 is technically also > possible. >> It does >>> a lot more violence to my understanding of the > architecture and >> software >>> structures that go with it, and is a very limited and narrow >> solution to >>> the problem. >>> >>> Yours, Joel >>> >>> On 11/20/2020 7:58 PM, Gyan Mishra wrote: >>>> Hi Joel >>>> >>>> In-line >>>> >>>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern >> > > >>>> > >>> wrote: >>>> >>>> Gyan, separate from Ole's comments about the difference >> between address >>>> assignment and delegation, I have another problem > following the >>>> reasoning below. >>>> >>>> Yes, the proposal for using shorter prefixes to > enable UE to >> perform >>>> delegation will require changes to the UE. >>>> >>>> Gyan> Agreed. So that change would be to RFC 4291 > 64 bit >> boundary >>>> to allow for longer prefix. Do you agree? >>>> >>>> If you don’t agree what do think the change would be to allow >> the UE to >>>> accept shorter prefix from the 3GPP gateway? >>>> >>>> >>>> But I do not see how that is relevant to any choice > we are >> trying to >>>> make. Any solution that enables UE to delegate addresses > (in the >> sense that >>>> they lack the capability now) willr equire changes to > the UE. >>>> >>>> >>>> >>>> Gyan> If the UE receives a /56 via RA it could > delegate /64 to >>>> downstream devices. No change needed to delegate /64, >> however a >>>> change is needed to accept /56 via RA. >>>> >>>> >>>> If 3GPP gateway supported PD - problem solved but that’s >> not the >>>> case and that does not sound like it will ever change > even with 5G. >>>> >>>> Gyan> The UE needs to be able to accept shorter prefix. >> That’s the >>>> IPV6 specification change that requires removal of the 64 bit >> boundary. >>>> >>>> Yoru proposed change to the SLAAC length if anything does more >> violence to >>>> the software (depending upon the exact software > architecture.) >>>> >>>> >>>> Gyan> What violence to software. There would be more >> violence to >>>> software if we removed the 64 bit boundary and allowed > slaac to >> support >>>> any vlsm prefix lengths. >>>> >>>> My /80 proposal would just shift the boundary 16 bits to /80. >>>> >>>> Hosts on the same subnet with two different masks would > not be >> on-net to >>>> each other as on different subnets. The router would be >> configured with >>>> the two subnets /64 and /80 subnet to support the two > device types. >>>> The solution would be a simple RA PIO flag that is set > and older >> hosts >>>> not upgraded would be backwards compatible and so would only >> support 64 >>>> bit boundary by ignoring flag. Hosts upgraded to support > would >>>> understand the flag and be able to support longer mask up > to /80. >>>> >>>> >>>> >>>> So I do not follow how you got to your conclusion. >>>> >>>> Yours, Joel >>>> >>>> On 11/20/2020 5:27 PM, Gyan Mishra wrote: >>>>> >>>>> (top posting) >>>>> >>>>> As I would like to clear the air as well as get to the >> crux of >>>> the v6ops >>>>> presentation development results as well as next steps >> for this >>>> draft >>>>> and the 6man variable slaac solutions draft: >>>>> >>>>> >>>>> This thread was in light of Lorenzo kindly > pointing out that >>>> upgrading >>>>> 3GPP is not all that needs be done for Cameron’s > 64share >> v2 to >>>> work - as >>>>> all mobile devices would stop working- as slaac > would not >> would be >>>>> effectively broken. >>>>> >>>>> The mobile device would receive a shorter prefix let’s >> say /56 >>>> but not >>>>> know what to do with it since it’s expecting a /64. >>>>> >>>>> So that a major gap and the only solution is > updating RFC >> 4291 >>>> removing >>>>> the 64 bit boundary allowing for shorter prefix > and now >> as well >>>> longer >>>>> prefixes to work and in that respect now provide > the much >> needed >>>> parity >>>>> with static and DHCPv6 which can do any prefix length. >>>>> >>>>> So that is a drastic change to RFC 4291. However, in >> light of this >>>>> development on the v6ops 109 call, my balancing act of >> best of both >>>>> worlds and also to keep everyone happy to make > this a WG >> effort >>>> for this >>>>> change by proposing in the subject heading /80 fixed >> boundary and >>>> not a >>>>> variable slaac change allowing all bits vlsm. >>>>> >>>>> Basically stealing 16 bits for network prefix out > of the >> IID, still >>>>> keeping the fixed boundary so longer than 80 would NOT >> be allowed. >>>>> >>>>> A /64 would now be equivalent to a /48 with now > 64k /80’s. >>>>> >>>>> This /80 would keep the operators and law enforcement >> happy as >>>> now 16 >>>>> bits less helps traceability but is still long > enough for >> 48 bits of >>>>> privacy to IP correlation by attackers. >>>>> >>>>> This /80 would be a nice optimal balance as it > would keep >> wired >>>>> broadband and mobile handset customers happy > respecting their >>>> privacy as >>>>> the 16 bits less of heuristics is minimal change that >> will impact IP >>>>> correlation by attackers. >>>>> >>>>> The IID as it’s less than the current 64 bit > cannot use >> MAC based >>>> EUI64 >>>>> IID, which is not a problem as Mac based IID is not >> recommended >>>> as most >>>>> all manufacturers use RFC 4941 and I believe Linux >> flavors some use >>>>> stable IID RFC 7217. >>>>> >>>>> So now the 48 bit IID would require a random IID > generation >>>> schema so >>>>> can use either RFC 4941 privacy extension or RFC 7217 >> stable IID to >>>>> generate the 48 bit IID. >>>>> >>>>> 3GPP subtending would now work issue mentioned in > the problem >>>> statement >>>>> draft without even having to use 64share as now longer >> prefixes >>>> up to >>>>> /80 would be supported allowing for further > segmentation of >>>> downstream >>>>> devices. >>>>> >>>>> This also would help wired broadband and soon fixed 5G >> broadband >>>>> proliferation where operators in light of BCP > RIPE-690, >> are sill >>>>> allocation via BNG gateways a /64, now operators can >> stay as-is, >>>> as the >>>>> /64 would now be allowed to be further segmented >> supporting 64k >>>> /80s, >>>>> way more then enough for SOHO. >>>>> >>>>> This would allow 64share if used by 3GPP operators to >> work and >>>> would not >>>>> require the 3GPP specification to be updated. We > don’t >> know even >>>> if the >>>>> 3GPP architecture specification can be updated to > support >> shorter >>>>> prefixes and if the 3GPP consortium of operators would >> agree to >>>> it. So >>>>> that is all theoretical of that change is possible. >>>>> >>>>> As with 5G with Enhanced VPN framework SR steering of >> high priority >>>>> traffic, traffic isolation and Network slicing >> capabilities becomes >>>>> mainstream and will soon be a real world reality > and as >> fixed 5G >>>>> broadband proliferation takes off and mobile 5G == the >> idea of a >>>>> wearable /48 will really be many /48s. >>>>> >>>>> As this paradigm shift takes place, operators > around the >> world >>>> will be >>>>> clamoring after the RIR for massive blocks, I > would say >> less than /8 >>>>> more like a /5 or /4. If you do the math on the > way high >> side a /10 >>>>> yields 7 bits so 128 divided by 5 RIRs yields 24 > ISPs per RIR >>>> which is >>>>> tiny number with the number of large size operators >> worldwide. >>>>> >>>>> With the massive proliferation of IOT devices and > just about >>>> every home >>>>> or office appliance on 5G, the problem now gets way >> exacerbated. >>>>> >>>>> As this evolution unfolds IANA will be scrambling to >> release all >>>>> remaining /3 as well as all unallocated blocks to > subvert >> RIR IPv6 >>>>> address space depletion. >>>>> >>>>> Playing Monday night quarterbacking in hindsight > we would >> never >>>> think >>>>> this would happen in a million years, but we would see >> IPv6 on >>>> the verge >>>>> of address space depletion. Unheard of but it can > happen >> as the >>>> saying >>>>> goes “when you build - they will come”. >>>>> >>>>> It is true as history has taught that very > important lesson. >>>>> >>>>> The answer to this real world problem is in the > subject >> heading >>>> of this >>>>> thread. >>>>> >>>>> This would also fix the day 1 issue I mentioned > allowing >> mix of >>>> slaac >>>>> devices with static and DHCPv6 up to /80. >>>>> >>>>> The variable slaac solution draft proposes a new > RA PIO flag >>>> that would >>>>> be used to signal longer prefixes, and would provide >> backwards >>>>> compatibility so that devices not supporting woud > ignore >> the flag >>>> and >>>>> devices on newer code supporting would use the > flag. We >> definitely >>>>> don’t want to impact any existing devices on the > existing >> 64 bit >>>> slaac >>>>> boundary standard. >>>>> >>>>> Dmytro has tested the solution on Linux kernel > signaling >> RA PIO >>>> flag and >>>>> was able to successfully test any length mask and > random IID >>>> generation >>>>> both RFC 4941 privacy extension as well as stable > IID RFC >> 7217. >>>>> >>>>> >>>> >> > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ > >> > > > > >>> >> > > >> > > >>>> >>>> >> > > > > > >>> >> > > >>> > > >>>> >>>>> If everyone is in agreement with what I have > stated on this >>>> thread, I >>>>> would like to ask the chairs for WG adoption as > this is a >> WG effort. >>>>> >>>>> I would like to garner support from all 6MAN > members with >> full >>>> consensus >>>>> to change the existing RFC 4941 /64 fixed boundary > to /80 >> fixed >>>> boundary. >>>>> >>>>> Kind Regards >>>>> >>>>> Gyan >>>>> >>>>> On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern >>>> > > >> > >> >>>>> > >> > >>>> wrote: >>>>> >>>>> I am missing something in your reasoning. You seem to say at >>>>> one point that (to > paraphrase) "we >> can't >>>> do this >>>>> because it does not work with the existing UE > software". >>>>> Any new solution where a UE delegates based on any >> change of >>>> any kind >>>>> (including lengthening the prefix, shortening the >> prefix, or >>>> magically >>>>> incanting new prefixes) requires that the UE be >> upgraded to know >>>>> what to do with the information. I do not see how that >>>> differentiates any of >>>>> the solutions. (Except "don't do anything", > which I >> think we >>>> do not >>>>> want to take.) >>>>> >>>>> Yours, Joel >>>>> >>>>> On 11/19/2020 5:03 PM, Gyan Mishra wrote: >>>>>> >>>>>> >>>>>> On Thu, Nov 19, 2020 at 10:33 AM >> > > >>>> >> >>>>> >> > > >> >>> >>>>>> >> > > >> >> >>>> > >> > >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 19 Nov 2020, at 14:58, Gyan Mishra >>>>> > >> > >> >>>> > >> > >>> >>>>>> >> > >>>> >> >>>>> >> > >>>> >> >>>>> wrote: >>>>>>> >>>>>>> You would need a new option. It > would likely be >>>> useful for the >>>>>> requesting router to indicate interest > in the >> option. Even >>>>> hinting >>>>>> at what prefix size it was expecting. >>>>>>> Now can you explain to me again the > reasons >> why this >>>>> approach is >>>>>> better than using the existing DHPCv6 > protocol >> packets? >>>>>>> >>>>>>> 3GPP gateway does not support DHCPv6 >>>>>> >>>>>> 3GPP gateway doesn't support new option. >> What's your >>>> point? >>>>>> >>>>>> >>>>>> >>>>>> The point of the v6ops presentation > and this >> email >>>> thread is >>>>> how to >>>>>> “extend a /64” in the 3GPP use case in > slide 1 of the >>>> deck you >>>>> compiled >>>>>> a list of options and of the two I had > highlighted >> in red >>>> were the >>>>>> 64share v2 Cameron’s option and the > variable slaac >>>> option. So on >>>>> the >>>>>> call this morning Lorenzo shot down 64share v2 >> shorter prefix >>>>> option as >>>>>> even if the 3GPP architecture was updated to >> support longer >>>>> prefixes and >>>>>> even is the 3GPP gateway was able to send a >> shorter prefix >>>> with A >>>>> flag >>>>>> not set, all mobile devices per Lorenzo’s point >> would be >>>> broken >>>>> as they >>>>>> would not accept the shorter let’s say /56 > prefix >> to build the >>>>> slaac 128 >>>>>> bit address. So the bottom line is the > 64share v2 >> won’t work >>>>> unless we >>>>>> update RFC 4291 and remove the 64 bit boundary. >>>>>> >>>>>> So we are back to square uno - no viable > solution >>>>>> >>>>>> So now we had thrown out the longer >64 > due to >> race to >>>> bottom >>>>> worries >>>>>> which I and others believe is Fud and as > described in >>>> slide 10 of >>>>> the >>>>>> v6ops “race to the bottom slide”. >>>>>> >>>>>> So a happy medium /80 fixed boundary I came up >> with that I >>>> think >>>>> solves >>>>>> a lot of the issue and not just the 3GPP > initial >>>> segmentation of >>>>>> downstream devices problem statement. >>>>>> >>>>>> Since we have to update RFC 4291 for > 64share v2 to >> work >>>> anyways >>>>> to allow >>>>>> for shorter prefixes, why not instead > create a new >> bottom >>>> at /80 >>>>> giving >>>>>> 16 bits more of prefix length and shrinking the >> IID down >>>> to 48 bits. >>>>>> Doing so you would not even have to update > the 3GPP >>>> architecture >>>>> as I >>>>>> don’t know if that would fly or not. Also this >> solves a >>>> few other >>>>>> problems at the same time. >>>>>> >>>>>> >>>>>> As I mentioned in the v6ops deck presented that >> vlsm 0 to >>>> 128 is >>>>>> mainstream for operators for static > addressing on >> router >>>> and switch >>>>>> infrastructure and dhcpv6 subnets longer > prefixes >> for network >>>>>> infrastructure appliance clusters, NFV/VNF >> virtualization >>>> and server >>>>>> farms. On host subnets where there is a > chance of >> mix of >>>> slaac >>>>> hosts >>>>>> with dhcpv6 devices the prefix length is > stuck at >> /64. So on >>>>> these mix >>>>>> addressing host subnets we cannot do longer >> prefixes following >>>>> our ND >>>>>> cache hard limit mantra to prevent ND cache > exhaustion >>>> issues as >>>>>> described in RFC 6164. >>>>>> >>>>>> So with the /80 new fixed boundary shifting > prefix >> length >>>> 16 bits >>>>> longer >>>>>> and shortening the IID by 16 bits gives > resolved >> the 3GPP >>>> issue >>>>> which >>>>>> 64share can work as is and subtending to > downstream >>>> devices will now >>>>>> work as a /64 is now equivalent to a /48 > with 64k >> /80s. Also >>>>> BCP-690 >>>>>> for broadband not all operators have > adopted the >> shorter >>>> prefix >>>>> lengths >>>>>> /56 or /48 recommendations and now that’s > not an >> issue as the >>>>> /64 would >>>>>> now suffice. >>>>>> >>>>>> From an operators perspective that gain > allows at >> least >>>> for 3GPP >>>>>> massive growth and subtending with a single /64 >> allows the >>>> operators >>>>>> such as Verizon with massive subscriber base >> worldwide can >>>> stay with >>>>>> current allocations and don’t have to ask >>>> >> > > >> > > >>> for /10. >>>>>> >>>>>> As 5G gets rolled out with Enhanced VPN > framework >> and Network >>>>> slicing >>>>>> paradigm, the demand for shorter blocks and > wearable >>>> multiple /48 >>>>> will >>>>>> be our new reality. >>>>>> >>>>>> Making that 16 bit shift now to /80 making > a /64 >> the new >>>> /48 will >>>>> give >>>>>> broadband and 3GPP subscribers a ton of > space to >>>> subtending their >>>>>> networks we would be set for the future. >> Especially with >>>> IOT the >>>>> demand >>>>>> for subtending will continue to grow > astronomically. >>>>>> >>>>>> Also IANA does not have to get start in > allocating the >>>> other /3 and >>>>>> other available blocks. >>>>>> >>>>>> Lots of problems being solved here with a fixed >> /80 new >>>> boundary. >>>>>> >>>>>> Also with the existing random IID generation >> schemes which >>>> we have >>>>>> tested on Linux kernel can do longer p >>>>> >>>> >> > > > > > >>>refixes > > >>>> using RFC 4941 privacy >>>>>> extension or RFC 7217 stable IID. >>>>>> >>>>>> Win-Win for all. >>>>>> >>>>>> Ole >>>>>> >>>>>> -- >>>>>> >>>>>> > >> > >> >>>> > > >> > >>>> >>>>>> >>>>>> *Gyan Mishra* >>>>>> >>>>>> /Network Solutions A//rchitect / >>>>>> >>>>>> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ v6ops >>>>>> mailing list v6ops@ietf.org > > >> > >> >>>> > > >> > >>> >>>>>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >>>> >> >> >>>>> >> > >>>> >> >>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> > > >> > >>> >>>>> >>>>> *Gyan Mishra* >>>>> >>>>> /Network Solutions A//rchitect / >>>>> >>>>> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD >>>>> >>>>> >>>> >>>> -- >>>> >>>> > >> >>>> >>>> *Gyan Mishra* >>>> >>>> /Network Solutions A//rchitect / >>>> >>>> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD >>>> >>>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >>> >> >> > -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org >> > >> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > >> > >> > -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 23 10:06:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992993A0BFA; Mon, 23 Nov 2020 10:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W82CEyeB-uXS; Mon, 23 Nov 2020 10:06:00 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 271B73A0BF7; Mon, 23 Nov 2020 10:05:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0ANI5uIX005659; Mon, 23 Nov 2020 13:05:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606154757; bh=Mw6mNnCDSBd7xmuE5H9aZ5kJkf8PMVHRWITlVud1fIs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=po+cGMtJOFmbYjEIlbdC782i05fMUjbXa/JtvflFbyOgPKAJHhzpFL/3uJqci0BVA B0w1YrGmrou3UifWTk1hwVTnMVQOeeP1twtRTqpStPlJcl+3XnuSkMWsaRAX8a7OLF 1U/KrERIjIIzyHGxecxn2tCBtzeg+HtvwvdJDrCGa1oN8pYGOf+uNfbV96deIbIJvz JngU8AkczajHwtcmKX8NhbUtMj/Q4odm9TQCwiFtA4Fj5p8KD4I2XkeMEKUbtdvvHE 9HL5d9le9my3d4GqZRT228V0q6qt5xW4fqpU309JwaMJGSUH8KFGpa1/OtmM9fCPYS nEB2bAEaHFtrQ== Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0ANI3IQT002178 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 23 Nov 2020 13:03:18 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 23 Nov 2020 10:03:17 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 23 Nov 2020 10:03:17 -0800 From: "Templin (US), Fred L" To: Mark Smith CC: 6MAN <6man@ietf.org>, IPv6 Operations Thread-Topic: [v6ops] Next step? [Re: The bottom is /112] Thread-Index: AdbBs7DABd4VOkfZTvWrxcKqAP+vAgADhn6g Date: Mon, 23 Nov 2020 18:03:17 +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: [137.137.12.6] x-tm-snts-smtp: D9D13AB51ABDE03529B8D0E8BDAE74FA524E14BF735A74DD136840E6AC7A95B72000:8 Content-Type: multipart/alternative; boundary="_000_c415d3fb4d854ae397b5f426bb15eed6boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] Next step? [Re: The bottom is /112] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 18:06:03 -0000 --_000_c415d3fb4d854ae397b5f426bb15eed6boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGl0IGlzIGFsc28gd29ydGggdW5kZXJzdGFuZGluZyBpbiB0aGUgYWxnb3JpdGhtIGJlbG93 IHRoYXQgdGhlIHJlcXVlc3Rpbmcgcm91dGVyDQpnZXRzIGJhY2sgYW4gUkEgbWVzc2FnZSB3aXRo IGEgdW5pY2FzdCBkZXN0aW5hdGlvbiBhZGRyZXNzIHRoYXQgaXMgKmRpZmZlcmVudCoNCnRoYW4g dGhlIHVuaWNhc3Qgc291cmNlIGFkZHJlc3MgdGhhdCBpdCBzZW50IGluIHRoZSBSUy4gVGhhdCBp cyBieSBkZXNpZ24sIGFzIHRoZQ0KUkEgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBjb25maWd1cmVk IGJ5IHRoZSBkZWxlZ2F0aW5nIHJvdXRlciBhbmQgYXNzaWduZWQgdG8NCnRoZSByZXF1ZXN0aW5n IHJvdXRlci4NCg0KVGhlIHJlcXVlc3Rpbmcgcm91dGVyIG11c3QgdGhlcmVmb3JlIGJlIHByZXBh cmVkIHRvIHJlY2VpdmUgYW4gUkEgbWVzc2FnZQ0Kc2VudCB0byBhIHVuaWNhc3QgZGVzdGluYXRp b24gYWRkcmVzcyB0aGF0IGlzIG5vdCBjdXJyZW50bHkgYXNzaWduZWQgdG8gdGhlIHJlY2Vpdmlu Zw0KaW50ZXJmYWNlLiBPbmNlIHRoZSByZXF1ZXN0aW5nIHJvdXRlciByZWNlaXZlcyB0aGUgUkEg bWVzc2FnZSwgaG93ZXZlciwgaXQgYXNzaWducw0KdGhlIHVuaWNhc3QgZGVzdGluYXRpb24gYWRk cmVzcyAoaS5lLiwgYW4gT01OSSBMTEEpIHRvIHRoZSByZWNlaXZpbmcgaW50ZXJmYWNlLiBUaGlz DQpwcm92aWRlcyBhbiBlZmZpY2llbnQgbWVhbnMgZm9yIHRoZSBuZXR3b3JrIHRvIHByb3Zpc2lv biBjbGllbnRzIHdpdGggYXNzdXJlZC11bmlxdWUNCkxMQXMgd2l0aG91dCByZXF1aXJpbmcgdGhl IGNsaWVudHMgdG8gaW52b2tlIERBRC4NCg0KRnJlZA0KDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2 Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiAoVVMpLCBGcmVkIEwNClNl bnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMjAgODoyNCBBTQ0KVG86IE1hcmsgU21pdGggPG1h cmt6enpzbWl0aEBnbWFpbC5jb20+DQpDYzogNk1BTiA8Nm1hbkBpZXRmLm9yZz47IElQdjYgT3Bl cmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBOZXh0IHN0ZXA/ IFtSZTogVGhlIGJvdHRvbSBpcyAvMTEyXQ0KDQpNYXJrLCBteSBpbml0aWFsIGRlc2NyaXB0aW9u IHdhcyBwdXJwb3NlZnVsbHkgbGlnaHQgb24gZGV0YWlscyBidXQgdG8gZ2V0IHRoZSBmdWxsIHBp Y3R1cmUNCnlvdSBjYW4gaGF2ZSBhIGxvb2sgYXQgdGhlIGZvbGxvd2luZyBkcmFmdDoNCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi02bWFuLWxsYS10eXBl Lw0KDQpUaGUgaWRlYSBmb3IgdGhpcyBMTEEtYmFzZWQgUEQgc2NoZW1lIGlzIGFzIGZvbGxvd3M6 DQoNCjEpIFRoZSByZXF1ZXN0aW5nIHJvdXRlciBjcmVhdGVzIGEgdGVtcG9yYXJ5IExMQSB1c2lu ZyBSRkM0OTQxKGJpcykgYW5kIHNldHMgYSBwcmVmaXggbGVuZ3RoDQppbmRpY2F0aW9uIGluc2lk ZSB0aGUgTExBIGl0c2VsZi4gVGhlIFJSIHRoZW4gdXNlcyB0aGUgTExBIGFzIHRoZSBJUHY2IHNv dXJjZSBhZGRyZXNzIG9mIGFuIFJTDQptZXNzYWdlIHRvIHNlbmQgdG8gdGhlIGRlbGVnYXRpbmcg cm91dGVyLg0KDQoyKSBXaGVuIHRoZSBkZWxlZ2F0aW5nIHJvdXRlciByZWNlaXZlcyB0aGUgUlMs IGl0IHNlZXMgdGhhdCB0aGUgSVB2NiBzb3VyY2UgaXMgYW4gUkZDNDk0MShiaXMpDQphZGRyZXNz IHdpdGggYSBub24temVybyBwcmVmaXggbGVuZ3RoIGluZGljYXRpb24uIFRoZSBEUiB0aGVuIGNv b3JkaW5hdGVzIHdpdGggdGhlIERIQ1B2Ng0Kc2VydmVyIHRvIHJlcXVlc3QgYSBQRCBvZiB0aGUg bGVuZ3RoIGluZGljYXRlZCBieSB0aGUgUlIuDQoNCjMpIFdoZW4gdGhlIERSIHJlY2VpdmVzIHRo ZSBQRCBmcm9tIHRoZSBESENQdjYgc2VydmVyLCBpdCBjcmVhdGVzIGFuIE9NTkkgTExBIGJ5DQpl bWJlZGRpbmcgdGhlIGRlbGVnYXRlZCBwcmVmaXggaW4gdGhlIElJRCBvZiBmZTgwOjovNjQsIGUu Zy4sIGFzIGZlODA6OjIwMDE6ZGI4OjE6Mi4NClRoZSBEUiB0aGVuIHNldHMgYSBwcmVmaXggbGVu Z3RoIGluZGljYXRpb24gaW4gdGhlIE9NTkkgTExBLCBhbmQgc2V0cyB0aGUgTExBIGFzIHRoZQ0K ZGVzdGluYXRpb24gYWRkcmVzcyBvZiBhbiBSQSBtZXNzYWdlIHRvIHNlbmQgYmFjayB0byB0aGUg UlIuDQoNCjQpIFdoZW4gdGhlIFJSIHJlY2VpdmVzIHRoZSBSQSBtZXNzYWdlLCBpdCBzZWVzIHRo YXQgdGhlIGRlc3RpbmF0aW9uIGlzIGFuIE9NTkkgTExBDQp3aXRoIGEgbm9uLXplcm8gcHJlZml4 IGxlbmd0aC4gVGhlIFJSIHRoZW4gdXNlcyB0aGUgZW1iZWRkZWQgcHJlZml4IHdpdGhpbiB0aGUg T01OSQ0KTExBIGFzIGl0cyBkZWxlZ2F0ZWQgcHJlZml4LCBhbmQgcmVnYXJkcyB0aGUgUm91dGVy IExpZmV0aW1lIGFzIHRoZSB0aW1lIGF0IHdoaWNoIHRoZQ0KZGVsZWdhdGVkIHByZWZpeCBuZWVk cyB0byBiZSByZW5ld2VkLg0KDQpZb3UgYWxzbyBhc2tlZCBhYm91dCB0aGUgbG9uZy1saXZlZCB1 c2FnZSBvZiB1bmlxdWUgTExBcywgYW5kIEkgdGhpbmsgd2hhdCB3ZSBuZWVkDQp0byBjb25zaWRl ciBpcyB0aGF0IElQdjYgaW50ZXJmYWNlcyBtYXkgY29uZmlndXJlIG11bHRpcGxlIExMQXMgb2Yg bXVsdGlwbGUgZGlmZmVyZW50DQp0eXBlcy4gVGhlIHR5cGVzIG5lZWQgdG8gYmUgY29vcmRpbmF0 ZWQgc28gdGhhdCB0aGV5IGRvIG5vdCBjb2xsaWRlIHdpdGggb25lIGFub3RoZXINCmFuZCBjYXVz ZSBkdXBsaWNhdGlvbi4gQWxsIG9mIHRoaXMgaXMgZXhwbGFpbmVkIGluIHRoZSBkcmFmdCBjaXRl ZCBhYm92ZS4NCg0KVGhhbmtzIC0gRnJlZA0KDQoNCkZyb206IE1hcmsgU21pdGggW21haWx0bzpt YXJrenp6c21pdGhAZ21haWwuY29tXQ0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAyMiwgMjAyMCAx MjoxMCBQTQ0KVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4NCkNjOiBDYSBCeSA8Y2IubGlz dDZAZ21haWwuY29tPG1haWx0bzpjYi5saXN0NkBnbWFpbC5jb20+PjsgQnJpYW4gRSBDYXJwZW50 ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tPj47IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3Bz QGlldGYub3JnPj47IDZNQU4gPDZtYW5AaWV0Zi5vcmc8bWFpbHRvOjZtYW5AaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtFWFRFUk5BTF0gUmU6IFt2Nm9wc10gTmV4dCBzdGVwPyBbUmU6IFRoZSBi b3R0b20gaXMgLzExMl0NCg0KDQpUaGlzIG1lc3NhZ2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9m IEJvZWluZy4gUGxlYXNlIGRvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVu bGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhhdCB0aGUgY29udGVudCBp cyBzYWZlLg0KDQoNCg0KDQoNCk9uIE1vbiwgMjMgTm92IDIwMjAsIDAxOjU5IFRlbXBsaW4gKFVT KSwgRnJlZCBMLCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSGksIEkgYmVsaWV2ZSB0aGUgQUVSTy9PTU5JIGFwcHJv YWNoIHRvIHByZWZpeCBkZWxlZ2F0aW9uIHdvdWxkIGJlIGdvb2QgZm9yIHRoZSAzR1BQDQpjYXNl IGFsc28uIFRoZSBhcHByb2FjaCBpcyBwcmVkaWNhdGVkIG9uIHRoZSByb3V0ZXIgcmV0dXJuaW5n IGFuIFJBIHdpdGggYW4gSVB2NiBsaW5rLWxvY2FsDQpkZXN0aW5hdGlvbiBhZGRyZXNzIGRldGVy bWluZWQgYnkgdGhlIGRlbGVnYXRlZCBwcmVmaXguIFRoZSBsaW5rLWxvY2FsIGFkZHJlc3MgaXMg Zm9ybWVkDQpieSB3cml0aW5nIHRoZSBtb3N0IHNpZ25pZmljYW50IDY0IGJpdHMgb2YgdGhlIGRl bGVnYXRlZCBwcmVmaXggaW50byB0aGUgaW50ZXJmYWNlIElEIG9mIHRoZQ0KcHJlZml4IGZlODA6 Oi82NC4NCg0KRm9yIGV4YW1wbGUsIGlmIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHdlcmUgMjAwMTpk Yjg6MTowOjovNTYgdGhlbiB0aGUgSVB2NiBsaW5rLWxvY2FsDQpkZXN0aW5hdGlvbiBhZGRyZXNz IGlzIGZlODA6OjIwMDE6ZGI4OjE6MC4gVGhpcyBwcm92aWRlcyBhdCBsZWFzdCB0d28gaW1wb3J0 YW50DQpvcGVyYXRpb25hbCBhZHZhbnRhZ2VzLg0KDQoxKSBJdCBjb252ZXlzIHRoZSBkZWxlZ2F0 ZWQgcHJlZml4IGluIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIFJBIHNvIHRo YXQNCm5vIFBJT3MgaW5zaWRlIHRoZSBSQSBuZWVkIHRvIGJlIHVzZWQgZm9yIHByZWZpeCBkZWxl Z2F0aW9uLg0KDQpJbiBteSBvcGVyYXRpb25hbCBleHBlcmllbmNlIGl0IGlzIGZhciBiZXR0ZXIg dG8gbWFrZSB0aGluZ3MgZXhwbGljaXQgaW4gcGFja2V0cyByYXRoZXIgdGhhbiBpbXBsaWNpdC4N Cg0KU2VlIFJGQzg0NjkgZm9yIGFuIGV4YW1wbGUgb2Ygd2hlcmUgd2hhdCB3YXMgaW1wbGljaXQg aW4gcGFja2V0cyBoYXMgY2F1c2VkIHNvIG1hbnkgcHJvYmxlbXMgdGhhdCBub3cgYmVpbmcgZXhw bGljaXQgaGFzIGJlY29tZSB0aGUgcmVjb21tZW5kYXRpb24uIChBYnNlbmNlIG9mIHRoaXMgaW4g YSB3aG9sZXNhbGVyJ3MgbmV0d29yayBjYXVzZWQgdXMgYW5kIGEgY3VzdG9tZXIgbW9udGhzIG9m IHRyb3VibGVzaG9vdGluZyBmb3IgdW51c3VhbCBwZXJmb3JtYW5jZSBwcm9ibGVtcywgYW5kIGlz IG5vdyBjb3N0aW5nIHVzIHNlcnZpY2Ugb3V0YWdlcyBmb3IgbWFueSBjdXN0b21lcnMgYXQgb25j ZSB3aGlsZSB0aGV5IHB1dCBpdCBpbiBwbGFjZS4pDQoNCg0KDQoyKSBJdCBzdXBwbGllcyB0aGUg bW9iaWxlIG5vZGUgd2l0aCBhIGd1YXJhbnRlZWQtdW5pcXVlIGxpbmstbG9jYWwgYWRkcmVzcyB0 aGF0DQppdCBjYW4gdXNlIGZvciBmdXR1cmUgY29tbXVuaWNhdGlvbnMgd2l0aG91dCB0aGUgbmVl ZCB0byBwZXJmb3JtIERBRC4NCg0KDQpTbyB0aGUgUkEgREEgaXMgY2FycmllcyBib3RoIGRlbGVn YXRlZCBwcmVmaXggaW5mb3JtYXRpb24gYW5kIHdpdGggbGluay1sb2NhbCBhZGRyZXNzIGNvbmZp Z3VyYXRpb24gdG9vPyBIb3cgZG9lcyBhIG5vZGUga25vdyB0byB1c2UgdGhlIFJBIERBIGFzIGl0 cyBsaW5rLWxvY2FsIGFkZHJlc3M/DQoNCldpdGggdGhlIHJpc2Ugb2Ygd2lyZWxlc3Mgd2UgbmVl ZCB0byBjYXJlIGFib3V0IHRoZSBnbG9iYWwgdHJhY2VhYmlsaXR5IG9mIGxpbmstbG9jYWwgYWRk cmVzc2VzIHRvby4gUGVyc2lzdGVudCwgZ2xvYmFsbHkgdW5pcXVlIGxpbmstbG9jYWwgSUlEcyBo YXZlIHRoZSBzYW1lIHByaXZhY3kgaW1wbGljYXRpb25zIGFzIHBlcnNpc3RlbnQgZ2xvYmFsbHkg dW5pcXVlIFdpRmkgTUFDIGFkZHJlc3NlcyBhbmQgQmx1ZXRvb3RoIE1BQyBhZGRyZXNzZXMuDQoN CkhhdmUgYSBsb29rIGF0IGh0dHBzOi8vd2lnbGUubmV0IGFuZCB0aGUgQW5kcm9pZCBhcHAgZm9y IGNvbGxlY3RpbmcgdGhlIGRhdGEuDQoNCkEgc2ltaWxhciBhcHAgZm9jdXNlZCBvbiBCbHVldG9v dGggaXMgUmFtYmxlLg0KDQpOZWl0aGVyIG9mIHRoZXNlIGFwcHMgcmVxdWlyZSBhIGhhY2tlZCBw aG9uZSwgdGhlIGNhbiBqdXN0IGJlIGluc3RhbGxlZCBhbmQgcnVuIGJ5IGFueWJvZHkgZnJvbSB0 aGUgR29vZ2xlIGFwcCBzdG9yZS4NCg0KDQpBZ2FpbiwgdGhlIHByb3Bvc2FsIGNvbWVzIGZyb20g dGhlIEFFUk8vT01OSSB1c2UgY2FzZSwgYnV0IEkgYmVsaWV2ZSBpcyBhbHNvDQpnb29kIGZvciAz R1BQIGFuZCByZWFsbHkgYW55IG90aGVyIHdpcmVsZXNzIHVzZSBjYXNlIHdoZXJlIGEgbGlnaHR3 ZWlnaHQNCnByZWZpeCBkZWxlZ2F0aW9uIGNhcGFiaWxpdHkgaXMgZGVzaXJlZC4NCg0KRnJlZA0K --_000_c415d3fb4d854ae397b5f426bb15eed6boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGksIGl0IGlzIGFsc28gd29ydGggdW5kZXJzdGFuZGluZyBpbiB0aGUgYWxnb3Jp dGhtIGJlbG93IHRoYXQgdGhlIHJlcXVlc3Rpbmcgcm91dGVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmdl dHMgYmFjayBhbiBSQSBtZXNzYWdlIHdpdGggYSB1bmljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mg dGhhdCBpcyAqPGI+ZGlmZmVyZW50PC9iPio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhhbiB0aGUgdW5p Y2FzdCBzb3VyY2UgYWRkcmVzcyB0aGF0IGl0IHNlbnQgaW4gdGhlIFJTLiBUaGF0IGlzIGJ5IGRl c2lnbiwgYXMgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJBIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMg Y29uZmlndXJlZCBieSB0aGUgZGVsZWdhdGluZyByb3V0ZXIgYW5kIGFzc2lnbmVkIHRvPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPnRoZSByZXF1ZXN0aW5nIHJvdXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSByZXF1ZXN0aW5nIHJvdXRlciBtdXN0IHRoZXJlZm9y ZSBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGFuIFJBIG1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ c2VudCB0byBhIHVuaWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyB0aGF0IGlzIG5vdCBjdXJyZW50 bHkgYXNzaWduZWQgdG8gdGhlIHJlY2VpdmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pbnRlcmZhY2Uu IE9uY2UgdGhlIHJlcXVlc3Rpbmcgcm91dGVyIHJlY2VpdmVzIHRoZSBSQSBtZXNzYWdlLCBob3dl dmVyLCBpdCBhc3NpZ25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZSB1bmljYXN0IGRlc3RpbmF0aW9u IGFkZHJlc3MgKGkuZS4sIGFuIE9NTkkgTExBKSB0byB0aGUgcmVjZWl2aW5nIGludGVyZmFjZS4g VGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5wcm92aWRlcyBhbiBlZmZpY2llbnQgbWVhbnMgZm9yIHRo ZSBuZXR3b3JrIHRvIHByb3Zpc2lvbiBjbGllbnRzIHdpdGggYXNzdXJlZC11bmlxdWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+TExBcyB3aXRob3V0IHJlcXVpcmluZyB0aGUgY2xpZW50cyB0byBpbnZva2Ug REFELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlRlbXBsaW4gKFVTKSwgRnJlZCBMPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92 ZW1iZXIgMjMsIDIwMjAgODoyNCBBTTxicj4NCjxiPlRvOjwvYj4gTWFyayBTbWl0aCAmbHQ7bWFy a3p6enNtaXRoQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IDZNQU4gJmx0OzZtYW5AaWV0 Zi5vcmcmZ3Q7OyBJUHY2IE9wZXJhdGlvbnMgJmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBOZXh0IHN0ZXA/IFtSZTogVGhlIGJvdHRvbSBpcyAv MTEyXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYXJrLCBteSBpbml0aWFsIGRlc2NyaXB0aW9uIHdh cyBwdXJwb3NlZnVsbHkgbGlnaHQgb24gZGV0YWlscyBidXQgdG8gZ2V0IHRoZSBmdWxsIHBpY3R1 cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+eW91IGNhbiBoYXZlIGEgbG9vayBhdCB0aGUgZm9sbG93aW5n IGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi02bWFuLWxs YS10eXBlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi02 bWFuLWxsYS10eXBlLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoZSBpZGVhIGZvciB0aGlzIExMQS1iYXNlZCBQRCBzY2hlbWUgaXMgYXMgZm9sbG93czo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjEpIFRoZSByZXF1ZXN0 aW5nIHJvdXRlciBjcmVhdGVzIGEgdGVtcG9yYXJ5IExMQSB1c2luZyBSRkM0OTQxKGJpcykgYW5k IHNldHMgYSBwcmVmaXggbGVuZ3RoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmluZGljYXRpb24gaW5zaWRl IHRoZSBMTEEgaXRzZWxmLiBUaGUgUlIgdGhlbiB1c2VzIHRoZSBMTEEgYXMgdGhlIElQdjYgc291 cmNlIGFkZHJlc3Mgb2YgYW4gUlM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bWVzc2FnZSB0byBzZW5kIHRv IHRoZSBkZWxlZ2F0aW5nIHJvdXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjIpIFdoZW4gdGhlIGRlbGVnYXRpbmcgcm91dGVyIHJlY2VpdmVzIHRoZSBSUywg aXQgc2VlcyB0aGF0IHRoZSBJUHY2IHNvdXJjZSBpcyBhbiBSRkM0OTQxKGJpcyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+YWRkcmVzcyB3aXRoIGEgbm9uLXplcm8gcHJlZml4IGxlbmd0aCBpbmRpY2F0aW9u LiBUaGUgRFIgdGhlbiBjb29yZGluYXRlcyB3aXRoIHRoZSBESENQdjY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+c2VydmVyIHRvIHJlcXVlc3QgYSBQRCBvZiB0aGUgbGVuZ3RoIGluZGljYXRlZCBieSB0aGUg UlIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4zKSBXaGVuIHRo ZSBEUiByZWNlaXZlcyB0aGUgUEQgZnJvbSB0aGUgREhDUHY2IHNlcnZlciwgaXQgY3JlYXRlcyBh biBPTU5JIExMQSBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5lbWJlZGRpbmcgdGhlIGRlbGVnYXRlZCBw cmVmaXggaW4gdGhlIElJRCBvZiBmZTgwOjovNjQsIGUuZy4sIGFzIGZlODA6OjIwMDE6ZGI4OjE6 Mi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIERSIHRoZW4gc2V0cyBhIHByZWZpeCBsZW5ndGggaW5k aWNhdGlvbiBpbiB0aGUgT01OSSBMTEEsIGFuZCBzZXRzIHRoZSBMTEEgYXMgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPmRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgYW4gUkEgbWVzc2FnZSB0byBzZW5kIGJh Y2sgdG8gdGhlIFJSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ NCkgV2hlbiB0aGUgUlIgcmVjZWl2ZXMgdGhlIFJBIG1lc3NhZ2UsIGl0IHNlZXMgdGhhdCB0aGUg ZGVzdGluYXRpb24gaXMgYW4gT01OSSBMTEE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aCBhIG5vbi16 ZXJvIHByZWZpeCBsZW5ndGguIFRoZSBSUiB0aGVuIHVzZXMgdGhlIGVtYmVkZGVkIHByZWZpeCB3 aXRoaW4gdGhlIE9NTkk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TExBIGFzIGl0cyBkZWxlZ2F0ZWQgcHJl Zml4LCBhbmQgcmVnYXJkcyB0aGUgUm91dGVyIExpZmV0aW1lIGFzIHRoZSB0aW1lIGF0IHdoaWNo IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kZWxlZ2F0ZWQgcHJlZml4IG5lZWRzIHRvIGJlIHJlbmV3 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb3UgYWxzbyBh c2tlZCBhYm91dCB0aGUgbG9uZy1saXZlZCB1c2FnZSBvZiB1bmlxdWUgTExBcywgYW5kIEkgdGhp bmsgd2hhdCB3ZSBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvIGNvbnNpZGVyIGlzIHRoYXQgSVB2 NiBpbnRlcmZhY2VzIG1heSBjb25maWd1cmUgbXVsdGlwbGUgTExBcyBvZiBtdWx0aXBsZSBkaWZm ZXJlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dHlwZXMuIFRoZSB0eXBlcyBuZWVkIHRvIGJlIGNvb3Jk aW5hdGVkIHNvIHRoYXQgdGhleSBkbyBub3QgY29sbGlkZSB3aXRoIG9uZSBhbm90aGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPmFuZCBjYXVzZSBkdXBsaWNhdGlvbi4gQWxsIG9mIHRoaXMgaXMgZXhwbGFp bmVkIGluIHRoZSBkcmFmdCBjaXRlZCBhYm92ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gTWFyayBTbWl0aCBbPGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5j b20iPm1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBTdW5kYXksIE5vdmVtYmVyIDIyLCAyMDIwIDEyOjEwIFBNPGJyPg0KPGI+VG86PC9iPiBUZW1w bGluIChVUyksIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20iPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g Q2EgQnkgJmx0OzxhIGhyZWY9Im1haWx0bzpjYi5saXN0NkBnbWFpbC5jb20iPmNiLmxpc3Q2QGdt YWlsLmNvbTwvYT4mZ3Q7OyBCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSI+YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPC9h PiZndDs7IElQdjYgT3BlcmF0aW9ucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn Ij52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7OyA2TUFOICZsdDs8YSBocmVmPSJtYWlsdG86Nm1hbkBp ZXRmLm9yZyI+Nm1hbkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb RVhURVJOQUxdIFJlOiBbdjZvcHNdIE5leHQgc3RlcD8gW1JlOiBUaGUgYm90dG9tIGlzIC8xMTJd PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk ZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO21h cmdpbi1sZWZ0Oi43NXB0O21hcmdpbi1yaWdodDouNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg c3R5bGU9ImJhY2tncm91bmQ6IzkxMEExOTtwYWRkaW5nOjUuMjVwdCAxLjVwdCA1LjI1cHQgMS41 cHQiPjwvdGQ+DQo8dGQgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7YmFja2dyb3Vu ZDojRkRGMkY0O3BhZGRpbmc6NS4yNXB0IDMuNzVwdCA1LjI1cHQgMTEuMjVwdDt3b3JkLXdyYXA6 YnJlYWstd29yZCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMTIxMjEiPlRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUg b2YgQm9laW5nLiBQbGVhc2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMg dW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250ZW50 IGlzIHNhZmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T24g TW9uLCAyMyBOb3YgMjAyMCwgMDE6NTkgVGVtcGxpbiAoVVMpLCBGcmVkIEwsICZsdDs8YSBocmVm PSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQu TC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSwgSSBiZWxpZXZlIHRo ZSBBRVJPL09NTkkgYXBwcm9hY2ggdG8gcHJlZml4IGRlbGVnYXRpb24gd291bGQgYmUgZ29vZCBm b3IgdGhlIDNHUFA8YnI+DQpjYXNlIGFsc28uIFRoZSBhcHByb2FjaCBpcyBwcmVkaWNhdGVkIG9u IHRoZSByb3V0ZXIgcmV0dXJuaW5nIGFuIFJBIHdpdGggYW4gSVB2NiBsaW5rLWxvY2FsPGJyPg0K ZGVzdGluYXRpb24gYWRkcmVzcyBkZXRlcm1pbmVkIGJ5IHRoZSBkZWxlZ2F0ZWQgcHJlZml4LiBU aGUgbGluay1sb2NhbCBhZGRyZXNzIGlzIGZvcm1lZDxicj4NCmJ5IHdyaXRpbmcgdGhlIG1vc3Qg c2lnbmlmaWNhbnQgNjQgYml0cyBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbnRvIHRoZSBpbnRl cmZhY2UgSUQgb2YgdGhlPGJyPg0KcHJlZml4IGZlODA6Oi82NC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KRm9yIGV4YW1wbGUsIGlmIHRoZSBkZWxlZ2F0 ZWQgcHJlZml4IHdlcmUgMjAwMTpkYjg6MTowOjovNTYgdGhlbiB0aGUgSVB2NiBsaW5rLWxvY2Fs PGJyPg0KZGVzdGluYXRpb24gYWRkcmVzcyBpcyBmZTgwOjoyMDAxOmRiODoxOjAuIFRoaXMgcHJv dmlkZXMgYXQgbGVhc3QgdHdvIGltcG9ydGFudDxicj4NCm9wZXJhdGlvbmFsIGFkdmFudGFnZXMu PGJyPg0KPGJyPg0KMSkgSXQgY29udmV5cyB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbiB0aGUgSVB2 NiBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBSQSBzbyB0aGF0PGJyPg0Kbm8gUElPcyBpbnNp ZGUgdGhlIFJBIG5lZWQgdG8gYmUgdXNlZCBmb3IgcHJlZml4IGRlbGVnYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SW4gbXkgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBpdCBpcyBmYXIgYmV0dGVyIHRvIG1ha2Ug dGhpbmdzIGV4cGxpY2l0IGluIHBhY2tldHMgcmF0aGVyIHRoYW4gaW1wbGljaXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlZSBSRkM4NDY5IGZvciBhbiBl eGFtcGxlIG9mIHdoZXJlIHdoYXQgd2FzIGltcGxpY2l0IGluIHBhY2tldHMgaGFzIGNhdXNlZCBz byBtYW55IHByb2JsZW1zIHRoYXQgbm93IGJlaW5nIGV4cGxpY2l0IGhhcyBiZWNvbWUgdGhlIHJl Y29tbWVuZGF0aW9uLiAoQWJzZW5jZSBvZiB0aGlzIGluIGEgd2hvbGVzYWxlcidzDQogbmV0d29y ayBjYXVzZWQgdXMgYW5kIGEgY3VzdG9tZXIgbW9udGhzIG9mIHRyb3VibGVzaG9vdGluZyBmb3Ig dW51c3VhbCBwZXJmb3JtYW5jZSBwcm9ibGVtcywgYW5kIGlzIG5vdyBjb3N0aW5nIHVzIHNlcnZp Y2Ugb3V0YWdlcyBmb3IgbWFueSBjdXN0b21lcnMgYXQgb25jZSB3aGlsZSB0aGV5IHB1dCBpdCBp biBwbGFjZS4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KMikgSXQgc3VwcGxpZXMgdGhlIG1vYmlsZSBu b2RlIHdpdGggYSBndWFyYW50ZWVkLXVuaXF1ZSBsaW5rLWxvY2FsIGFkZHJlc3MgdGhhdDxicj4N Cml0IGNhbiB1c2UgZm9yIGZ1dHVyZSBjb21tdW5pY2F0aW9ucyB3aXRob3V0IHRoZSBuZWVkIHRv IHBlcmZvcm0gREFELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U28gdGhl IFJBIERBIGlzIGNhcnJpZXMgYm90aCBkZWxlZ2F0ZWQgcHJlZml4IGluZm9ybWF0aW9uIGFuZCB3 aXRoIGxpbmstbG9jYWwgYWRkcmVzcyBjb25maWd1cmF0aW9uIHRvbz8gSG93IGRvZXMgYSBub2Rl IGtub3cgdG8gdXNlIHRoZSBSQSBEQSBhcyBpdHMgbGluay1sb2NhbCBhZGRyZXNzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaXRoIHRoZSByaXNlIG9mIHdp cmVsZXNzIHdlIG5lZWQgdG8gY2FyZSBhYm91dCB0aGUgZ2xvYmFsIHRyYWNlYWJpbGl0eSBvZiBs aW5rLWxvY2FsIGFkZHJlc3NlcyB0b28uIFBlcnNpc3RlbnQsIGdsb2JhbGx5IHVuaXF1ZSBsaW5r LWxvY2FsIElJRHMgaGF2ZSB0aGUgc2FtZSBwcml2YWN5IGltcGxpY2F0aW9ucw0KIGFzIHBlcnNp c3RlbnQgZ2xvYmFsbHkgdW5pcXVlIFdpRmkgTUFDIGFkZHJlc3NlcyBhbmQgQmx1ZXRvb3RoIE1B QyBhZGRyZXNzZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkhhdmUgYSBsb29rIGF0DQo8YSBocmVmPSJodHRwczovL3dpZ2xlLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd2lnbGUubmV0PC9hPiBhbmQgdGhlIEFuZHJvaWQgYXBwIGZvciBjb2xsZWN0 aW5nIHRoZSBkYXRhLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5BIHNpbWlsYXIgYXBwIGZvY3VzZWQgb24gQmx1ZXRvb3RoIGlzIFJhbWJsZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TmVpdGhlciBvZiB0aGVz ZSBhcHBzIHJlcXVpcmUgYSBoYWNrZWQgcGhvbmUsIHRoZSBjYW4ganVzdCBiZSBpbnN0YWxsZWQg YW5kIHJ1biBieSBhbnlib2R5IGZyb20gdGhlIEdvb2dsZSBhcHAgc3RvcmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkFnYWluLCB0aGUgcHJvcG9z YWwgY29tZXMgZnJvbSB0aGUgQUVSTy9PTU5JIHVzZSBjYXNlLCBidXQgSSBiZWxpZXZlIGlzIGFs c288YnI+DQpnb29kIGZvciAzR1BQIGFuZCByZWFsbHkgYW55IG90aGVyIHdpcmVsZXNzIHVzZSBj YXNlIHdoZXJlIGEgbGlnaHR3ZWlnaHQ8YnI+DQpwcmVmaXggZGVsZWdhdGlvbiBjYXBhYmlsaXR5 IGlzIGRlc2lyZWQuPGJyPg0KPGJyPg0KRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c415d3fb4d854ae397b5f426bb15eed6boeingcom_-- From nobody Mon Nov 23 10:12:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE2E3A05F8; Mon, 23 Nov 2020 10:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.154 X-Spam-Level: *** X-Spam-Status: No, score=3.154 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=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 2mgoxXr5lTwx; Mon, 23 Nov 2020 10:12:34 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 326B63A0596; Mon, 23 Nov 2020 10:12:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0ANICW7K017969; Mon, 23 Nov 2020 19:12:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EDE78208FE8; Mon, 23 Nov 2020 19:12:31 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DB9F0208F99; Mon, 23 Nov 2020 19:12:31 +0100 (CET) Received: from [10.11.240.70] ([10.11.240.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0ANICVJW030728; Mon, 23 Nov 2020 19:12:31 +0100 To: Mikael Abrahamsson , Gyan Mishra Cc: 6MAN <6man@ietf.org>, IPv6 Operations References: From: Alexandre Petrescu Message-ID: Date: Mon, 23 Nov 2020 19:12:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 18:12:36 -0000 Le 23/11/2020 à 13:24, Mikael Abrahamsson a écrit : > On Mon, 23 Nov 2020, Gyan Mishra wrote: > >> How do we propose to solve this problem if operators don’t support >> PD even though the 3GPP standard has supported PD for over 10 >> years. >> >> Another twist to this puzzle is Android has 90% of the mobile >> handset marketplace worldwide and adamantly states they will NOT >> support DHCPv6 or PD. >> >> I researched Apple which has 10% of the market and they also do >> not support PD. >> >> Whats the solution now? > > The obvious use-case for PD is the "LTE router" fixed-wireless > use-case. There the problem of getting a DHCPv6-PD client into the > UE isn't the same as on handsets. A lot of those platforms already > support DHCPv6-PD for their wired versions (some have both LTE and > wired WAN). > > So this brings us back to the mobile core. Why doesn't this today, 8 > years after DHCPv6-PD was introduced in 3GPP standards, still not > support PD? > > I don't know but I know staff at operators who claim to have tried > (more than 5 years ago). I do not know why their efforts failed. > Perhaps the mobile core vendors successfully managed to divide the > customer base so there was no critical mass. I can only speculate. > I just find it weird that there are now demands to change > *everything* downstream from the 3GPP bearer to handle smaller > subnets instead of enabling PD in mobile core. It is an interesting note. Put that way indeed it looks weird. Indeed a variable length plen in SLAAC with a non 64bit IID would be changes downstream rather than upstream. I can say however that such a change could also accommodate the upstream; if the RA from PGW ('P' Gateway in 3GPP network) contained a /56, and if we didnt want to create a new option in RA, then it would be necessary to use an IID of length 72. At which point operators might complain about a 'race to the up' if I can say so. It might be that after many efforts, discussion, software written, trials, some people tend to conclude that changes in the 3GPP iface to mobile are hardly feasible with respect to that /64. Weird it is, I agree. Alex > From nobody Mon Nov 23 12:23:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F5B3A0DA1; Mon, 23 Nov 2020 12:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4uEW80PaIMB; Mon, 23 Nov 2020 12:23:32 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440B43A0DA2; Mon, 23 Nov 2020 12:23:32 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id w187so1513105pfd.5; Mon, 23 Nov 2020 12:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=k5yUgDdS5ceT8RJfWmjh5NXEBObz9rs+Z5PEZnwgV/g=; b=OYMIeDiN2j+ELmuBPpSeE9T2tyMaBuozQd8e59EDePm6UE3J5OjW6FRrfVIrgkn34W zch+lFivz6PsAA4u7S1DmghdZWBqy27qBLIm40F9RRvnO98IxMc6dujEYhJB7v7J6qyv BkaQDnZYun92GtUKY87tu54sZyFvdiPvOxU8o8GS8U0Hbq321pfB38mVFVYyxHQaV35C Fb4RXAbHLtf1qSQid7NcB453bXJ8KomsBnUkNjScwibep4qjt/5SwnPN5FIslAfxwajI G2y1YwwO7GacgGQSOXPtXqzNl3i4SzdyXJyWyHElWALdaqWSdnie7u+MViXaIBWYXWGO QGBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k5yUgDdS5ceT8RJfWmjh5NXEBObz9rs+Z5PEZnwgV/g=; b=lW0ITM+UrlL8z0EofrnNz3pO2e7kORzgjWIOupfmgvjWBQCYQFDCNo5d5dsxpGn5/Z 9XYArpYUJ7x1r+Xgecev/KhnCJQ34dOewL36J/LQOyKFMPH0RXjxU3X+iC6MfjRDLoQy 1mZnLA7LT75VmZc1z/ESUI+jTRCr+byerdtajnOGDz8uAdmAYoBqXD4HIMke/sDwlvHR 0y1pvMmy9jF7J2UNPVzKI0bVrqFWXofX5cczVlQP5bYn4pwdEddF1cgC8j/0Plz2PQ9S WJ5izkJnMiccdG2wrbYOWh8BEPo228Zu+Mg0up9k/ZAzh/0WJDeMLC07wovDOoGxKB+x v1pw== X-Gm-Message-State: AOAM530+7wlWS9PlPllkeMuRgkTWf0heu4GmMtZYY4o51vjBfnJSMgmN ZWcVYTYn+oQvT+KkXm7OGgU= X-Google-Smtp-Source: ABdhPJzi2L7UzanvyOx7UZKYzqZtt9WpDJNUNlMlDqP2HOFvHnWX6gb1i0+/kCUXTm8D6ByiZLRwPQ== X-Received: by 2002:a63:4450:: with SMTP id t16mr970111pgk.312.1606163011717; Mon, 23 Nov 2020 12:23:31 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id m4sm5963700pfd.203.2020.11.23.12.23.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Nov 2020 12:23:30 -0800 (PST) To: "Pascal Thubert (pthubert)" , Gyan Mishra , "otroan@employees.org" Cc: IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> From: Brian E Carpenter Message-ID: <70755435-26f9-4c48-a9ae-2b7eb521f8a1@gmail.com> Date: Tue, 24 Nov 2020 09:23:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 20:23:34 -0000 I've had several guesses but RFC 8929 still puzzles me :-) Regards Brian On 23-Nov-20 22:03, Pascal Thubert (pthubert) wrote: > Hello Brian >=20 > Please note that RFC 8929 would work there too -that's proxy ND with th= e backbone on the Wi-Fi link and the wireless access on the 3GPP link-, u= sed in the routing proxy mode - that's when the links are not bridgeable-= =2E. > Basically the phone as a routing proxy installs host (connected) routes= towards the 3GPP link for the addresses present there, and defends those= addresses over the Wi-Fi Link. > On paper the result is similar to RFC 7278, but the method is a bit dif= ferent since internally it relies on ND proxy as opposed to anycast. Argu= ably the phone would self-assign another global address on the Wi-Fi link= , if it cares to have one at all on that link. > Bottom line is yes, I agree we should consider the applicability of wha= t we have before we start breaking things down. >=20 > Keep safe; >=20 > Pascal >=20 >> -----Original Message----- >> From: v6ops On Behalf Of Brian E Carpenter >> Sent: jeudi 19 novembre 2020 23:50 >> To: Gyan Mishra ; otroan@employees.org >> Cc: IPv6 Operations ; 6MAN <6man@ietf.org>; JORDI PALE= T >> MARTINEZ >> Subject: Re: [v6ops] The bottom is /112 >> >> And if we had left the boundary at /80, as it was in 1995 (RFC1884), w= ould you >> now be arguing for /96, since in that case 3GPP would have settled on = /80? >> >> Sorry, but this is exactly and precisely a 16-bit jump in the race to = the bottom. >> And it breaks all existing SLAAC hosts on the way. >> >> The problem here is caused by 3GPP, but a solution like Cameron's shou= ld work >> for everybody with minimal changes. >> >> Regards >> Brian >> >> On 20-Nov-20 11:03, Gyan Mishra wrote: >>> >>> >>> On Thu, Nov 19, 2020 at 10:33 AM > > wrote: >>> >>> >>> >>> > On 19 Nov 2020, at 14:58, Gyan Mishra > > wrote: >>> > >>> > You would need a new option. It would likely be useful for the = requesting >> router to indicate interest in the option. Even hinting at what prefix= size it was >> expecting. >>> > Now can you explain to me again the reasons why this approach i= s better >> than using the existing DHPCv6 protocol packets? >>> > >>> >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6 >>> >>> 3GPP gateway doesn't support new option. What's your point? >>> >>> >>> >>> =C2=A0 =C2=A0 The point of the v6ops presentation and this email thre= ad is how to =E2=80=9Cextend >> a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 of the deck you c= ompiled a list of options >> and of the two I had highlighted in red were the 64share v2 Cameron=E2= =80=99s option >> and the variable slaac option.=C2=A0 So on the call this morning Loren= zo shot down >> 64share v2 shorter prefix option as even if the 3GPP architecture was = updated >> to support longer prefixes and even is the 3GPP gateway was able to se= nd a >> shorter prefix with A flag not set, all mobile devices per Lorenzo=E2=80= =99s point would >> be broken as they would not accept the shorter let=E2=80=99s say /56 p= refix to build the >> slaac 128 bit address.=C2=A0 So the bottom line is the 64share v2 won=E2= =80=99t work unless >> we update RFC 4291 and remove the 64 bit boundary. >>> >>> =C2=A0So we are back to square uno - no viable solution >>> >>> =C2=A0So now we had thrown out the longer >64 due to race to bottom w= orries >> which I and others believe is Fud and as described in slide 10 of the = v6ops =E2=80=9Crace >> to the bottom slide=E2=80=9D. >>> >>> So a happy medium /80 fixed boundary I came up with that I think solv= es a lot >> of the issue and not just the 3GPP initial segmentation of downstream = devices >> problem statement. >>> >>> Since we have to update RFC 4291 for 64share v2 to work anyways to al= low >> for shorter prefixes, why not instead create a new bottom at /80 givin= g 16 bits >> more of prefix length and shrinking the IID down to 48 bits.=C2=A0 Doi= ng so you would >> not even have to update the 3GPP architecture as I don=E2=80=99t know = if that would fly >> or not.=C2=A0 Also this solves a few other problems at the same time. >>> >>> >>> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is main= stream >> for operators for static addressing on router and switch infrastructur= e and >> dhcpv6 subnets longer prefixes for network infrastructure appliance cl= usters, >> NFV/VNF virtualization and server farms.=C2=A0 On host subnets where t= here is a >> chance of mix of slaac hosts with dhcpv6 =C2=A0devices the prefix leng= th is stuck at >> /64.=C2=A0 So on these mix addressing host subnets we cannot do longer= prefixes >> following our ND cache hard limit mantra to prevent ND cache exhaustio= n issues >> as described in RFC 6164. >>> >>> So with the /80 new fixed boundary shifting prefix length 16 bits lon= ger and >> shortening the IID by 16 bits gives resolved the 3GPP issue which 64sh= are can >> work as is and subtending to downstream devices will now work as a /64= is now >> equivalent to a /48 with 64k /80s.=C2=A0 Also BCP-690 for broadband no= t all >> operators have adopted the shorter prefix lengths /56 or /48 >> recommendations =C2=A0and now that=E2=80=99s not an issue as the /64 w= ould now suffice. >>> >>> From an operators perspective that gain allows at least for 3GPP mass= ive >> growth and subtending with a single /64 allows the operators such as V= erizon >> with massive subscriber base worldwide can stay with current allocatio= ns and >> don=E2=80=99t have to ask for /10. >>> >>> As 5G gets rolled out with Enhanced VPN framework and Network slicing= >> paradigm, the demand for shorter blocks and wearable multiple /48 will= be our >> new reality. >>> >>> Making that 16 bit shift now to /80 making a /64 the new /48 will giv= e >> broadband and 3GPP subscribers a ton of space to subtending their netw= orks >> we would be set for the future.=C2=A0 Especially with IOT the demand f= or subtending >> will continue to grow astronomically. >>> >>> Also IANA does not have to get start in allocating the other /3 and o= ther >> available blocks. >>> >>> Lots of problems being solved here with a fixed /80 new boundary. >>> >>> Also with the existing random IID generation schemes which we have te= sted >> on Linux kernel can do longer prefixes using RFC 4941 privacy extensio= n or RFC >> 7217 stable IID. >>> >>> Win-Win for all. >>> >>> Ole >>> >>> -- >>> >>> >>> >>> *Gyan Mishra* >>> >>> /Network Solutions A//rchitect=C2=A0/ >>> >>> /M 301 502-1347 >>> 13101 Columbia Pike >>> /Silver Spring, MD >>> >>> >>> >>> _______________________________________________ >>> 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 Mon Nov 23 12:43:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A03A1160; Mon, 23 Nov 2020 12:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqG-P35Jfv44; Mon, 23 Nov 2020 12:42:59 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6963A1158; Mon, 23 Nov 2020 12:42:58 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id e8so4164819pfh.2; Mon, 23 Nov 2020 12:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=02Uv3vlUE1VCbcINvPDOri3z1/W20iy8mszMIvHO9p8=; b=VZWrpXNpXjq0XTnKxvKO/xG/me0hPiLrRFRngXnm2OQadHcHV/4dW9rlqXXgM49MqH BpD9JzyFi99QlLqNpK5md4+KaI58o+HcC6/jY2TuTsuxyYnIddCTDj87BiRpXwOaEMOi uN+Aj3kaQyuEyb6MsVur6Phx6kPCgkf5FVcfDSMNWIZt8c2wrIMA6FvmndJNENej24Uq HZuYlNQ67mZDli8B629QkRbMo3brOaSISnxvahCvcrnNPouH7fAQUs5gY0eZXEXxM+GB gCn8sPEGxvmFuetOcUSiZHZ/8c6vaxcOB671Tt5B4kFWdksE33zzQkKo11+S3EsV5qLQ uB+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=02Uv3vlUE1VCbcINvPDOri3z1/W20iy8mszMIvHO9p8=; b=KPSulaIyJ9Pwq2YTLGYVv0qhta7fya9IpRemhLc1OpNu7UnJbIlcvmLrihYC+xu4rL dbUrFdbLeIkOQBz4MZRItEs6IX65cFPQI07TZ/51Bx/k6+D5YmTfv83bWNix3T+lRkH8 U2toIFyccIGWYaTaQB8ZkOY5GBmsvOnyuglSiBClGG8MO0JCgApfnxtRCXf6CqB6ESTp b6U64koNq3Fosc/vxbh4mSvokVx/koaAIp6rxnxdXWXwfoXsJTOWJBLLR/ajtcd32y8I ttpt5xf/n+w3X2mi3JK4hrSt5yb1bNQLzQH/mtQ+1DgUzYTHUNNsqwnO/j3rVTkaN+no 8xiA== X-Gm-Message-State: AOAM530KiLzS87v5gcRz08xlJji/aUUq792dgtBM0m6RMZt7HXbsScAS cNMS4jrIleD7qGsmaxETxjI= X-Google-Smtp-Source: ABdhPJz7rDYPUTTZ/lDcaCRH2sm3zUlRqaN1C6FQro2WwScSPkpoV/L2fTQL9OM9vtrN8tGhNEmJnQ== X-Received: by 2002:a63:e849:: with SMTP id a9mr951389pgk.300.1606164178508; Mon, 23 Nov 2020 12:42:58 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id z22sm2975556pfn.153.2020.11.23.12.42.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Nov 2020 12:42:57 -0800 (PST) To: "Pascal Thubert (pthubert)" , Gyan Mishra , "otroan@employees.org" Cc: IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> <70755435-26f9-4c48-a9ae-2b7eb521f8a1@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <245adecc-b037-a837-4d61-84eb6bd39311@gmail.com> Date: Tue, 24 Nov 2020 09:42:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <70755435-26f9-4c48-a9ae-2b7eb521f8a1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 20:43:01 -0000 OK, that was cheating: citing an RFC the day before it was published ;-).= Regards Brian On 24-Nov-20 09:23, Brian E Carpenter wrote: > I've had several guesses but RFC 8929 still puzzles me :-) >=20 > Regards > Brian >=20 > On 23-Nov-20 22:03, Pascal Thubert (pthubert) wrote: >> Hello Brian >> >> Please note that RFC 8929 would work there too -that's proxy ND with t= he backbone on the Wi-Fi link and the wireless access on the 3GPP link-, = used in the routing proxy mode - that's when the links are not bridgeable= -.. >> Basically the phone as a routing proxy installs host (connected) route= s towards the 3GPP link for the addresses present there, and defends thos= e addresses over the Wi-Fi Link. >> On paper the result is similar to RFC 7278, but the method is a bit di= fferent since internally it relies on ND proxy as opposed to anycast. Arg= uably the phone would self-assign another global address on the Wi-Fi lin= k, if it cares to have one at all on that link. >> Bottom line is yes, I agree we should consider the applicability of wh= at we have before we start breaking things down. >> >> Keep safe; >> >> Pascal >> >>> -----Original Message----- >>> From: v6ops On Behalf Of Brian E Carpenter >>> Sent: jeudi 19 novembre 2020 23:50 >>> To: Gyan Mishra ; otroan@employees.org >>> Cc: IPv6 Operations ; 6MAN <6man@ietf.org>; JORDI PAL= ET >>> MARTINEZ >>> Subject: Re: [v6ops] The bottom is /112 >>> >>> And if we had left the boundary at /80, as it was in 1995 (RFC1884), = would you >>> now be arguing for /96, since in that case 3GPP would have settled on= /80? >>> >>> Sorry, but this is exactly and precisely a 16-bit jump in the race to= the bottom. >>> And it breaks all existing SLAAC hosts on the way. >>> >>> The problem here is caused by 3GPP, but a solution like Cameron's sho= uld work >>> for everybody with minimal changes. >>> >>> Regards >>> Brian >>> >>> On 20-Nov-20 11:03, Gyan Mishra wrote: >>>> >>>> >>>> On Thu, Nov 19, 2020 at 10:33 AM >> > wrote: >>>> >>>> >>>> >>>> > On 19 Nov 2020, at 14:58, Gyan Mishra >> > wrote: >>>> > >>>> > You would need a new option. It would likely be useful for the= requesting >>> router to indicate interest in the option. Even hinting at what prefi= x size it was >>> expecting. >>>> > Now can you explain to me again the reasons why this approach = is better >>> than using the existing DHPCv6 protocol packets? >>>> > >>>> >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6 >>>> >>>> 3GPP gateway doesn't support new option. What's your point? >>>> >>>> >>>> >>>> =C2=A0 =C2=A0 The point of the v6ops presentation and this email thr= ead is how to =E2=80=9Cextend >>> a /64=E2=80=9D in the 3GPP use case =C2=A0in slide 1 of the deck you = compiled a list of options >>> and of the two I had highlighted in red were the 64share v2 Cameron=E2= =80=99s option >>> and the variable slaac option.=C2=A0 So on the call this morning Lore= nzo shot down >>> 64share v2 shorter prefix option as even if the 3GPP architecture was= updated >>> to support longer prefixes and even is the 3GPP gateway was able to s= end a >>> shorter prefix with A flag not set, all mobile devices per Lorenzo=E2= =80=99s point would >>> be broken as they would not accept the shorter let=E2=80=99s say /56 = prefix to build the >>> slaac 128 bit address.=C2=A0 So the bottom line is the 64share v2 won= =E2=80=99t work unless >>> we update RFC 4291 and remove the 64 bit boundary. >>>> >>>> =C2=A0So we are back to square uno - no viable solution >>>> >>>> =C2=A0So now we had thrown out the longer >64 due to race to bottom = worries >>> which I and others believe is Fud and as described in slide 10 of the= v6ops =E2=80=9Crace >>> to the bottom slide=E2=80=9D. >>>> >>>> So a happy medium /80 fixed boundary I came up with that I think sol= ves a lot >>> of the issue and not just the 3GPP initial segmentation of downstream= devices >>> problem statement. >>>> >>>> Since we have to update RFC 4291 for 64share v2 to work anyways to a= llow >>> for shorter prefixes, why not instead create a new bottom at /80 givi= ng 16 bits >>> more of prefix length and shrinking the IID down to 48 bits.=C2=A0 Do= ing so you would >>> not even have to update the 3GPP architecture as I don=E2=80=99t know= if that would fly >>> or not.=C2=A0 Also this solves a few other problems at the same time.= >>>> >>>> >>>> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is mai= nstream >>> for operators for static addressing on router and switch infrastructu= re and >>> dhcpv6 subnets longer prefixes for network infrastructure appliance c= lusters, >>> NFV/VNF virtualization and server farms.=C2=A0 On host subnets where = there is a >>> chance of mix of slaac hosts with dhcpv6 =C2=A0devices the prefix len= gth is stuck at >>> /64.=C2=A0 So on these mix addressing host subnets we cannot do longe= r prefixes >>> following our ND cache hard limit mantra to prevent ND cache exhausti= on issues >>> as described in RFC 6164. >>>> >>>> So with the /80 new fixed boundary shifting prefix length 16 bits lo= nger and >>> shortening the IID by 16 bits gives resolved the 3GPP issue which 64s= hare can >>> work as is and subtending to downstream devices will now work as a /6= 4 is now >>> equivalent to a /48 with 64k /80s.=C2=A0 Also BCP-690 for broadband n= ot all >>> operators have adopted the shorter prefix lengths /56 or /48 >>> recommendations =C2=A0and now that=E2=80=99s not an issue as the /64 = would now suffice. >>>> >>>> From an operators perspective that gain allows at least for 3GPP mas= sive >>> growth and subtending with a single /64 allows the operators such as = Verizon >>> with massive subscriber base worldwide can stay with current allocati= ons and >>> don=E2=80=99t have to ask for /10. >>>> >>>> As 5G gets rolled out with Enhanced VPN framework and Network slicin= g >>> paradigm, the demand for shorter blocks and wearable multiple /48 wil= l be our >>> new reality. >>>> >>>> Making that 16 bit shift now to /80 making a /64 the new /48 will gi= ve >>> broadband and 3GPP subscribers a ton of space to subtending their net= works >>> we would be set for the future.=C2=A0 Especially with IOT the demand = for subtending >>> will continue to grow astronomically. >>>> >>>> Also IANA does not have to get start in allocating the other /3 and = other >>> available blocks. >>>> >>>> Lots of problems being solved here with a fixed /80 new boundary. >>>> >>>> Also with the existing random IID generation schemes which we have t= ested >>> on Linux kernel can do longer prefixes using RFC 4941 privacy extensi= on or RFC >>> 7217 stable IID. >>>> >>>> Win-Win for all. >>>> >>>> Ole >>>> >>>> -- >>>> >>>> >>>> >>>> *Gyan Mishra* >>>> >>>> /Network Solutions A//rchitect=C2=A0/ >>>> >>>> /M 301 502-1347 >>>> 13101 Columbia Pike >>>> /Silver Spring, MD >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Nov 23 14:18:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B053A1380; Mon, 23 Nov 2020 14:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKBxdqueAlei; Mon, 23 Nov 2020 14:18:27 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 BB3343A137E; Mon, 23 Nov 2020 14:18:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0ANMINrm020526; Mon, 23 Nov 2020 17:18:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606169904; bh=VQov/uJaXnPtPsXulpc5g6ddQezILxwyHokAVbZeOI8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=q36Kywn2vDYLR5ecKeiNX3ic7KumrZxQDJ6Q7LfSXzoLIQVTTG200QRrs1Y1b/oaY pIbwEg/AUGzMLIMpgzFWUWM9oIMFcG0xkEa1a3uvW60XzL3XDp9v17gw8mnmIIK8YO SAwo5ycV1dOxGQ1BlyQwq5L773K5kjB4Try0J+dOFD0rDQXHt74/VtS/kiu0B0ne/H PWiJzS3cN8KLGRNmCC8yvDL62p60QIIoU+1k4LtLQGRv0tZFYtEoz8NvkGmMGlpZ+7 cRJjj3nXloUKyEgJP4sykZaCxchRFUvY97HNh/rZguV8Spiqx7W/HwVchBropDjLT8 xOmsmVyEO+Ckg== Received: from XCH16-01-08.nos.boeing.com (xch16-01-08.nos.boeing.com [144.115.65.218]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0ANMIL5h020500 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 23 Nov 2020 17:18:21 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-08.nos.boeing.com (144.115.65.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 23 Nov 2020 14:18:20 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.2044.004; Mon, 23 Nov 2020 14:18:20 -0800 From: "Manfredi (US), Albert E" To: Gyan Mishra , 6MAN <6man@ietf.org>, IPv6 Operations Thread-Topic: [EXTERNAL] How do you solve 3GPP issue if neither operator nor handset supports PD? Thread-Index: AQHWwWyZML0ak3gy8U6YYdoceleq4anWSA/A Date: Mon, 23 Nov 2020 22:18:20 +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: [144.115.204.6] x-tm-snts-smtp: 32BAC4654383A4DF58194AD6082B0F6D1ADFC2A4C3D13206D5012C9CA2DE344F2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 22:18:29 -0000 RnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgR3lhbiBNaXNo cmENCg0KPiBIb3cgZG8gd2UgcHJvcG9zZSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gaWYgb3BlcmF0 b3JzIGRvbuKAmXQgc3VwcG9ydCBQRCBldmVuIHRob3VnaCB0aGUgwqAzR1BQIHN0YW5kYXJkIGhh cyBzdXBwb3J0ZWQgUEQgZm9yIG92ZXIgMTAgeWVhcnMuDQoNCk1heWJlIEkndmUgbWlzc2VkIHRo aXMgZGV0YWlsIGluIHRoZSB0aHJlYWQuIEFyZSB5b3Ugc2F5aW5nIHRoYXQgQW5kcm9pZCB3b3Vs ZCBiZSBoYXBweSB0byB0ZXRoZXIgZG93bnN0cmVhbSBkZXZpY2VzIHdpbGwgYSBsb25nZXIgcHJl Zml4LCBhbmQgc3VwcG9ydCBTTEFBQyB3aXRoIGRpZmZlcmVudCBsZW5ndGggSUlEcywgYnV0IG5v dCBoYXBweSB0byBhY2NlcHQgc2hvcnRlciBwcmVmaXhlcyBmcm9tIHVwc3RyZWFtPyBPciBpcyB0 aGlzIHlvdXIgc3VnZ2VzdGlvbiwgd2hpY2ggYXNzdW1lcyB0aGF0IEFuZHJvaWQgd2lsbCBmb3Jl dmVyIG9wcG9zZSByZWNlaXZpbmcgYW55dGhpbmcgb3RoZXIgdGhhbiAvNjRzPw0KDQpTZWVtcyB0 byBtZSB0aGF0IGFjY2VwdGluZyAvNTYgb3IgLzQ4cyBzaG91bGQgYmUgYW4gZWFzaWVyIHVwZ3Jh ZGUsIGFuZCBjcmVhdGUgYSBsb3QgbGVzcyBjb21tb3Rpb24gaW4gdGhlIElFVEYsIGF0IHRoaXMg dGltZS4NCg0KQmVydA0KDQo= From nobody Mon Nov 23 17:27:03 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1A83A0A0B for ; Mon, 23 Nov 2020 17:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.689 X-Spam-Level: X-Spam-Status: No, score=-15.689 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0f5s0TrFA6e for ; Mon, 23 Nov 2020 17:26:56 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BCC3A0CED for ; Mon, 23 Nov 2020 17:26:14 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id z14so16000222ilm.10 for ; Mon, 23 Nov 2020 17:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9RnuQV38a+sM3iQ3sidbDuy7TjzmW6qKnp24Ls+T+cY=; b=kn0L2OdH7fggJAFmeQxO3Wi13zOuXzpxZGK1JfcEBnQZl5NOCeAU/XOY2Eg6ZK0swr orr+FYoEQoLNRGIFtn9HqBtG2wP1O6RP8s2TcHUFpG6d5LloRTCRlvvnrUnOgjZcWp9o zjz86h4abpscL0X1Jf9rJTk7h5HikdseW3fri00vpXudQKRE+Ozs/mmadUfi5F0sWEsL kDlr573R5LHbWyLgMNF3J9QGmVZ9SnTAKjBZZSYJY1CtKNi/HHKUDKz7dwM0uzjB8tJ1 POBxqsruCO8EZCOrOX0shvX1v7LMbPVwP/uhCp4jmXfA9RX6J/9Xq6etiiBa7dBSBBzD o+Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9RnuQV38a+sM3iQ3sidbDuy7TjzmW6qKnp24Ls+T+cY=; b=quMMsZyStGt4i2KzZj7Yhjb9nZaDsaLoNssTTaXeMd0Nw1PvqkJeim61tX5LiBPHrS 6KkwBlM9bFbIQRzKlgKha3KdfhgGEDAqJzd0tNiq6qUyr9NA9C4+K4lIoVlxHpxANz/8 84IMfo785leoocSMC+CzdZI+hrgpk/z2t8OvEyV11L/fHqS5CTKfeZgZQAFFOYV4hOsl S7feO/E+Lv0PilduOVq5NPHbtuUWvnMPO3vtGrDUtaTR5b6MeV+nWBmICnmKWNCT8RgE Z2/tI8AHtTomPmREx0hHOkAtms+idyYTKMdrJjEaxvb52rpq1i5qpfReHSKlhmsL8A0Y C5dw== X-Gm-Message-State: AOAM532rir1h3IUt3qeM+XrqoVayBfaWXBaO2Fyjut9JJ8Y4ekIHm78t 2hd7BC+g8KYDebUrZlialNgMb0rOUqS6ccLFmktc9w== X-Google-Smtp-Source: ABdhPJyivtEeI5e/lG68D9kaq5Dcb8OkMoSvv2/hmCzLBOrsjFUPdcKLw84IT/67IjuGllS23hnMY0qMXasXyN9cYtY= X-Received: by 2002:a92:cbcc:: with SMTP id s12mr2347652ilq.229.1606181173510; Mon, 23 Nov 2020 17:26:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 24 Nov 2020 10:26:02 +0900 Message-ID: To: Gyan Mishra , Cameron Byrne Cc: 6MAN <6man@ietf.org>, Alexandre Petrescu , IPv6 Operations , "draft-mishra-6man-variable-slaac@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b583105b4d03235" Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 01:26:59 -0000 --0000000000004b583105b4d03235 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think anyone ever said Android will not support DHCPv6 PD. That said, implementing DHCPv6 PD on cellular is difficult for technical reasons, including: - There is no DHCPv6 PD implementation in Android, so one would need to be written. - The natural place for such an implementation is in the IpClient code, which does not (yet?) run on cellular networks. Something like the new RA option proposed in the 64share v2 thread (+Camero= n Byrne ) - assuming it gains consensus - would be much easier to implement. As an alternative: it's possible to extend the Android telephony HAL to allow the baseband to return a delegated prefix as well as the directly-connected route. That way, if a modem vendor (e.g., Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent code (which is not part of the Android OS), it can simply pass up the prefix through the HAL and the OS can use it. As we know, DHCPv6 PD has been mentioned in 3GPP standards for several releases. Are there any 3GPP specs on how prefix delegation should be used? Are there any requirements that might simplify the implementation? For example, a requirement that the delegated prefix may not change for the lifetime of the session, and that its lifetime is infinite, would be consistent with the 3GPP requirements around RAs, and would substantially simplify implementation. On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra wrote: > > How do we propose to solve this problem if operators don=E2=80=99t suppor= t PD even > though the 3GPP standard has supported PD for over 10 years. > > Another twist to this puzzle is Android has 90% of the mobile handset > marketplace worldwide and adamantly states they will NOT support DHCPv6 o= r > PD. > > I researched Apple which has 10% of the market and they also do not > support PD. > > Whats the solution now? > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000004b583105b4d03235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think anyone ever said Android will not s= upport DHCPv6 PD. That said, implementing DHCPv6 PD on cellular=C2=A0is dif= ficult for technical reasons, including:
  • There is no DHCP= v6 PD implementation in Android, so one would need to be written.
  • T= he natural place for such an implementation is in the IpClient code, which = does not (yet?) run on cellular networks.
Something like the = new RA option proposed in the 64share v2 thread (+Cameron Byrne) - assuming it gains consensus = - would be much easier to implement.

As = an alternative: it's possible to extend the Android telephony HAL to al= low the baseband to return a delegated prefix as well as the directly-conne= cted route. That way, if a modem vendor (e.g., Qualcomm, Mediatek, ...) imp= lements DHCPv6 PD in baseband-dependent code (which is not part of the Andr= oid OS), it can simply pass up the prefix through the HAL and the OS can us= e it.

As we know, DHCPv6 PD has been mentioned in = 3GPP standards for several releases. Are there any 3GPP specs on how prefix= delegation should be used? Are there any requirements that might simplify= the implementation? For example, a requirement that the delegated prefix m= ay not change for the lifetime of the session, and that its lifetime is inf= inite, would be consistent with the 3GPP requirements around RAs, and would= substantially simplify implementation.

On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra <hayabusagsm@gmail.com>= wrote:

How do we = propose to solve this problem if operators don=E2=80=99t support PD even th= ough the =C2=A03GPP standard has supported PD for over 10 years.

Another twist to this puzzle is An= droid has 90% of the mobile handset marketplace worldwide and adamantly sta= tes they will NOT support DHCPv6 or PD.

I researched Apple which has 10% of the market and they als= o do not support PD.

Wha= ts the solution now?
--


Gyan Mishra

Network Solutions Architect=C2=A0

M = 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000004b583105b4d03235-- From nobody Mon Nov 23 22:33:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04413A13AA; Mon, 23 Nov 2020 22:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWgl_OB3xant; Mon, 23 Nov 2020 22:32:59 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8AC3A1425; Mon, 23 Nov 2020 22:32:43 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id 92so15297139otd.5; Mon, 23 Nov 2020 22:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2yITO8yI6AIOKuy8jabGVQTSrgGHh+8X4z3nfxId7vA=; b=ixlplgZLl1wcYVDGcKd7RTk5+Xfp3M/4yLuam0Ew7ouRtYBtBv0oeBAwYyWDJL+eUj kQz7PFmv5NuTw2LkVS7Ia/k3c1DitLETQQxsHKDVrMzWkQ6MKLA/eOacEXm7HhabsWEF LfzhYl43zrJwqeWiLQW7DOhwSmRwngeFu6WDvmmIULFtoEf+MlJ6xDqHzMPMxWWOLwH5 iQYz3tKDfmoaZ17i4Sa4HvE9nA9ZUmv6aKCHHRaj6IcgwY405jJhQnmQhTx98NcA46xd JKfsxJBCID7dZZzrDczw0jJ7l8Ti7f2ZQE8CgjK6zwIlWbJT1i/LghQvaTDkW8yzRa3g JZ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2yITO8yI6AIOKuy8jabGVQTSrgGHh+8X4z3nfxId7vA=; b=WWvV/NXasJtyt04fI1NMpI6oBcxOwiVIIkHB2FgJEyFkTqhx4QA6xXEo3omHt0N91h k2Ztp09MlNPCM+4PoSnAC78j+gIoKrepcHHOs5pwT2VPeqnn+iI9Nu0Tbt7NdnAazTMv +sajkUBYNldcoaCwxT9t6+/V7Hc3iw7YPTdqlRs+yGq3YZdGenbQz6OTa2mbnUKZQwoX M6maFtZDyHdxBg+2E12HgdnjKjuFG8ZhHwBjVQWQHjpXWufks9QExgSYjBVhESxIP6Gn DiJeb0Xvs/RST6gENfS9YfQvCk8F0snl1oOA7kQXwNalCgZR6Yl0PcA+EtkBX63smpqp M/mA== X-Gm-Message-State: AOAM531N6TnWHGe4LTMwPYjcyDtNFXg8iBhG+Sn5QXpF+vIcPCgxIhtz P5397MMrIYKc2qQYCm7YRXgCvctCAXLKTXCRMh8= X-Google-Smtp-Source: ABdhPJzicmn/Lb54avaF6Bku4JP/bmYJTHo8IownCdnvKIRFGbpdRKdk2GAbs1DfFbBWIEHGUopjuko6IFfzx/5+bSk= X-Received: by 2002:a05:6830:1e08:: with SMTP id s8mr2395441otr.144.1606199563235; Mon, 23 Nov 2020 22:32:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Kline Date: Mon, 23 Nov 2020 22:32:32 -0800 Message-ID: To: Lorenzo Colitti Cc: Gyan Mishra , Cameron Byrne , Alexandre Petrescu , 6MAN <6man@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 06:33:01 -0000 There have been, I think, 2-4 (more?) ND-based PD or PD-like proposals. The main argument against ND-PD, as I recall from PIO-X days, has been "we have DHCPv6 PD, ND PD will have to replicate most of the same semantics, why do we need two ways to do this?" If, on the other hand, we are to understand that 3GPP operators are just not deploying DHCPv6 PD (for whatever reason), then I think a reasonable argument can be made that "we wouldn't have two, because we currently have zero." If the above is true, I, for one, would be interested to evaluate a simple, clean draft that did things like: [1] define a PDIO, and its use in RAs and RSes (for requesting a prefix length or refreshing/requesting a previously delegated prefix), [2] define the scope of applicability (i.e. in contexts where it can be guaranteed that only one client will receive the RA), [3] did not make unnecessary reference to link technologies, mobility architectures, or the like (just define the generic deployment requirements, however they may be met), [4] did not try to make other unrelated changes (like redoing the /64 SLAAC boundary; residential PD has been working fine for a while) and [5] define the relationship to any PIOs present (i.e. a PDIO that covers or equals a PIO with L=3D0 can inform the client that it's in an RFC 8273-style environment whereas L=3D1 indicates an RFC 6603 situation). I think it's possible to over-complicate the work, but if the deployment requirements are well-scoped I think it could be fairly clean and simple. On Mon, Nov 23, 2020 at 5:27 PM Lorenzo Colitti wrote: > > I don't think anyone ever said Android will not support DHCPv6 PD. That s= aid, implementing DHCPv6 PD on cellular is difficult for technical reasons,= including: > > There is no DHCPv6 PD implementation in Android, so one would need to be = written. > The natural place for such an implementation is in the IpClient code, whi= ch does not (yet?) run on cellular networks. > > Something like the new RA option proposed in the 64share v2 thread (+Came= ron Byrne) - assuming it gains consensus - would be much easier to implemen= t. > > As an alternative: it's possible to extend the Android telephony HAL to a= llow the baseband to return a delegated prefix as well as the directly-conn= ected route. That way, if a modem vendor (e.g., Qualcomm, Mediatek, ...) im= plements DHCPv6 PD in baseband-dependent code (which is not part of the And= roid OS), it can simply pass up the prefix through the HAL and the OS can u= se it. > > As we know, DHCPv6 PD has been mentioned in 3GPP standards for several re= leases. Are there any 3GPP specs on how prefix delegation should be used? A= re there any requirements that might simplify the implementation? For examp= le, a requirement that the delegated prefix may not change for the lifetime= of the session, and that its lifetime is infinite, would be consistent wit= h the 3GPP requirements around RAs, and would substantially simplify implem= entation. > > On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra wrote= : >> >> >> How do we propose to solve this problem if operators don=E2=80=99t suppo= rt PD even though the 3GPP standard has supported PD for over 10 years. >> >> Another twist to this puzzle is Android has 90% of the mobile handset ma= rketplace worldwide and adamantly states they will NOT support DHCPv6 or PD= . >> >> I researched Apple which has 10% of the market and they also do not supp= ort PD. >> >> Whats the solution now? >> -- >> >> >> Gyan Mishra >> >> Network Solutions Architect >> >> M 301 502-1347 >> 13101 Columbia Pike >> Silver Spring, MD >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Nov 24 03:56:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9C3A09AC; Tue, 24 Nov 2020 03:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=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 i3vsQpJ9GWUL; Tue, 24 Nov 2020 03:56:31 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D122B3A09A5; Tue, 24 Nov 2020 03:56:29 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1khWvp-0000E1C; Tue, 24 Nov 2020 12:56:25 +0100 Message-Id: To: v6ops@ietf.org Cc: Erik Kline , 6MAN <6man@ietf.org> From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: In-reply-to: Your message of "Mon, 23 Nov 2020 22:32:32 -0800 ." Date: Tue, 24 Nov 2020 12:56:25 +0100 Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 11:56:33 -0000 > There have been, I think, 2-4 (more?) ND-based PD or PD-like > proposals. The main argument against ND-PD, as I recall from PIO-X > days, has been "we have DHCPv6 PD, ND PD will have to replicate > most of the same semantics, why do we need two ways to do this?" > > If, on the other hand, we are to understand that 3GPP operators > are just not deploying DHCPv6 PD (for whatever reason), then I > think a reasonable argument can be made that "we wouldn't have two, > because we currently have zero." We are creating 2 mechanisms, the fact that the mobile world doesn't use it doesn't remove DHCP PD from the 3GPP standards. Is there any guarantee that the mobile world will implement this new option or will we be back here in a couple of years with the same discussion? I.e., if we do a new option when will it be part of 3GPP specs, when will routers support it, when will telco's update routers and roll out this feature. When will handset support it, etc. That said, it seems to me that by and large DHCPv6 PD is the wrong model for many of our current use cases. So if we can come up with something better, then it is reasonable to have a newer mechanism that is better. > If the above is true, I, for one, would be interested to evaluate > a simple, clean draft that did things like: > > [1] define a PDIO, and its use in RAs and RSes (for requesting > a prefix length or refreshing/requesting a previously delegated > prefix), Yes > [2] define the scope of applicability (i.e. in contexts where > it can be guaranteed that only one client will receive the RA), We may need to do the work in two steps. One is something that works only links that are hardwired point-to-point such as ppp. A second step would be to include point-to-point ethernet links. > [3] did not make unnecessary reference to link technologies, > mobility architectures, or the like (just define the generic > deployment requirements, however they may be met), Indeed. > [4] did not try to make other unrelated changes (like redoing > the /64 SLAAC boundary; residential PD has been working fine > for a while) and Yes. > [5] define the relationship to any PIOs present (i.e. a PDIO > that covers or equals a PIO with L=0 can inform the client that > it's in an RFC 8273-style environment whereas L=1 indicates an RFC > 6603 situation). I think we should be explicit. If part of the prefix is not avaiable then there should be a field in the PDIO that says so. > I think it's possible to over-complicate the work, but if the > deployment requirements are well-scoped I think it could be fairly > clean and simple. The hard part is coming up with a model such that we don't have to write a series of drafts on how to deal with operational issues (such as renumbering) as few years later. I.e., the DHCPv6 PD model doesn't work for many cases, what model do we agree on that does work. From nobody Tue Nov 24 04:17:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E76C3A09F1; Tue, 24 Nov 2020 04:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 QpvDvMxM_juS; Tue, 24 Nov 2020 04:17:31 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1983A09F0; Tue, 24 Nov 2020 04:17:30 -0800 (PST) Received: from astfgl.hanazo.no (77.16.72.77.tmi.telenormobil.no [77.16.72.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id AF39A4E11AD8; Tue, 24 Nov 2020 12:17:28 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 33D4C45DD987; Tue, 24 Nov 2020 13:17:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: otroan@employees.org In-Reply-To: Date: Tue, 24 Nov 2020 13:17:24 +0100 Cc: Lorenzo Colitti , IPv6 Operations , 6MAN <6man@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" , Alexandre Petrescu Content-Transfer-Encoding: quoted-printable Message-Id: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org> References: To: Erik Kline X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 12:17:32 -0000 Hi Erik, et al, > There have been, I think, 2-4 (more?) ND-based PD or PD-like > proposals. The main argument against ND-PD, as I recall from PIO-X > days, has been "we have DHCPv6 PD, ND PD will have to replicate most > of the same semantics, why do we need two ways to do this?" >=20 > If, on the other hand, we are to understand that 3GPP operators are > just not deploying DHCPv6 PD (for whatever reason), then I think a > reasonable argument can be made that "we wouldn't have two, because we > currently have zero." >=20 > If the above is true, I, for one, would be interested to evaluate a > simple, clean draft that did things like: >=20 > [1] define a PDIO, and its use in RAs and RSes (for requesting a > prefix length or refreshing/requesting a previously delegated prefix), >=20 > [2] define the scope of applicability (i.e. in contexts where it > can be guaranteed that only one client will receive the RA), >=20 > [3] did not make unnecessary reference to link technologies, > mobility architectures, or the like (just define the generic > deployment requirements, however they may be met), >=20 > [4] did not try to make other unrelated changes (like redoing the > /64 SLAAC boundary; residential PD has been working fine for a while) > and >=20 > [5] define the relationship to any PIOs present (i.e. a PDIO that > covers or equals a PIO with L=3D0 can inform the client that it's in = an > RFC 8273-style environment whereas L=3D1 indicates an RFC 6603 > situation). >=20 > I think it's possible to over-complicate the work, but if the > deployment requirements are well-scoped I think it could be fairly > clean and simple. I come to realise something and I want to hear if others agree. The 3GPP model is in may ways very similar to the model I described in = P2P Ethernet. It's not traditional address assignment happening on that link. The = upstream router does not have a connected route and glean adjacency = (address resolution required) towards the host. When a RA with a /64 PIO is sent and the mobile terminal does tethering, = it's much more like prefix delegation of that /64. In a traditional RA+PIO with L=3D1, the router states: This prefix is directly connected between us and requires address = resolution. If A=3D1 && plen =3D=3D 64 you can generate an address from this = prefix. In the P2P Ethernet/3GPP case it says: This prefix is not used on the link between us. The prefix is dedicated to you, and I promise to install a route like: ipv6 route p2p-interface | interface, NH pointing at you. You can if you like configure an address on the interface on the = upstream link, as the router will forward traffic to anything in that prefix blindly. (you aren't strictly doing SLAAC at that point though.) In the latter case the prefix-length can be <1-128>. Now, if someone else could more succinctly express that difference... Best regards, Ole= From nobody Tue Nov 24 05:01:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7013A0C21 for ; Tue, 24 Nov 2020 05:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzGopLUjmlxa for ; Tue, 24 Nov 2020 05:01:28 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9933A0C1E for ; Tue, 24 Nov 2020 05:01:28 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id o11so21792663ioo.11 for ; Tue, 24 Nov 2020 05:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ky761iqfPa8hMPTiFl2+LyZCJMd4bIvSZ7Fphr+7s0=; b=mWZB2LEPD/YICYPPN0Ki9e4nbawungIwtSHxjXB6AWfh5+5gMz+13z4mdySDsjkExR HG+Ni2R+L7gwnrrM0ntlZ1Gq5CbXTQWj9MGJvj9+nwbKnhh1awGfpcSFTASRrzjY82ye RZbNzuzxttNXSwM0ZIbR3NzMFLZswwQygZMF0/OASvO/63kGM18YzEQXCVG5piH5PMKy D/NAw/uQYLwj2Hd9W9MAVoI2CK9kSojcsSu3K52FSheaK8PWWVck+6K1TonQVq9twqdb vqoWQ3OLcQ9I56pecqW/FuOjVEjPa28ITw7kG26D0SMAY/ZyeR5D4QJtmpwgZWuuHQ/A CK7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ky761iqfPa8hMPTiFl2+LyZCJMd4bIvSZ7Fphr+7s0=; b=sKjCcOcWnG6hVPkJeXYZzQ6QDT9D6FSCuta+zQqKa+G23wcG8lHlihkoEYQqYqyppU 3i+Qcp+HMnAEKh6xn+2l5acaM/DXFfEh0izRJmxgX8XnkIxTV9ZnOU7DY8PXGwzLh0dM Th3S1OhHREdlPll+LdfQ2XU6sxk0BPXpfgPWAB1ZQ+X/mQBlh196e1+yfNQmMrK8MTcc 0UGPV8ppgRft2s+1pYCILNufXn1IwVb6HWjL6WELgN5oVkA2Z82Tg1eYObNZXtM9qSAi d0Qm84Je7h7SzyA8T6YY+5+mHiMztsaLZakoQjWqhpH2u1ku660Qfqk2dXpU0kSac/Ja K2wg== X-Gm-Message-State: AOAM5305MIGKwAj8KKtlLyML8BCj1WmskA0y62pFZ/HmmAbkUvGPBWJQ 02/WUtsHZRtdscrjRFsjVZOq9UgfV4phUhXHGoccJw== X-Google-Smtp-Source: ABdhPJxs7h72F1/eSfMB3p5aKQQUgF0T++3wq0Ro03uPm+8sQ/w0ewt1d8Y7x2Z1nxarwwsj1tiitIMIQTcU4b2k0ZQ= X-Received: by 2002:a6b:d801:: with SMTP id y1mr3800674iob.61.1606222887501; Tue, 24 Nov 2020 05:01:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 24 Nov 2020 22:01:16 +0900 Message-ID: To: Philip Homburg , Cameron Byrne , Gyan Mishra Cc: "v6ops@ietf.org WG" , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000a4643105b4d9e829" Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 13:01:30 -0000 --000000000000a4643105b4d9e829 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 8:56 PM Philip Homburg wrote: > Is there any guarantee that the mobile world will implement this new option > or will we be back here in a couple of years with the same discussion? > I.e., > if we do a new option when will it be part of 3GPP specs, when will routers > support it, when will telco's update routers and roll out this feature. > When > will handset support it, etc. > As for handset support: as I said, at least on Android such an option would be easier to implement than DHCPv6 PD. I don't know how easy it would be to get it into 3GPP implementations. +Cameron Byrne +Gyan Mishra , do you know? Is such a new RA option something that could happen via a feature request to 3GPP equipment vendors, or would it require a year-long process of revving the 3GPP specs and waiting for vendors to pick up the new 3GPP release? --000000000000a4643105b4d9e829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2020 at 8:56 PM Philip Ho= mburg <pch-v6ops-9@u-1.phi= coh.com> wrote:
Is there any guarantee that the mobile wo= rld will implement this new option
or will we be back here in a couple of years with the same discussion? I.e.= ,
if we do a new option when will it be part of 3GPP specs, when will routers=
support it, when will telco's update routers and roll out this feature.= When
will handset support it, etc.

As for ha= ndset support: as I said, at least on Android such an option would be easie= r to implement than DHCPv6 PD.

I don't know ho= w easy it would be to get it into 3GPP implementations.=C2=A0+Cameron Byrne=C2=A0+Gyan = Mishra, do you know? Is such a new RA option something that could happe= n via a feature request to 3GPP equipment vendors, or would it require a ye= ar-long process of revving the 3GPP specs and waiting=C2=A0for vendors to p= ick up the new 3GPP release?
--000000000000a4643105b4d9e829-- From nobody Tue Nov 24 05:18:25 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEA13A0CBC; Tue, 24 Nov 2020 05:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHS9GRlhpOXn; Tue, 24 Nov 2020 05:18:18 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 4530A3A0CBA; Tue, 24 Nov 2020 05:18:16 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E7920B1; Tue, 24 Nov 2020 14:18:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1606223893; bh=eibu2BeViaZEX/4uLJ6crpMukYhAa2AQv1GXXYnjdC8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QUMnaw5pPTsXgQsUBpKcHu+I41lP+K7VOnz8DmuhaBbWCNVum8zJAgPbaI1vF7OPu myuJIghbCjhA59zfDSgviwmI9NGZ1568NlZbeX+Kt8TIO3DdX6aSyvafMqCrp4kD0h 29uXeF3FOXinNvY44BEuxXBQ1p0xU1bBDHwuzLjQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E2E68B0; Tue, 24 Nov 2020 14:18:13 +0100 (CET) Date: Tue, 24 Nov 2020 14:18:13 +0100 (CET) From: Mikael Abrahamsson To: otroan@employees.org cc: Erik Kline , "draft-mishra-6man-variable-slaac@ietf.org" , IPv6 Operations , 6MAN <6man@ietf.org>, Lorenzo Colitti In-Reply-To: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org> Message-ID: References: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 13:18:20 -0000 On Tue, 24 Nov 2020, otroan@employees.org wrote: > The 3GPP model is in may ways very similar to the model I described in P2P Ethernet. The 3GPP model is almost identical to PPP, HDLC, ATM, IPIP or whatever that doesn't have an ethernet header and isn't a broadcast medium. > It's not traditional address assignment happening on that link. The upstream router does not have a connected route and glean adjacency (address resolution required) towards the host. > > When a RA with a /64 PIO is sent and the mobile terminal does tethering, it's much more like prefix delegation of that /64. > > In a traditional RA+PIO with L=1, the router states: > This prefix is directly connected between us and requires address resolution. > If A=1 && plen == 64 you can generate an address from this prefix. > > In the P2P Ethernet/3GPP case it says: > This prefix is not used on the link between us. > The prefix is dedicated to you, and I promise to install a route like: > ipv6 route p2p-interface | interface, NH pointing at you. > You can if you like configure an address on the interface on the upstream link, > as the router will forward traffic to anything in that prefix blindly. > (you aren't strictly doing SLAAC at that point though.) > > In the latter case the prefix-length can be <1-128>. > > Now, if someone else could more succinctly express that difference... I don't think it should be inferred by the link type, I think similar to PIO-X it should be explicit. For broadcast media we put in some constraints, but there it gets more complicated. If we could start defining the "hey, I routed the entire PIO to you" somehow for P2P then we could continue with that for broadcast medium in a follow-up RFC. For reference: https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Nov 24 07:58:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E093A1205; Tue, 24 Nov 2020 07:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.155 X-Spam-Level: *** X-Spam-Status: No, score=3.155 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 iL8p7gDW4FXy; Tue, 24 Nov 2020 07:57:46 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 33CCA3A11CD; Tue, 24 Nov 2020 07:57:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOFveIV002469; Tue, 24 Nov 2020 16:57:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 47212209416; Tue, 24 Nov 2020 16:57:40 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2D07920944B; Tue, 24 Nov 2020 16:57:40 +0100 (CET) Received: from [10.11.244.24] ([10.11.244.24]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOFvd2T013360; Tue, 24 Nov 2020 16:57:39 +0100 To: Erik Kline , Lorenzo Colitti Cc: Gyan Mishra , Cameron Byrne , 6MAN <6man@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" , IPv6 Operations References: From: Alexandre Petrescu Message-ID: <675c8025-93ff-d0bc-e9be-e900f41f19df@gmail.com> Date: Tue, 24 Nov 2020 16:57:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:57:55 -0000 Le 24/11/2020 à 07:32, Erik Kline a écrit : > > > There have been, I think, 2-4 (more?) ND-based PD or PD-like > proposals. The main argument against ND-PD, as I recall from PIO-X > days, has been "we have DHCPv6 PD, ND PD will have to replicate most > of the same semantics, why do we need two ways to do this?" > > If, on the other hand, we are to understand that 3GPP operators are > just not deploying DHCPv6 PD (for whatever reason), then I think a > reasonable argument can be made that "we wouldn't have two, because > we currently have zero." > > If the above is true, I, for one, would be interested to evaluate a > simple, clean draft that did things like: > > [1] define a PDIO, and its use in RAs and RSes (for requesting a > prefix length or refreshing/requesting a previously delegated > prefix), > > [2] define the scope of applicability (i.e. in contexts where it can > be guaranteed that only one client will receive the RA), [2.1] - the option should be implemented on as many as possible platforms, before proceeding. Android is a perfect candidate, but there are more platforms different than Android that use same networks as Android does - e.g. 'IoT routers' - who also need such option. > [3] did not make unnecessary reference to link technologies, mobility > architectures, or the like (just define the generic deployment > requirements, however they may be met), > > [4] did not try to make other unrelated changes (like redoing the /64 > SLAAC boundary; residential PD has been working fine for a while) > and > > [5] define the relationship to any PIOs present (i.e. a PDIO that > covers or equals a PIO with L=0 can inform the client that it's in > an RFC 8273-style environment whereas L=1 indicates an RFC 6603 > situation). [5.1] - define whether or not this option is used to form an address on the receiving interface. Define whether or not this option must be accompanied by a regular PIO. Consider the consideration of the reduction of numbers of bytes on wireless links. Consider whether or not the use of this option implies that more other messages must be sent on the link. [5.2] - define the additional security implications of using the new option. > I think it's possible to over-complicate the work, but if the > deployment requirements are well-scoped I think it could be fairly > clean and simple. It is a good goal. Alex . > > On Mon, Nov 23, 2020 at 5:27 PM Lorenzo Colitti > wrote: >> >> I don't think anyone ever said Android will not support DHCPv6 PD. >> That said, implementing DHCPv6 PD on cellular is difficult for >> technical reasons, including: >> >> There is no DHCPv6 PD implementation in Android, so one would need >> to be written. The natural place for such an implementation is in >> the IpClient code, which does not (yet?) run on cellular networks. >> >> Something like the new RA option proposed in the 64share v2 thread >> (+Cameron Byrne) - assuming it gains consensus - would be much >> easier to implement. >> >> As an alternative: it's possible to extend the Android telephony >> HAL to allow the baseband to return a delegated prefix as well as >> the directly-connected route. That way, if a modem vendor (e.g., >> Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent >> code (which is not part of the Android OS), it can simply pass up >> the prefix through the HAL and the OS can use it. >> >> As we know, DHCPv6 PD has been mentioned in 3GPP standards for >> several releases. Are there any 3GPP specs on how prefix delegation >> should be used? Are there any requirements that might simplify the >> implementation? For example, a requirement that the delegated >> prefix may not change for the lifetime of the session, and that its >> lifetime is infinite, would be consistent with the 3GPP >> requirements around RAs, and would substantially simplify >> implementation. >> >> On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra >> wrote: >>> >>> >>> How do we propose to solve this problem if operators don’t >>> support PD even though the 3GPP standard has supported PD for >>> over 10 years. >>> >>> Another twist to this puzzle is Android has 90% of the mobile >>> handset marketplace worldwide and adamantly states they will NOT >>> support DHCPv6 or PD. >>> >>> I researched Apple which has 10% of the market and they also do >>> not support PD. >>> >>> Whats the solution now? -- >>> >>> >>> Gyan Mishra >>> >>> Network Solutions Architect >>> >>> M 301 502-1347 13101 Columbia Pike Silver Spring, MD >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Tue Nov 24 09:00:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78623A1214; Tue, 24 Nov 2020 09:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.155 X-Spam-Level: *** X-Spam-Status: No, score=3.155 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 TXNcnU1JtOWf; Tue, 24 Nov 2020 09:00:49 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 355B73A120E; Tue, 24 Nov 2020 09:00:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOH0dWq021016; Tue, 24 Nov 2020 18:00:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EB2B2209518; Tue, 24 Nov 2020 18:00:38 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D3D9F2094FB; Tue, 24 Nov 2020 18:00:38 +0100 (CET) Received: from [10.11.244.24] ([10.11.244.24]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AOH0cTc014762; Tue, 24 Nov 2020 18:00:38 +0100 To: otroan@employees.org, Erik Kline Cc: Lorenzo Colitti , IPv6 Operations , 6MAN <6man@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" References: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org> From: Alexandre Petrescu Message-ID: Date: Tue, 24 Nov 2020 18:00:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1DB65027-BEF2-4C0A-ACF4-C979DA7444C2@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 17:00:51 -0000 Le 24/11/2020 à 13:17, otroan@employees.org a écrit : [...] > I come to realise something and I want to hear if others agree. Since publication I wondered whether P2P Ethernet is an L2TP 'in disguise'? I mean, If I understand correctly, L2TP is used in residential networks much how the P2P Ethernet seems to be assumed to work on a cellular link: a ptp link whose interfaces are highly like Ethernet. > The 3GPP model is in may ways very similar to the model I described in P2P Ethernet. > It's not traditional address assignment happening on that link. The upstream router does not have a connected route > and glean adjacency (address resolution required) towards the host. > > When a RA with a /64 PIO is sent and the mobile terminal does tethering, it's much more like prefix delegation of that /64. > > In a traditional RA+PIO with L=1, the router states: > This prefix is directly connected between us and requires address resolution. > If A=1 && plen == 64 you can generate an address from this prefix. > > In the P2P Ethernet/3GPP case it says: > This prefix is not used on the link between us. > The prefix is dedicated to you, and I promise to install a route like: > ipv6 route p2p-interface | interface, NH pointing at you. > You can if you like configure an address on the interface on the upstream link, > as the router will forward traffic to anything in that prefix blindly. > (you aren't strictly doing SLAAC at that point though.) > > In the latter case the prefix-length can be <1-128>. > > Now, if someone else could more succinctly express that difference... I cant express it more succinctly. The difference between 'assigning a prefix to a link' and 'allocating a prefix to a Host' depends on the nexthop presence and the kind of iface in the routing table entry. In the simplest linuces, three alternate forms of entries in the routing table are possible: (1) nexthop '*' | kind of iface 'Ethernet' (2) nexthop '*' | kind of iface 'ptp' (3) nexthop IP-of-Host | kind of iface 'Ethernet' or 'ptp' (assume a prefix/plen in each entry) In the first form, a Gateway 'assigns' that prefix on that link. The Host can form an address within that prefix, but packets whose dst is some address within that prefix might not reach that Host, because other Host might have it, and because ND would kick in and resolve to that other Host's IP address; ND is used because there is no nexthop. This is the typical Ethernet. This is called 'connected' route, I think, on Cisco. In the second form, a Gateway 'assigns' the prefix to that link, and also 'delegates' the prefix to the Host. Packets whose dst is any address prefixed by that prefix will be transmitted to that Host, because ND is not used on ptp links, because even if there is no nexthop, the 'ptp' is exceptional; 'ptp' means no ND because there are always two neighbors that know each other very well. In the third form, a Gateway 'delegates' the prefix to the Host but does not 'assign' it on the link. The Host cant form an address out of that prefix on the receiving interface. That prefix is not assigned to that link. But packets addressed to any address prefixed by that prefix are indeed forwarded to the Host, because ND is not used here because there is a next-hop. In summary: Assign to link Delegate to Host (1) x (2) x x (3) x Alex > > Best regards, > Ole > From nobody Tue Nov 24 11:06:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E503E3A164D; Tue, 24 Nov 2020 11:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hckVkfhsEO0U; Tue, 24 Nov 2020 11:06:34 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2216F3A164C; Tue, 24 Nov 2020 11:06:28 -0800 (PST) Received: from [IPv6:2800:810:464:8164:3143:1df2:74fd:43d0] (unknown [IPv6:2800:810:464:8164:3143:1df2:74fd:43d0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 73FFC283AE6; Tue, 24 Nov 2020 19:06:24 +0000 (UTC) To: Alexander Azimov , tcpm , v6ops@ietf.org References: From: Fernando Gont Message-ID: Date: Tue, 24 Nov 2020 16:05:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 19:06:37 -0000 On 19/11/20 07:48, Alexander Azimov wrote: > Dear colleagues, > > I have added in the cc both v6op and tcpm for a reason and let me > explain why. > > It's clear that we are moving forward with load balancing that uses flow > label (FL). And the pressure will increase with SRv6 adoption. But at > the moment wide adoption of FL-based load-balancing may create > significant issues for TCP Anycast services. > > RFC6437 suggests putting hash from 5-tuple into FL value. And as far as > I know, there is no document that updates this behavior. This > description is perfectly fine, but what is implemented in the Linux > kernel is different: FL is carrying hash from 5-tuple with an additional > seed, and this seed is randomly changed after each RTO/SYN_RTO event. Changing the FL upon RTO is a bug. I guess/assume that when you say SYN-RTO, you really mean "user timeout", rather than RTO. If you don't, then that's also a bug. If you do, I fail to understand what's the reason for wanting the FL to change in that case, because as a result of port randomization, it 0s unlikely that the same four-tuple is employed for the next connection retry. > Here are related patches: > > * https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.mtv.corp.google.com/ > * https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@herbertland.com/ > * https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/ > > > This is a great thing by the way because in the data center > environment with multiple equal paths it gives a way to have > pseudo-multipath TCP which jumps between paths in case of an outage. > There might be interest to writedown an informational document for this. That's a bad idea, since specs-wise the Flow-Label is not guaranteed to remain unchanged from source to destination. If you want to ahve multiple paths, then you should implement that in routing. > I wonder what you think is a proper solution: > > * Making FL related RTO change as knob instead of default behavior; > * Adding negotiation behavior in TCP; > * Something else? Just make the FL a function of the connection "identifier". And keeo it constant for the lifetime of that conenction. 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 Tue Nov 24 11:28:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC9B3A1836; Tue, 24 Nov 2020 11:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfVz3TBW_-Bq; Tue, 24 Nov 2020 11:28:39 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503FD3A0E2A; Tue, 24 Nov 2020 11:28:33 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id n11so20453734ota.2; Tue, 24 Nov 2020 11:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d2Xk5BepEbljT/Z1DDKDV6TQTWWdAO2+ntkk96OgV6Q=; b=Ny9BF7iUIP3MYWQ1UBgx6UE4q4FXPMsuuVnlVV9p3l1+Mz1f0ySXLW4aeRLzUdjEpU WK/0/E6p61UvOIN8OrHq1My1YXyBVkV0hlztYZO8YsGishtE8XQnrfxY6pm83ZP98owO r9Sm5Cl1fnxR/cvuEktOvCS29S+ih/R/NLQJnVBe5Ae/SDYGMuJ+dHJ1GLf3IO2NX8kT Ly+ga4UhJEiAkiXW77nQrvC86UQvP8KJpA1lsL0kU9H3OsCgzgmXo3ydBHMV76bbBOVf mqgn3yH3KpLfp1yrsNs6MZSh5XIihkZYz9A/j4Rw3PaQyOF8aXmSV48U/dRwNtC5uu8E M0fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d2Xk5BepEbljT/Z1DDKDV6TQTWWdAO2+ntkk96OgV6Q=; b=hhzcYOFA8+wRpzuXEapTCOB5VKZB1oy8XQVcr8Pgt7gE89OJ0UJJG0cPa0H1YhWy4n 7OA5IWnbh9cv0I4CIl6cf6kbdUdiYCE7XU9wAZ7d0WV0uj+OJkQX6oOttQ7SIqgjfZa7 sWxDiMTeAZVKWkR9Jt8qhX5RJFZpuh0ys0z5Fh6wEuVHHYvJ9GNod25fx3gzpBwrZLEQ eEcZ1VTQU1bYxrRqlKe6Y/YurmX5p/2+XBRfJGCb1M6QFEzzPfeggX1rYVOtzVFbMdWM J7IvxPS+ahRBwzd/J5dBmgJMQSXW/NdFvhqNrntuKNz5bkf084U1z7aEibXi/39lrbTS eeVQ== X-Gm-Message-State: AOAM531BzvcM+EREv9CF30SNTX05bT+V3NgjpIk5zNx8G1MrAsWHCOXG prDg3MFqQiMXnoHe8kJuwLcLM4Vwj/69XnuLlBioeLYlN+M= X-Google-Smtp-Source: ABdhPJwpCkE7Wo9kQRbR/wp1Wr+ihnnRJ5+6pRxlD+/U08o7Gwg896MomdUurN34kHYD2hWwb2a6bX/kH9pay7nM5Ug= X-Received: by 2002:a9d:4c92:: with SMTP id m18mr108833otf.248.1606246112526; Tue, 24 Nov 2020 11:28:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Tue, 24 Nov 2020 22:28:21 +0300 Message-ID: To: Fernando Gont Cc: tcpm , IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000f5860905b4df50ad" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 19:28:41 -0000 --000000000000f5860905b4df50ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fernando, Stating that FL change during TCP session lifetime is a bug - is a bit harsh. It is a fantastic idea to change the FL value if RTO or SYN_RTO happens in a controlled environment. These are very specific TCP timeouts, that provide enough guarantee that there will be no out-of-order packets, though your packets will reach the destination even in case of an outage inside your network. Zero influence on your services in case of the network outage - doesn't sound like a bug for me. The problem is with the current Linux (though I haven't checked other OSes) defaults. Specifically, with the default behavior after RTO event. =D0=B2=D1=82, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 22:06, Ferna= ndo Gont : > On 19/11/20 07:48, Alexander Azimov wrote: > > Dear colleagues, > > > > I have added in the cc both v6op and tcpm for a reason and let me > > explain why. > > > > It's clear that we are moving forward with load balancing that uses flo= w > > label (FL). And the pressure will increase with SRv6 adoption. But at > > the moment wide adoption of FL-based load-balancing may create > > significant issues for TCP Anycast services. > > > > RFC6437 suggests putting hash from 5-tuple into FL value. And as far as > > I know, there is no document that updates this behavior. This > > description is perfectly fine, but what is implemented in the Linux > > kernel is different: FL is carrying hash from 5-tuple with an additiona= l > > seed, and this seed is randomly changed after each RTO/SYN_RTO event. > > Changing the FL upon RTO is a bug. > > I guess/assume that when you say SYN-RTO, you really mean "user > timeout", rather than RTO. If you don't, then that's also a bug. > If you do, I fail to understand what's the reason for wanting the FL to > change in that case, because as a result of port randomization, it 0s > unlikely that the same four-tuple is employed for the next connection > retry. > > > > Here are related patches: > > > > * > https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.m= tv.corp.google.com/ > > * > https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@he= rbertland.com/ > > * > https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/ > > > > > > This is a great thing by the way because in the data center > > environment with multiple equal paths it gives a way to have > > pseudo-multipath TCP which jumps between paths in case of an outage. > > There might be interest to writedown an informational document for this= . > > That's a bad idea, since specs-wise the Flow-Label is not guaranteed to > remain unchanged from source to destination. If you want to ahve > multiple paths, then you should implement that in routing. > > > > > I wonder what you think is a proper solution: > > > > * Making FL related RTO change as knob instead of default behavior; > > * Adding negotiation behavior in TCP; > > * Something else? > > Just make the FL a function of the connection "identifier". And keeo it > constant for the lifetime of that conenction. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > --=20 Best regards, Alexander Azimov --000000000000f5860905b4df50ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fernando,

Stating that FL= change during TCP session lifetime is a bug - is a bit harsh.

It is= a fantastic idea to change the FL value if RTO or SYN_RTO happens in=C2=A0= a controlled=C2=A0environment.=C2=A0
These are very specific TCP timeout= s, that provide enough guarantee that there will be no out-of-order packets= , though your packets will reach the=C2=A0destination=C2=A0even in case of = an outage inside your network. Zero influence on your services in case of t= he network outage - doesn't sound like a bug for me.

The problem= is with the current Linux (though I haven't checked other OSes) defaul= ts. Specifically, with the default behavior after RTO event.

=D0= =B2=D1=82, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 22:06, Fernando= Gont <fernando@gont.com.ar&= gt;:
On 19/11/20= 07:48, Alexander Azimov wrote:
> Dear colleagues,
>
> I have added in the cc both v6op and tcpm for a reason and let me
> explain why.
>
> It's clear that we are moving forward with load balancing that use= s flow
> label (FL). And the pressure will increase with SRv6 adoption. But at =
> the moment wide adoption of FL-based load-balancing may create
> significant issues for TCP Anycast services.
>
> RFC6437 suggests putting hash from 5-tuple into FL value. And as far a= s
> I know, there is no document that updates this behavior. This
> description is perfectly fine, but what is implemented in the Linux > kernel is different: FL is carrying=C2=A0hash=C2=A0from 5-tuple with a= n additional
> seed, and this seed is randomly changed=C2=A0after each RTO/SYN_RTO ev= ent.

Changing the FL upon RTO is a bug.

I guess/assume that when you say SYN-RTO, you really mean "user
timeout", rather than RTO. If you don't, then that's also a bu= g.
If you do, I fail to understand what's the reason for wanting the FL to=
change in that case, because as a result of port randomization, it 0s
unlikely that the same four-tuple is employed for the next connection retry= .


> Here are related patches:
>
>=C2=A0 =C2=A0* https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20= 628@tomh.mtv.corp.google.com/
>=C2=A0 =C2=A0* https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-to= m@herbertland.com/
>=C2=A0 =C2=A0* https://lor= e.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/
>
>
> This is a great thing by the way because in the data center
> environment=C2=A0with multiple equal paths=C2=A0it gives a way to have=
> pseudo-multipath=C2=A0TCP which jumps between paths in case of an outa= ge.
> There might be interest to writedown an informational document for thi= s.

That's a bad idea, since specs-wise the Flow-Label is not guaranteed to=
remain unchanged from source to destination. If you want to ahve
multiple paths, then you should implement that in routing.



> I wonder what you think is a proper solution:
>
>=C2=A0 =C2=A0* Making FL related RTO change as knob instead of default = behavior;
>=C2=A0 =C2=A0* Adding negotiation=C2=A0behavior in TCP;
>=C2=A0 =C2=A0* Something else?

Just make the FL a function of the connection "identifier". And k= eeo it
constant for the lifetime of that conenction.

Thanks,
--
Fernando Gont
e-mail: fernando@= gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





--
Best regards,
Alexander Azi= mov
--000000000000f5860905b4df50ad-- From nobody Tue Nov 24 11:44:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E833A18BC for ; Tue, 24 Nov 2020 11:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBqG2dBBEPZm for ; Tue, 24 Nov 2020 11:44:06 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320D13A18BB for ; Tue, 24 Nov 2020 11:44:06 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id mc24so9126494ejb.6 for ; Tue, 24 Nov 2020 11:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FU2O2RNZOW//Q1QmbUgngJsTZOfiFc8CERjeQLE9RyM=; b=MuM2a2ACT0B2bBsONHR4Y3o1+oAtOwPb+z4PmSsGwxi6u3joaI1HmUOMSmDzAaC8ff CTTKWzxMxGFxR2AAFCPQYOr5iEllhF+MDy396vDZxevgBjsuMUyE2iAZsUBOoJfrvi0p U4iuqFBkvnoG+w0KpTfvL2BBZ+Njln4ss8DEJBIa8gSZ8myS8Q2m7HqMRO69upbk64em 0EqB/PV6bVRm5sgc59EYDld1xedD++td0r1sjydx/tE2JGtNCI2RHniak3muw8Rm6OSM oLE3chsp8+YWhVQZ26mZbW6mwb99JHzgNhtRtceXu4LL4nskp6dD8I4lIbKSWUsd8Uv9 Uyxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FU2O2RNZOW//Q1QmbUgngJsTZOfiFc8CERjeQLE9RyM=; b=ckqwk0sMZcxUAAGmhw0EHrAzZ4ZlW4KOGlXL6STF2lzJphn7kvUb8cE1s0TLFWOWw7 +wvp7jVxvfrOR+F09EMaxXsY5ZfFiSSHBPBEJSg3tTAN0VN9bHN6TdiLYrk3bUYm3lY5 ioFhYSocdggRH2Ttl3vi4zKe7f9QCQko7fAm8bdnX6cJAPv+LwzJlJnkXJ3CVO32+qWG Wi+Xch5mrVvE9Bbgsq/tDg7G9aoeJSIE5BYGQROjwgUS6gCJmV2tGvBY9F7Fxoe2qsk9 iQbT0hXqB49JPXrh0FcBcHLdOwkHzzZ60rdUpeW6/6uZ80woIz5KncEm8JFaIDGIg2vd 6xDA== X-Gm-Message-State: AOAM531HqCAAvnLC5yRMktddVBaWlQwoJhJ2Uofh55YkacpRswgUuVXr KD/itCRLYTJxGYgLW5io3vHuQfqrVpbsxUAatVQTJw== X-Google-Smtp-Source: ABdhPJx20aiuCkrIyqkT15ZaWAeIEao5pLNrlTzgaz7F+bCqqZHC3tHUWhpJRQq1DRNlnXGgT4aFYBb8WVuoop/BAxU= X-Received: by 2002:a17:906:e2da:: with SMTP id gr26mr5337739ejb.265.1606247044480; Tue, 24 Nov 2020 11:44:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Tue, 24 Nov 2020 12:43:52 -0700 Message-ID: To: Fernando Gont Cc: Alexander Azimov , tcpm , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 19:44:08 -0000 On Tue, Nov 24, 2020 at 12:07 PM Fernando Gont wrote: > > On 19/11/20 07:48, Alexander Azimov wrote: > > Dear colleagues, > > > > I have added in the cc both v6op and tcpm for a reason and let me > > explain why. > > > > It's clear that we are moving forward with load balancing that uses flow > > label (FL). And the pressure will increase with SRv6 adoption. But at > > the moment wide adoption of FL-based load-balancing may create > > significant issues for TCP Anycast services. > > > > RFC6437 suggests putting hash from 5-tuple into FL value. And as far as > > I know, there is no document that updates this behavior. This > > description is perfectly fine, but what is implemented in the Linux > > kernel is different: FL is carrying hash from 5-tuple with an additional > > seed, and this seed is randomly changed after each RTO/SYN_RTO event. > > Changing the FL upon RTO is a bug. > > I guess/assume that when you say SYN-RTO, you really mean "user > timeout", rather than RTO. If you don't, then that's also a bug. > If you do, I fail to understand what's the reason for wanting the FL to > change in that case, because as a result of port randomization, it 0s > unlikely that the same four-tuple is employed for the next connection retry. > > > > Here are related patches: > > > > * https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.mtv.corp.google.com/ > > * https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@herbertland.com/ > > * https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/ > > > > > > This is a great thing by the way because in the data center > > environment with multiple equal paths it gives a way to have > > pseudo-multipath TCP which jumps between paths in case of an outage. > > There might be interest to writedown an informational document for this. > > That's a bad idea, since specs-wise the Flow-Label is not guaranteed to > remain unchanged from source to destination. If you want to ahve > multiple paths, then you should implement that in routing. > > > > > I wonder what you think is a proper solution: > > > > * Making FL related RTO change as knob instead of default behavior; > > * Adding negotiation behavior in TCP; > > * Something else? > > Just make the FL a function of the connection "identifier". And keeo it > constant for the lifetime of that conenction. Fernando, Modulating the flow label is a means to affect the routing of packets through the network that uses flow labels as input to the ECMP hash. The basic idea is that the flow label associated with a connection is randomly changed when the stack observes that the connection is failing (e.g. and an RTO). There is nothing in the specs that prevents this since the source is at liberty to set the flow label as it sees fit. The feature is useful in large datacenter networks, like pparently Facebook where the patches originate, since information discerned by TCP can opportunistically be applied to route selection. The practical issue is that there are stateful devices like firewalls that require consistent routing in the network in which case changing the flow label can confuse them. As I mentioned, the original intent was that the flow label randomization feature should be opt-in instead of on by default. Tom > > Thanks, > -- > 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 From nobody Tue Nov 24 11:45:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AB93A18BF; Tue, 24 Nov 2020 11:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DIlQD3lTVTI; Tue, 24 Nov 2020 11:45:40 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B733A18BD; Tue, 24 Nov 2020 11:45:40 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 81so138414pgf.0; Tue, 24 Nov 2020 11:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=l3QdHBNYMCLYS5OFoHm7WqZ7++WzPT2C5Rx7LvQUUW8=; b=fUeU8mppvgPYZNhUoXlm+/13drnVp2Uz0wzmjMDva3PcBGuNfBCbLNvxFqT6/YxU53 taU44jHVA3ZyZpC6D3LOcFPlXRJcPyztJoWbfP3FwfDqIEpb5cMTUumc3qLxTGJHKkZU dhE38FdGD30JlADytwQDHi9VbEhnahvJdPO/eaaK8H/1tRya8BXWAU8COhN4MJtODoZU vewS+IlLCk18vNI2D2LQyR96V6ImDg5PY3uGVfPFbo2fHkBEOri1gja55q6TqtbDSL0X /X9PpCYNyvMsYMy6x2pgKEYgfZBa/2yw6wtSMTnCVc2EGPfNP1JOJDDansFPkps04jhp trug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=l3QdHBNYMCLYS5OFoHm7WqZ7++WzPT2C5Rx7LvQUUW8=; b=fclLeMBErhrEyMMi7tIvnGUg4mERU0tsvmmWZvumsollFUIkvGX61X6OuDDTxKbdrp 1HtdAesJEPiPbasB+lLUo3qkEIyZX1CCeNG7ad7zCxmPhvVMhWmd64ow0kSoA6ZuuFBi 9XtvQMKMAkPgJVgd5vBbqBjXant5zmyd4dKjXniMEyMqun2JYDf3Pwdhd8FMRwRamRsB LHI8yqRoObfwo86GCCtCZwP5L8TdnriGdmAuLd0ejQF4ChIMgWvVhQ5XXhj0AjUyDErq zyjlMCiPVz44+30OoPuW8gF7oCrRQRXrw+qs+LGwzdDjx3egK4H4LxlGBslA7X64Otmh pjHQ== X-Gm-Message-State: AOAM532mBOHkDmnravYhpn/TPBCuU0S/x0TQiLvLQ5gOvqwFhPcIgnSN gt6PddEB+XvdeJTqu8YRll0= X-Google-Smtp-Source: ABdhPJx0ZmKNteCUBaHAg7f9GJobBYwVWBd1yWDfJknzzAaae67YUowh0xal3/HjhpB3r1vHP4Bm5A== X-Received: by 2002:a17:90b:b15:: with SMTP id bf21mr186253pjb.21.1606247139592; Tue, 24 Nov 2020 11:45:39 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id z12sm15943744pfg.123.2020.11.24.11.45.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 11:45:38 -0800 (PST) To: Alexander Azimov , Fernando Gont Cc: IPv6 Operations , tcpm References: From: Brian E Carpenter Message-ID: Date: Wed, 25 Nov 2020 08:45:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 19:45:42 -0000 On 25-Nov-20 08:28, Alexander Azimov wrote: > Hi Fernando, >=20 > Stating that FL change during TCP session lifetime is a bug - is a bit = harsh. It's a bug. It definitely breaks server load balancing, which in practice= is more important than en route load balancing, because it will probably= switch your session to a different server. (OK, I know that there are me= chanisms sometimes for rescuing a session that has unexpectedly moved fro= m one server to another, but in general it's a fail.) I assume you have read https://tools.ietf.org/html/rfc7098 Regards Brian >=20 > It is a fantastic idea to change the FL value if RTO or SYN_RTO happens= in=C2=A0a controlled=C2=A0environment.=C2=A0 > These are very specific TCP timeouts, that provide enough guarantee tha= t there will be no out-of-order packets, though your packets will reach t= he=C2=A0destination=C2=A0even in case of an outage inside your network. Z= ero influence on your services in case of the network outage - doesn't so= und like a bug for me. >=20 > The problem is with the current Linux (though I haven't checked other O= Ses) defaults. Specifically, with the default behavior after RTO event. >=20 > =D0=B2=D1=82, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 22:06, F= ernando Gont >: >=20 > On 19/11/20 07:48, Alexander Azimov wrote: > > Dear colleagues, > > > > I have added in the cc both v6op and tcpm for a reason and let me= > > explain why. > > > > It's clear that we are moving forward with load balancing that us= es flow > > label (FL). And the pressure will increase with SRv6 adoption. Bu= t at > > the moment wide adoption of FL-based load-balancing may create > > significant issues for TCP Anycast services. > > > > RFC6437 suggests putting hash from 5-tuple into FL value. And as = far as > > I know, there is no document that updates this behavior. This > > description is perfectly fine, but what is implemented in the Lin= ux > > kernel is different: FL is carrying=C2=A0hash=C2=A0from 5-tuple w= ith an additional > > seed, and this seed is randomly changed=C2=A0after each RTO/SYN_R= TO event. >=20 > Changing the FL upon RTO is a bug. >=20 > I guess/assume that when you say SYN-RTO, you really mean "user > timeout", rather than RTO. If you don't, then that's also a bug. > If you do, I fail to understand what's the reason for wanting the F= L to > change in that case, because as a result of port randomization, it = 0s > unlikely that the same four-tuple is employed for the next connecti= on retry. >=20 >=20 > > Here are related patches: > > > >=C2=A0 =C2=A0* https://lore.kernel.org/netdev/alpine.DEB.2.02.1407= 012100290.20628@tomh.mtv.corp.google.com/ > >=C2=A0 =C2=A0* https://lore.kernel.org/netdev/1438124526-2129341-1= -git-send-email-tom@herbertland.com/ > >=C2=A0 =C2=A0* https://lore.kernel.org/netdev/20160928020337.30572= 38-1-brakmo@fb.com/ > > > > > > This is a great thing by the way because in the data center > > environment=C2=A0with multiple equal paths=C2=A0it gives a way to= have > > pseudo-multipath=C2=A0TCP which jumps between paths in case of an= outage. > > There might be interest to writedown an informational document fo= r this. >=20 > That's a bad idea, since specs-wise the Flow-Label is not guarantee= d to > remain unchanged from source to destination. If you want to ahve > multiple paths, then you should implement that in routing. >=20 >=20 >=20 > > I wonder what you think is a proper solution: > > > >=C2=A0 =C2=A0* Making FL related RTO change as knob instead of def= ault behavior; > >=C2=A0 =C2=A0* Adding negotiation=C2=A0behavior in TCP; > >=C2=A0 =C2=A0* Something else? >=20 > Just make the FL a function of the connection "identifier". And kee= o it > constant for the lifetime of that conenction. >=20 > Thanks, > --=20 > 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 >=20 >=20 > --=20 > Best regards, > Alexander Azimov >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Nov 24 12:00:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBC13A097D for ; Tue, 24 Nov 2020 12:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmWdhtUVbSth for ; Tue, 24 Nov 2020 11:59:59 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FC73A08F6 for ; Tue, 24 Nov 2020 11:59:59 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id k4so115530edl.0 for ; Tue, 24 Nov 2020 11:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=v9qkRwTfoCBHPKCZzc5O5Y/ldG9QNYn+YcU6f8uxqr4=; b=kQhmeAmeFd+WKt4xHlJsXCB3LXhm6A+7N2IH3n89b95q6V/RPHxdfyR6L614ayw6vx RnKnt8JpPnY0uKJbM5klgdc4z7etJKzuV1juS7lZWDGKJYfVShxN3/Za0K2MpGa5vOCm XK/W23CtyglYxdkvK4TtcDOL+YyjK0DvJyGAyqApeQ3VgtuyY93Lnf4hANRrrA/taupM +1dad4RyQ8Y8YwaWvNDkAYVb3fzsxpv0L9c1V++bpACq1HNKUc2QGKdyR8vpUfrQuPeF 0WNiR+qxKVyGl8k/hLrW2gFjy+LCaDxCQyN2/7bb9eXrl25DHeJRitDODI4qNFrHKCpR QOLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=v9qkRwTfoCBHPKCZzc5O5Y/ldG9QNYn+YcU6f8uxqr4=; b=kLoD+9CuAIQ9G9WFnw6X7os8YhOFZ3bJ+J4CHlxah0mI1hTfWWDAYX6TnCkH8MHe+a Li0M8gbMOW7swVEMU9q0Npsb3e9lkbBuPZtlEEDmIc/1fBf+sASswAHivPodMXuyvNHJ MqdiUukbMZcf+yx/eLUFQfgTjjLF2fzRrU6JoMmZw7xCnllXDXoTPY8s4A5xaoHPvlzY 3ujMXAt2hKL13pONb7QL1gtjCp5UzeDIGOAYtUxG1F83sdK6L4bzgtewoHPi9+vILA+P Q5Fi3GIxn2tN8C8vUYiVVtyoN2XwTiiU1RD9rrcom7TNF8iTbhT4PvO3CR3xxvEdABw0 OWZQ== X-Gm-Message-State: AOAM531JW55HHmVXkHkQZb8tH7JKgyjTw+zJ91zd98JTdREc7vTuEuO1 BmdVnpwenqFxBVoVKa2D0mMwseWF4dZygHKjkhbB2g== X-Google-Smtp-Source: ABdhPJwbpZfa9c+WP7F5mmDQAcP/BL3v0oiq1XtN3FWFonl3mtwYUWf6fqoQiwNbswdL2ZV3FUsIaRmC9hg1i7B47Xw= X-Received: by 2002:aa7:dc49:: with SMTP id g9mr105933edu.383.1606247997550; Tue, 24 Nov 2020 11:59:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Tue, 24 Nov 2020 12:59:46 -0700 Message-ID: To: Brian E Carpenter Cc: Alexander Azimov , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 20:00:04 -0000 On Tue, Nov 24, 2020 at 12:46 PM Brian E Carpenter wrote: > > On 25-Nov-20 08:28, Alexander Azimov wrote: > > Hi Fernando, > > > > Stating that FL change during TCP session lifetime is a bug - is a bit = harsh. > > It's a bug. It definitely breaks server load balancing, which in practice= is more important than en route load balancing, because it will probably s= witch your session to a different server. (OK, I know that there are mechan= isms sometimes for rescuing a session that has unexpectedly moved from one = server to another, but in general it's a fail.) > Brian, IMO it's not that this breaks server load balancing, it's really that server load balancing and other stateful mechanisms break multipath, multihoming, and adaptive routing! In any case, I would agree that in the current Internet it is pragmatic in the current Internet to aim for consistent routing as the default. Tom > I assume you have read https://tools.ietf.org/html/rfc7098 > > Regards > Brian > > > > > It is a fantastic idea to change the FL value if RTO or SYN_RTO happens= in a controlled environment. > > These are very specific TCP timeouts, that provide enough guarantee tha= t there will be no out-of-order packets, though your packets will reach the= destination even in case of an outage inside your network. Zero influence = on your services in case of the network outage - doesn't sound like a bug f= or me. > > > > The problem is with the current Linux (though I haven't checked other O= Ses) defaults. Specifically, with the default behavior after RTO event. > > > > =D0=B2=D1=82, 24 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 22:06, F= ernando Gont >: > > > > On 19/11/20 07:48, Alexander Azimov wrote: > > > Dear colleagues, > > > > > > I have added in the cc both v6op and tcpm for a reason and let me > > > explain why. > > > > > > It's clear that we are moving forward with load balancing that us= es flow > > > label (FL). And the pressure will increase with SRv6 adoption. Bu= t at > > > the moment wide adoption of FL-based load-balancing may create > > > significant issues for TCP Anycast services. > > > > > > RFC6437 suggests putting hash from 5-tuple into FL value. And as = far as > > > I know, there is no document that updates this behavior. This > > > description is perfectly fine, but what is implemented in the Lin= ux > > > kernel is different: FL is carrying hash from 5-tuple with an add= itional > > > seed, and this seed is randomly changed after each RTO/SYN_RTO ev= ent. > > > > Changing the FL upon RTO is a bug. > > > > I guess/assume that when you say SYN-RTO, you really mean "user > > timeout", rather than RTO. If you don't, then that's also a bug. > > If you do, I fail to understand what's the reason for wanting the F= L to > > change in that case, because as a result of port randomization, it = 0s > > unlikely that the same four-tuple is employed for the next connecti= on retry. > > > > > > > Here are related patches: > > > > > > * https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.= 20628@tomh.mtv.corp.google.com/ > > > * https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-= email-tom@herbertland.com/ > > > * https://lore.kernel.org/netdev/20160928020337.3057238-1-brakm= o@fb.com/ > > > > > > > > > This is a great thing by the way because in the data center > > > environment with multiple equal paths it gives a way to have > > > pseudo-multipath TCP which jumps between paths in case of an outa= ge. > > > There might be interest to writedown an informational document fo= r this. > > > > That's a bad idea, since specs-wise the Flow-Label is not guarantee= d to > > remain unchanged from source to destination. If you want to ahve > > multiple paths, then you should implement that in routing. > > > > > > > > > I wonder what you think is a proper solution: > > > > > > * Making FL related RTO change as knob instead of default behav= ior; > > > * Adding negotiation behavior in TCP; > > > * Something else? > > > > Just make the FL a function of the connection "identifier". And kee= o it > > constant for the lifetime of that conenction. > > > > Thanks, > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont= @si6networks.com > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > > > > > > -- > > Best regards, > > Alexander Azimov > > > > _______________________________________________ > > 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 Tue Nov 24 23:13:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A6C3A112D; Tue, 24 Nov 2020 23:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 G6ejUeGjDEYm; Tue, 24 Nov 2020 23:13:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0E03A1129; Tue, 24 Nov 2020 23:13:33 -0800 (PST) Received: from [IPv6:2800:810:464:8164:dc8c:7589:8676:bd67] (unknown [IPv6:2800:810:464:8164:dc8c:7589:8676:bd67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 085AF28050F; Wed, 25 Nov 2020 07:13:28 +0000 (UTC) To: Alexander Azimov Cc: tcpm , IPv6 Operations References: From: Fernando Gont Message-ID: Date: Wed, 25 Nov 2020 04:04:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 07:13:38 -0000 On 24/11/20 16:28, Alexander Azimov wrote: > Hi Fernando, > > Stating that FL change during TCP session lifetime is a bug - is a bit > harsh. Apologies if it came across like that -- the intent was to be blunt, rather than harsh. > It is a fantastic idea to change the FL value if RTO or SYN_RTO happens > in a controlled environment. As noted in my previous email, I'm not sure what you mean by RTO -- but if you really mean "retransmission timeout", doing that fails the definition of FL by RFC6437 and others. -- a retransmitted packet belongs to the ame flow, not to a different one. That aside, please define "controlled environment". :-) > These are very specific TCP timeouts, that provide enough guarantee that > there will be no out-of-order packets, Strictly speaking, that's incorrect:: the RTO is an estimation, and may be fired incorrectly (although the whole point of measuring the RTT anc computing the RTO is for that case to be rather rare). > though your packets will reach > the destination even in case of an outage inside your network. Zero > influence on your services in case of the network outage - doesn't sound > like a bug for me. It seems to me that this sort of behavior is the reason for which folks actually disable the use of the FL. (i.e., think what happens for load balancers). 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 Tue Nov 24 23:13:52 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6A13A1139; Tue, 24 Nov 2020 23:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YESaIJGHZQ3F; Tue, 24 Nov 2020 23:13:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2403A112A; Tue, 24 Nov 2020 23:13:36 -0800 (PST) Received: from [IPv6:2800:810:464:8164:dc8c:7589:8676:bd67] (unknown [IPv6:2800:810:464:8164:dc8c:7589:8676:bd67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 21EE3280546; Wed, 25 Nov 2020 07:13:32 +0000 (UTC) To: Tom Herbert Cc: Alexander Azimov , tcpm , IPv6 Operations References: From: Fernando Gont Message-ID: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> Date: Wed, 25 Nov 2020 04:13:20 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 07:13:43 -0000 Hi, Tom, On 24/11/20 16:43, Tom Herbert wrote: [....] > Modulating the flow label is a means to affect the routing of packets > through the network that uses flow labels as input to the ECMP hash. What's the point? 1) You cannot tell *if* the FL is being used. 2) Changing the FL does not necessarily mean that packets will employ a different link. 3) If the network is failing, shouldn't you handle this via routing? > The basic idea is that the flow label associated with a connection is > randomly changed when the stack observes that the connection is > failing (e.g. and an RTO). There is nothing in the specs that prevents > this since the source is at liberty to set the flow label as it sees > fit. The FL is expected to remain constant for the life of a flow. A retransmitted packet is part of the same flow as the originally-transmitted packet. So this seems to be contradicting the very specification of the FL. For instance, If a RTO for a flow causes the FL to change, then one may possibly argue that the FL is not naming/labeling what is said/expected to be anming/labeling. > The feature is useful in large datacenter networks, like > pparently Facebook where the patches originate, since information > discerned by TCP can opportunistically be applied to route selection. > The practical issue is that there are stateful devices like firewalls > that require consistent routing in the network in which case changing > the flow label can confuse them. As I mentioned, the original intent > was that the flow label randomization feature should be opt-in instead > of on by default. So... where is the "source" of the packet that would be "modulating" the FL? 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 Nov 25 11:35:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2C43A1BE1 for ; Wed, 25 Nov 2020 11:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W8dV4ZGo8vU for ; Wed, 25 Nov 2020 11:35:20 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950663A1BDF for ; Wed, 25 Nov 2020 11:35:20 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id cq7so3792721edb.4 for ; Wed, 25 Nov 2020 11:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iKRu8L6k2Wzc+EUc36nWFqtRrs07O1b+4cGtQZ2Jces=; b=1CvkNK/u5S1DLQfhdC2b/IBPyBXy52CQhbS5AFdaB3PGbNzGHFDnhEj1V95zZXxeFO ClJo5TU6yt5UiQSGBJ0xT4eEp4bMOClopYjjdLfXMdk+eOflH9Wj36QuSGb9L0l4swby rGf84txa/rjncjzUrbE9pdBJdEfWcBLndyjMKtQs9h02kQwwkbjwnU7PmB47Zq6FSzDx hB+B3cKSG+d50iHAPGMwzWfXZSOvlzjgdwcdr225s0xWZs8kPnBQ4sh+HVUTlr3fnmHW ee7hTPzwGCOb7LdvtLv81ltmKtCpmWgETwc/3xMc91NAZLpq8A5KEweGTNLoh9LJW4Tj reIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iKRu8L6k2Wzc+EUc36nWFqtRrs07O1b+4cGtQZ2Jces=; b=a+SJu50bxxQc1NKsb6js+4LToa0mIbId+ut6YiWOm8/FGjw4UJ9PuyNRhuHzPIUxq6 w+OwCY9WtIBHBwuBZhtmboz20XjWwwpWK/ZxyluvwmaJB/3Q+kRi2p2Spj6X9tPGboNV 9GxWqg6EUtHXOsUX0d0LdVwNEqXfFT9BVNOwOpo+ey+YMcEW/9V2Cz83NkTi82+gbVSD n6+KIKeg9aeGTxjdT62a/RgZ389xAGbK/5K0mqYOjxead+vCIFeb9xDsk1vHoLBOLSCz 8BxhiiZ5ZOlvFJRBAQvWAmygG9cABD7aWq1+101DovIjgrtKH4cLxg9N8NRkjlkUnE8u Do1A== X-Gm-Message-State: AOAM53310yNEhcDbKniDLvcJ0OUsUlbYt2ojBB8i9GNQXNXHxU9RMaaI TGLaFtE+Rg0s+2Az6803fJgLXlXPhpJCOb0kQQ7Ieg== X-Google-Smtp-Source: ABdhPJyZWH9g/uec0zdhtlFbmrH5jXXcQo/IL4Ps6aWcgsrIkDSWeqa0u+giKJ4nEDMo7jW1qe0ATkp6XJTJouXGM5Y= X-Received: by 2002:a05:6402:114b:: with SMTP id g11mr5111616edw.228.1606332918541; Wed, 25 Nov 2020 11:35:18 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> In-Reply-To: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> From: Tom Herbert Date: Wed, 25 Nov 2020 12:35:07 -0700 Message-ID: To: Fernando Gont Cc: Alexander Azimov , tcpm , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:35:22 -0000 Hi Fernando, comments in line... On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: > > Hi, Tom, > > On 24/11/20 16:43, Tom Herbert wrote: > [....] > > Modulating the flow label is a means to affect the routing of packets > > through the network that uses flow labels as input to the ECMP hash. > > What's the point? > > 1) You cannot tell *if* the FL is being used. > Generally true, but in a limited domain this information could be discerned. I'd note that it's also generally true that we don't know if there is a load balancer or stateful firewall in the path that requires consistent routing, but in a limited domain we could know that also. > 2) Changing the FL does not necessarily mean that packets will employ a > different link. It's an opportunistic mechanism. If a connection is failing and we get a better path that fixes it by simply changing the flow label then what's the harm? > > 3) If the network is failing, shouldn't you handle this via routing? > Sure, but then that requires an out of band feedback loop from a TCP implementation to the network infrastructure to indicate there is a problem and then the network needs to respond. That's significant infrastructure and higher reaction time than doing something in TCP and IP. Think of modulating the flow label is an inexpensive form of source routing within a limited domain that doesn't need any infrastructure or heavyweight protocols or something like segment routing. > > > > The basic idea is that the flow label associated with a connection is > > randomly changed when the stack observes that the connection is > > failing (e.g. and an RTO). There is nothing in the specs that prevents > > this since the source is at liberty to set the flow label as it sees > > fit. > > The FL is expected to remain constant for the life of a flow. A > retransmitted packet is part of the same flow as the > originally-transmitted packet. So this seems to be contradicting the > very specification of the FL. > > For instance, If a RTO for a flow causes the FL to change, then one may > possibly argue that the FL is not naming/labeling what is said/expected > to be anming/labeling. Specifically, RFC6437 states: "It is therefore RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution." So that is clearly a just recommendation, and not a requirement (and definitely not a MUST). Furthermore, RFC6437 states: "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1." So there's no guarantee in the protocol specs that flow labels are consistent for the life of the connection, which means that the network cannot assume that and thus it would be incorrect if the network tried to enforce flow label consistency as a protocol requirement. As I said, it is prudent to try to be consistent with flow labels and the default behavior in Linux should be changed, however I do not believe there's a valid claim of non-conformance that motivates removal of the feature that is already deployed. Tom > > > > > The feature is useful in large datacenter networks, like > > pparently Facebook where the patches originate, since information > > discerned by TCP can opportunistically be applied to route selection. > > The practical issue is that there are stateful devices like firewalls > > that require consistent routing in the network in which case changing > > the flow label can confuse them. As I mentioned, the original intent > > was that the flow label randomization feature should be opt-in instead > > of on by default. > > So... where is the "source" of the packet that would be "modulating" the FL? > > 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 Nov 25 11:40:03 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B619D3A1BE7; Wed, 25 Nov 2020 11:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC6yqgv_rFZp; Wed, 25 Nov 2020 11:39:57 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 7FA513A1BE5; Wed, 25 Nov 2020 11:39:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4ChB711msQz1nsT2; Wed, 25 Nov 2020 11:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1606333197; bh=a0jtMrN6cPnLUIYqiIhsA6vO3/yEn3HPNFwYzRC7LOE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VeMclSfdHXMmXzVzafNvQ1GUZujsxm+RWZMvXNyXHLl9XfMOkIDsB3OyZBVY80VnE 7YyREH5qS4hSagNwa1vvv2r+LQOmbHKgwisiszb8qhaLm7XyoEvoYYYs+CrtRt7WZ8 AAhQCUaAAqeOnQCz1hS8pwZuJMngUDJ0lWp9WH0U= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4ChB704hsQz1nsWT; Wed, 25 Nov 2020 11:39:56 -0800 (PST) To: Tom Herbert Cc: IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> From: "Joel M. Halpern" Message-ID: <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> Date: Wed, 25 Nov 2020 14:39:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:40:02 -0000 This kind of thing is why, as I understand it, MPTCP has discovery mechanisms ot know if both sides use it, and can select alternative addresses for communication. Trying to guess flow labels that might avoid a problem because it might be an ECMP problem, is just flailing about. Not a good design for operational protocols. And in general, designing protocols around "I know exactly what is going on" (the requirement for what you describe that goes well beyond just "limited domains") is also a recipe for failure. The Flow Label RFCs are actually very explicit that a flow label is supposed to be stable for the life of the flow. Otherwise, it isn't a flow label. Yours, Joel On 11/25/2020 2:35 PM, Tom Herbert wrote: > Hi Fernando, comments in line... > > On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: >> >> Hi, Tom, >> >> On 24/11/20 16:43, Tom Herbert wrote: >> [....] >>> Modulating the flow label is a means to affect the routing of packets >>> through the network that uses flow labels as input to the ECMP hash. >> >> What's the point? >> >> 1) You cannot tell *if* the FL is being used. >> > Generally true, but in a limited domain this information could be > discerned. I'd note that it's also generally true that we don't know > if there is a load balancer or stateful firewall in the path that > requires consistent routing, but in a limited domain we could know > that also. > >> 2) Changing the FL does not necessarily mean that packets will employ a >> different link. > > It's an opportunistic mechanism. If a connection is failing and we get > a better path that fixes it by simply changing the flow label then > what's the harm? > >> >> 3) If the network is failing, shouldn't you handle this via routing? >> > Sure, but then that requires an out of band feedback loop from a TCP > implementation to the network infrastructure to indicate there is a > problem and then the network needs to respond. That's significant > infrastructure and higher reaction time than doing something in TCP > and IP. Think of modulating the flow label is an inexpensive form of > source routing within a limited domain that doesn't need any > infrastructure or heavyweight protocols or something like segment > routing. > >> >> >>> The basic idea is that the flow label associated with a connection is >>> randomly changed when the stack observes that the connection is >>> failing (e.g. and an RTO). There is nothing in the specs that prevents >>> this since the source is at liberty to set the flow label as it sees >>> fit. >> >> The FL is expected to remain constant for the life of a flow. A >> retransmitted packet is part of the same flow as the >> originally-transmitted packet. So this seems to be contradicting the >> very specification of the FL. >> >> For instance, If a RTO for a flow causes the FL to change, then one may >> possibly argue that the FL is not naming/labeling what is said/expected >> to be anming/labeling. > > Specifically, RFC6437 states: > > "It is therefore RECOMMENDED that source hosts support the flow label > by setting the flow label field for all packets of a given flow to the > same value chosen from an approximation to a discrete uniform > distribution." > > So that is clearly a just recommendation, and not a requirement (and > definitely not a MUST). Furthermore, RFC6437 states: > > "A forwarding node MUST either leave a non-zero flow label value > unchanged or change it only for compelling operational security > reasons as described in Section 6.1." > > So there's no guarantee in the protocol specs that flow labels are > consistent for the life of the connection, which means that the > network cannot assume that and thus it would be incorrect if the > network tried to enforce flow label consistency as a protocol > requirement. As I said, it is prudent to try to be consistent with > flow labels and the default behavior in Linux should be changed, > however I do not believe there's a valid claim of non-conformance that > motivates removal of the feature that is already deployed. > > Tom > > > > >> >> >> >>> The feature is useful in large datacenter networks, like >>> pparently Facebook where the patches originate, since information >>> discerned by TCP can opportunistically be applied to route selection. >>> The practical issue is that there are stateful devices like firewalls >>> that require consistent routing in the network in which case changing >>> the flow label can confuse them. As I mentioned, the original intent >>> was that the flow label randomization feature should be opt-in instead >>> of on by default. >> >> So... where is the "source" of the packet that would be "modulating" the FL? >> >> Thanks, >> -- >> 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 > From nobody Wed Nov 25 12:04:56 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7456B3A1C64; Wed, 25 Nov 2020 12:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGikAEzXeGsZ; Wed, 25 Nov 2020 12:04:47 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31523A1C63; Wed, 25 Nov 2020 12:04:47 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id t37so3360256pga.7; Wed, 25 Nov 2020 12:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=42KFVBc8+ZWoF+JqgQiO4syNYF9y+7EKA+BfDce5prs=; b=p0nwqbnzoS0Kzdv0SJYKxq8qfCOJIx2wTDYVQ6sNBIYtMQ7DOk7KF+GAm2c3VcSzcW J5PX4LeXKtll/YPNybnblPgzEaBacea+w0eVSBbDiNtcuQYtWLeJmI3WRfsdfdJ1DZRq mSOshJh5ZiPp4s8uay9uD+dbqhOaotX9fgTc4V7fiXONnieN+l1ow57Dm1gTy1o3RxOS W8VEJNBgrrJdicJSu1SXlkiHzcqW3GiD+ZBDF2UoFbSwA3CSG+F6gQJnCFbl5zfDk7Cg sXbDJVWoHZp36m7yBx2OFTzC914DSIslXWdxRMjmc6GI1clsBpPyT40v1Xn9tFmxhSiN 7QpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=42KFVBc8+ZWoF+JqgQiO4syNYF9y+7EKA+BfDce5prs=; b=pG2N5BUkXGxqYJgcWj65TvIbnx9E4s6RiI4pdtQUBUsF4SkbrC1ds1Vd1QFbl6ku2W mXOfMjrbYuggcrKVolPgF/KVAjdIJgZKGg997kecW8hxAZ25OR5AAcrZwnSHBB6nakpA NFoMCblx4zlQ3Xf3JPbSY5uc84WVteJQ0mFrYSbtipuvSYMerI8pllCC8pYViZalHl1x Du1r84pR8BfUmGzp+vYA7TU6BySzYp9SxrKIUIKfSkiOmgy+f6B7NoaDuTG5YXK3NCgK 0jlIdQ/fRch6FVGexFTFCa+W5z2fSuLBHqbmAzAzgSRhcCZ+ncfGIMYIz724iKPq+nBG pUfA== X-Gm-Message-State: AOAM530S38nfO9+rmWQyjje1dUeoT1kHQhQc6lJ67xZ5pY+nFeol73Rw TZkuuqkjLYMCR1pmAxaI0qL3EoKkiWwlNQ== X-Google-Smtp-Source: ABdhPJyMBMxaHkYZ66l0Y2iytk3PaXXjZ9PdYsd+8ReFqvo7Lq/Qz2hVMJgQ+dWTNMF8bIufpr2T7g== X-Received: by 2002:a62:5e81:0:b029:197:baa5:1792 with SMTP id s123-20020a625e810000b0290197baa51792mr4501345pfb.80.1606334686622; Wed, 25 Nov 2020 12:04:46 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id y5sm3834165pjt.42.2020.11.25.12.04.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 12:04:45 -0800 (PST) To: "Joel M. Halpern" , Tom Herbert Cc: IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Brian E Carpenter Message-ID: <2645ef05-c1e6-e12e-df49-20d318ba39ee@gmail.com> Date: Thu, 26 Nov 2020 09:04:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 20:04:51 -0000 Hi Joel, On 26-Nov-20 08:39, Joel M. Halpern wrote: > This kind of thing is why, as I understand it, MPTCP has discovery > mechanisms ot know if both sides use it, and can select alternative > addresses for communication. > > Trying to guess flow labels that might avoid a problem because it might > be an ECMP problem, is just flailing about. Not a good design for > operational protocols. > > And in general, designing protocols around "I know exactly what is going > on" (the requirement for what you describe that goes well beyond just > "limited domains") is also a recipe for failure. > > The Flow Label RFCs are actually very explicit that a flow label is > supposed to be stable for the life of the flow. Otherwise, it isn't a > flow label. That's correct. However, the first paragraph of RFC6437 tells you that it's the prerogative of the source of a flow to decide what is a flow. It even says "a flow is not necessarily 1:1 mapped to a transport connection." Therefore, Tom is correct that a source is conformant even if it changes its mind halfway through a TCP connection. However, it's only safe to do that if the source also knows that no harm will result, which it cannot know in the general case. In a limited domain, the source could know that there is no server load balancing in place, in which case changing the label is not automatically damaging. Thus, this is not something that should ever become a default behaviour, and I think this thread began with a complaint that in some o/s release it was the default. Regards Brian > > Yours, > Joel > > On 11/25/2020 2:35 PM, Tom Herbert wrote: >> Hi Fernando, comments in line... >> >> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: >>> >>> Hi, Tom, >>> >>> On 24/11/20 16:43, Tom Herbert wrote: >>> [....] >>>> Modulating the flow label is a means to affect the routing of packets >>>> through the network that uses flow labels as input to the ECMP hash. >>> >>> What's the point? >>> >>> 1) You cannot tell *if* the FL is being used. >>> >> Generally true, but in a limited domain this information could be >> discerned. I'd note that it's also generally true that we don't know >> if there is a load balancer or stateful firewall in the path that >> requires consistent routing, but in a limited domain we could know >> that also. >> >>> 2) Changing the FL does not necessarily mean that packets will employ a >>> different link. >> >> It's an opportunistic mechanism. If a connection is failing and we get >> a better path that fixes it by simply changing the flow label then >> what's the harm? >> >>> >>> 3) If the network is failing, shouldn't you handle this via routing? >>> >> Sure, but then that requires an out of band feedback loop from a TCP >> implementation to the network infrastructure to indicate there is a >> problem and then the network needs to respond. That's significant >> infrastructure and higher reaction time than doing something in TCP >> and IP. Think of modulating the flow label is an inexpensive form of >> source routing within a limited domain that doesn't need any >> infrastructure or heavyweight protocols or something like segment >> routing. >> >>> >>> >>>> The basic idea is that the flow label associated with a connection is >>>> randomly changed when the stack observes that the connection is >>>> failing (e.g. and an RTO). There is nothing in the specs that prevents >>>> this since the source is at liberty to set the flow label as it sees >>>> fit. >>> >>> The FL is expected to remain constant for the life of a flow. A >>> retransmitted packet is part of the same flow as the >>> originally-transmitted packet. So this seems to be contradicting the >>> very specification of the FL. >>> >>> For instance, If a RTO for a flow causes the FL to change, then one may >>> possibly argue that the FL is not naming/labeling what is said/expected >>> to be anming/labeling. >> >> Specifically, RFC6437 states: >> >> "It is therefore RECOMMENDED that source hosts support the flow label >> by setting the flow label field for all packets of a given flow to the >> same value chosen from an approximation to a discrete uniform >> distribution." >> >> So that is clearly a just recommendation, and not a requirement (and >> definitely not a MUST). Furthermore, RFC6437 states: >> >> "A forwarding node MUST either leave a non-zero flow label value >> unchanged or change it only for compelling operational security >> reasons as described in Section 6.1." >> >> So there's no guarantee in the protocol specs that flow labels are >> consistent for the life of the connection, which means that the >> network cannot assume that and thus it would be incorrect if the >> network tried to enforce flow label consistency as a protocol >> requirement. As I said, it is prudent to try to be consistent with >> flow labels and the default behavior in Linux should be changed, >> however I do not believe there's a valid claim of non-conformance that >> motivates removal of the feature that is already deployed. >> >> Tom >> >> >> >> >>> >>> >>> >>>> The feature is useful in large datacenter networks, like >>>> pparently Facebook where the patches originate, since information >>>> discerned by TCP can opportunistically be applied to route selection. >>>> The practical issue is that there are stateful devices like firewalls >>>> that require consistent routing in the network in which case changing >>>> the flow label can confuse them. As I mentioned, the original intent >>>> was that the flow label randomization feature should be opt-in instead >>>> of on by default. >>> >>> So... where is the "source" of the packet that would be "modulating" the FL? >>> >>> Thanks, >>> -- >>> 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 >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 25 12:05:27 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DDA3A1C69 for ; Wed, 25 Nov 2020 12:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQq9vBSH6zgN for ; Wed, 25 Nov 2020 12:05:16 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396E53A1CAC for ; Wed, 25 Nov 2020 12:05:13 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id oq3so4737855ejb.7 for ; Wed, 25 Nov 2020 12:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fcooyIZCSMch3fTbFOLokrdujEjrdUAGttzOwcEB5tU=; b=IqGI+/ARxrRXUbowuvoNX4o+J1DVc/2mFsiy30gS02MSOOWJxSDrHcPzIA46kw6+Z4 yAVGqY7AZ2Bd9AjlncwVe/sbiYLOOP55H+3VHa90yXDQi7ErrSMNUvCs8xtd0osm192G KvmxVo5Ynf4Lx7EyOGljQ5hkk9O1AZifcChgS7LA+DqbGP5mWD/Kv8qxzSzcAdETwYh+ G9e0T+5w8c2elNOkFC+5AIuvd5EIY2NXpKVrHwYL0rt3STPlexoZBfyDMwXUWSMwArIo Ws7maAAyxKLVExWTWpV+6WOBqCJ7pUTmQTYrzyEWMYakPRwsSwCMeHF428CkEbaprZp1 ti8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fcooyIZCSMch3fTbFOLokrdujEjrdUAGttzOwcEB5tU=; b=HHwHNUEGDc2epTuIb5qqorGM2BlDgochTL/4lMz4H3k/NJ8y0e0xK0ivLhCqPutdnV vSUIc8eSwlHN5PGa/P7Cb288meMwmpS9jRUOgsja5+d7EiLrPCY4bhPpLmpQ/uqeTysy 3ZJI5yVzTglyEgsY7pu9aILeoC9pFKNGuDIsTl4ump0R+5e//rrYId0iqIs/CWESf6mg i6n3IcocfruapRGTbz5cftQPEiI/M5lYA5BqjLGiQtK+DHQXCedJhsNwteioGw7di2TU Y1vJOxYRalgjWfsWEuzKVxuG2BM8yar5+9h63vKumMb8lvwn1PitZwN79ZZFzgg/07Oa uaeQ== X-Gm-Message-State: AOAM531eo0Vi3Y6o5nodawNTyQIpkGY04FYXMwt3667g5MRLDDGqAvFa o2dpC3F1ZIKSGyfo7oznd+bqoAO07bLp+oy1kiUSYLeCpmk= X-Google-Smtp-Source: ABdhPJwx/znQ66iAKYmdAJEV4MnLbSaRZ1ZT/TpKPYbZpXPm7wOw19C9hZH7ijmbZM/ujPfIVZxHUjuyl2jFhYvWPCY= X-Received: by 2002:a17:906:3294:: with SMTP id 20mr4584338ejw.239.1606334711385; Wed, 25 Nov 2020 12:05:11 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> In-Reply-To: <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Tom Herbert Date: Wed, 25 Nov 2020 13:05:00 -0700 Message-ID: To: "Joel M. Halpern" Cc: IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 20:05:23 -0000 Joel, Is there an RFC that clearly and unambiguously states that a host MUST use the same flow label for the lifetime _and_ clearly defines exactly what a flow is with respect to such a requirement (for instance, how would you define a flow and enforce such a requirement in UDP? IPsec? other encapsulations?). If there is such a requirement then we'll change the code to be conformant. Tom On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern wrote: > > This kind of thing is why, as I understand it, MPTCP has discovery > mechanisms ot know if both sides use it, and can select alternative > addresses for communication. > > Trying to guess flow labels that might avoid a problem because it might > be an ECMP problem, is just flailing about. Not a good design for > operational protocols. > > And in general, designing protocols around "I know exactly what is going > on" (the requirement for what you describe that goes well beyond just > "limited domains") is also a recipe for failure. > > The Flow Label RFCs are actually very explicit that a flow label is > supposed to be stable for the life of the flow. Otherwise, it isn't a > flow label. > > Yours, > Joel > > On 11/25/2020 2:35 PM, Tom Herbert wrote: > > Hi Fernando, comments in line... > > > > On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: > >> > >> Hi, Tom, > >> > >> On 24/11/20 16:43, Tom Herbert wrote: > >> [....] > >>> Modulating the flow label is a means to affect the routing of packets > >>> through the network that uses flow labels as input to the ECMP hash. > >> > >> What's the point? > >> > >> 1) You cannot tell *if* the FL is being used. > >> > > Generally true, but in a limited domain this information could be > > discerned. I'd note that it's also generally true that we don't know > > if there is a load balancer or stateful firewall in the path that > > requires consistent routing, but in a limited domain we could know > > that also. > > > >> 2) Changing the FL does not necessarily mean that packets will employ a > >> different link. > > > > It's an opportunistic mechanism. If a connection is failing and we get > > a better path that fixes it by simply changing the flow label then > > what's the harm? > > > >> > >> 3) If the network is failing, shouldn't you handle this via routing? > >> > > Sure, but then that requires an out of band feedback loop from a TCP > > implementation to the network infrastructure to indicate there is a > > problem and then the network needs to respond. That's significant > > infrastructure and higher reaction time than doing something in TCP > > and IP. Think of modulating the flow label is an inexpensive form of > > source routing within a limited domain that doesn't need any > > infrastructure or heavyweight protocols or something like segment > > routing. > > > >> > >> > >>> The basic idea is that the flow label associated with a connection is > >>> randomly changed when the stack observes that the connection is > >>> failing (e.g. and an RTO). There is nothing in the specs that prevents > >>> this since the source is at liberty to set the flow label as it sees > >>> fit. > >> > >> The FL is expected to remain constant for the life of a flow. A > >> retransmitted packet is part of the same flow as the > >> originally-transmitted packet. So this seems to be contradicting the > >> very specification of the FL. > >> > >> For instance, If a RTO for a flow causes the FL to change, then one may > >> possibly argue that the FL is not naming/labeling what is said/expected > >> to be anming/labeling. > > > > Specifically, RFC6437 states: > > > > "It is therefore RECOMMENDED that source hosts support the flow label > > by setting the flow label field for all packets of a given flow to the > > same value chosen from an approximation to a discrete uniform > > distribution." > > > > So that is clearly a just recommendation, and not a requirement (and > > definitely not a MUST). Furthermore, RFC6437 states: > > > > "A forwarding node MUST either leave a non-zero flow label value > > unchanged or change it only for compelling operational security > > reasons as described in Section 6.1." > > > > So there's no guarantee in the protocol specs that flow labels are > > consistent for the life of the connection, which means that the > > network cannot assume that and thus it would be incorrect if the > > network tried to enforce flow label consistency as a protocol > > requirement. As I said, it is prudent to try to be consistent with > > flow labels and the default behavior in Linux should be changed, > > however I do not believe there's a valid claim of non-conformance that > > motivates removal of the feature that is already deployed. > > > > Tom > > > > > > > > > >> > >> > >> > >>> The feature is useful in large datacenter networks, like > >>> pparently Facebook where the patches originate, since information > >>> discerned by TCP can opportunistically be applied to route selection. > >>> The practical issue is that there are stateful devices like firewalls > >>> that require consistent routing in the network in which case changing > >>> the flow label can confuse them. As I mentioned, the original intent > >>> was that the flow label randomization feature should be opt-in instead > >>> of on by default. > >> > >> So... where is the "source" of the packet that would be "modulating" the FL? > >> > >> Thanks, > >> -- > >> 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 > > From nobody Wed Nov 25 13:28:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E293A1ECE; Wed, 25 Nov 2020 13:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpDmqAOQC1Tg; Wed, 25 Nov 2020 13:27:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 543973A1E94; Wed, 25 Nov 2020 13:27:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4ChDWX1HK2z1nwrK; Wed, 25 Nov 2020 13:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1606339672; bh=feWobQX63XBosVSXdSvhuC/jwbLg/k8cOu5WhaTI6f8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QE7FapcL2gi4lyg3s2h1hKLqCHHw2bAIGZfBwYGIYf55OkSUzmToKJA7uGUITTbya OsKgnpZXXvPYNM7ob5uRdlwlerkXBd884kYq5DgNdrXjIGmQ8jj5Nqz17BbCXQcAyv Oi1zplX6ro8yuHc+OmhK5r8dfGIWtTdpmNN8+2ws= X-Quarantine-ID: <9Ztez0OfM0yx> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4ChDWW0PnXz1nwr0; Wed, 25 Nov 2020 13:27:50 -0800 (PST) To: Tom Herbert Cc: IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 25 Nov 2020 16:27:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 21:28:03 -0000 No, as Brian says, there are escape clauses in the flow definitions. But changing the flow label due to traffic problems does not correspond to packets being in actually different flows. If one were using UDP, and mixing loss sensitive packets with loss insensitive packets for a special application, sure, one could use two flow labels. But that is not what you are describing. Yours, Joel On 11/25/2020 3:05 PM, Tom Herbert wrote: > Joel, > > Is there an RFC that clearly and unambiguously states that a host MUST > use the same flow label for the lifetime _and_ clearly defines exactly > what a flow is with respect to such a requirement (for instance, how > would you define a flow and enforce such a requirement in UDP? IPsec? > other encapsulations?). If there is such a requirement then we'll > change the code to be conformant. > > Tom > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern wrote: >> >> This kind of thing is why, as I understand it, MPTCP has discovery >> mechanisms ot know if both sides use it, and can select alternative >> addresses for communication. >> >> Trying to guess flow labels that might avoid a problem because it might >> be an ECMP problem, is just flailing about. Not a good design for >> operational protocols. >> >> And in general, designing protocols around "I know exactly what is going >> on" (the requirement for what you describe that goes well beyond just >> "limited domains") is also a recipe for failure. >> >> The Flow Label RFCs are actually very explicit that a flow label is >> supposed to be stable for the life of the flow. Otherwise, it isn't a >> flow label. >> >> Yours, >> Joel >> >> On 11/25/2020 2:35 PM, Tom Herbert wrote: >>> Hi Fernando, comments in line... >>> >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: >>>> >>>> Hi, Tom, >>>> >>>> On 24/11/20 16:43, Tom Herbert wrote: >>>> [....] >>>>> Modulating the flow label is a means to affect the routing of packets >>>>> through the network that uses flow labels as input to the ECMP hash. >>>> >>>> What's the point? >>>> >>>> 1) You cannot tell *if* the FL is being used. >>>> >>> Generally true, but in a limited domain this information could be >>> discerned. I'd note that it's also generally true that we don't know >>> if there is a load balancer or stateful firewall in the path that >>> requires consistent routing, but in a limited domain we could know >>> that also. >>> >>>> 2) Changing the FL does not necessarily mean that packets will employ a >>>> different link. >>> >>> It's an opportunistic mechanism. If a connection is failing and we get >>> a better path that fixes it by simply changing the flow label then >>> what's the harm? >>> >>>> >>>> 3) If the network is failing, shouldn't you handle this via routing? >>>> >>> Sure, but then that requires an out of band feedback loop from a TCP >>> implementation to the network infrastructure to indicate there is a >>> problem and then the network needs to respond. That's significant >>> infrastructure and higher reaction time than doing something in TCP >>> and IP. Think of modulating the flow label is an inexpensive form of >>> source routing within a limited domain that doesn't need any >>> infrastructure or heavyweight protocols or something like segment >>> routing. >>> >>>> >>>> >>>>> The basic idea is that the flow label associated with a connection is >>>>> randomly changed when the stack observes that the connection is >>>>> failing (e.g. and an RTO). There is nothing in the specs that prevents >>>>> this since the source is at liberty to set the flow label as it sees >>>>> fit. >>>> >>>> The FL is expected to remain constant for the life of a flow. A >>>> retransmitted packet is part of the same flow as the >>>> originally-transmitted packet. So this seems to be contradicting the >>>> very specification of the FL. >>>> >>>> For instance, If a RTO for a flow causes the FL to change, then one may >>>> possibly argue that the FL is not naming/labeling what is said/expected >>>> to be anming/labeling. >>> >>> Specifically, RFC6437 states: >>> >>> "It is therefore RECOMMENDED that source hosts support the flow label >>> by setting the flow label field for all packets of a given flow to the >>> same value chosen from an approximation to a discrete uniform >>> distribution." >>> >>> So that is clearly a just recommendation, and not a requirement (and >>> definitely not a MUST). Furthermore, RFC6437 states: >>> >>> "A forwarding node MUST either leave a non-zero flow label value >>> unchanged or change it only for compelling operational security >>> reasons as described in Section 6.1." >>> >>> So there's no guarantee in the protocol specs that flow labels are >>> consistent for the life of the connection, which means that the >>> network cannot assume that and thus it would be incorrect if the >>> network tried to enforce flow label consistency as a protocol >>> requirement. As I said, it is prudent to try to be consistent with >>> flow labels and the default behavior in Linux should be changed, >>> however I do not believe there's a valid claim of non-conformance that >>> motivates removal of the feature that is already deployed. >>> >>> Tom >>> >>> >>> >>> >>>> >>>> >>>> >>>>> The feature is useful in large datacenter networks, like >>>>> pparently Facebook where the patches originate, since information >>>>> discerned by TCP can opportunistically be applied to route selection. >>>>> The practical issue is that there are stateful devices like firewalls >>>>> that require consistent routing in the network in which case changing >>>>> the flow label can confuse them. As I mentioned, the original intent >>>>> was that the flow label randomization feature should be opt-in instead >>>>> of on by default. >>>> >>>> So... where is the "source" of the packet that would be "modulating" the FL? >>>> >>>> Thanks, >>>> -- >>>> 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 >>> From nobody Wed Nov 25 14:13:35 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0ED3A1EE9 for ; Wed, 25 Nov 2020 14:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOq58t1weDd3 for ; Wed, 25 Nov 2020 14:13:27 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1433A1ED4 for ; Wed, 25 Nov 2020 14:13:26 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id lt17so4642853ejb.3 for ; Wed, 25 Nov 2020 14:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WxdQiywIPlAyDaIo00bMFE94JVqujKhxjM2KopTZ6Mg=; b=E8CBiwMuIw3ttPfv0pyd7ev5NZBQjwN3T1CSOIreCT5esXuu14bAdfqYyWodpbV444 feo9IKDzxEKJMk9w59Quz9dvy+C+LqqAkpUxqTLjD/F7uwxcmMDBB+GTSHSqpICirOAM SJzgEBX3LX1EBPpDMPle4tvLCLQ7GHnC84//CVoO8p72FdLo9qywcj8Q5npJBhxxX+Sq J+YK45z+CJU2hIrBzIcuK6+CRzfMo7mQRd49Wz0HJRHjQ6X/Hm3WS5/bY6mX0WyTXjAJ s7nrf5G9N06+GrvQZI6zNLs7sgUfFCqTkurJ1fKV9yD5lL4RgUvGB2IR1rWzJj4Ouxts 1P9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WxdQiywIPlAyDaIo00bMFE94JVqujKhxjM2KopTZ6Mg=; b=gntiF4/XHnUK6qQJgHUFM4FDl6qJ8KGE7K2Dpi+o0zNVdo0JlAW26kPdDNL3RT1x6E 4uKpSg7nbiGCrh+hMOR0iu21p1mLBn8aly5Dn4MWqWnA6t8YO/ZKjxvYVoHaPUiT/lui Gd3rdVt7YDpqjB8w0I+OX6ZYiEMs2ivaY+Z1fViZAOkJqT4oiocVxU6id07xus9zYEUZ bEmb9uRzlMG20fCKdqP8L43QiTT0+44odPpKVlvLLGGlrhnqxKipQJz3+4gPFv/WMucH 4AxaK/UZADHrwMle6hrLgrvrOWYzqnMtoGhDr/1zowrDh4edpRku5hTzBuZJDogMdtyq 0KMA== X-Gm-Message-State: AOAM533iqrccyso3PGZftLQFZ/gzC9J/6KLEOP0NrMY9qH1dLPwcLa6n 3GpsDaFFHY3sxGoRKW9UjIv8pGMWTj1bg4s0BYIDFg== X-Google-Smtp-Source: ABdhPJwuken19hAvQqUqHZreGho/udbFEVyecKPAEhXbyr+FG36vuGUBMU0z+Zw4yvdKvEBXtZ+4peX1pZWhGpj7a34= X-Received: by 2002:a17:906:180b:: with SMTP id v11mr79086eje.41.1606342403708; Wed, 25 Nov 2020 14:13:23 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> In-Reply-To: From: Tom Herbert Date: Wed, 25 Nov 2020 14:13:11 -0800 Message-ID: To: "Joel M. Halpern" Cc: IPv6 Operations , tcpm Content-Type: multipart/alternative; boundary="0000000000005c70cc05b4f5bcdb" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 22:13:31 -0000 --0000000000005c70cc05b4f5bcdb Content-Type: text/plain; charset="UTF-8" Joel, is there a normative definition of a flow? On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern wrote: > No, as Brian says, there are escape clauses in the flow definitions. > > But changing the flow label due to traffic problems does not correspond > to packets being in actually different flows. > If one were using UDP, and mixing loss sensitive packets with loss > insensitive packets for a special application, sure, one could use two > flow labels. But that is not what you are describing. > > Yours, > Joel > > On 11/25/2020 3:05 PM, Tom Herbert wrote: > > Joel, > > > > Is there an RFC that clearly and unambiguously states that a host MUST > > use the same flow label for the lifetime _and_ clearly defines exactly > > what a flow is with respect to such a requirement (for instance, how > > would you define a flow and enforce such a requirement in UDP? IPsec? > > other encapsulations?). If there is such a requirement then we'll > > change the code to be conformant. > > > > Tom > > > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern > wrote: > >> > >> This kind of thing is why, as I understand it, MPTCP has discovery > >> mechanisms ot know if both sides use it, and can select alternative > >> addresses for communication. > >> > >> Trying to guess flow labels that might avoid a problem because it might > >> be an ECMP problem, is just flailing about. Not a good design for > >> operational protocols. > >> > >> And in general, designing protocols around "I know exactly what is going > >> on" (the requirement for what you describe that goes well beyond just > >> "limited domains") is also a recipe for failure. > >> > >> The Flow Label RFCs are actually very explicit that a flow label is > >> supposed to be stable for the life of the flow. Otherwise, it isn't a > >> flow label. > >> > >> Yours, > >> Joel > >> > >> On 11/25/2020 2:35 PM, Tom Herbert wrote: > >>> Hi Fernando, comments in line... > >>> > >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont > wrote: > >>>> > >>>> Hi, Tom, > >>>> > >>>> On 24/11/20 16:43, Tom Herbert wrote: > >>>> [....] > >>>>> Modulating the flow label is a means to affect the routing of packets > >>>>> through the network that uses flow labels as input to the ECMP hash. > >>>> > >>>> What's the point? > >>>> > >>>> 1) You cannot tell *if* the FL is being used. > >>>> > >>> Generally true, but in a limited domain this information could be > >>> discerned. I'd note that it's also generally true that we don't know > >>> if there is a load balancer or stateful firewall in the path that > >>> requires consistent routing, but in a limited domain we could know > >>> that also. > >>> > >>>> 2) Changing the FL does not necessarily mean that packets will employ > a > >>>> different link. > >>> > >>> It's an opportunistic mechanism. If a connection is failing and we get > >>> a better path that fixes it by simply changing the flow label then > >>> what's the harm? > >>> > >>>> > >>>> 3) If the network is failing, shouldn't you handle this via routing? > >>>> > >>> Sure, but then that requires an out of band feedback loop from a TCP > >>> implementation to the network infrastructure to indicate there is a > >>> problem and then the network needs to respond. That's significant > >>> infrastructure and higher reaction time than doing something in TCP > >>> and IP. Think of modulating the flow label is an inexpensive form of > >>> source routing within a limited domain that doesn't need any > >>> infrastructure or heavyweight protocols or something like segment > >>> routing. > >>> > >>>> > >>>> > >>>>> The basic idea is that the flow label associated with a connection is > >>>>> randomly changed when the stack observes that the connection is > >>>>> failing (e.g. and an RTO). There is nothing in the specs that > prevents > >>>>> this since the source is at liberty to set the flow label as it sees > >>>>> fit. > >>>> > >>>> The FL is expected to remain constant for the life of a flow. A > >>>> retransmitted packet is part of the same flow as the > >>>> originally-transmitted packet. So this seems to be contradicting the > >>>> very specification of the FL. > >>>> > >>>> For instance, If a RTO for a flow causes the FL to change, then one > may > >>>> possibly argue that the FL is not naming/labeling what is > said/expected > >>>> to be anming/labeling. > >>> > >>> Specifically, RFC6437 states: > >>> > >>> "It is therefore RECOMMENDED that source hosts support the flow label > >>> by setting the flow label field for all packets of a given flow to the > >>> same value chosen from an approximation to a discrete uniform > >>> distribution." > >>> > >>> So that is clearly a just recommendation, and not a requirement (and > >>> definitely not a MUST). Furthermore, RFC6437 states: > >>> > >>> "A forwarding node MUST either leave a non-zero flow label value > >>> unchanged or change it only for compelling operational security > >>> reasons as described in Section 6.1." > >>> > >>> So there's no guarantee in the protocol specs that flow labels are > >>> consistent for the life of the connection, which means that the > >>> network cannot assume that and thus it would be incorrect if the > >>> network tried to enforce flow label consistency as a protocol > >>> requirement. As I said, it is prudent to try to be consistent with > >>> flow labels and the default behavior in Linux should be changed, > >>> however I do not believe there's a valid claim of non-conformance that > >>> motivates removal of the feature that is already deployed. > >>> > >>> Tom > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>>> The feature is useful in large datacenter networks, like > >>>>> pparently Facebook where the patches originate, since information > >>>>> discerned by TCP can opportunistically be applied to route selection. > >>>>> The practical issue is that there are stateful devices like firewalls > >>>>> that require consistent routing in the network in which case changing > >>>>> the flow label can confuse them. As I mentioned, the original intent > >>>>> was that the flow label randomization feature should be opt-in > instead > >>>>> of on by default. > >>>> > >>>> So... where is the "source" of the packet that would be "modulating" > the FL? > >>>> > >>>> Thanks, > >>>> -- > >>>> 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 > >>> > --0000000000005c70cc05b4f5bcdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joel, is there a normative definition of a flow?
=
On Wed= , Nov 25, 2020, 1:27 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
No, as Brian says, there are escape clauses in the flow definitions= .

But changing the flow label due to traffic problems does not correspond to packets being in actually different flows.
If one were using UDP, and mixing loss sensitive packets with loss
insensitive packets for a special application, sure, one could use two
flow labels.=C2=A0 But that is not what you are describing.

Yours,
Joel

On 11/25/2020 3:05 PM, Tom Herbert wrote:
> Joel,
>
> Is there an RFC that clearly and unambiguously states that a host MUST=
> use the same flow label for the lifetime _and_ clearly defines exactly=
> what a flow is with respect to such a requirement (for instance, how > would you define a flow and enforce such a requirement in UDP? IPsec?<= br> > other encapsulations?). If there is such a requirement then we'll<= br> > change the code to be conformant.
>
> Tom
>
> On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern <jmh@joelhalpern.= com> wrote:
>>
>> This kind of thing is why, as I understand it, MPTCP has discovery=
>> mechanisms ot know if both sides use it, and can select alternativ= e
>> addresses for communication.
>>
>> Trying to guess flow labels that might avoid a problem because it = might
>> be an ECMP problem, is just flailing about.=C2=A0 Not a good desig= n for
>> operational protocols.
>>
>> And in general, designing protocols around "I know exactly wh= at is going
>> on"=C2=A0 (the requirement for what you describe that goes we= ll beyond just
>> "limited domains") is also a recipe for failure.
>>
>> The Flow Label RFCs are actually very explicit that a flow label i= s
>> supposed to be stable for the life of the flow.=C2=A0 Otherwise, i= t isn't a
>> flow label.
>>
>> Yours,
>> Joel
>>
>> On 11/25/2020 2:35 PM, Tom Herbert wrote:
>>> Hi Fernando, comments in line...
>>>
>>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont <fernando@= gont.com.ar> wrote:
>>>>
>>>> Hi, Tom,
>>>>
>>>> On 24/11/20 16:43, Tom Herbert wrote:
>>>> [....]
>>>>> Modulating the flow label is a means to affect the rou= ting of packets
>>>>> through the network that uses flow labels as input to = the ECMP hash.
>>>>
>>>> What's the point?
>>>>
>>>> 1) You cannot tell *if* the FL is being used.
>>>>
>>> Generally true, but in a limited domain this information could= be
>>> discerned. I'd note that it's also generally true that= we don't know
>>> if there is a load balancer or stateful firewall in the path t= hat
>>> requires consistent routing, but in a limited domain we could = know
>>> that also.
>>>
>>>> 2) Changing the FL does not necessarily mean that packets = will employ a
>>>> different link.
>>>
>>> It's an opportunistic mechanism. If a connection is failin= g and we get
>>> a better path that fixes it by simply changing the flow label = then
>>> what's the harm?
>>>
>>>>
>>>> 3) If the network is failing, shouldn't you handle thi= s via routing?
>>>>
>>> Sure, but then that requires an out of band feedback loop from= a TCP
>>> implementation to the network infrastructure to indicate there= is a
>>> problem and then the network needs to respond. That's sign= ificant
>>> infrastructure and higher reaction time than doing something i= n TCP
>>> and IP. Think of modulating the flow label is an inexpensive f= orm of
>>> source routing within a limited domain that doesn't need a= ny
>>> infrastructure or heavyweight protocols or something like segm= ent
>>> routing.
>>>
>>>>
>>>>
>>>>> The basic idea is that the flow label associated with = a connection is
>>>>> randomly changed when the stack observes that the conn= ection is
>>>>> failing (e.g. and an RTO). There is nothing in the spe= cs that prevents
>>>>> this since the source is at liberty to set the flow la= bel as it sees
>>>>> fit.
>>>>
>>>> The FL is expected to remain constant for the life of a fl= ow. A
>>>> retransmitted packet is part of the same flow as the
>>>> originally-transmitted packet. So this seems to be contrad= icting the
>>>> very specification of the FL.
>>>>
>>>> For instance, If a RTO for a flow causes the FL to change,= then one may
>>>> possibly argue that the FL is not naming/labeling what is = said/expected
>>>> to be anming/labeling.
>>>
>>> Specifically, RFC6437 states:
>>>
>>> "It is therefore RECOMMENDED that source hosts support th= e flow label
>>> by setting the flow label field for all packets of a given flo= w to the
>>> same value chosen from an approximation to a discrete uniform<= br> >>> distribution."
>>>
>>> So that is clearly a just recommendation, and not a requiremen= t (and
>>> definitely not a MUST). Furthermore, RFC6437 states:
>>>
>>> "A forwarding node MUST either leave a non-zero flow labe= l value
>>> unchanged or change it only for compelling operational securit= y
>>> reasons as described in Section 6.1."
>>>
>>> So there's no guarantee in the protocol specs that flow la= bels are
>>> consistent for the life of the connection, which means that th= e
>>> network cannot assume that and thus it would be incorrect if t= he
>>> network tried to enforce flow label consistency as a protocol<= br> >>> requirement. As I said, it is prudent to try to be consistent = with
>>> flow labels and the default behavior in Linux should be change= d,
>>> however I do not believe there's a valid claim of non-conf= ormance that
>>> motivates removal of the feature that is already deployed.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>> The feature is useful in large datacenter networks, li= ke
>>>>> pparently Facebook where the patches originate, since = information
>>>>> discerned by TCP can opportunistically be applied to r= oute selection.
>>>>> The practical issue is that there are stateful devices= like firewalls
>>>>> that require consistent routing in the network in whic= h case changing
>>>>> the flow label can confuse them. As I mentioned, the o= riginal intent
>>>>> was that the flow label randomization feature should b= e opt-in instead
>>>>> of on by default.
>>>>
>>>> So... where is the "source" of the packet that w= ould be "modulating" the FL?
>>>>
>>>> Thanks,
>>>> --
>>>> Fernando Gont
>>>> e-mail: fernando@gont.com.ar || fgont@si6networks= .com
>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D= 076 FFF1
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/list= info/v6ops
>>>
--0000000000005c70cc05b4f5bcdb-- From nobody Wed Nov 25 14:33:59 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB43A1F16; Wed, 25 Nov 2020 14:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRoGAESFMVrn; Wed, 25 Nov 2020 14:33:48 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4723A0CDD; Wed, 25 Nov 2020 14:33:48 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id y7so3673493pfq.11; Wed, 25 Nov 2020 14:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QMExF4ke5oEJQZHMD9QX5vBOxSZXJ0QGEhOgBuvsF68=; b=XXKOl+9VHpwdkDmWkAZ68KAN77ncRDkqSg8VHhDPtuP1Ymb/1PTHHrlRNH+gDnnYg/ UxeECbWjBxW8Dq9wUy8xSA41WgPfD58CyAdZJRzVA/3drhKCc/U/2bFHu/PtGTJairx5 YUZX8ajIX6wa5NJlNe1KzcJLVQypQKvPXPZGXvxiKSBf8BDcDPnOhMSnnvlsbv1fEeXN hwFo4be6/ct0yCL29SIaPqhCiKUDSVvxmGJ6ULauDga+33EBd/Ea0KLZ5L+jqN72w6xR /hBSqnBmjPdyrJo/dfPDoh7cDz60SBbqyhvfyjQ3Eq2yw2b+takcExXGSHBegvv1G+fE laig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QMExF4ke5oEJQZHMD9QX5vBOxSZXJ0QGEhOgBuvsF68=; b=miNbsJ0ipSXXxXzCToY+3ssk33A9/0/+l9gOamEM/v6nmqIOyd1LChVfK8N9s0FEqn gstrO/1zPj/GA3h9yWX2aHu/jxfQeH9lcdqEaMMrYN1crZ7UWIfCNm/cMCjyc+PqbBr9 T33e7/QE0vgeoLRBjjz/XdyfcjJZ9/umKvjKEqgQngcgzyUoPjY/R/FI4XF04kcKNIp8 XZUYx1Wkfr8eUNxl68PzW2fF7iiP7QukPvBuvSLtROuFxsDhDKqNkON8943+7ZBxhGrW Znrbn2W0V1ZQNx9YjB6lYEhN0V+YcrQtizxi9aIO2AQyC/BgllRK/B8w4h6CS4MKkgz9 8HMQ== X-Gm-Message-State: AOAM532TiTJg6ozxIk4VTl8YyLg30uLhWgD2KvUFIqKLBZGbRzEfz9mM /wPCfao6hUj1XHrSsIGbPsigj+f2O815IA== X-Google-Smtp-Source: ABdhPJwmnNgppsFseDMBGGxRCGj6ModoBe7YEFHh4HtVI/7MZfghzOBteOU0yHNHAbO2HQxCXVj80w== X-Received: by 2002:a17:90b:941:: with SMTP id dw1mr6736698pjb.147.1606343627166; Wed, 25 Nov 2020 14:33:47 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id s18sm2893351pfc.5.2020.11.25.14.33.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 14:33:46 -0800 (PST) To: Tom Herbert , "Joel M. Halpern" Cc: IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Thu, 26 Nov 2020 11:33:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 22:33:53 -0000 I'm not Joel, but I did once spend some time grepping RFCs to find out wh= ether "flow" or "microflow" was the preferred term. In RFC2474, which is normat= ive, we have: Microflow: a single instance of an application-to-application flow of packets which is identified by source address, destination address, protocol id, and source port, destination port (where applicable). But in the flow label work we explicitly avoided being that precise, and did not use the term "microflow". There might be some load balancing scenarios where you want a broader definition, even including bidirection= al flows. There are expired drafts on that topic: draft-tarreau-extend-flow-label-balancing draft-wang-6man-flow-label-reflection Regards Brian On 26-Nov-20 11:13, Tom Herbert wrote: > Joel, is there a normative definition of a flow? >=20 > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern > wrote: >=20 > No, as Brian says, there are escape clauses in the flow definitions= =2E >=20 > But changing the flow label due to traffic problems does not corres= pond > to packets being in actually different flows. > If one were using UDP, and mixing loss sensitive packets with loss > insensitive packets for a special application, sure, one could use = two > flow labels.=C2=A0 But that is not what you are describing. >=20 > Yours, > Joel >=20 > On 11/25/2020 3:05 PM, Tom Herbert wrote: > > Joel, > > > > Is there an RFC that clearly and unambiguously states that a host= MUST > > use the same flow label for the lifetime _and_ clearly defines ex= actly > > what a flow is with respect to such a requirement (for instance, = how > > would you define a flow and enforce such a requirement in UDP? IP= sec? > > other encapsulations?). If there is such a requirement then we'll= > > change the code to be conformant. > > > > Tom > > > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern > wrote: > >> > >> This kind of thing is why, as I understand it, MPTCP has discove= ry > >> mechanisms ot know if both sides use it, and can select alternat= ive > >> addresses for communication. > >> > >> Trying to guess flow labels that might avoid a problem because i= t might > >> be an ECMP problem, is just flailing about.=C2=A0 Not a good des= ign for > >> operational protocols. > >> > >> And in general, designing protocols around "I know exactly what = is going > >> on"=C2=A0 (the requirement for what you describe that goes well = beyond just > >> "limited domains") is also a recipe for failure. > >> > >> The Flow Label RFCs are actually very explicit that a flow label= is > >> supposed to be stable for the life of the flow.=C2=A0 Otherwise,= it isn't a > >> flow label. > >> > >> Yours, > >> Joel > >> > >> On 11/25/2020 2:35 PM, Tom Herbert wrote: > >>> Hi Fernando, comments in line... > >>> > >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont > wrote: > >>>> > >>>> Hi, Tom, > >>>> > >>>> On 24/11/20 16:43, Tom Herbert wrote: > >>>> [....] > >>>>> Modulating the flow label is a means to affect the routing of= packets > >>>>> through the network that uses flow labels as input to the ECM= P hash. > >>>> > >>>> What's the point? > >>>> > >>>> 1) You cannot tell *if* the FL is being used. > >>>> > >>> Generally true, but in a limited domain this information could = be > >>> discerned. I'd note that it's also generally true that we don't= know > >>> if there is a load balancer or stateful firewall in the path th= at > >>> requires consistent routing, but in a limited domain we could k= now > >>> that also. > >>> > >>>> 2) Changing the FL does not necessarily mean that packets will= employ a > >>>> different link. > >>> > >>> It's an opportunistic mechanism. If a connection is failing and= we get > >>> a better path that fixes it by simply changing the flow label t= hen > >>> what's the harm? > >>> > >>>> > >>>> 3) If the network is failing, shouldn't you handle this via ro= uting? > >>>> > >>> Sure, but then that requires an out of band feedback loop from = a TCP > >>> implementation to the network infrastructure to indicate there = is a > >>> problem and then the network needs to respond. That's significa= nt > >>> infrastructure and higher reaction time than doing something in= TCP > >>> and IP. Think of modulating the flow label is an inexpensive fo= rm of > >>> source routing within a limited domain that doesn't need any > >>> infrastructure or heavyweight protocols or something like segme= nt > >>> routing. > >>> > >>>> > >>>> > >>>>> The basic idea is that the flow label associated with a conne= ction is > >>>>> randomly changed when the stack observes that the connection = is > >>>>> failing (e.g. and an RTO). There is nothing in the specs that= prevents > >>>>> this since the source is at liberty to set the flow label as = it sees > >>>>> fit. > >>>> > >>>> The FL is expected to remain constant for the life of a flow. = A > >>>> retransmitted packet is part of the same flow as the > >>>> originally-transmitted packet. So this seems to be contradicti= ng the > >>>> very specification of the FL. > >>>> > >>>> For instance, If a RTO for a flow causes the FL to change, the= n one may > >>>> possibly argue that the FL is not naming/labeling what is said= /expected > >>>> to be anming/labeling. > >>> > >>> Specifically, RFC6437 states: > >>> > >>> "It is therefore RECOMMENDED that source hosts support the flow= label > >>> by setting the flow label field for all packets of a given flow= to the > >>> same value chosen from an approximation to a discrete uniform > >>> distribution." > >>> > >>> So that is clearly a just recommendation, and not a requirement= (and > >>> definitely not a MUST). Furthermore, RFC6437 states: > >>> > >>> "A forwarding node MUST either leave a non-zero flow label valu= e > >>> unchanged or change it only for compelling operational security= > >>> reasons as described in Section 6.1." > >>> > >>> So there's no guarantee in the protocol specs that flow labels = are > >>> consistent for the life of the connection, which means that the= > >>> network cannot assume that and thus it would be incorrect if th= e > >>> network tried to enforce flow label consistency as a protocol > >>> requirement. As I said, it is prudent to try to be consistent w= ith > >>> flow labels and the default behavior in Linux should be changed= , > >>> however I do not believe there's a valid claim of non-conforman= ce that > >>> motivates removal of the feature that is already deployed. > >>> > >>> Tom > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>>> The feature is useful in large datacenter networks, like > >>>>> pparently Facebook where the patches originate, since informa= tion > >>>>> discerned by TCP can opportunistically be applied to route se= lection. > >>>>> The practical issue is that there are stateful devices like f= irewalls > >>>>> that require consistent routing in the network in which case = changing > >>>>> the flow label can confuse them. As I mentioned, the original= intent > >>>>> was that the flow label randomization feature should be opt-i= n instead > >>>>> of on by default. > >>>> > >>>> So... where is the "source" of the packet that would be "modul= ating" the FL? > >>>> > >>>> Thanks, > >>>> -- > >>>> 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 > >>> >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Nov 25 16:16:06 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8D63A064E for ; Wed, 25 Nov 2020 16:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKaVFqujjSm5 for ; Wed, 25 Nov 2020 16:16:02 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8973A067A for ; Wed, 25 Nov 2020 16:16:02 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id q3so303519edr.12 for ; Wed, 25 Nov 2020 16:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o6M9JzL0xm0OD2nnsrd2Ip3bYZXIG6TMOIrJr7YwqcY=; b=ORz+VeyKgpzNz+a7eEu+bo+4ZXt3BbGwivunw4/42rXkxolzdD84YOHFMDBdJsn0zh LZy5Q0UGPESGvDTqO0DH754N7xd6l64XJB26ttgfnzmNHEbSD13+NK1aKvhuui4Jc6l1 U7KGPJ4XDEhH0Pu/D3iDq3ZL3A0j6zmSuXM17j/nSPRvXefGOecQdAB0X/wLm5m8bnsv ne4NDRxWBf6B8PnZV0O5tEGS871YMspRa2tatUh8FH2FWNuHQgp0cARTzwKBCn9uN64V S1V3mBNnRIUmz8dD/+Odbv/X/vSreRokwXDoy7r9P351YSf+riHo8lcAq3YFIRvvDNrU ykWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o6M9JzL0xm0OD2nnsrd2Ip3bYZXIG6TMOIrJr7YwqcY=; b=Y49W7rBBbyc8RbtGdgpZywU7GrO59Nr9kgp3pXpkR14h65ssbuldfGB/Zn3KYJcrE3 +GBEKUJ1D3qWeQHKRJA2t8DltYUEAIoaS1U60GlqsmHzQP7XSe8n7UjNyu7oOmToAyzN qbNBR0ZKPF5upDe6S79R9lHzXUBZY9qpa28Bwe3QZvxUoT7VMaP4rGyu2EeehezfDxg0 YS10AqtSyTdJF3n/pPCGjhuV6xDyxLCJu/QEhU4IjYQ/RYfD03plvRQVEP1s8Hd0gpuz zC5/i4MzZr5ozSWPiTa6z73KvFqBoqVrYW7zQyFTJhlQoqvbQ4E7o8cn+HC7nsld/qyI ye5g== X-Gm-Message-State: AOAM533aD7lLIUdfpOGe03EVVHyLwtf34PSPv2oGGA6ZMPvZb51qqRev O32pnU0SCf+MFDgWZhtMfIwT7Oum7zFfEPxIOhaHeA== X-Google-Smtp-Source: ABdhPJxZ0t1PhJb3eiLV8a/TuJs+dxV77o+hZkO1ZtQ0Kx0x71j8K1LV6/sgOkrrw4ZSaZog9rtzHEQWLkRCWZmgmd4= X-Received: by 2002:aa7:c313:: with SMTP id l19mr151566edq.293.1606349760354; Wed, 25 Nov 2020 16:16:00 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> In-Reply-To: From: Tom Herbert Date: Wed, 25 Nov 2020 17:15:49 -0700 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 00:16:04 -0000 On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter wrote: > > I'm not Joel, but I did once spend some time grepping RFCs to find out whether > "flow" or "microflow" was the preferred term. In RFC2474, which is normative, > we have: > > Microflow: a single instance of an application-to-application flow of > packets which is identified by source address, destination address, > protocol id, and source port, destination port (where applicable). > > But in the flow label work we explicitly avoided being that precise, and > did not use the term "microflow". There might be some load balancing > scenarios where you want a broader definition, even including bidirectional > flows. There are expired drafts on that topic: > draft-tarreau-extend-flow-label-balancing > draft-wang-6man-flow-label-reflection > Brian, Random Packet Spraying (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.297.529&rep=rep1&type=pdf) is an interesting idea where packets for a single connection are purposely distributed across multiple paths for load distribution. Per packet randomized flow labels with flow label aware ECMP makes this quite easy to do without requiring any special support in switches like you'd need with IPv4. I'm not necessarily advocating this, but it does highlight one potential use case of having a flow label that doesn;t have rigidly defined requirements on the host. Tom > Regards > Brian > > On 26-Nov-20 11:13, Tom Herbert wrote: > > Joel, is there a normative definition of a flow? > > > > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern > wrote: > > > > No, as Brian says, there are escape clauses in the flow definitions. > > > > But changing the flow label due to traffic problems does not correspond > > to packets being in actually different flows. > > If one were using UDP, and mixing loss sensitive packets with loss > > insensitive packets for a special application, sure, one could use two > > flow labels. But that is not what you are describing. > > > > Yours, > > Joel > > > > On 11/25/2020 3:05 PM, Tom Herbert wrote: > > > Joel, > > > > > > Is there an RFC that clearly and unambiguously states that a host MUST > > > use the same flow label for the lifetime _and_ clearly defines exactly > > > what a flow is with respect to such a requirement (for instance, how > > > would you define a flow and enforce such a requirement in UDP? IPsec? > > > other encapsulations?). If there is such a requirement then we'll > > > change the code to be conformant. > > > > > > Tom > > > > > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern > wrote: > > >> > > >> This kind of thing is why, as I understand it, MPTCP has discovery > > >> mechanisms ot know if both sides use it, and can select alternative > > >> addresses for communication. > > >> > > >> Trying to guess flow labels that might avoid a problem because it might > > >> be an ECMP problem, is just flailing about. Not a good design for > > >> operational protocols. > > >> > > >> And in general, designing protocols around "I know exactly what is going > > >> on" (the requirement for what you describe that goes well beyond just > > >> "limited domains") is also a recipe for failure. > > >> > > >> The Flow Label RFCs are actually very explicit that a flow label is > > >> supposed to be stable for the life of the flow. Otherwise, it isn't a > > >> flow label. > > >> > > >> Yours, > > >> Joel > > >> > > >> On 11/25/2020 2:35 PM, Tom Herbert wrote: > > >>> Hi Fernando, comments in line... > > >>> > > >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont > wrote: > > >>>> > > >>>> Hi, Tom, > > >>>> > > >>>> On 24/11/20 16:43, Tom Herbert wrote: > > >>>> [....] > > >>>>> Modulating the flow label is a means to affect the routing of packets > > >>>>> through the network that uses flow labels as input to the ECMP hash. > > >>>> > > >>>> What's the point? > > >>>> > > >>>> 1) You cannot tell *if* the FL is being used. > > >>>> > > >>> Generally true, but in a limited domain this information could be > > >>> discerned. I'd note that it's also generally true that we don't know > > >>> if there is a load balancer or stateful firewall in the path that > > >>> requires consistent routing, but in a limited domain we could know > > >>> that also. > > >>> > > >>>> 2) Changing the FL does not necessarily mean that packets will employ a > > >>>> different link. > > >>> > > >>> It's an opportunistic mechanism. If a connection is failing and we get > > >>> a better path that fixes it by simply changing the flow label then > > >>> what's the harm? > > >>> > > >>>> > > >>>> 3) If the network is failing, shouldn't you handle this via routing? > > >>>> > > >>> Sure, but then that requires an out of band feedback loop from a TCP > > >>> implementation to the network infrastructure to indicate there is a > > >>> problem and then the network needs to respond. That's significant > > >>> infrastructure and higher reaction time than doing something in TCP > > >>> and IP. Think of modulating the flow label is an inexpensive form of > > >>> source routing within a limited domain that doesn't need any > > >>> infrastructure or heavyweight protocols or something like segment > > >>> routing. > > >>> > > >>>> > > >>>> > > >>>>> The basic idea is that the flow label associated with a connection is > > >>>>> randomly changed when the stack observes that the connection is > > >>>>> failing (e.g. and an RTO). There is nothing in the specs that prevents > > >>>>> this since the source is at liberty to set the flow label as it sees > > >>>>> fit. > > >>>> > > >>>> The FL is expected to remain constant for the life of a flow. A > > >>>> retransmitted packet is part of the same flow as the > > >>>> originally-transmitted packet. So this seems to be contradicting the > > >>>> very specification of the FL. > > >>>> > > >>>> For instance, If a RTO for a flow causes the FL to change, then one may > > >>>> possibly argue that the FL is not naming/labeling what is said/expected > > >>>> to be anming/labeling. > > >>> > > >>> Specifically, RFC6437 states: > > >>> > > >>> "It is therefore RECOMMENDED that source hosts support the flow label > > >>> by setting the flow label field for all packets of a given flow to the > > >>> same value chosen from an approximation to a discrete uniform > > >>> distribution." > > >>> > > >>> So that is clearly a just recommendation, and not a requirement (and > > >>> definitely not a MUST). Furthermore, RFC6437 states: > > >>> > > >>> "A forwarding node MUST either leave a non-zero flow label value > > >>> unchanged or change it only for compelling operational security > > >>> reasons as described in Section 6.1." > > >>> > > >>> So there's no guarantee in the protocol specs that flow labels are > > >>> consistent for the life of the connection, which means that the > > >>> network cannot assume that and thus it would be incorrect if the > > >>> network tried to enforce flow label consistency as a protocol > > >>> requirement. As I said, it is prudent to try to be consistent with > > >>> flow labels and the default behavior in Linux should be changed, > > >>> however I do not believe there's a valid claim of non-conformance that > > >>> motivates removal of the feature that is already deployed. > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> > > >>>> > > >>>> > > >>>> > > >>>>> The feature is useful in large datacenter networks, like > > >>>>> pparently Facebook where the patches originate, since information > > >>>>> discerned by TCP can opportunistically be applied to route selection. > > >>>>> The practical issue is that there are stateful devices like firewalls > > >>>>> that require consistent routing in the network in which case changing > > >>>>> the flow label can confuse them. As I mentioned, the original intent > > >>>>> was that the flow label randomization feature should be opt-in instead > > >>>>> of on by default. > > >>>> > > >>>> So... where is the "source" of the packet that would be "modulating" the FL? > > >>>> > > >>>> Thanks, > > >>>> -- > > >>>> 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 > > >>> > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Thu Nov 26 01:34:24 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CAF3A0B6E; Thu, 26 Nov 2020 01:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iXUn606boMO; Thu, 26 Nov 2020 01:34:16 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACB83A0B74; Thu, 26 Nov 2020 01:34:16 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id k3so1322159otp.12; Thu, 26 Nov 2020 01:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6i2UIRIcCmDOKlC10XLkrbtGGakS9jR6ru7+roBSLN4=; b=hK13hU8dJhykLpH5ROHQXEEpRkDgF63YawuhUBPgwRHCys1x9skeXGlbx7o/ur7vyv lZY5YJJNWfQ7PfHIMYSDSEKhlmWka8SLXAZj8hhzt6F06cnc7uOwqeOk1G9QZgoZ5MRB cOwNng3XoVeKX+Hould2J+86t8lwAN+94JbfV85GMz+ApfOruRxEBMbkS7KOzbOh7fCz t1W7cQiqLSEVKchUF9vR8T7ABD9PmCwfMBY5jStEBIFFnDxCkrj5RtC3/vlYa/HHAvE1 XN3b30+PGjcxrGN1TYS2SgT0lMGtxReUVWsp8UpdDWY79DdLwRiHxZucIEL3SvgFaOWV Ba6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6i2UIRIcCmDOKlC10XLkrbtGGakS9jR6ru7+roBSLN4=; b=TL/UiqjYtof0xjU93NFQSqcZW7/RAvh3MgHn/ddAMa6ScpCDriJurbKVrOjRPeNQid qouiwzzLz8cd150wOehvrdNBg82Mgn8IuKiuHfs5rEGRRPNyEAyZyjl2Zbs9ROrKrr5T qQeLMkS3sSC7uZAlsihBisUtTHRFJJ75Isksu28qcQUL8pNi2BFlX4iuRFCOAw5yIBv0 +2PiwyXowB81eZQWRloImUhxod+G0iaUpiQixK8cQslLIRNiMr06L4UOY/irIEFy55e5 UD5Rt+sBciuipxKdaEw7JV8KJSJd2C3QHCiyAwR//FU53i1Y9Dy9Czai6NlwTs/tdhzP oWsw== X-Gm-Message-State: AOAM533wZYaB5j9fyko/JZ7RfO6lVdR+UibVR+f4cYgpwbYxr60JCXTF yoXlW40BDkwcn9Qi8qZ2oBnt2QDOZKEwr1eCrLyYSanRlMs= X-Google-Smtp-Source: ABdhPJy27wvl/Nc0VfP/i7FiZJzgBFRmkpFp22fUaewtPjtM73MoAi6fEbfN1c38zLmyiihRwohwYVFpNjQb4JnP4T8= X-Received: by 2002:a9d:4c92:: with SMTP id m18mr1814874otf.248.1606383255507; Thu, 26 Nov 2020 01:34:15 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> In-Reply-To: From: Alexander Azimov Date: Thu, 26 Nov 2020 12:34:04 +0300 Message-ID: To: Tom Herbert Cc: Brian E Carpenter , tcpm , IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000005157af05b4ff3f8f" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 09:34:19 -0000 --0000000000005157af05b4ff3f8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear colleagues, We started discussing an incorrect default behavior, and Tom has already confirmed that it will be fixed. Later the thread turned into an argument if the flow label can be changed during connection/flow lifetime according to current RFC documents, though these documents can be updated. This looks a bit weird for me because I always thought that it is the IETF community's responsibility to document proper solutions. If something undocumented but worthy happens in the industry - IETF should catch up. So, I would like to get back to the discussion of reasons and their safety. The general idea of changing the routing path upon network outage/degradation looks obvious. Getting kind of source-based routing can significantly reduce the reaction time and improve end-user experience. The flow label has a perfect match here: transparent for the application, set by the source, not part of 5-tuple, while it can be used in the load balancing. IMO poorly documented. I would like to learn your feedback for the next wording: Let say that the flow label is a hash of values from the IP packet's 5-tuple and random number. Then 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be recalculated. 2. In the case of RTO timeout expiration in the established TCP session the flow label MAY be recalculated. This setting MUST be switched off by default. 3. Otherwise flow label SHOULD be preserved unchanged. The first point stands for redirecting connection from the degraded path before the connection is established, and it looks safe. The second one can also improve performance if it is set on the server-side. Please comment if you see security flaws in such a design. =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 03:16, Tom H= erbert : > On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter > wrote: > > > > I'm not Joel, but I did once spend some time grepping RFCs to find out > whether > > "flow" or "microflow" was the preferred term. In RFC2474, which is > normative, > > we have: > > > > Microflow: a single instance of an application-to-application flow o= f > > packets which is identified by source address, destination address, > > protocol id, and source port, destination port (where applicable). > > > > But in the flow label work we explicitly avoided being that precise, an= d > > did not use the term "microflow". There might be some load balancing > > scenarios where you want a broader definition, even including > bidirectional > > flows. There are expired drafts on that topic: > > draft-tarreau-extend-flow-label-balancing > > draft-wang-6man-flow-label-reflection > > > Brian, > > Random Packet Spraying > ( > https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.529&rep= =3Drep1&type=3Dpdf > ) > is an interesting idea where packets for a single connection are > purposely distributed across multiple paths for load distribution. Per > packet randomized flow labels with flow label aware ECMP makes this > quite easy to do without requiring any special support in switches > like you'd need with IPv4. I'm not necessarily advocating this, but it > does highlight one potential use case of having a flow label that > doesn;t have rigidly defined requirements on the host. > > Tom > > > Regards > > Brian > > > > On 26-Nov-20 11:13, Tom Herbert wrote: > > > Joel, is there a normative definition of a flow? > > > > > > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern > wrote: > > > > > > No, as Brian says, there are escape clauses in the flow > definitions. > > > > > > But changing the flow label due to traffic problems does not > correspond > > > to packets being in actually different flows. > > > If one were using UDP, and mixing loss sensitive packets with los= s > > > insensitive packets for a special application, sure, one could us= e > two > > > flow labels. But that is not what you are describing. > > > > > > Yours, > > > Joel > > > > > > On 11/25/2020 3:05 PM, Tom Herbert wrote: > > > > Joel, > > > > > > > > Is there an RFC that clearly and unambiguously states that a > host MUST > > > > use the same flow label for the lifetime _and_ clearly defines > exactly > > > > what a flow is with respect to such a requirement (for instance= , > how > > > > would you define a flow and enforce such a requirement in UDP? > IPsec? > > > > other encapsulations?). If there is such a requirement then we'= ll > > > > change the code to be conformant. > > > > > > > > Tom > > > > > > > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern < > jmh@joelhalpern.com > wrote: > > > >> > > > >> This kind of thing is why, as I understand it, MPTCP has > discovery > > > >> mechanisms ot know if both sides use it, and can select > alternative > > > >> addresses for communication. > > > >> > > > >> Trying to guess flow labels that might avoid a problem because > it might > > > >> be an ECMP problem, is just flailing about. Not a good design > for > > > >> operational protocols. > > > >> > > > >> And in general, designing protocols around "I know exactly wha= t > is going > > > >> on" (the requirement for what you describe that goes well > beyond just > > > >> "limited domains") is also a recipe for failure. > > > >> > > > >> The Flow Label RFCs are actually very explicit that a flow > label is > > > >> supposed to be stable for the life of the flow. Otherwise, it > isn't a > > > >> flow label. > > > >> > > > >> Yours, > > > >> Joel > > > >> > > > >> On 11/25/2020 2:35 PM, Tom Herbert wrote: > > > >>> Hi Fernando, comments in line... > > > >>> > > > >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont < > fernando@gont.com.ar > wrote: > > > >>>> > > > >>>> Hi, Tom, > > > >>>> > > > >>>> On 24/11/20 16:43, Tom Herbert wrote: > > > >>>> [....] > > > >>>>> Modulating the flow label is a means to affect the routing > of packets > > > >>>>> through the network that uses flow labels as input to the > ECMP hash. > > > >>>> > > > >>>> What's the point? > > > >>>> > > > >>>> 1) You cannot tell *if* the FL is being used. > > > >>>> > > > >>> Generally true, but in a limited domain this information coul= d > be > > > >>> discerned. I'd note that it's also generally true that we > don't know > > > >>> if there is a load balancer or stateful firewall in the path > that > > > >>> requires consistent routing, but in a limited domain we could > know > > > >>> that also. > > > >>> > > > >>>> 2) Changing the FL does not necessarily mean that packets > will employ a > > > >>>> different link. > > > >>> > > > >>> It's an opportunistic mechanism. If a connection is failing > and we get > > > >>> a better path that fixes it by simply changing the flow label > then > > > >>> what's the harm? > > > >>> > > > >>>> > > > >>>> 3) If the network is failing, shouldn't you handle this via > routing? > > > >>>> > > > >>> Sure, but then that requires an out of band feedback loop fro= m > a TCP > > > >>> implementation to the network infrastructure to indicate ther= e > is a > > > >>> problem and then the network needs to respond. That's > significant > > > >>> infrastructure and higher reaction time than doing something > in TCP > > > >>> and IP. Think of modulating the flow label is an inexpensive > form of > > > >>> source routing within a limited domain that doesn't need any > > > >>> infrastructure or heavyweight protocols or something like > segment > > > >>> routing. > > > >>> > > > >>>> > > > >>>> > > > >>>>> The basic idea is that the flow label associated with a > connection is > > > >>>>> randomly changed when the stack observes that the connectio= n > is > > > >>>>> failing (e.g. and an RTO). There is nothing in the specs > that prevents > > > >>>>> this since the source is at liberty to set the flow label a= s > it sees > > > >>>>> fit. > > > >>>> > > > >>>> The FL is expected to remain constant for the life of a flow= . > A > > > >>>> retransmitted packet is part of the same flow as the > > > >>>> originally-transmitted packet. So this seems to be > contradicting the > > > >>>> very specification of the FL. > > > >>>> > > > >>>> For instance, If a RTO for a flow causes the FL to change, > then one may > > > >>>> possibly argue that the FL is not naming/labeling what is > said/expected > > > >>>> to be anming/labeling. > > > >>> > > > >>> Specifically, RFC6437 states: > > > >>> > > > >>> "It is therefore RECOMMENDED that source hosts support the > flow label > > > >>> by setting the flow label field for all packets of a given > flow to the > > > >>> same value chosen from an approximation to a discrete uniform > > > >>> distribution." > > > >>> > > > >>> So that is clearly a just recommendation, and not a > requirement (and > > > >>> definitely not a MUST). Furthermore, RFC6437 states: > > > >>> > > > >>> "A forwarding node MUST either leave a non-zero flow label > value > > > >>> unchanged or change it only for compelling operational securi= ty > > > >>> reasons as described in Section 6.1." > > > >>> > > > >>> So there's no guarantee in the protocol specs that flow label= s > are > > > >>> consistent for the life of the connection, which means that t= he > > > >>> network cannot assume that and thus it would be incorrect if > the > > > >>> network tried to enforce flow label consistency as a protocol > > > >>> requirement. As I said, it is prudent to try to be consistent > with > > > >>> flow labels and the default behavior in Linux should be > changed, > > > >>> however I do not believe there's a valid claim of > non-conformance that > > > >>> motivates removal of the feature that is already deployed. > > > >>> > > > >>> Tom > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>> The feature is useful in large datacenter networks, like > > > >>>>> pparently Facebook where the patches originate, since > information > > > >>>>> discerned by TCP can opportunistically be applied to route > selection. > > > >>>>> The practical issue is that there are stateful devices like > firewalls > > > >>>>> that require consistent routing in the network in which cas= e > changing > > > >>>>> the flow label can confuse them. As I mentioned, the > original intent > > > >>>>> was that the flow label randomization feature should be > opt-in instead > > > >>>>> of on by default. > > > >>>> > > > >>>> So... where is the "source" of the packet that would be > "modulating" the FL? > > > >>>> > > > >>>> Thanks, > > > >>>> -- > > > >>>> Fernando Gont > > > >>>> e-mail: fernando@gont.com.ar > || fgont@si6networks.com > > > >>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D07= 6 > FFF1 > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> v6ops mailing list > > > >>> v6ops@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/v6ops > > > >>> > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Best regards, Alexander Azimov --0000000000005157af05b4ff3f8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear colleagues,

We started discussing an incorrect= default behavior, and Tom has already confirmed that it will be fixed.
=
Later the thread turned into an argument if the flow label can be chang= ed during connection/flow lifetime according to current RFC documents, thou= gh these documents can be updated. This looks a bit weird for me because I = always thought that it is the IETF community's responsibility to docume= nt proper solutions. If something undocumented but worthy happens in the in= dustry - IETF should catch up. So, I would like to get back to the discussi= on of reasons and their safety.

The general idea of changing the ro= uting path upon network outage/degradation looks obvious. Getting kind of s= ource-based routing can significantly reduce the reaction=20 time and improve end-user experience. The flow label has a perfect match h= ere: transparent for the application, set by the source, not part of 5-tupl= e, while it can be used in the load balancing. IMO poorly documented. I wou= ld like to learn your feedback for the next wording:

Let say that th= e flow label is a hash of values from the IP packet's 5-tuple and rando= m number. Then

1. In the case of SYN or SYN-ACK retransmission flow = label SHOULD be recalculated.
2. In the case of RTO timeout expiration i= n the established TCP session the flow label MAY be=20 recalculated. This setting MUST be switched off by default.
3. Otherwise= flow label SHOULD be preserved unchanged.

The first point stands fo= r redirecting connection from the degraded path before the connection is es= tablished, and it looks safe. The second one can also improve performance i= f it is set on the server-side. Please comment if you see security flaws in= such a design.

=D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. = =D0=B2 03:16, Tom Herbert <tom@he= rbertland.com>:
On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter
<brian.= e.carpenter@gmail.com> wrote:
>
> I'm not Joel, but I did once spend some time grepping RFCs to find= out whether
> "flow" or "microflow" was the preferred term. In R= FC2474, which is normative,
> we have:
>
>=C2=A0 =C2=A0 Microflow: a single instance of an application-to-applica= tion flow of
>=C2=A0 =C2=A0 packets which is identified by source address, destinatio= n address,
>=C2=A0 =C2=A0 protocol id, and source port, destination port (where app= licable).
>
> But in the flow label work we explicitly avoided being that precise, a= nd
> did not use the term "microflow". There might be some load b= alancing
> scenarios where you want a broader definition, even including bidirect= ional
> flows. There are expired drafts on that topic:
> draft-tarreau-extend-flow-label-balancing
> draft-wang-6man-flow-label-reflection
>
Brian,

Random Packet Spraying
(ht= tps://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.529&rep= =3Drep1&type=3Dpdf)
is an interesting idea where packets for a single connection are
purposely distributed across multiple paths for load distribution. Per
packet randomized flow labels with flow label aware ECMP makes this
quite easy to do without requiring any special support in switches
like you'd need with IPv4. I'm not necessarily advocating this, but= it
does highlight one potential use case of having a flow label that
doesn;t have rigidly defined requirements on the host.

Tom

> Regards
>=C2=A0 =C2=A0 Brian
>
> On 26-Nov-20 11:13, Tom Herbert wrote:
> > Joel, is there a normative definition of a flow?
> >
> > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern <jmh@joelhalpern.com <mailt= o:jmh@joelhalpern.= com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0No, as Brian says, there are escape clauses in= the flow definitions.
> >
> >=C2=A0 =C2=A0 =C2=A0But changing the flow label due to traffic pro= blems does not correspond
> >=C2=A0 =C2=A0 =C2=A0to packets being in actually different flows.<= br> > >=C2=A0 =C2=A0 =C2=A0If one were using UDP, and mixing loss sensiti= ve packets with loss
> >=C2=A0 =C2=A0 =C2=A0insensitive packets for a special application,= sure, one could use two
> >=C2=A0 =C2=A0 =C2=A0flow labels.=C2=A0 But that is not what you ar= e describing.
> >
> >=C2=A0 =C2=A0 =C2=A0Yours,
> >=C2=A0 =C2=A0 =C2=A0Joel
> >
> >=C2=A0 =C2=A0 =C2=A0On 11/25/2020 3:05 PM, Tom Herbert wrote:
> >=C2=A0 =C2=A0 =C2=A0> Joel,
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Is there an RFC that clearly and unambigu= ously states that a host MUST
> >=C2=A0 =C2=A0 =C2=A0> use the same flow label for the lifetime = _and_ clearly defines exactly
> >=C2=A0 =C2=A0 =C2=A0> what a flow is with respect to such a req= uirement (for instance, how
> >=C2=A0 =C2=A0 =C2=A0> would you define a flow and enforce such = a requirement in UDP? IPsec?
> >=C2=A0 =C2=A0 =C2=A0> other encapsulations?). If there is such = a requirement then we'll
> >=C2=A0 =C2=A0 =C2=A0> change the code to be conformant.
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Tom
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> On Wed, Nov 25, 2020 at 12:39 PM Joel M. = Halpern <jmh@jo= elhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> This kind of thing is why, as I under= stand it, MPTCP has discovery
> >=C2=A0 =C2=A0 =C2=A0>> mechanisms ot know if both sides use = it, and can select alternative
> >=C2=A0 =C2=A0 =C2=A0>> addresses for communication.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> Trying to guess flow labels that migh= t avoid a problem because it might
> >=C2=A0 =C2=A0 =C2=A0>> be an ECMP problem, is just flailing = about.=C2=A0 Not a good design for
> >=C2=A0 =C2=A0 =C2=A0>> operational protocols.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> And in general, designing protocols a= round "I know exactly what is going
> >=C2=A0 =C2=A0 =C2=A0>> on"=C2=A0 (the requirement for w= hat you describe that goes well beyond just
> >=C2=A0 =C2=A0 =C2=A0>> "limited domains") is also = a recipe for failure.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> The Flow Label RFCs are actually very= explicit that a flow label is
> >=C2=A0 =C2=A0 =C2=A0>> supposed to be stable for the life of= the flow.=C2=A0 Otherwise, it isn't a
> >=C2=A0 =C2=A0 =C2=A0>> flow label.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> Yours,
> >=C2=A0 =C2=A0 =C2=A0>> Joel
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> On 11/25/2020 2:35 PM, Tom Herbert wr= ote:
> >=C2=A0 =C2=A0 =C2=A0>>> Hi Fernando, comments in line...<= br> > >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> On Wed, Nov 25, 2020 at 12:13 AM = Fernando Gont <fernando@gont.com.ar <mailto:fernando@gont.com.ar>> wrote:
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> Hi, Tom,
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> On 24/11/20 16:43, Tom Herber= t wrote:
> >=C2=A0 =C2=A0 =C2=A0>>>> [....]
> >=C2=A0 =C2=A0 =C2=A0>>>>> Modulating the flow label= is a means to affect the routing of packets
> >=C2=A0 =C2=A0 =C2=A0>>>>> through the network that = uses flow labels as input to the ECMP hash.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> What's the point?
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> 1) You cannot tell *if* the F= L is being used.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Generally true, but in a limited = domain this information could be
> >=C2=A0 =C2=A0 =C2=A0>>> discerned. I'd note that it&#= 39;s also generally true that we don't know
> >=C2=A0 =C2=A0 =C2=A0>>> if there is a load balancer or st= ateful firewall in the path that
> >=C2=A0 =C2=A0 =C2=A0>>> requires consistent routing, but = in a limited domain we could know
> >=C2=A0 =C2=A0 =C2=A0>>> that also.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> 2) Changing the FL does not n= ecessarily mean that packets will employ a
> >=C2=A0 =C2=A0 =C2=A0>>>> different link.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> It's an opportunistic mechani= sm. If a connection is failing and we get
> >=C2=A0 =C2=A0 =C2=A0>>> a better path that fixes it by si= mply changing the flow label then
> >=C2=A0 =C2=A0 =C2=A0>>> what's the harm?
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> 3) If the network is failing,= shouldn't you handle this via routing?
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Sure, but then that requires an o= ut of band feedback loop from a TCP
> >=C2=A0 =C2=A0 =C2=A0>>> implementation to the network inf= rastructure to indicate there is a
> >=C2=A0 =C2=A0 =C2=A0>>> problem and then the network need= s to respond. That's significant
> >=C2=A0 =C2=A0 =C2=A0>>> infrastructure and higher reactio= n time than doing something in TCP
> >=C2=A0 =C2=A0 =C2=A0>>> and IP. Think of modulating the f= low label is an inexpensive form of
> >=C2=A0 =C2=A0 =C2=A0>>> source routing within a limited d= omain that doesn't need any
> >=C2=A0 =C2=A0 =C2=A0>>> infrastructure or heavyweight pro= tocols or something like segment
> >=C2=A0 =C2=A0 =C2=A0>>> routing.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>> The basic idea is that th= e flow label associated with a connection is
> >=C2=A0 =C2=A0 =C2=A0>>>>> randomly changed when the= stack observes that the connection is
> >=C2=A0 =C2=A0 =C2=A0>>>>> failing (e.g. and an RTO)= . There is nothing in the specs that prevents
> >=C2=A0 =C2=A0 =C2=A0>>>>> this since the source is = at liberty to set the flow label as it sees
> >=C2=A0 =C2=A0 =C2=A0>>>>> fit.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> The FL is expected to remain = constant for the life of a flow. A
> >=C2=A0 =C2=A0 =C2=A0>>>> retransmitted packet is part = of the same flow as the
> >=C2=A0 =C2=A0 =C2=A0>>>> originally-transmitted packet= . So this seems to be contradicting the
> >=C2=A0 =C2=A0 =C2=A0>>>> very specification of the FL.=
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> For instance, If a RTO for a = flow causes the FL to change, then one may
> >=C2=A0 =C2=A0 =C2=A0>>>> possibly argue that the FL is= not naming/labeling what is said/expected
> >=C2=A0 =C2=A0 =C2=A0>>>> to be anming/labeling.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Specifically, RFC6437 states:
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> "It is therefore RECOMMENDED= that source hosts support the flow label
> >=C2=A0 =C2=A0 =C2=A0>>> by setting the flow label field f= or all packets of a given flow to the
> >=C2=A0 =C2=A0 =C2=A0>>> same value chosen from an approxi= mation to a discrete uniform
> >=C2=A0 =C2=A0 =C2=A0>>> distribution."
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> So that is clearly a just recomme= ndation, and not a requirement (and
> >=C2=A0 =C2=A0 =C2=A0>>> definitely not a MUST). Furthermo= re, RFC6437 states:
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> "A forwarding node MUST eith= er leave a non-zero flow label value
> >=C2=A0 =C2=A0 =C2=A0>>> unchanged or change it only for c= ompelling operational security
> >=C2=A0 =C2=A0 =C2=A0>>> reasons as described in Section 6= .1."
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> So there's no guarantee in th= e protocol specs that flow labels are
> >=C2=A0 =C2=A0 =C2=A0>>> consistent for the life of the co= nnection, which means that the
> >=C2=A0 =C2=A0 =C2=A0>>> network cannot assume that and th= us it would be incorrect if the
> >=C2=A0 =C2=A0 =C2=A0>>> network tried to enforce flow lab= el consistency as a protocol
> >=C2=A0 =C2=A0 =C2=A0>>> requirement. As I said, it is pru= dent to try to be consistent with
> >=C2=A0 =C2=A0 =C2=A0>>> flow labels and the default behav= ior in Linux should be changed,
> >=C2=A0 =C2=A0 =C2=A0>>> however I do not believe there= 9;s a valid claim of non-conformance that
> >=C2=A0 =C2=A0 =C2=A0>>> motivates removal of the feature = that is already deployed.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Tom
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>> The feature is useful in = large datacenter networks, like
> >=C2=A0 =C2=A0 =C2=A0>>>>> pparently Facebook where = the patches originate, since information
> >=C2=A0 =C2=A0 =C2=A0>>>>> discerned by TCP can oppo= rtunistically be applied to route selection.
> >=C2=A0 =C2=A0 =C2=A0>>>>> The practical issue is th= at there are stateful devices like firewalls
> >=C2=A0 =C2=A0 =C2=A0>>>>> that require consistent r= outing in the network in which case changing
> >=C2=A0 =C2=A0 =C2=A0>>>>> the flow label can confus= e them. As I mentioned, the original intent
> >=C2=A0 =C2=A0 =C2=A0>>>>> was that the flow label r= andomization feature should be opt-in instead
> >=C2=A0 =C2=A0 =C2=A0>>>>> of on by default.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> So... where is the "sour= ce" of the packet that would be "modulating" the FL?
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> Thanks,
> >=C2=A0 =C2=A0 =C2=A0>>>> --
> >=C2=A0 =C2=A0 =C2=A0>>>> Fernando Gont
> >=C2=A0 =C2=A0 =C2=A0>>>> e-mail: fernando@gont.com.ar <mailto:fernando@gont.com.a= r> || fgo= nt@si6networks.com <mailto:fgont@si6networks.com>
> >=C2=A0 =C2=A0 =C2=A0>>>> PGP Fingerprint: 7809 84F5 32= 2E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> _________________________________= ______________
> >=C2=A0 =C2=A0 =C2=A0>>> v6ops mailing list
> >=C2=A0 =C2=A0 =C2=A0>>> v6ops@ietf.org <mailto:v6ops@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0>>> https://www.iet= f.org/mailman/listinfo/v6ops
> >=C2=A0 =C2=A0 =C2=A0>>>
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/v6ops=
> >
>

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


--
Best regards,
Alexander Azi= mov
--0000000000005157af05b4ff3f8f-- From nobody Thu Nov 26 08:39:45 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C783A14AB for ; Thu, 26 Nov 2020 08:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.6 X-Spam-Level: X-Spam-Status: No, score=-15.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj1s5SlIRG1E for ; Thu, 26 Nov 2020 08:39:37 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B803A14A9 for ; Thu, 26 Nov 2020 08:39:36 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id a186so2695198wme.1 for ; Thu, 26 Nov 2020 08:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=edWfoAmVLZbYlmpbCJONOdlNJLI3bMwOAVJSH9ZaLCQ=; b=iUoi9IwLGLbG5Rpoemq2UQDon2zWNuLsqbnW3WmSzRecaosWeumRIntXHtuIjTBcsR duEZLqgZXuBCkGjGSD8BYjUjPYO87CU8nfbxKqzya4QP04zGCwq8y24OlhwQzOQh7dIL EYpnVfzIe7Jx2jh3f0HxJtU2WUKyDxJLJJxS0thyA94UfP9+FXCqvcZl4wJ/cYqI+2mO Rx02+uRRwYDbHzUMhU1ypuVKlagMuwJHIkGY/l37kRz3iM4XdtxS3NohJZnavzy1z3ub MYeDooXhpqTSmrYa/+FdOnruWCWJY95yiG9TLGyDOKrUbAXXLCk71ejAcjZ4VqSytsjn I+2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=edWfoAmVLZbYlmpbCJONOdlNJLI3bMwOAVJSH9ZaLCQ=; b=lEIbojvHH6NS9d9HN1oqoSEq0qy5gq+lJKSlIsqdQ6ssAO9o5q161CMZxsviwQvFzk t5n2TmCbGiE5nqTrVTyR6CAbz5EgldUh0JU6P4nXR4CgJx2Fpm+KQSKlw3eskXQAdosS QFa4Vl/hH/Jzwjh0qWPrrlC7k1KrtH8TOMo1BMfaBvhJX0POBZ/e5lGcFGL9A4c/6p87 aLZqPE27sQXoDXq/ftkwOxfhxSOGpF6yM06CaP8Dx+2jt5BTalVdmM2+Yc3m+DQMfVk8 /sR8MbPxa9p7JLySVckxWH/XdFxIGztYOPlwl+52u2fy5QAbKu972nTUzc/ObL4uv5XU 9gpA== X-Gm-Message-State: AOAM532ibAZME8D9WCkmo+y+tLcWSqMcnh3gZQDNmjhRkA/Gc/jV8JyP 37xIOsNq27x++CB7zAwlSwc2SzULB7IvErqSpAor2Q== X-Google-Smtp-Source: ABdhPJzqXxadN+VVfaKqKqKd6ElReYkMJOQ8O5ba/SnFB+r0DbboFc/wdwFUdnF2KFMXogyMhIABcSyHr2oNVDNz2sY= X-Received: by 2002:a7b:cd11:: with SMTP id f17mr4215376wmj.127.1606408774663; Thu, 26 Nov 2020 08:39:34 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> In-Reply-To: From: Yuchung Cheng Date: Thu, 26 Nov 2020 08:38:57 -0800 Message-ID: To: Alexander Azimov Cc: Tom Herbert , IPv6 Operations , tcpm , Brian E Carpenter Content-Type: multipart/alternative; boundary="00000000000061231205b5053001" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 16:39:40 -0000 --00000000000061231205b5053001 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 26, 2020 at 1:34 AM Alexander Azimov wrote: > Dear colleagues, > > We started discussing an incorrect default behavior, and Tom has already > confirmed that it will be fixed. > > Later the thread turned into an argument if the flow label can be changed > during connection/flow lifetime according to current RFC documents, thoug= h > these documents can be updated. This looks a bit weird for me because I > always thought that it is the IETF community's responsibility to document > proper solutions. If something undocumented but worthy happens in the > industry - IETF should catch up. So, I would like to get back to the > discussion of reasons and their safety. > > The general idea of changing the routing path upon network > outage/degradation looks obvious. Getting kind of source-based routing ca= n > significantly reduce the reaction time and improve end-user experience. T= he > flow label has a perfect match here: transparent for the application, set > by the source, not part of 5-tuple, while it can be used in the load > balancing. IMO poorly documented. I would like to learn your feedback for > the next wording: > > Let say that the flow label is a hash of values from the IP packet's > 5-tuple and random number. Then > > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be > recalculated. > 2. In the case of RTO timeout expiration in the established TCP session > the flow label MAY be recalculated. This setting MUST be switched off by > default. > 3. Otherwise flow label SHOULD be preserved unchanged. > For completion, we might want to discuss reverse-path failure that RTO-triggered rehash in (1)(2) alone can not repair the connection in established or handshake phases. https://patchwork.ozlabs.org/project/netdev/patch/20180829215356.235336-1-y= cheng@google.com/ I also agree with Tom that the general feature is very useful in keeping TCP connected with partial route failures, but the default should be an opt-in. > > The first point stands for redirecting connection from the degraded path > before the connection is established, and it looks safe. The second one c= an > also improve performance if it is set on the server-side. Please comment = if > you see security flaws in such a design. > > =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 03:16, Tom= Herbert : > >> On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter >> wrote: >> > >> > I'm not Joel, but I did once spend some time grepping RFCs to find out >> whether >> > "flow" or "microflow" was the preferred term. In RFC2474, which is >> normative, >> > we have: >> > >> > Microflow: a single instance of an application-to-application flow = of >> > packets which is identified by source address, destination address, >> > protocol id, and source port, destination port (where applicable). >> > >> > But in the flow label work we explicitly avoided being that precise, a= nd >> > did not use the term "microflow". There might be some load balancing >> > scenarios where you want a broader definition, even including >> bidirectional >> > flows. There are expired drafts on that topic: >> > draft-tarreau-extend-flow-label-balancing >> > draft-wang-6man-flow-label-reflection >> > >> Brian, >> >> Random Packet Spraying >> ( >> https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.529&rep= =3Drep1&type=3Dpdf >> ) >> is an interesting idea where packets for a single connection are >> purposely distributed across multiple paths for load distribution. Per >> packet randomized flow labels with flow label aware ECMP makes this >> quite easy to do without requiring any special support in switches >> like you'd need with IPv4. I'm not necessarily advocating this, but it >> does highlight one potential use case of having a flow label that >> doesn;t have rigidly defined requirements on the host. >> >> Tom >> >> > Regards >> > Brian >> > >> > On 26-Nov-20 11:13, Tom Herbert wrote: >> > > Joel, is there a normative definition of a flow? >> > > >> > > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern > > wrote: >> > > >> > > No, as Brian says, there are escape clauses in the flow >> definitions. >> > > >> > > But changing the flow label due to traffic problems does not >> correspond >> > > to packets being in actually different flows. >> > > If one were using UDP, and mixing loss sensitive packets with lo= ss >> > > insensitive packets for a special application, sure, one could >> use two >> > > flow labels. But that is not what you are describing. >> > > >> > > Yours, >> > > Joel >> > > >> > > On 11/25/2020 3:05 PM, Tom Herbert wrote: >> > > > Joel, >> > > > >> > > > Is there an RFC that clearly and unambiguously states that a >> host MUST >> > > > use the same flow label for the lifetime _and_ clearly defines >> exactly >> > > > what a flow is with respect to such a requirement (for >> instance, how >> > > > would you define a flow and enforce such a requirement in UDP? >> IPsec? >> > > > other encapsulations?). If there is such a requirement then >> we'll >> > > > change the code to be conformant. >> > > > >> > > > Tom >> > > > >> > > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern < >> jmh@joelhalpern.com > wrote: >> > > >> >> > > >> This kind of thing is why, as I understand it, MPTCP has >> discovery >> > > >> mechanisms ot know if both sides use it, and can select >> alternative >> > > >> addresses for communication. >> > > >> >> > > >> Trying to guess flow labels that might avoid a problem becaus= e >> it might >> > > >> be an ECMP problem, is just flailing about. Not a good desig= n >> for >> > > >> operational protocols. >> > > >> >> > > >> And in general, designing protocols around "I know exactly >> what is going >> > > >> on" (the requirement for what you describe that goes well >> beyond just >> > > >> "limited domains") is also a recipe for failure. >> > > >> >> > > >> The Flow Label RFCs are actually very explicit that a flow >> label is >> > > >> supposed to be stable for the life of the flow. Otherwise, i= t >> isn't a >> > > >> flow label. >> > > >> >> > > >> Yours, >> > > >> Joel >> > > >> >> > > >> On 11/25/2020 2:35 PM, Tom Herbert wrote: >> > > >>> Hi Fernando, comments in line... >> > > >>> >> > > >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont < >> fernando@gont.com.ar > wrote: >> > > >>>> >> > > >>>> Hi, Tom, >> > > >>>> >> > > >>>> On 24/11/20 16:43, Tom Herbert wrote: >> > > >>>> [....] >> > > >>>>> Modulating the flow label is a means to affect the routing >> of packets >> > > >>>>> through the network that uses flow labels as input to the >> ECMP hash. >> > > >>>> >> > > >>>> What's the point? >> > > >>>> >> > > >>>> 1) You cannot tell *if* the FL is being used. >> > > >>>> >> > > >>> Generally true, but in a limited domain this information >> could be >> > > >>> discerned. I'd note that it's also generally true that we >> don't know >> > > >>> if there is a load balancer or stateful firewall in the path >> that >> > > >>> requires consistent routing, but in a limited domain we coul= d >> know >> > > >>> that also. >> > > >>> >> > > >>>> 2) Changing the FL does not necessarily mean that packets >> will employ a >> > > >>>> different link. >> > > >>> >> > > >>> It's an opportunistic mechanism. If a connection is failing >> and we get >> > > >>> a better path that fixes it by simply changing the flow labe= l >> then >> > > >>> what's the harm? >> > > >>> >> > > >>>> >> > > >>>> 3) If the network is failing, shouldn't you handle this via >> routing? >> > > >>>> >> > > >>> Sure, but then that requires an out of band feedback loop >> from a TCP >> > > >>> implementation to the network infrastructure to indicate >> there is a >> > > >>> problem and then the network needs to respond. That's >> significant >> > > >>> infrastructure and higher reaction time than doing something >> in TCP >> > > >>> and IP. Think of modulating the flow label is an inexpensive >> form of >> > > >>> source routing within a limited domain that doesn't need any >> > > >>> infrastructure or heavyweight protocols or something like >> segment >> > > >>> routing. >> > > >>> >> > > >>>> >> > > >>>> >> > > >>>>> The basic idea is that the flow label associated with a >> connection is >> > > >>>>> randomly changed when the stack observes that the >> connection is >> > > >>>>> failing (e.g. and an RTO). There is nothing in the specs >> that prevents >> > > >>>>> this since the source is at liberty to set the flow label >> as it sees >> > > >>>>> fit. >> > > >>>> >> > > >>>> The FL is expected to remain constant for the life of a >> flow. A >> > > >>>> retransmitted packet is part of the same flow as the >> > > >>>> originally-transmitted packet. So this seems to be >> contradicting the >> > > >>>> very specification of the FL. >> > > >>>> >> > > >>>> For instance, If a RTO for a flow causes the FL to change, >> then one may >> > > >>>> possibly argue that the FL is not naming/labeling what is >> said/expected >> > > >>>> to be anming/labeling. >> > > >>> >> > > >>> Specifically, RFC6437 states: >> > > >>> >> > > >>> "It is therefore RECOMMENDED that source hosts support the >> flow label >> > > >>> by setting the flow label field for all packets of a given >> flow to the >> > > >>> same value chosen from an approximation to a discrete unifor= m >> > > >>> distribution." >> > > >>> >> > > >>> So that is clearly a just recommendation, and not a >> requirement (and >> > > >>> definitely not a MUST). Furthermore, RFC6437 states: >> > > >>> >> > > >>> "A forwarding node MUST either leave a non-zero flow label >> value >> > > >>> unchanged or change it only for compelling operational >> security >> > > >>> reasons as described in Section 6.1." >> > > >>> >> > > >>> So there's no guarantee in the protocol specs that flow >> labels are >> > > >>> consistent for the life of the connection, which means that >> the >> > > >>> network cannot assume that and thus it would be incorrect if >> the >> > > >>> network tried to enforce flow label consistency as a protoco= l >> > > >>> requirement. As I said, it is prudent to try to be consisten= t >> with >> > > >>> flow labels and the default behavior in Linux should be >> changed, >> > > >>> however I do not believe there's a valid claim of >> non-conformance that >> > > >>> motivates removal of the feature that is already deployed. >> > > >>> >> > > >>> Tom >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>>> The feature is useful in large datacenter networks, like >> > > >>>>> pparently Facebook where the patches originate, since >> information >> > > >>>>> discerned by TCP can opportunistically be applied to route >> selection. >> > > >>>>> The practical issue is that there are stateful devices lik= e >> firewalls >> > > >>>>> that require consistent routing in the network in which >> case changing >> > > >>>>> the flow label can confuse them. As I mentioned, the >> original intent >> > > >>>>> was that the flow label randomization feature should be >> opt-in instead >> > > >>>>> of on by default. >> > > >>>> >> > > >>>> So... where is the "source" of the packet that would be >> "modulating" the FL? >> > > >>>> >> > > >>>> Thanks, >> > > >>>> -- >> > > >>>> 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 >> > > >>> >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > > > -- > Best regards, > Alexander Azimov > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000061231205b5053001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Thu, Nov 26, 2020 at 1:34 AM Alexander Azimov <a.e.azimov@gmail.com> wro= te:
Dear colleagues,

We started discussing an incorrect default beh= avior, and Tom has already confirmed that it will be fixed.

Later th= e thread turned into an argument if the flow label can be changed during co= nnection/flow lifetime according to current RFC documents, though these doc= uments can be updated. This looks a bit weird for me because I always thoug= ht that it is the IETF community's responsibility to document proper so= lutions. If something undocumented but worthy happens in the industry - IET= F should catch up. So, I would like to get back to the discussion of reason= s and their safety.

The general idea of changing the routing path u= pon network outage/degradation looks obvious. Getting kind of source-based = routing can significantly reduce the reaction=20 time and improve end-user experience. The flow label has a perfect match h= ere: transparent for the application, set by the source, not part of 5-tupl= e, while it can be used in the load balancing. IMO poorly documented. I wou= ld like to learn your feedback for the next wording:

Let say that th= e flow label is a hash of values from the IP packet's 5-tuple and rando= m number. Then

1. In the case of SYN or SYN-ACK retransmission flow = label SHOULD be recalculated.
2. In the case of RTO timeout expiration i= n the established TCP session the flow label MAY be=20 recalculated. This setting MUST be switched off by default.
3. Otherwise= flow label SHOULD be preserved unchanged.
=C2= =A0
For completion, we might want to discuss reverse-path failure= that RTO-triggered rehash in (1)(2) alone can not repair the connection in= established or handshake phases.

I also agree with Tom t= hat the general feature is very useful in keeping TCP connected with partia= l route failures, but the default should be an opt-in.
=C2=A0

Th= e first point stands for redirecting connection from the degraded path befo= re the connection is established, and it looks safe. The second one can als= o improve performance if it is set on the server-side. Please comment if yo= u see security flaws in such a design.

=D1=87=D1=82, 26 =D0=BD=D0=BE=D1= =8F=D0=B1. 2020 =D0=B3. =D0=B2 03:16, Tom Herbert <tom@herbertland.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Nov 25, 2020 at 3:= 33 PM Brian E Carpenter
<brian.= e.carpenter@gmail.com> wrote:
>
> I'm not Joel, but I did once spend some time grepping RFCs to find= out whether
> "flow" or "microflow" was the preferred term. In R= FC2474, which is normative,
> we have:
>
>=C2=A0 =C2=A0 Microflow: a single instance of an application-to-applica= tion flow of
>=C2=A0 =C2=A0 packets which is identified by source address, destinatio= n address,
>=C2=A0 =C2=A0 protocol id, and source port, destination port (where app= licable).
>
> But in the flow label work we explicitly avoided being that precise, a= nd
> did not use the term "microflow". There might be some load b= alancing
> scenarios where you want a broader definition, even including bidirect= ional
> flows. There are expired drafts on that topic:
> draft-tarreau-extend-flow-label-balancing
> draft-wang-6man-flow-label-reflection
>
Brian,

Random Packet Spraying
(ht= tps://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.529&rep= =3Drep1&type=3Dpdf)
is an interesting idea where packets for a single connection are
purposely distributed across multiple paths for load distribution. Per
packet randomized flow labels with flow label aware ECMP makes this
quite easy to do without requiring any special support in switches
like you'd need with IPv4. I'm not necessarily advocating this, but= it
does highlight one potential use case of having a flow label that
doesn;t have rigidly defined requirements on the host.

Tom

> Regards
>=C2=A0 =C2=A0 Brian
>
> On 26-Nov-20 11:13, Tom Herbert wrote:
> > Joel, is there a normative definition of a flow?
> >
> > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern <jmh@joelhalpern.com <mailt= o:jmh@joelhalpern.= com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0No, as Brian says, there are escape clauses in= the flow definitions.
> >
> >=C2=A0 =C2=A0 =C2=A0But changing the flow label due to traffic pro= blems does not correspond
> >=C2=A0 =C2=A0 =C2=A0to packets being in actually different flows.<= br> > >=C2=A0 =C2=A0 =C2=A0If one were using UDP, and mixing loss sensiti= ve packets with loss
> >=C2=A0 =C2=A0 =C2=A0insensitive packets for a special application,= sure, one could use two
> >=C2=A0 =C2=A0 =C2=A0flow labels.=C2=A0 But that is not what you ar= e describing.
> >
> >=C2=A0 =C2=A0 =C2=A0Yours,
> >=C2=A0 =C2=A0 =C2=A0Joel
> >
> >=C2=A0 =C2=A0 =C2=A0On 11/25/2020 3:05 PM, Tom Herbert wrote:
> >=C2=A0 =C2=A0 =C2=A0> Joel,
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Is there an RFC that clearly and unambigu= ously states that a host MUST
> >=C2=A0 =C2=A0 =C2=A0> use the same flow label for the lifetime = _and_ clearly defines exactly
> >=C2=A0 =C2=A0 =C2=A0> what a flow is with respect to such a req= uirement (for instance, how
> >=C2=A0 =C2=A0 =C2=A0> would you define a flow and enforce such = a requirement in UDP? IPsec?
> >=C2=A0 =C2=A0 =C2=A0> other encapsulations?). If there is such = a requirement then we'll
> >=C2=A0 =C2=A0 =C2=A0> change the code to be conformant.
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Tom
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> On Wed, Nov 25, 2020 at 12:39 PM Joel M. = Halpern <jmh@jo= elhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> This kind of thing is why, as I under= stand it, MPTCP has discovery
> >=C2=A0 =C2=A0 =C2=A0>> mechanisms ot know if both sides use = it, and can select alternative
> >=C2=A0 =C2=A0 =C2=A0>> addresses for communication.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> Trying to guess flow labels that migh= t avoid a problem because it might
> >=C2=A0 =C2=A0 =C2=A0>> be an ECMP problem, is just flailing = about.=C2=A0 Not a good design for
> >=C2=A0 =C2=A0 =C2=A0>> operational protocols.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> And in general, designing protocols a= round "I know exactly what is going
> >=C2=A0 =C2=A0 =C2=A0>> on"=C2=A0 (the requirement for w= hat you describe that goes well beyond just
> >=C2=A0 =C2=A0 =C2=A0>> "limited domains") is also = a recipe for failure.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> The Flow Label RFCs are actually very= explicit that a flow label is
> >=C2=A0 =C2=A0 =C2=A0>> supposed to be stable for the life of= the flow.=C2=A0 Otherwise, it isn't a
> >=C2=A0 =C2=A0 =C2=A0>> flow label.
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> Yours,
> >=C2=A0 =C2=A0 =C2=A0>> Joel
> >=C2=A0 =C2=A0 =C2=A0>>
> >=C2=A0 =C2=A0 =C2=A0>> On 11/25/2020 2:35 PM, Tom Herbert wr= ote:
> >=C2=A0 =C2=A0 =C2=A0>>> Hi Fernando, comments in line...<= br> > >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> On Wed, Nov 25, 2020 at 12:13 AM = Fernando Gont <fernando@gont.com.ar <mailto:fernando@gont.com.ar>> wrote:
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> Hi, Tom,
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> On 24/11/20 16:43, Tom Herber= t wrote:
> >=C2=A0 =C2=A0 =C2=A0>>>> [....]
> >=C2=A0 =C2=A0 =C2=A0>>>>> Modulating the flow label= is a means to affect the routing of packets
> >=C2=A0 =C2=A0 =C2=A0>>>>> through the network that = uses flow labels as input to the ECMP hash.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> What's the point?
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> 1) You cannot tell *if* the F= L is being used.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Generally true, but in a limited = domain this information could be
> >=C2=A0 =C2=A0 =C2=A0>>> discerned. I'd note that it&#= 39;s also generally true that we don't know
> >=C2=A0 =C2=A0 =C2=A0>>> if there is a load balancer or st= ateful firewall in the path that
> >=C2=A0 =C2=A0 =C2=A0>>> requires consistent routing, but = in a limited domain we could know
> >=C2=A0 =C2=A0 =C2=A0>>> that also.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> 2) Changing the FL does not n= ecessarily mean that packets will employ a
> >=C2=A0 =C2=A0 =C2=A0>>>> different link.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> It's an opportunistic mechani= sm. If a connection is failing and we get
> >=C2=A0 =C2=A0 =C2=A0>>> a better path that fixes it by si= mply changing the flow label then
> >=C2=A0 =C2=A0 =C2=A0>>> what's the harm?
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> 3) If the network is failing,= shouldn't you handle this via routing?
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Sure, but then that requires an o= ut of band feedback loop from a TCP
> >=C2=A0 =C2=A0 =C2=A0>>> implementation to the network inf= rastructure to indicate there is a
> >=C2=A0 =C2=A0 =C2=A0>>> problem and then the network need= s to respond. That's significant
> >=C2=A0 =C2=A0 =C2=A0>>> infrastructure and higher reactio= n time than doing something in TCP
> >=C2=A0 =C2=A0 =C2=A0>>> and IP. Think of modulating the f= low label is an inexpensive form of
> >=C2=A0 =C2=A0 =C2=A0>>> source routing within a limited d= omain that doesn't need any
> >=C2=A0 =C2=A0 =C2=A0>>> infrastructure or heavyweight pro= tocols or something like segment
> >=C2=A0 =C2=A0 =C2=A0>>> routing.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>> The basic idea is that th= e flow label associated with a connection is
> >=C2=A0 =C2=A0 =C2=A0>>>>> randomly changed when the= stack observes that the connection is
> >=C2=A0 =C2=A0 =C2=A0>>>>> failing (e.g. and an RTO)= . There is nothing in the specs that prevents
> >=C2=A0 =C2=A0 =C2=A0>>>>> this since the source is = at liberty to set the flow label as it sees
> >=C2=A0 =C2=A0 =C2=A0>>>>> fit.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> The FL is expected to remain = constant for the life of a flow. A
> >=C2=A0 =C2=A0 =C2=A0>>>> retransmitted packet is part = of the same flow as the
> >=C2=A0 =C2=A0 =C2=A0>>>> originally-transmitted packet= . So this seems to be contradicting the
> >=C2=A0 =C2=A0 =C2=A0>>>> very specification of the FL.=
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> For instance, If a RTO for a = flow causes the FL to change, then one may
> >=C2=A0 =C2=A0 =C2=A0>>>> possibly argue that the FL is= not naming/labeling what is said/expected
> >=C2=A0 =C2=A0 =C2=A0>>>> to be anming/labeling.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Specifically, RFC6437 states:
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> "It is therefore RECOMMENDED= that source hosts support the flow label
> >=C2=A0 =C2=A0 =C2=A0>>> by setting the flow label field f= or all packets of a given flow to the
> >=C2=A0 =C2=A0 =C2=A0>>> same value chosen from an approxi= mation to a discrete uniform
> >=C2=A0 =C2=A0 =C2=A0>>> distribution."
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> So that is clearly a just recomme= ndation, and not a requirement (and
> >=C2=A0 =C2=A0 =C2=A0>>> definitely not a MUST). Furthermo= re, RFC6437 states:
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> "A forwarding node MUST eith= er leave a non-zero flow label value
> >=C2=A0 =C2=A0 =C2=A0>>> unchanged or change it only for c= ompelling operational security
> >=C2=A0 =C2=A0 =C2=A0>>> reasons as described in Section 6= .1."
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> So there's no guarantee in th= e protocol specs that flow labels are
> >=C2=A0 =C2=A0 =C2=A0>>> consistent for the life of the co= nnection, which means that the
> >=C2=A0 =C2=A0 =C2=A0>>> network cannot assume that and th= us it would be incorrect if the
> >=C2=A0 =C2=A0 =C2=A0>>> network tried to enforce flow lab= el consistency as a protocol
> >=C2=A0 =C2=A0 =C2=A0>>> requirement. As I said, it is pru= dent to try to be consistent with
> >=C2=A0 =C2=A0 =C2=A0>>> flow labels and the default behav= ior in Linux should be changed,
> >=C2=A0 =C2=A0 =C2=A0>>> however I do not believe there= 9;s a valid claim of non-conformance that
> >=C2=A0 =C2=A0 =C2=A0>>> motivates removal of the feature = that is already deployed.
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> Tom
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>> The feature is useful in = large datacenter networks, like
> >=C2=A0 =C2=A0 =C2=A0>>>>> pparently Facebook where = the patches originate, since information
> >=C2=A0 =C2=A0 =C2=A0>>>>> discerned by TCP can oppo= rtunistically be applied to route selection.
> >=C2=A0 =C2=A0 =C2=A0>>>>> The practical issue is th= at there are stateful devices like firewalls
> >=C2=A0 =C2=A0 =C2=A0>>>>> that require consistent r= outing in the network in which case changing
> >=C2=A0 =C2=A0 =C2=A0>>>>> the flow label can confus= e them. As I mentioned, the original intent
> >=C2=A0 =C2=A0 =C2=A0>>>>> was that the flow label r= andomization feature should be opt-in instead
> >=C2=A0 =C2=A0 =C2=A0>>>>> of on by default.
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> So... where is the "sour= ce" of the packet that would be "modulating" the FL?
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>> Thanks,
> >=C2=A0 =C2=A0 =C2=A0>>>> --
> >=C2=A0 =C2=A0 =C2=A0>>>> Fernando Gont
> >=C2=A0 =C2=A0 =C2=A0>>>> e-mail: fernando@gont.com.ar <mailto:fernando@gont.com.a= r> || fgo= nt@si6networks.com <mailto:fgont@si6networks.com>
> >=C2=A0 =C2=A0 =C2=A0>>>> PGP Fingerprint: 7809 84F5 32= 2E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>>
> >=C2=A0 =C2=A0 =C2=A0>>>
> >=C2=A0 =C2=A0 =C2=A0>>> _________________________________= ______________
> >=C2=A0 =C2=A0 =C2=A0>>> v6ops mailing list
> >=C2=A0 =C2=A0 =C2=A0>>> v6ops@ietf.org <mailto:v6ops@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0>>> https://www.iet= f.org/mailman/listinfo/v6ops
> >=C2=A0 =C2=A0 =C2=A0>>>
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/v6ops=
> >
>

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


--
Best regards,
Alexander Azimov
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000061231205b5053001-- From nobody Thu Nov 26 11:53:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5EB3A0937; Thu, 26 Nov 2020 11:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmK6Qy6hjEjq; Thu, 26 Nov 2020 11:53:04 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A1D3A0934; Thu, 26 Nov 2020 11:53:04 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id b6so2470864pfp.7; Thu, 26 Nov 2020 11:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7KsfzhLZojDWOSaUcpbCg7Z+oYHfH1TZPipK+ib5TZM=; b=RaOv69KgSn1labbz2LL1KLRiZfhWImU+CRWRCPqrUeOFF3cv0YAAOHKTcXvxsZklB0 kO1OBlVQbmng/WfPs4shnTlF2Ss9ljQ6W7fBJMc0yWN3+FD9ff8V7fGcAiqnvfYCVVsH agn33WxBkruzdMJ2QRAoUvCxWiXxJQfwOvZ7XTvKbwC3/dxb6osqTfqOdupnG8Posnux GzJhHhMvpr72KSgq+r4KL012Gkk7SLMpRWl8sDfklTgXjKzmpHFBubLf2j52rL7Go2w2 RqSAznNV6KS0Bb8tesKkGtQw9mFLHLvUx4mPrEhigpYSaUvNzO74hZSDkdcULUaDPRu3 8rmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7KsfzhLZojDWOSaUcpbCg7Z+oYHfH1TZPipK+ib5TZM=; b=lDe3ZZ3QQCk2nCQbBQueFaZksZocp1w+oplnL4eKzSDiOJt/rTdeIT5+DTomwmpGfG rSSSUz5yo+rL9zCQevEG47nwFdmb1SY+5yIhYAmqOAxkTKjDcHGXcreCXAQPAETG7xs6 53UEOpWOJuk0zCVp+3SMrrSUWPsSYgUM5IEPUDc0V98jyJY5UdxSQK6RuIyN8udCNk+t PH6VMNTR8ZFZBwop+czaretmULtUqvYhr6fVBhsSmun/faYif86SrNkOkfQ50StBiLYk Ry39cep7wcWqCV+s/iIZvbQPNs7BEmDFHRHFWhnywTlMXudluUv68i9Wod9xhhgoFegw 150Q== X-Gm-Message-State: AOAM531QnKffRni0PQEiSQkszeUOAmxdqOhRt+HeTDXW/41Umu7qDZNw 30d0iL3EpmSsMnlhLY2fpHF5WYJ0RSbO4g== X-Google-Smtp-Source: ABdhPJxwQkKaIB2EbIoW1srp6ULXjykpHUb+Gs9uEpFKxhU/589BqhoF+njIlywiiMSpPCHfEOVojw== X-Received: by 2002:a63:5941:: with SMTP id j1mr3728838pgm.59.1606420383173; Thu, 26 Nov 2020 11:53:03 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id m5sm7300617pjl.19.2020.11.26.11.53.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Nov 2020 11:53:02 -0800 (PST) To: Alexander Azimov , Tom Herbert Cc: tcpm , IPv6 Operations References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Fri, 27 Nov 2020 08:52:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 19:53:07 -0000 Alexander, > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be re= calculated. =2E.. > The first point stands for redirecting connection from the degraded pat= h before the connection is established, and it looks safe. I am convinced that it is often unsafe, because that depends on exactly h= ow a server farm load balancer handles such cases. If it maintains the TC= P session on the same actual server if there is SYN(-ACK) retransmission,= the flow label must not be changed. The benefit for possible broken routing is quite hypothetical, whereas th= e risk to session persistence at the server is real. (Remember that the source cann= ot know by magic that there is server load balancing at the far end, but = it's the common case today.) > 2. In the case of RTO timeout expiration in the established TCP session= the flow label MAY be recalculated. This setting MUST be switched off by= default. As noted before, this is only safe in a limited domain where it is known = with certainty that server load balancing is not in use. I think it's the= refore a corner case and specifically, the appropriate normative statemen= t would be SHOULD NOT, which is defined very carefully in RFC2119 exactly= for this sort of case. But in fact I think we should not attempt to legislate on this point. The= value is marginal at best. As others have said, this is not the way to t= ackle operational routing problems. Regards Brian Carpenter On 26-Nov-20 22:34, Alexander Azimov wrote: > Dear colleagues, >=20 > We started discussing an incorrect default behavior, and Tom has alread= y confirmed that it will be fixed. >=20 > Later the thread turned into an argument if the flow label can be chang= ed during connection/flow lifetime according to current RFC documents, th= ough these documents can be updated. This looks a bit weird for me becaus= e I always thought that it is the IETF community's responsibility to docu= ment proper solutions. If something undocumented but worthy happens in th= e industry - IETF should catch up. So, I would like to get back to the di= scussion of reasons and their safety. >=20 > The general idea of changing the routing path upon network outage/degra= dation looks obvious. Getting kind of source-based routing can significan= tly reduce the reaction time and improve end-user experience. The flow la= bel has a perfect match here: transparent for the application, set by the= source, not part of 5-tuple, while it can be used in the load balancing.= IMO poorly documented. I would like to learn your feedback for the next = wording: >=20 > Let say that the flow label is a hash of values from the IP packet's 5-= tuple and random number. Then >=20 > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be re= calculated. > 2. In the case of RTO timeout expiration in the established TCP session= the flow label MAY be recalculated. This setting MUST be switched off by= default. > 3. Otherwise flow label SHOULD be preserved unchanged. >=20 > The first point stands for redirecting connection from the degraded pat= h before the connection is established, and it looks safe. The second one= can also improve performance if it is set on the server-side. Please com= ment if you see security flaws in such a design. >=20 > =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 03:16, T= om Herbert >: >=20 > On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter > > = wrote: > > > > I'm not Joel, but I did once spend some time grepping RFCs to fin= d out whether > > "flow" or "microflow" was the preferred term. In RFC2474, which i= s normative, > > we have: > > > >=C2=A0 =C2=A0 Microflow: a single instance of an application-to-ap= plication flow of > >=C2=A0 =C2=A0 packets which is identified by source address, desti= nation address, > >=C2=A0 =C2=A0 protocol id, and source port, destination port (wher= e applicable). > > > > But in the flow label work we explicitly avoided being that preci= se, and > > did not use the term "microflow". There might be some load balanc= ing > > scenarios where you want a broader definition, even including bid= irectional > > flows. There are expired drafts on that topic: > > draft-tarreau-extend-flow-label-balancing > > draft-wang-6man-flow-label-reflection > > > Brian, >=20 > Random Packet Spraying > (https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.52= 9&rep=3Drep1&type=3Dpdf) > is an interesting idea where packets for a single connection are > purposely distributed across multiple paths for load distribution. = Per > packet randomized flow labels with flow label aware ECMP makes this= > quite easy to do without requiring any special support in switches > like you'd need with IPv4. I'm not necessarily advocating this, but= it > does highlight one potential use case of having a flow label that > doesn;t have rigidly defined requirements on the host. >=20 > Tom >=20 > > Regards > >=C2=A0 =C2=A0 Brian > > > > On 26-Nov-20 11:13, Tom Herbert wrote: > > > Joel, is there a normative definition of a flow? > > > > > > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern >> wrote: > > > > > >=C2=A0 =C2=A0 =C2=A0No, as Brian says, there are escape clauses = in the flow definitions. > > > > > >=C2=A0 =C2=A0 =C2=A0But changing the flow label due to traffic p= roblems does not correspond > > >=C2=A0 =C2=A0 =C2=A0to packets being in actually different flows= =2E > > >=C2=A0 =C2=A0 =C2=A0If one were using UDP, and mixing loss sensi= tive packets with loss > > >=C2=A0 =C2=A0 =C2=A0insensitive packets for a special applicatio= n, sure, one could use two > > >=C2=A0 =C2=A0 =C2=A0flow labels.=C2=A0 But that is not what you = are describing. > > > > > >=C2=A0 =C2=A0 =C2=A0Yours, > > >=C2=A0 =C2=A0 =C2=A0Joel > > > > > >=C2=A0 =C2=A0 =C2=A0On 11/25/2020 3:05 PM, Tom Herbert wrote: > > >=C2=A0 =C2=A0 =C2=A0> Joel, > > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> Is there an RFC that clearly and unambiguo= usly states that a host MUST > > >=C2=A0 =C2=A0 =C2=A0> use the same flow label for the lifetime _= and_ clearly defines exactly > > >=C2=A0 =C2=A0 =C2=A0> what a flow is with respect to such a requ= irement (for instance, how > > >=C2=A0 =C2=A0 =C2=A0> would you define a flow and enforce such a= requirement in UDP? IPsec? > > >=C2=A0 =C2=A0 =C2=A0> other encapsulations?). If there is such a= requirement then we'll > > >=C2=A0 =C2=A0 =C2=A0> change the code to be conformant. > > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> Tom > > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> On Wed, Nov 25, 2020 at 12:39 PM Joel M. H= alpern >> wrote: > > >=C2=A0 =C2=A0 =C2=A0>> > > >=C2=A0 =C2=A0 =C2=A0>> This kind of thing is why, as I understan= d it, MPTCP has discovery > > >=C2=A0 =C2=A0 =C2=A0>> mechanisms ot know if both sides use it, = and can select alternative > > >=C2=A0 =C2=A0 =C2=A0>> addresses for communication. > > >=C2=A0 =C2=A0 =C2=A0>> > > >=C2=A0 =C2=A0 =C2=A0>> Trying to guess flow labels that might av= oid a problem because it might > > >=C2=A0 =C2=A0 =C2=A0>> be an ECMP problem, is just flailing abou= t.=C2=A0 Not a good design for > > >=C2=A0 =C2=A0 =C2=A0>> operational protocols. > > >=C2=A0 =C2=A0 =C2=A0>> > > >=C2=A0 =C2=A0 =C2=A0>> And in general, designing protocols aroun= d "I know exactly what is going > > >=C2=A0 =C2=A0 =C2=A0>> on"=C2=A0 (the requirement for what you d= escribe that goes well beyond just > > >=C2=A0 =C2=A0 =C2=A0>> "limited domains") is also a recipe for f= ailure. > > >=C2=A0 =C2=A0 =C2=A0>> > > >=C2=A0 =C2=A0 =C2=A0>> The Flow Label RFCs are actually very exp= licit that a flow label is > > >=C2=A0 =C2=A0 =C2=A0>> supposed to be stable for the life of the= flow.=C2=A0 Otherwise, it isn't a > > >=C2=A0 =C2=A0 =C2=A0>> flow label. > > >=C2=A0 =C2=A0 =C2=A0>> > > >=C2=A0 =C2=A0 =C2=A0>> Yours, > > >=C2=A0 =C2=A0 =C2=A0>> Joel > > >=C2=A0 =C2=A0 =C2=A0>> > > >=C2=A0 =C2=A0 =C2=A0>> On 11/25/2020 2:35 PM, Tom Herbert wrote:= > > >=C2=A0 =C2=A0 =C2=A0>>> Hi Fernando, comments in line... > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> On Wed, Nov 25, 2020 at 12:13 AM Fernand= o Gont >> wrote: > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> Hi, Tom, > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> On 24/11/20 16:43, Tom Herbert wrote: > > >=C2=A0 =C2=A0 =C2=A0>>>> [....] > > >=C2=A0 =C2=A0 =C2=A0>>>>> Modulating the flow label is a means t= o affect the routing of packets > > >=C2=A0 =C2=A0 =C2=A0>>>>> through the network that uses flow lab= els as input to the ECMP hash. > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> What's the point? > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> 1) You cannot tell *if* the FL is being= used. > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>> Generally true, but in a limited domain = this information could be > > >=C2=A0 =C2=A0 =C2=A0>>> discerned. I'd note that it's also gener= ally true that we don't know > > >=C2=A0 =C2=A0 =C2=A0>>> if there is a load balancer or stateful = firewall in the path that > > >=C2=A0 =C2=A0 =C2=A0>>> requires consistent routing, but in a li= mited domain we could know > > >=C2=A0 =C2=A0 =C2=A0>>> that also. > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> 2) Changing the FL does not necessarily= mean that packets will employ a > > >=C2=A0 =C2=A0 =C2=A0>>>> different link. > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> It's an opportunistic mechanism. If a co= nnection is failing and we get > > >=C2=A0 =C2=A0 =C2=A0>>> a better path that fixes it by simply ch= anging the flow label then > > >=C2=A0 =C2=A0 =C2=A0>>> what's the harm? > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> 3) If the network is failing, shouldn't= you handle this via routing? > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>> Sure, but then that requires an out of b= and feedback loop from a TCP > > >=C2=A0 =C2=A0 =C2=A0>>> implementation to the network infrastruc= ture to indicate there is a > > >=C2=A0 =C2=A0 =C2=A0>>> problem and then the network needs to re= spond. That's significant > > >=C2=A0 =C2=A0 =C2=A0>>> infrastructure and higher reaction time = than doing something in TCP > > >=C2=A0 =C2=A0 =C2=A0>>> and IP. Think of modulating the flow lab= el is an inexpensive form of > > >=C2=A0 =C2=A0 =C2=A0>>> source routing within a limited domain t= hat doesn't need any > > >=C2=A0 =C2=A0 =C2=A0>>> infrastructure or heavyweight protocols = or something like segment > > >=C2=A0 =C2=A0 =C2=A0>>> routing. > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>>> The basic idea is that the flow label = associated with a connection is > > >=C2=A0 =C2=A0 =C2=A0>>>>> randomly changed when the stack observ= es that the connection is > > >=C2=A0 =C2=A0 =C2=A0>>>>> failing (e.g. and an RTO). There is no= thing in the specs that prevents > > >=C2=A0 =C2=A0 =C2=A0>>>>> this since the source is at liberty to= set the flow label as it sees > > >=C2=A0 =C2=A0 =C2=A0>>>>> fit. > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> The FL is expected to remain constant f= or the life of a flow. A > > >=C2=A0 =C2=A0 =C2=A0>>>> retransmitted packet is part of the sam= e flow as the > > >=C2=A0 =C2=A0 =C2=A0>>>> originally-transmitted packet. So this = seems to be contradicting the > > >=C2=A0 =C2=A0 =C2=A0>>>> very specification of the FL. > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> For instance, If a RTO for a flow cause= s the FL to change, then one may > > >=C2=A0 =C2=A0 =C2=A0>>>> possibly argue that the FL is not namin= g/labeling what is said/expected > > >=C2=A0 =C2=A0 =C2=A0>>>> to be anming/labeling. > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> Specifically, RFC6437 states: > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> "It is therefore RECOMMENDED that source= hosts support the flow label > > >=C2=A0 =C2=A0 =C2=A0>>> by setting the flow label field for all = packets of a given flow to the > > >=C2=A0 =C2=A0 =C2=A0>>> same value chosen from an approximation = to a discrete uniform > > >=C2=A0 =C2=A0 =C2=A0>>> distribution." > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> So that is clearly a just recommendation= , and not a requirement (and > > >=C2=A0 =C2=A0 =C2=A0>>> definitely not a MUST). Furthermore, RFC= 6437 states: > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> "A forwarding node MUST either leave a n= on-zero flow label value > > >=C2=A0 =C2=A0 =C2=A0>>> unchanged or change it only for compelli= ng operational security > > >=C2=A0 =C2=A0 =C2=A0>>> reasons as described in Section 6.1." > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> So there's no guarantee in the protocol = specs that flow labels are > > >=C2=A0 =C2=A0 =C2=A0>>> consistent for the life of the connectio= n, which means that the > > >=C2=A0 =C2=A0 =C2=A0>>> network cannot assume that and thus it w= ould be incorrect if the > > >=C2=A0 =C2=A0 =C2=A0>>> network tried to enforce flow label cons= istency as a protocol > > >=C2=A0 =C2=A0 =C2=A0>>> requirement. As I said, it is prudent to= try to be consistent with > > >=C2=A0 =C2=A0 =C2=A0>>> flow labels and the default behavior in = Linux should be changed, > > >=C2=A0 =C2=A0 =C2=A0>>> however I do not believe there's a valid= claim of non-conformance that > > >=C2=A0 =C2=A0 =C2=A0>>> motivates removal of the feature that is= already deployed. > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> Tom > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>>> The feature is useful in large datacen= ter networks, like > > >=C2=A0 =C2=A0 =C2=A0>>>>> pparently Facebook where the patches o= riginate, since information > > >=C2=A0 =C2=A0 =C2=A0>>>>> discerned by TCP can opportunistically= be applied to route selection. > > >=C2=A0 =C2=A0 =C2=A0>>>>> The practical issue is that there are = stateful devices like firewalls > > >=C2=A0 =C2=A0 =C2=A0>>>>> that require consistent routing in the= network in which case changing > > >=C2=A0 =C2=A0 =C2=A0>>>>> the flow label can confuse them. As I = mentioned, the original intent > > >=C2=A0 =C2=A0 =C2=A0>>>>> was that the flow label randomization = feature should be opt-in instead > > >=C2=A0 =C2=A0 =C2=A0>>>>> of on by default. > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> So... where is the "source" of the pack= et that would be "modulating" the FL? > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> Thanks, > > >=C2=A0 =C2=A0 =C2=A0>>>> -- > > >=C2=A0 =C2=A0 =C2=A0>>>> Fernando Gont > > >=C2=A0 =C2=A0 =C2=A0>>>> e-mail: fernando@gont.com.ar > || fgont@si6networks.com > > > >=C2=A0 =C2=A0 =C2=A0>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1= C9 3945 96EE A9EF D076 FFF1 > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>> > > >=C2=A0 =C2=A0 =C2=A0>>> ________________________________________= _______ > > >=C2=A0 =C2=A0 =C2=A0>>> v6ops mailing list > > >=C2=A0 =C2=A0 =C2=A0>>> v6ops@ietf.org <= mailto:v6ops@ietf.org > > > >=C2=A0 =C2=A0 =C2=A0>>> https://www.ietf.org/mailman/listinfo/v6= ops > > >=C2=A0 =C2=A0 =C2=A0>>> > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > --=20 > Best regards, > Alexander Azimov From nobody Thu Nov 26 12:36:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C533A0D64; Thu, 26 Nov 2020 12:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68bCO_P2Ao9g; Thu, 26 Nov 2020 12:36:45 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643133A0B2D; Thu, 26 Nov 2020 12:36:45 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id h19so2879095otr.1; Thu, 26 Nov 2020 12:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sWGdLHcAR8etsExYzs670N+p1KTnMTLkY8Z+fzFhauE=; b=sQA9zaqveiAc4OxYR98OuVpk1txhAnk3+zlVDj2mSxjmQYnCipnPGm0AqYI851Omt1 EfDjXNkSh4QqDkjPBqrRu1/cQUwbqfn/SaDJgWPMt4CtgzJ+4R0kff5Stu+UUpTKcsBA fvmC2uh7pEV2GAODULkbkXP65uZ8FaaTmnir86+V4oV+LBsvD6KMgF+BFPFkeMITjNkF 1/zEkHw32/XNs99dt0DAzKTMp9cmiGM4jGay9ErlToLQYN0VUmTEs+p94xJ8PLTZXYM+ zSgidtPAbEzEyZEwZO5XZFohQZCYkphJ5MPjkSffZvl0+q78pfToGoqIzsvEPwwOTjrA OxpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sWGdLHcAR8etsExYzs670N+p1KTnMTLkY8Z+fzFhauE=; b=YgvqhuxZSmqLpTpvGeYjqNwk3MS0Jf0cctFuWw7KHwoAg52Gb6Vkqih6misnufUSgN je4iN0avqaAa6sGqKBZD6Ebzq5sq81EqO0Ry95OSbxAHXw2JgD6Dj7caU1aPn3SHDyVd OayxKcz05nmHnoRhw0B55FOOKdIhWhwBtZ1H8KXqkdFhyGwyE9X9JpgAM//HzuTqemf4 425z5y4wDFLRPflqss40JrV/gnSbxbRgSrw6Ga8FwPCZCMLmmRjS5VdgSw+qV7VssfBv Q+gyOrwzCS/NzWqkwSlTzQjK3hQ0z/ZrD8l7qmY+ASj1d8jE87L0GiYEtggaypnfi/CO IqeA== X-Gm-Message-State: AOAM532wRoVW7X8+/UpVCvQt/y9aTLTLrRwgVrQW7thZRRXWUJuf7iwj W+dO4vd779h/dcplmJL5KqDP658r90NlfBUr/m0= X-Google-Smtp-Source: ABdhPJworRl9dvv3KZByEiXhc2KOE102EhSQIm9Ij/0foxU77PRcrf1eX4x8RY3kN9BN+ucdqBmL6YLOf1ondo9xUI8= X-Received: by 2002:a9d:4c92:: with SMTP id m18mr3590603otf.248.1606423004656; Thu, 26 Nov 2020 12:36:44 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> In-Reply-To: From: Alexander Azimov Date: Thu, 26 Nov 2020 23:36:33 +0300 Message-ID: To: Brian E Carpenter Cc: Tom Herbert , tcpm , IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000008d395f05b5088044" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 20:36:49 -0000 --0000000000008d395f05b5088044 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, May I ask you to give more details on this issue: I am convinced that it is often unsafe, because that depends on exactly how > a server farm load balancer handles such cases. If it maintains the TCP > session on the same actual server if there is SYN(-ACK) retransmission, t= he > flow label must not be changed. If a retransmitted SYN goes to another server/anycast point this won't bring much harm. At least we haven't experienced such problems in our datacenters. =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 22:53, Brian= E Carpenter : > Alexander, > > > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be > recalculated. > ... > > The first point stands for redirecting connection from the degraded pat= h > before the connection is established, and it looks safe. > > I am convinced that it is often unsafe, because that depends on exactly > how a server farm load balancer handles such cases. If it maintains the T= CP > session on the same actual server if there is SYN(-ACK) retransmission, t= he > flow label must not be changed. > The benefit for possible broken routing is quite hypothetical, whereas th= e > risk to > session persistence at the server is real. (Remember that the source > cannot know by magic that there is server load balancing at the far end, > but it's the common case today.) > > > 2. In the case of RTO timeout expiration in the established TCP session > the flow label MAY be recalculated. This setting MUST be switched off by > default. > > As noted before, this is only safe in a limited domain where it is known > with certainty that server load balancing is not in use. I think it's > therefore a corner case and specifically, the appropriate normative > statement would be SHOULD NOT, which is defined very carefully in RFC2119 > exactly for this sort of case. > > But in fact I think we should not attempt to legislate on this point. The > value is marginal at best. As others have said, this is not the way to > tackle operational routing problems. > > Regards > Brian Carpenter > > On 26-Nov-20 22:34, Alexander Azimov wrote: > > Dear colleagues, > > > > We started discussing an incorrect default behavior, and Tom has alread= y > confirmed that it will be fixed. > > > > Later the thread turned into an argument if the flow label can be > changed during connection/flow lifetime according to current RFC document= s, > though these documents can be updated. This looks a bit weird for me > because I always thought that it is the IETF community's responsibility t= o > document proper solutions. If something undocumented but worthy happens i= n > the industry - IETF should catch up. So, I would like to get back to the > discussion of reasons and their safety. > > > > The general idea of changing the routing path upon network > outage/degradation looks obvious. Getting kind of source-based routing ca= n > significantly reduce the reaction time and improve end-user experience. T= he > flow label has a perfect match here: transparent for the application, set > by the source, not part of 5-tuple, while it can be used in the load > balancing. IMO poorly documented. I would like to learn your feedback for > the next wording: > > > > Let say that the flow label is a hash of values from the IP packet's > 5-tuple and random number. Then > > > > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be > recalculated. > > 2. In the case of RTO timeout expiration in the established TCP session > the flow label MAY be recalculated. This setting MUST be switched off by > default. > > 3. Otherwise flow label SHOULD be preserved unchanged. > > > > The first point stands for redirecting connection from the degraded pat= h > before the connection is established, and it looks safe. The second one c= an > also improve performance if it is set on the server-side. Please comment = if > you see security flaws in such a design. > > > > =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 03:16, T= om Herbert tom@herbertland.com>>: > > > > On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter > > > > wrote: > > > > > > I'm not Joel, but I did once spend some time grepping RFCs to fin= d > out whether > > > "flow" or "microflow" was the preferred term. In RFC2474, which i= s > normative, > > > we have: > > > > > > Microflow: a single instance of an application-to-application > flow of > > > packets which is identified by source address, destination > address, > > > protocol id, and source port, destination port (where > applicable). > > > > > > But in the flow label work we explicitly avoided being that > precise, and > > > did not use the term "microflow". There might be some load > balancing > > > scenarios where you want a broader definition, even including > bidirectional > > > flows. There are expired drafts on that topic: > > > draft-tarreau-extend-flow-label-balancing > > > draft-wang-6man-flow-label-reflection > > > > > Brian, > > > > Random Packet Spraying > > ( > https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.297.529&rep= =3Drep1&type=3Dpdf > ) > > is an interesting idea where packets for a single connection are > > purposely distributed across multiple paths for load distribution. > Per > > packet randomized flow labels with flow label aware ECMP makes this > > quite easy to do without requiring any special support in switches > > like you'd need with IPv4. I'm not necessarily advocating this, but > it > > does highlight one potential use case of having a flow label that > > doesn;t have rigidly defined requirements on the host. > > > > Tom > > > > > Regards > > > Brian > > > > > > On 26-Nov-20 11:13, Tom Herbert wrote: > > > > Joel, is there a normative definition of a flow? > > > > > > > > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halpern < > jmh@joelhalpern.com jmh@joelhalpern.com >> wrote: > > > > > > > > No, as Brian says, there are escape clauses in the flow > definitions. > > > > > > > > But changing the flow label due to traffic problems does no= t > correspond > > > > to packets being in actually different flows. > > > > If one were using UDP, and mixing loss sensitive packets > with loss > > > > insensitive packets for a special application, sure, one > could use two > > > > flow labels. But that is not what you are describing. > > > > > > > > Yours, > > > > Joel > > > > > > > > On 11/25/2020 3:05 PM, Tom Herbert wrote: > > > > > Joel, > > > > > > > > > > Is there an RFC that clearly and unambiguously states tha= t > a host MUST > > > > > use the same flow label for the lifetime _and_ clearly > defines exactly > > > > > what a flow is with respect to such a requirement (for > instance, how > > > > > would you define a flow and enforce such a requirement in > UDP? IPsec? > > > > > other encapsulations?). If there is such a requirement > then we'll > > > > > change the code to be conformant. > > > > > > > > > > Tom > > > > > > > > > > On Wed, Nov 25, 2020 at 12:39 PM Joel M. Halpern < > jmh@joelhalpern.com jmh@joelhalpern.com >> wrote: > > > > >> > > > > >> This kind of thing is why, as I understand it, MPTCP has > discovery > > > > >> mechanisms ot know if both sides use it, and can select > alternative > > > > >> addresses for communication. > > > > >> > > > > >> Trying to guess flow labels that might avoid a problem > because it might > > > > >> be an ECMP problem, is just flailing about. Not a good > design for > > > > >> operational protocols. > > > > >> > > > > >> And in general, designing protocols around "I know > exactly what is going > > > > >> on" (the requirement for what you describe that goes > well beyond just > > > > >> "limited domains") is also a recipe for failure. > > > > >> > > > > >> The Flow Label RFCs are actually very explicit that a > flow label is > > > > >> supposed to be stable for the life of the flow. > Otherwise, it isn't a > > > > >> flow label. > > > > >> > > > > >> Yours, > > > > >> Joel > > > > >> > > > > >> On 11/25/2020 2:35 PM, Tom Herbert wrote: > > > > >>> Hi Fernando, comments in line... > > > > >>> > > > > >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont < > fernando@gont.com.ar fernando@gont.com.ar >> wrote: > > > > >>>> > > > > >>>> Hi, Tom, > > > > >>>> > > > > >>>> On 24/11/20 16:43, Tom Herbert wrote: > > > > >>>> [....] > > > > >>>>> Modulating the flow label is a means to affect the > routing of packets > > > > >>>>> through the network that uses flow labels as input to > the ECMP hash. > > > > >>>> > > > > >>>> What's the point? > > > > >>>> > > > > >>>> 1) You cannot tell *if* the FL is being used. > > > > >>>> > > > > >>> Generally true, but in a limited domain this informatio= n > could be > > > > >>> discerned. I'd note that it's also generally true that > we don't know > > > > >>> if there is a load balancer or stateful firewall in the > path that > > > > >>> requires consistent routing, but in a limited domain we > could know > > > > >>> that also. > > > > >>> > > > > >>>> 2) Changing the FL does not necessarily mean that > packets will employ a > > > > >>>> different link. > > > > >>> > > > > >>> It's an opportunistic mechanism. If a connection is > failing and we get > > > > >>> a better path that fixes it by simply changing the flow > label then > > > > >>> what's the harm? > > > > >>> > > > > >>>> > > > > >>>> 3) If the network is failing, shouldn't you handle thi= s > via routing? > > > > >>>> > > > > >>> Sure, but then that requires an out of band feedback > loop from a TCP > > > > >>> implementation to the network infrastructure to indicat= e > there is a > > > > >>> problem and then the network needs to respond. That's > significant > > > > >>> infrastructure and higher reaction time than doing > something in TCP > > > > >>> and IP. Think of modulating the flow label is an > inexpensive form of > > > > >>> source routing within a limited domain that doesn't nee= d > any > > > > >>> infrastructure or heavyweight protocols or something > like segment > > > > >>> routing. > > > > >>> > > > > >>>> > > > > >>>> > > > > >>>>> The basic idea is that the flow label associated with > a connection is > > > > >>>>> randomly changed when the stack observes that the > connection is > > > > >>>>> failing (e.g. and an RTO). There is nothing in the > specs that prevents > > > > >>>>> this since the source is at liberty to set the flow > label as it sees > > > > >>>>> fit. > > > > >>>> > > > > >>>> The FL is expected to remain constant for the life of = a > flow. A > > > > >>>> retransmitted packet is part of the same flow as the > > > > >>>> originally-transmitted packet. So this seems to be > contradicting the > > > > >>>> very specification of the FL. > > > > >>>> > > > > >>>> For instance, If a RTO for a flow causes the FL to > change, then one may > > > > >>>> possibly argue that the FL is not naming/labeling what > is said/expected > > > > >>>> to be anming/labeling. > > > > >>> > > > > >>> Specifically, RFC6437 states: > > > > >>> > > > > >>> "It is therefore RECOMMENDED that source hosts support > the flow label > > > > >>> by setting the flow label field for all packets of a > given flow to the > > > > >>> same value chosen from an approximation to a discrete > uniform > > > > >>> distribution." > > > > >>> > > > > >>> So that is clearly a just recommendation, and not a > requirement (and > > > > >>> definitely not a MUST). Furthermore, RFC6437 states: > > > > >>> > > > > >>> "A forwarding node MUST either leave a non-zero flow > label value > > > > >>> unchanged or change it only for compelling operational > security > > > > >>> reasons as described in Section 6.1." > > > > >>> > > > > >>> So there's no guarantee in the protocol specs that flow > labels are > > > > >>> consistent for the life of the connection, which means > that the > > > > >>> network cannot assume that and thus it would be > incorrect if the > > > > >>> network tried to enforce flow label consistency as a > protocol > > > > >>> requirement. As I said, it is prudent to try to be > consistent with > > > > >>> flow labels and the default behavior in Linux should be > changed, > > > > >>> however I do not believe there's a valid claim of > non-conformance that > > > > >>> motivates removal of the feature that is already > deployed. > > > > >>> > > > > >>> Tom > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>> The feature is useful in large datacenter networks, > like > > > > >>>>> pparently Facebook where the patches originate, since > information > > > > >>>>> discerned by TCP can opportunistically be applied to > route selection. > > > > >>>>> The practical issue is that there are stateful device= s > like firewalls > > > > >>>>> that require consistent routing in the network in > which case changing > > > > >>>>> the flow label can confuse them. As I mentioned, the > original intent > > > > >>>>> was that the flow label randomization feature should > be opt-in instead > > > > >>>>> of on by default. > > > > >>>> > > > > >>>> So... where is the "source" of the packet that would b= e > "modulating" the FL? > > > > >>>> > > > > >>>> Thanks, > > > > >>>> -- > > > > >>>> Fernando Gont > > > > >>>> e-mail: fernando@gont.com.ar fernando@gont.com.ar> fernando@gont.com.ar>> || fgont@si6networks.com fgont@si6networks.com> fgont@si6networks.com>> > > > > >>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE > A9EF D076 FFF1 > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> v6ops mailing list > > > > >>> v6ops@ietf.org v6ops@ietf.org > > > > > >>> https://www.ietf.org/mailman/listinfo/v6ops > > > > >>> > > > > > > > > > > > > _______________________________________________ > > > > v6ops mailing list > > > > v6ops@ietf.org > > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > -- > > Best regards, > > Alexander Azimov > > --=20 Best regards, Alexander Azimov --0000000000008d395f05b5088044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

May I ask you to give more detai= ls on this issue:

I am convinced that it is often unsafe, because that depends o= n exactly how a server farm load balancer handles such cases. If it maintai= ns the TCP session on the same actual server if there is SYN(-ACK) retransm= ission, the flow label must not be changed.=C2=A0=C2=A0
If= a retransmitted SYN goes to another server/anycast point this won't br= ing much harm. At least we haven't experienced such problems in our dat= acenters.

=D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. = =D0=B2 22:53, Brian E Carpenter <brian.e.carpenter@gmail.com>:
Alexander,

> 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be r= ecalculated.
...
> The first point stands for redirecting connection from the degraded pa= th before the connection is established, and it looks safe.

I am convinced that it is often unsafe, because that depends on exactly how= a server farm load balancer handles such cases. If it maintains the TCP se= ssion on the same actual server if there is SYN(-ACK) retransmission, the f= low label must not be changed.
The benefit for possible broken routing is quite hypothetical, whereas the = risk to
session persistence at the server is real. (Remember that the source cannot= know by magic that there is server load balancing at the far end, but it&#= 39;s the common case today.)

> 2. In the case of RTO timeout expiration in the established TCP sessio= n the flow label MAY be recalculated. This setting MUST be switched off by = default.

As noted before, this is only safe in a limited domain where it is known wi= th certainty that server load balancing is not in use. I think it's the= refore a corner case and specifically, the appropriate normative statement = would be SHOULD NOT, which is defined very carefully in RFC2119 exactly for= this sort of case.

But in fact I think we should not attempt to legislate on this point. The v= alue is marginal at best. As others have said, this is not the way to tackl= e operational routing problems.

Regards
=C2=A0 =C2=A0Brian Carpenter

On 26-Nov-20 22:34, Alexander Azimov wrote:
> Dear colleagues,
>
> We started discussing an incorrect default behavior, and Tom has alrea= dy confirmed that it will be fixed.
>
> Later the thread turned into an argument if the flow label can be chan= ged during connection/flow lifetime according to current RFC documents, tho= ugh these documents can be updated. This looks a bit weird for me because I= always thought that it is the IETF community's responsibility to docum= ent proper solutions. If something undocumented but worthy happens in the i= ndustry - IETF should catch up. So, I would like to get back to the discuss= ion of reasons and their safety.
>
> The general idea of changing the routing path upon network outage/degr= adation looks obvious. Getting kind of source-based routing can significant= ly reduce the reaction time and improve end-user experience. The flow label= has a perfect match here: transparent for the application, set by the sour= ce, not part of 5-tuple, while it can be used in the load balancing. IMO po= orly documented. I would like to learn your feedback for the next wording:<= br> >
> Let say that the flow label is a hash of values from the IP packet'= ;s 5-tuple and random number. Then
>
> 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be r= ecalculated.
> 2. In the case of RTO timeout expiration in the established TCP sessio= n the flow label MAY be recalculated. This setting MUST be switched off by = default.
> 3. Otherwise flow label SHOULD be preserved unchanged.
>
> The first point stands for redirecting connection from the degraded pa= th before the connection is established, and it looks safe. The second one = can also improve performance if it is set on the server-side. Please commen= t if you see security flaws in such a design.
>
> =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 03:16, = Tom Herbert <to= m@herbertland.com <mailto:tom@herbertland.com>>:
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter >=C2=A0 =C2=A0 =C2=A0<brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.= com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I'm not Joel, but I did once spend some ti= me grepping RFCs to find out whether
>=C2=A0 =C2=A0 =C2=A0> "flow" or "microflow" was = the preferred term. In RFC2474, which is normative,
>=C2=A0 =C2=A0 =C2=A0> we have:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Microflow: a single instance of a= n application-to-application flow of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 packets which is identified by so= urce address, destination address,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 protocol id, and source port, des= tination port (where applicable).
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> But in the flow label work we explicitly avoid= ed being that precise, and
>=C2=A0 =C2=A0 =C2=A0> did not use the term "microflow". Th= ere might be some load balancing
>=C2=A0 =C2=A0 =C2=A0> scenarios where you want a broader definition,= even including bidirectional
>=C2=A0 =C2=A0 =C2=A0> flows. There are expired drafts on that topic:=
>=C2=A0 =C2=A0 =C2=A0> draft-tarreau-extend-flow-label-balancing
>=C2=A0 =C2=A0 =C2=A0> draft-wang-6man-flow-label-reflection
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0Brian,
>
>=C2=A0 =C2=A0 =C2=A0Random Packet Spraying
>=C2=A0 =C2=A0 =C2=A0(https://citeseerx.ist.psu.edu/viewdoc/download?doi=3D= 10.1.1.297.529&rep=3Drep1&type=3Dpdf)
>=C2=A0 =C2=A0 =C2=A0is an interesting idea where packets for a single c= onnection are
>=C2=A0 =C2=A0 =C2=A0purposely distributed across multiple paths for loa= d distribution. Per
>=C2=A0 =C2=A0 =C2=A0packet randomized flow labels with flow label aware= ECMP makes this
>=C2=A0 =C2=A0 =C2=A0quite easy to do without requiring any special supp= ort in switches
>=C2=A0 =C2=A0 =C2=A0like you'd need with IPv4. I'm not necessar= ily advocating this, but it
>=C2=A0 =C2=A0 =C2=A0does highlight one potential use case of having a f= low label that
>=C2=A0 =C2=A0 =C2=A0doesn;t have rigidly defined requirements on the ho= st.
>
>=C2=A0 =C2=A0 =C2=A0Tom
>
>=C2=A0 =C2=A0 =C2=A0> Regards
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Brian
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On 26-Nov-20 11:13, Tom Herbert wrote:
>=C2=A0 =C2=A0 =C2=A0> > Joel, is there a normative definition of = a flow?
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > On Wed, Nov 25, 2020, 1:27 PM Joel M. Hal= pern <jmh@joelh= alpern.com <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>&g= t;> wrote:
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0No, as Brian says, the= re are escape clauses in the flow definitions.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0But changing the flow = label due to traffic problems does not correspond
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0to packets being in ac= tually different flows.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0If one were using UDP,= and mixing loss sensitive packets with loss
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0insensitive packets fo= r a special application, sure, one could use two
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0flow labels.=C2=A0 But= that is not what you are describing.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0Joel
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0On 11/25/2020 3:05 PM,= Tom Herbert wrote:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Joel,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Is there an RFC t= hat clearly and unambiguously states that a host MUST
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> use the same flow= label for the lifetime _and_ clearly defines exactly
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> what a flow is wi= th respect to such a requirement (for instance, how
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> would you define = a flow and enforce such a requirement in UDP? IPsec?
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> other encapsulati= ons?). If there is such a requirement then we'll
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> change the code t= o be conformant.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Tom
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> On Wed, Nov 25, 2= 020 at 12:39 PM Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com= <mailto:jm= h@joelhalpern.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> This kind of = thing is why, as I understand it, MPTCP has discovery
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> mechanisms ot= know if both sides use it, and can select alternative
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> addresses for= communication.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> Trying to gue= ss flow labels that might avoid a problem because it might
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> be an ECMP pr= oblem, is just flailing about.=C2=A0 Not a good design for
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> operational p= rotocols.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> And in genera= l, designing protocols around "I know exactly what is going
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> on"=C2= =A0 (the requirement for what you describe that goes well beyond just
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> "limited= domains") is also a recipe for failure.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> The Flow Labe= l RFCs are actually very explicit that a flow label is
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> supposed to b= e stable for the life of the flow.=C2=A0 Otherwise, it isn't a
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> flow label. >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> Yours,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> Joel
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> On 11/25/2020= 2:35 PM, Tom Herbert wrote:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Hi Fernan= do, comments in line...
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> On Wed, N= ov 25, 2020 at 12:13 AM Fernando Gont <fernando@gont.com.ar <mailto:fernando@gont.com.ar> &l= t;mailto:fernando= @gont.com.ar <mailto:fernando@gont.com.ar>>> wrote:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> Hi, T= om,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> On 24= /11/20 16:43, Tom Herbert wrote:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> [....= ]
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> M= odulating the flow label is a means to affect the routing of packets
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> t= hrough the network that uses flow labels as input to the ECMP hash.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> What&= #39;s the point?
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> 1) Yo= u cannot tell *if* the FL is being used.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Generally= true, but in a limited domain this information could be
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> discerned= . I'd note that it's also generally true that we don't know
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> if there = is a load balancer or stateful firewall in the path that
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> requires = consistent routing, but in a limited domain we could know
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> that also= .
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> 2) Ch= anging the FL does not necessarily mean that packets will employ a
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> diffe= rent link.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> It's = an opportunistic mechanism. If a connection is failing and we get
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> a better = path that fixes it by simply changing the flow label then
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> what'= s the harm?
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> 3) If= the network is failing, shouldn't you handle this via routing?
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Sure, but= then that requires an out of band feedback loop from a TCP
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> implement= ation to the network infrastructure to indicate there is a
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> problem a= nd then the network needs to respond. That's significant
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> infrastru= cture and higher reaction time than doing something in TCP
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> and IP. T= hink of modulating the flow label is an inexpensive form of
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> source ro= uting within a limited domain that doesn't need any
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> infrastru= cture or heavyweight protocols or something like segment
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> routing.<= br> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> T= he basic idea is that the flow label associated with a connection is
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> r= andomly changed when the stack observes that the connection is
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> f= ailing (e.g. and an RTO). There is nothing in the specs that prevents
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> t= his since the source is at liberty to set the flow label as it sees
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> f= it.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> The F= L is expected to remain constant for the life of a flow. A
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> retra= nsmitted packet is part of the same flow as the
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> origi= nally-transmitted packet. So this seems to be contradicting the
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> very = specification of the FL.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> For i= nstance, If a RTO for a flow causes the FL to change, then one may
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> possi= bly argue that the FL is not naming/labeling what is said/expected
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> to be= anming/labeling.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Specifica= lly, RFC6437 states:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> "It = is therefore RECOMMENDED that source hosts support the flow label
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> by settin= g the flow label field for all packets of a given flow to the
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> same valu= e chosen from an approximation to a discrete uniform
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> distribut= ion."
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> So that i= s clearly a just recommendation, and not a requirement (and
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> definitel= y not a MUST). Furthermore, RFC6437 states:
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> "A f= orwarding node MUST either leave a non-zero flow label value
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> unchanged= or change it only for compelling operational security
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> reasons a= s described in Section 6.1."
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> So there&= #39;s no guarantee in the protocol specs that flow labels are
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> consisten= t for the life of the connection, which means that the
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> network c= annot assume that and thus it would be incorrect if the
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> network t= ried to enforce flow label consistency as a protocol
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> requireme= nt. As I said, it is prudent to try to be consistent with
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> flow labe= ls and the default behavior in Linux should be changed,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> however I= do not believe there's a valid claim of non-conformance that
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> motivates= removal of the feature that is already deployed.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Tom
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> T= he feature is useful in large datacenter networks, like
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> p= parently Facebook where the patches originate, since information
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> d= iscerned by TCP can opportunistically be applied to route selection.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> T= he practical issue is that there are stateful devices like firewalls
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> t= hat require consistent routing in the network in which case changing
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> t= he flow label can confuse them. As I mentioned, the original intent
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> w= as that the flow label randomization feature should be opt-in instead
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> o= f on by default.
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> So...= where is the "source" of the packet that would be "modulati= ng" the FL?
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> Thank= s,
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> -- >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> Ferna= ndo Gont
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> e-mai= l: fernando@gont.= com.ar <mailto:fernando@gont.com.ar> <mailto:fernando@gont.com.ar <mailto:fernando@gont.com.ar>= > || fgont@si= 6networks.com <mailto:fgont@si6networks.com> <mailto:fgont@si6networks.com <mailto:= fgont@si6network= s.com>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> PGP F= ingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> _________= ______________________________________
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> v6ops mai= ling list
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> v6ops@ietf.org <mailto:= v6ops@ietf.org> = <mailto:v6ops@ietf.o= rg <mailto:v6ops= @ietf.org>>
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> https://www.ietf.org/mailman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> > _________________________________________= ______
>=C2=A0 =C2=A0 =C2=A0> > v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0> > v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> > https://www.ietf.org/ma= ilman/listinfo/v6ops
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0v6ops mailing list
>=C2=A0 =C2=A0 =C2=A0v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list= info/v6ops
>
>
>
> --
> Best regards,
> Alexander Azimov



--
Best regards,
Alexander Azi= mov
--0000000000008d395f05b5088044-- From nobody Thu Nov 26 17:50:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A25C3A0F0C; Thu, 26 Nov 2020 17:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvzQ5EVJphLQ; Thu, 26 Nov 2020 17:50:43 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40ED3A0F09; Thu, 26 Nov 2020 17:50:42 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id b6so3087853pfp.7; Thu, 26 Nov 2020 17:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VRIc/uAp7ODSAwelFB8KJGjxlq6At3N43SFSJFknG7s=; b=fBTtyvxlK/Yd1K/UX9PIgGLxqEdD3RWH1FR2/nZWQb5FKw1JZxqSLJ7DiaVkzcpPUA hTpEdQnxJKjQsoG4Zd8CXiTFApnljmtOJrIJaGBPn5GTQyxREjIEwdHgVqSXNOSEirDD NfwEYNYDkILbB+E/Mydw2G4QnojQ4Zoo0pZzBfBaO4ZUVRQf+MsbD+Hqa29i9jmxxg6o Jhqy4iUxc3t/GEPiYbQcmRmgXl5NqSotjwOHF9bzYSRj4JLcE7o1YfdWe3PrJyD8wnZt 3e9pOvxA5zOyM1x9tW/1idxWrXuXIwpFgy3pv5vWtOM9kyO/awLul0dGJSSB1sMFJrsD jhhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VRIc/uAp7ODSAwelFB8KJGjxlq6At3N43SFSJFknG7s=; b=qpUA08okS+QMLl3De9cTob3t7SdgVUJxH9SYc+n/TM9qu//0gdyJ7xizNoM1E1ofsg m4YOvtdgDHQPzfVUxarE99r7Zv9rkauvaJ4RG4UdMaZwVENtbDtBx2rhll+c70py05xr +9OF/wXSb3yeKhSmF9Jc842fLvTRX+JegR38j1WTGe7RQhza2HNjWrCA85SYgyOESlHl lvGcDgDFiIB8ZaQ622YKWu4Lu0ov9TBrKYnJnObgFcf2EQwme6xBkhoRKFMA4GZUr7+o MwmyTzplAhiVGhdbmCGOmz2uXAnoBaTfcpcsPuZQMsR0+ylqQyHmZb8mzpY/xPx5/uo2 95VQ== X-Gm-Message-State: AOAM533CRUe7fxAojsd/+gVxFZjeCd7kHRn+dPlzq9Y9RYV/2u4a3+RX OmWOt8dWVOtyBec3y9QjqgVzga/0Q/A2ng== X-Google-Smtp-Source: ABdhPJxTTM27aqAL2+fOI9Tt3SW/Gl4n1SeqmljlXH+oG2jetqMGVE/sM16CjqIsyWuDrZS3qZqVyQ== X-Received: by 2002:a63:211:: with SMTP id 17mr4688968pgc.56.1606441841817; Thu, 26 Nov 2020 17:50:41 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id q14sm6020665pfl.163.2020.11.26.17.50.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Nov 2020 17:50:40 -0800 (PST) To: Alexander Azimov Cc: Tom Herbert , tcpm , IPv6 Operations References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Fri, 27 Nov 2020 14:50:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 01:50:48 -0000 On 27-Nov-20 09:36, Alexander Azimov wrote: > Brian, >=20 > May I ask you to give more details on this issue: >=20 > I am convinced that it is often unsafe, because that depends on exa= ctly how a server farm load balancer handles such cases. If it maintains = the TCP session on the same actual server if there is SYN(-ACK) retransmi= ssion, the flow label must not be changed.=C2=A0=C2=A0 >=20 > If a retransmitted SYN goes to another server/anycast point this won't = bring much harm. At least we haven't experienced such problems in our dat= acenters. I think depends on details that are definitively out of the IETF's scope.= When exactly does the load balancing system assign a session to a given = server, how much state does that create, what resources does it reserve, = and when are the state and the reserved resources released? Also, in some cases, I could imagine that the data centre will not see a = problem, but the client might see one that they would not otherwise have = seen. Again, it depends on details that are out of our scope. So I think = it's a topic that we should intentionally avoid. (Possibly it's a topic t= hat QUIC should consider, when they consider server load balancing in gen= eral.) Regards Brian >=20 > =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 22:53, B= rian E Carpenter >: >=20 > Alexander, >=20 > > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD= be recalculated. > ... > > The first point stands for redirecting connection from the degrad= ed path before the connection is established, and it looks safe. >=20 > I am convinced that it is often unsafe, because that depends on exa= ctly how a server farm load balancer handles such cases. If it maintains = the TCP session on the same actual server if there is SYN(-ACK) retransmi= ssion, the flow label must not be changed. > The benefit for possible broken routing is quite hypothetical, wher= eas the risk to > session persistence at the server is real. (Remember that the sourc= e cannot know by magic that there is server load balancing at the far end= , but it's the common case today.) >=20 > > 2. In the case of RTO timeout expiration in the established TCP s= ession the flow label MAY be recalculated. This setting MUST be switched = off by default. >=20 > As noted before, this is only safe in a limited domain where it is = known with certainty that server load balancing is not in use. I think it= 's therefore a corner case and specifically, the appropriate normative st= atement would be SHOULD NOT, which is defined very carefully in RFC2119 e= xactly for this sort of case. >=20 > But in fact I think we should not attempt to legislate on this poin= t. The value is marginal at best. As others have said, this is not the wa= y to tackle operational routing problems. >=20 > Regards > =C2=A0 =C2=A0Brian Carpenter >=20 > On 26-Nov-20 22:34, Alexander Azimov wrote: > > Dear colleagues, > > > > We started discussing an incorrect default behavior, and Tom has = already confirmed that it will be fixed. > > > > Later the thread turned into an argument if the flow label can be= changed during connection/flow lifetime according to current RFC documen= ts, though these documents can be updated. This looks a bit weird for me = because I always thought that it is the IETF community's responsibility t= o document proper solutions. If something undocumented but worthy happens= in the industry - IETF should catch up. So, I would like to get back to = the discussion of reasons and their safety. > > > > The general idea of changing the routing path upon network outage= /degradation looks obvious. Getting kind of source-based routing can sign= ificantly reduce the reaction time and improve end-user experience. The f= low label has a perfect match here: transparent for the application, set = by the source, not part of 5-tuple, while it can be used in the load bala= ncing. IMO poorly documented. I would like to learn your feedback for the= next wording: > > > > Let say that the flow label is a hash of values from the IP packe= t's 5-tuple and random number. Then > > > > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD= be recalculated. > > 2. In the case of RTO timeout expiration in the established TCP s= ession the flow label MAY be recalculated. This setting MUST be switched = off by default. > > 3. Otherwise flow label SHOULD be preserved unchanged. > > > > The first point stands for redirecting connection from the degrad= ed path before the connection is established, and it looks safe. The seco= nd one can also improve performance if it is set on the server-side. Plea= se comment if you see security flaws in such a design. > > > > =D1=87=D1=82, 26 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 03= :16, Tom Herbert >>: > > > >=C2=A0 =C2=A0 =C2=A0On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpen= ter > >=C2=A0 =C2=A0 =C2=A0 >> wrote: > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> I'm not Joel, but I did once spend some time= grepping RFCs to find out whether > >=C2=A0 =C2=A0 =C2=A0> "flow" or "microflow" was the preferred term= =2E In RFC2474, which is normative, > >=C2=A0 =C2=A0 =C2=A0> we have: > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Microflow: a single instance of= an application-to-application flow of > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 packets which is identified by = source address, destination address, > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 protocol id, and source port, d= estination port (where applicable). > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> But in the flow label work we explicitly avo= ided being that precise, and > >=C2=A0 =C2=A0 =C2=A0> did not use the term "microflow". There migh= t be some load balancing > >=C2=A0 =C2=A0 =C2=A0> scenarios where you want a broader definitio= n, even including bidirectional > >=C2=A0 =C2=A0 =C2=A0> flows. There are expired drafts on that topi= c: > >=C2=A0 =C2=A0 =C2=A0> draft-tarreau-extend-flow-label-balancing > >=C2=A0 =C2=A0 =C2=A0> draft-wang-6man-flow-label-reflection > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0Brian, > > > >=C2=A0 =C2=A0 =C2=A0Random Packet Spraying > >=C2=A0 =C2=A0 =C2=A0(https://citeseerx.ist.psu.edu/viewdoc/downloa= d?doi=3D10.1.1.297.529&rep=3Drep1&type=3Dpdf) > >=C2=A0 =C2=A0 =C2=A0is an interesting idea where packets for a sin= gle connection are > >=C2=A0 =C2=A0 =C2=A0purposely distributed across multiple paths fo= r load distribution. Per > >=C2=A0 =C2=A0 =C2=A0packet randomized flow labels with flow label = aware ECMP makes this > >=C2=A0 =C2=A0 =C2=A0quite easy to do without requiring any special= support in switches > >=C2=A0 =C2=A0 =C2=A0like you'd need with IPv4. I'm not necessarily= advocating this, but it > >=C2=A0 =C2=A0 =C2=A0does highlight one potential use case of havin= g a flow label that > >=C2=A0 =C2=A0 =C2=A0doesn;t have rigidly defined requirements on t= he host. > > > >=C2=A0 =C2=A0 =C2=A0Tom > > > >=C2=A0 =C2=A0 =C2=A0> Regards > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Brian > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> On 26-Nov-20 11:13, Tom Herbert wrote: > >=C2=A0 =C2=A0 =C2=A0> > Joel, is there a normative definition of a= flow? > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> > On Wed, Nov 25, 2020, 1:27 PM Joel M. Halp= ern > >>> wrote: > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0No, as Brian says, ther= e are escape clauses in the flow definitions. > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0But changing the flow l= abel due to traffic problems does not correspond > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0to packets being in act= ually different flows. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0If one were using UDP, = and mixing loss sensitive packets with loss > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0insensitive packets for= a special application, sure, one could use two > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0flow labels.=C2=A0 But = that is not what you are describing. > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0Yours, > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0Joel > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0On 11/25/2020 3:05 PM, = Tom Herbert wrote: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Joel, > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Is there an RFC that = clearly and unambiguously states that a host MUST > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> use the same flow lab= el for the lifetime _and_ clearly defines exactly > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> what a flow is with r= espect to such a requirement (for instance, how > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> would you define a fl= ow and enforce such a requirement in UDP? IPsec? > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> other encapsulations?= ). If there is such a requirement then we'll > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> change the code to be= conformant. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> Tom > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0> On Wed, Nov 25, 2020 = at 12:39 PM Joel M. Halpern > >>> wrote: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> This kind of thing i= s why, as I understand it, MPTCP has discovery > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> mechanisms ot know i= f both sides use it, and can select alternative > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> addresses for commun= ication. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> Trying to guess flow= labels that might avoid a problem because it might > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> be an ECMP problem, = is just flailing about.=C2=A0 Not a good design for > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> operational protocol= s. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> And in general, desi= gning protocols around "I know exactly what is going > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> on"=C2=A0 (the requi= rement for what you describe that goes well beyond just > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> "limited domains") i= s also a recipe for failure. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> The Flow Label RFCs = are actually very explicit that a flow label is > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> supposed to be stabl= e for the life of the flow.=C2=A0 Otherwise, it isn't a > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> flow label. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> Yours, > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> Joel > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>> On 11/25/2020 2:35 P= M, Tom Herbert wrote: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Hi Fernando, commen= ts in line... > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> On Wed, Nov 25, 202= 0 at 12:13 AM Fernando Gont > >>> wrote: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> Hi, Tom, > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> On 24/11/20 16:43,= Tom Herbert wrote: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> [....] > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> Modulating the fl= ow label is a means to affect the routing of packets > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> through the netwo= rk that uses flow labels as input to the ECMP hash. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> What's the point? > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> 1) You cannot tell= *if* the FL is being used. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Generally true, but= in a limited domain this information could be > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> discerned. I'd note= that it's also generally true that we don't know > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> if there is a load = balancer or stateful firewall in the path that > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> requires consistent= routing, but in a limited domain we could know > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> that also. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> 2) Changing the FL= does not necessarily mean that packets will employ a > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> different link. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> It's an opportunist= ic mechanism. If a connection is failing and we get > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> a better path that = fixes it by simply changing the flow label then > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> what's the harm? > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> 3) If the network = is failing, shouldn't you handle this via routing? > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Sure, but then that= requires an out of band feedback loop from a TCP > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> implementation to t= he network infrastructure to indicate there is a > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> problem and then th= e network needs to respond. That's significant > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> infrastructure and = higher reaction time than doing something in TCP > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> and IP. Think of mo= dulating the flow label is an inexpensive form of > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> source routing with= in a limited domain that doesn't need any > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> infrastructure or h= eavyweight protocols or something like segment > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> routing. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> The basic idea is= that the flow label associated with a connection is > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> randomly changed = when the stack observes that the connection is > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> failing (e.g. and= an RTO). There is nothing in the specs that prevents > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> this since the so= urce is at liberty to set the flow label as it sees > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> fit. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> The FL is expected= to remain constant for the life of a flow. A > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> retransmitted pack= et is part of the same flow as the > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> originally-transmi= tted packet. So this seems to be contradicting the > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> very specification= of the FL. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> For instance, If a= RTO for a flow causes the FL to change, then one may > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> possibly argue tha= t the FL is not naming/labeling what is said/expected > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> to be anming/label= ing. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Specifically, RFC64= 37 states: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> "It is therefore RE= COMMENDED that source hosts support the flow label > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> by setting the flow= label field for all packets of a given flow to the > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> same value chosen f= rom an approximation to a discrete uniform > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> distribution." > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> So that is clearly = a just recommendation, and not a requirement (and > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> definitely not a MU= ST). Furthermore, RFC6437 states: > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> "A forwarding node = MUST either leave a non-zero flow label value > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> unchanged or change= it only for compelling operational security > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> reasons as describe= d in Section 6.1." > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> So there's no guara= ntee in the protocol specs that flow labels are > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> consistent for the = life of the connection, which means that the > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> network cannot assu= me that and thus it would be incorrect if the > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> network tried to en= force flow label consistency as a protocol > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> requirement. As I s= aid, it is prudent to try to be consistent with > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> flow labels and the= default behavior in Linux should be changed, > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> however I do not be= lieve there's a valid claim of non-conformance that > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> motivates removal o= f the feature that is already deployed. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> Tom > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> The feature is us= eful in large datacenter networks, like > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> pparently Faceboo= k where the patches originate, since information > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> discerned by TCP = can opportunistically be applied to route selection. > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> The practical iss= ue is that there are stateful devices like firewalls > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> that require cons= istent routing in the network in which case changing > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> the flow label ca= n confuse them. As I mentioned, the original intent > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> was that the flow= label randomization feature should be opt-in instead > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>>> of on by default.= > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> So... where is the= "source" of the packet that would be "modulating" the FL? > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> Thanks, > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> -- > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> Fernando Gont > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> e-mail: fernando@g= ont.com.ar > >= > || fgont@si6networks.com > >> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> PGP Fingerprint: 7= 809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> ___________________= ____________________________ > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> v6ops mailing list > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> v6ops@ietf.org > >> > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> https://www.ietf.or= g/mailman/listinfo/v6ops > >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> > __________________________________________= _____ > >=C2=A0 =C2=A0 =C2=A0> > v6ops mailing list > >=C2=A0 =C2=A0 =C2=A0> > v6ops@ietf.org > > >=C2=A0 =C2=A0 =C2=A0> > https://www.ietf.org/mailman/listinfo/v6op= s > >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0> > > > >=C2=A0 =C2=A0 =C2=A0______________________________________________= _ > >=C2=A0 =C2=A0 =C2=A0v6ops mailing list > >=C2=A0 =C2=A0 =C2=A0v6ops@ietf.org > > >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > -- > > Best regards, > > Alexander Azimov >=20 >=20 >=20 > --=20 > Best regards, > Alexander Azimov From nobody Fri Nov 27 12:42:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D83A0E87; Fri, 27 Nov 2020 12:42:03 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 BC9DmJ34equ1; Fri, 27 Nov 2020 12:42:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955643A0E84; Fri, 27 Nov 2020 12:41:57 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3C33C283BC9; Fri, 27 Nov 2020 20:41:52 +0000 (UTC) To: Tom Herbert Cc: Alexander Azimov , tcpm , IPv6 Operations References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> From: Fernando Gont Message-ID: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> Date: Fri, 27 Nov 2020 17:41:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 20:42:03 -0000 Hello, Tom, On 25/11/20 16:35, Tom Herbert wrote: > Hi Fernando, comments in line... > > On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: >> >> Hi, Tom, >> >> On 24/11/20 16:43, Tom Herbert wrote: >> [....] >>> Modulating the flow label is a means to affect the routing of packets >>> through the network that uses flow labels as input to the ECMP hash. >> >> What's the point? >> >> 1) You cannot tell *if* the FL is being used. >> > Generally true, but in a limited domain this information could be > discerned. I'd note that it's also generally true that we don't know > if there is a load balancer or stateful firewall in the path that > requires consistent routing, but in a limited domain we could know > that also. Exactly. So my take is that the drawbacks for the general case outweigh the benefits of the specific case. >> 2) Changing the FL does not necessarily mean that packets will employ a >> different link. > > It's an opportunistic mechanism. If a connection is failing and we get > a better path that fixes it by simply changing the flow label then > what's the harm? Complexity, and the possible negative implications for the general case. That said, why don't you fix the problem where you should (i.e., routing)? >> 3) If the network is failing, shouldn't you handle this via routing? >> > Sure, but then that requires an out of band feedback loop from a TCP > implementation to the network infrastructure to indicate there is a > problem and then the network needs to respond. Not really. TCP does not deal with paths (not should it). If the network detects a link is failing, it should route around the problem. > That's significant > infrastructure and higher reaction time than doing something in TCP > and IP. Think of modulating the flow label is an inexpensive form of > source routing within a limited domain that doesn't need any > infrastructure or heavyweight protocols or something like segment > routing. Downsides: * It breaks load balancing * It depends on the source doing something -- but you don't necessarily control the source -- and you cannot tell if the source implements it * It doesn't solve the problem for nodes that do not behave as expected My take is that if you really care about this, you're already (or should!) be solving the problem in a different (and more general) way. >>> The basic idea is that the flow label associated with a connection is >>> randomly changed when the stack observes that the connection is >>> failing (e.g. and an RTO). There is nothing in the specs that prevents >>> this since the source is at liberty to set the flow label as it sees >>> fit. >> >> The FL is expected to remain constant for the life of a flow. A >> retransmitted packet is part of the same flow as the >> originally-transmitted packet. So this seems to be contradicting the >> very specification of the FL. >> >> For instance, If a RTO for a flow causes the FL to change, then one may >> possibly argue that the FL is not naming/labeling what is said/expected >> to be anming/labeling. > > Specifically, RFC6437 states: > > "It is therefore RECOMMENDED that source hosts support the flow label > by setting the flow label field for all packets of a given flow to the > same value chosen from an approximation to a discrete uniform > distribution." > > So that is clearly a just recommendation, and not a requirement (and > definitely not a MUST). Furthermore, RFC6437 states: > > "A forwarding node MUST either leave a non-zero flow label value > unchanged or change it only for compelling operational security > reasons as described in Section 6.1." My concern is that we may leave the FL unusable. > So there's no guarantee in the protocol specs that flow labels are > consistent for the life of the connection, which means that the > network cannot assume that and thus it would be incorrect if the > network tried to enforce flow label consistency as a protocol > requirement. You're probably right in that respect. And, in retrospective, I think it would have been better if we had specified the FL to be unmutable. > As I said, it is prudent to try to be consistent with > flow labels and the default behavior in Linux should be changed, Sorry: is the current Linux behavior to modulate the FL? > however I do not believe there's a valid claim of non-conformance that > motivates removal of the feature that is already deployed. I personally consider the changing the FL for a flow to be a bug. That said, if the default setting is the correct/compliant behavior, at the end of the day we're all adults, and whoever overrides the default behavior is supposed to know what he/she does -- and if they don't, they get what they deserve ;-) So, in that light, I wouldn't push to remove the optional behavior, *provided* the default behavior is correct. 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 Fri Nov 27 12:47:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924C3A0E8C; Fri, 27 Nov 2020 12:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=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 O7Oq7HXekToy; Fri, 27 Nov 2020 12:47:36 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC083A0E87; Fri, 27 Nov 2020 12:47:35 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A8F92283BC9; Fri, 27 Nov 2020 20:47:32 +0000 (UTC) To: Tom Herbert , Brian E Carpenter Cc: tcpm , IPv6 Operations References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Fernando Gont Message-ID: Date: Fri, 27 Nov 2020 17:47:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 20:47:38 -0000 Tom, On 25/11/20 21:15, Tom Herbert wrote: > On Wed, Nov 25, 2020 at 3:33 PM Brian E Carpenter > wrote: >> >> I'm not Joel, but I did once spend some time grepping RFCs to find out whether >> "flow" or "microflow" was the preferred term. In RFC2474, which is normative, >> we have: >> >> Microflow: a single instance of an application-to-application flow of >> packets which is identified by source address, destination address, >> protocol id, and source port, destination port (where applicable). >> >> But in the flow label work we explicitly avoided being that precise, and >> did not use the term "microflow". There might be some load balancing >> scenarios where you want a broader definition, even including bidirectional >> flows. There are expired drafts on that topic: >> draft-tarreau-extend-flow-label-balancing >> draft-wang-6man-flow-label-reflection >> > Brian, > > Random Packet Spraying > (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.297.529&rep=rep1&type=pdf) > is an interesting idea where packets for a single connection are > purposely distributed across multiple paths for load distribution. Per > packet randomized flow labels with flow label aware ECMP makes this > quite easy to do without requiring any special support in switches > like you'd need with IPv4. I'm not necessarily advocating this, but it > does highlight one potential use case of having a flow label that > doesn;t have rigidly defined requirements on the host. You don't need to randomize the FL of packets corresponding to a flow to get this --- simply do round-robin at the router that wants load-sharing over different links. OTOH, if you do randomize the FL of each packet, then routers that want to avoid packet reordering simply can'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 Fri Nov 27 12:52:28 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B083A0E8B; Fri, 27 Nov 2020 12:52:26 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 w4JRSMgJeH_P; Fri, 27 Nov 2020 12:52:24 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB773A0DB2; Fri, 27 Nov 2020 12:52:24 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5DB63283BC9; Fri, 27 Nov 2020 20:52:21 +0000 (UTC) To: Alexander Azimov , Tom Herbert Cc: IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <239c4b67-1d9a-da00-7bb0-52019be1b7c1@joelhalpern.com> From: Fernando Gont Message-ID: <5cb3b43e-913f-d6cd-f7e2-192f14daf4c2@gont.com.ar> Date: Fri, 27 Nov 2020 17:52:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 20:52:27 -0000 On 26/11/20 06:34, Alexander Azimov wrote: > Dear colleagues, > > We started discussing an incorrect default behavior, and Tom has already > confirmed that it will be fixed. > > Later the thread turned into an argument if the flow label can be > changed during connection/flow lifetime according to current RFC > documents, though these documents can be updated. This looks a bit weird > for me because I always thought that it is the IETF community's > responsibility to document proper solutions. If something undocumented > but worthy happens in the industry - IETF should catch up. So, I would > like to get back to the discussion of reasons and their safety. > > The general idea of changing the routing path upon network > outage/degradation looks obvious. Getting kind of source-based routing > can significantly reduce the reaction time and improve end-user > experience. The flow label has a perfect match here: transparent for the > application, set by the source, not part of 5-tuple, while it can be > used in the load balancing. If you have two links, then, upon change of the FL, you have 50% change that the path will be different -- not good. What would you do if the failure continues? -- keep changing the FL? > Let say that the flow label is a hash of values from the IP packet's > 5-tuple and random number. Then > > 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be > recalculated. This one MUST be switched of by default, too. (along with #2). > 2. In the case of RTO timeout expiration in the established TCP session > the flow label MAY be recalculated. This setting MUST be switched off by > default. > 3. Otherwise flow label SHOULD be preserved unchanged. > > The first point stands for redirecting connection from the degraded path > before the connection is established, and it looks safe. The second one > can also improve performance if it is set on the server-side. Please > comment if you see security flaws in such a design. At the very least, one should analyze the case where in #1, a packet gets delayed, you change the FL and retransmit, and finally you get a response to the original packet (and/or to both packets). 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 Fri Nov 27 15:31:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2F53A03C9 for ; Fri, 27 Nov 2020 15:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v6bqEeDmxuR for ; Fri, 27 Nov 2020 15:31:51 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63ADE3A0365 for ; Fri, 27 Nov 2020 15:31:51 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id y4so7256510edy.5 for ; Fri, 27 Nov 2020 15:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KHVcGF66BJ6131S4PRwX4pt0p5yKDCntZmdun1QTP5M=; b=mKwTKQTn6zil88N7l1F7J3cF+4dM+MN17z4N/yEcbwYwoaanjnzBDtrl0xIo/4BVCt a0CnB3ACIDyLbdewD6UQ+mg5g9l2mizdJ5Ouj4UlgCzCrZTOuF1D7ipQKeDCSxC7TKnf JcMTO1/2oCTPWOZljZjSbREwstus6i6fwryq7d5Rfr3PMv++XHm5zUKNb+xuxcpw3Fwv DcIDd8+aUVosbHz78rf6GAR91ctIgZRavh0NEEvtXO4VxJbmm/CNEpOaKxoUb1wP+tDU fivBSK3JRTz1QkGcqj8OIZqFBNHLl5qGswSkS+ZX3rhecU0jZCX+jayiN17We29eXOOH FD5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KHVcGF66BJ6131S4PRwX4pt0p5yKDCntZmdun1QTP5M=; b=I3KT8eZhkxP+icSgb9wA+F9NJ9B5SSKuvYLFfEJ3U+7N4reVVt00/LV69+PN/Twioh EI5qwtSx0JNylGt1CNX8e/xnt3QZOXgM4QN0TTBveJ+PT2//p0nnQEgB15UI8IVCRMEQ QiXMrfRWPziUG2JakC7sH+kyspJFTVGzMQ4sq0qa8URTDbQ6zH0ByDO3cj1xnKvTKVOM qnOe2u9fd7W05llV5vtRgcOmbPXn3hv0cAyrSYJYwKNVfj++Wt7jV43EP6Eqq4e4bOPh NNQlz9SbstM2k48DeQC/3rf+Anwqgk4zEKzJ+nU8S4bUd3VzIKGkDkmfxLW/0vGn70OP 7ujQ== X-Gm-Message-State: AOAM531yaEKps1HSc0V3Aam8CI0dsMHZEiUVtcZKqkDZsnp9l3MaokVB pY2j6k76oYAfQvR887z11kQb3mKP/lxW4bhkeXQ0IQ== X-Google-Smtp-Source: ABdhPJx8PFZFGZ5tLxeT6YigWlaxceNYqyBlTdoN2FKAzW/VOcBIJEY8PTEJJAs3PVCO46/h4A8r3grp9WeRTWnUxAM= X-Received: by 2002:a50:c050:: with SMTP id u16mr10447493edd.177.1606519909574; Fri, 27 Nov 2020 15:31:49 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> In-Reply-To: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> From: Tom Herbert Date: Fri, 27 Nov 2020 16:31:38 -0700 Message-ID: To: Fernando Gont Cc: Alexander Azimov , tcpm , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 23:31:53 -0000 On Fri, Nov 27, 2020 at 1:41 PM Fernando Gont wrote: > > Hello, Tom, > > On 25/11/20 16:35, Tom Herbert wrote: > > Hi Fernando, comments in line... > > > > On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont wrote: > >> > >> Hi, Tom, > >> > >> On 24/11/20 16:43, Tom Herbert wrote: > >> [....] > >>> Modulating the flow label is a means to affect the routing of packets > >>> through the network that uses flow labels as input to the ECMP hash. > >> > >> What's the point? > >> > >> 1) You cannot tell *if* the FL is being used. > >> > > Generally true, but in a limited domain this information could be > > discerned. I'd note that it's also generally true that we don't know > > if there is a load balancer or stateful firewall in the path that > > requires consistent routing, but in a limited domain we could know > > that also. > > Exactly. So my take is that the drawbacks for the general case outweigh > the benefits of the specific case. > > > > >> 2) Changing the FL does not necessarily mean that packets will employ a > >> different link. > > > > It's an opportunistic mechanism. If a connection is failing and we get > > a better path that fixes it by simply changing the flow label then > > what's the harm? > > Complexity, and the possible negative implications for the general case. > > That said, why don't you fix the problem where you should (i.e., routing)? > > > > >> 3) If the network is failing, shouldn't you handle this via routing? > >> > > Sure, but then that requires an out of band feedback loop from a TCP > > implementation to the network infrastructure to indicate there is a > > problem and then the network needs to respond. > > Not really. TCP does not deal with paths (not should it). If the network > detects a link is failing, it should route around the problem. > Fernando, All we know in this case is that *TCP* has detected a connection is failing and there may be a potential problem with a path, we don't know that the network has detected any problems like some link is failing or will ever detect any problem. So in such a scenario, what recourse does the host have to try to salvage its connections? If the answer is that the host should always patiently wait for the network to figure out what is happening, then that's going to be a hard sell to application and host stack developers (remember the network is a black box from their perspective that they really don't trust). If the answer is that the host is supposed to inform the network of issues with it's connections and then host and network work together to solve then that's great; but then what is the general protocol that has been established to facilitate that and solved the problem of how hosts and network work together in concert to solve user's problems? Tom > > > > That's significant > > infrastructure and higher reaction time than doing something in TCP > > and IP. Think of modulating the flow label is an inexpensive form of > > source routing within a limited domain that doesn't need any > > infrastructure or heavyweight protocols or something like segment > > routing. > > Downsides: > > * It breaks load balancing > * It depends on the source doing something -- but you don't necessarily > control the source -- and you cannot tell if the source implements it > * It doesn't solve the problem for nodes that do not behave as expected > > My take is that if you really care about this, you're already (or > should!) be solving the problem in a different (and more general) way. > > > > >>> The basic idea is that the flow label associated with a connection is > >>> randomly changed when the stack observes that the connection is > >>> failing (e.g. and an RTO). There is nothing in the specs that prevents > >>> this since the source is at liberty to set the flow label as it sees > >>> fit. > >> > >> The FL is expected to remain constant for the life of a flow. A > >> retransmitted packet is part of the same flow as the > >> originally-transmitted packet. So this seems to be contradicting the > >> very specification of the FL. > >> > >> For instance, If a RTO for a flow causes the FL to change, then one may > >> possibly argue that the FL is not naming/labeling what is said/expected > >> to be anming/labeling. > > > > Specifically, RFC6437 states: > > > > "It is therefore RECOMMENDED that source hosts support the flow label > > by setting the flow label field for all packets of a given flow to the > > same value chosen from an approximation to a discrete uniform > > distribution." > > > > So that is clearly a just recommendation, and not a requirement (and > > definitely not a MUST). Furthermore, RFC6437 states: > > > > "A forwarding node MUST either leave a non-zero flow label value > > unchanged or change it only for compelling operational security > > reasons as described in Section 6.1." > > My concern is that we may leave the FL unusable. > > > > > > So there's no guarantee in the protocol specs that flow labels are > > consistent for the life of the connection, which means that the > > network cannot assume that and thus it would be incorrect if the > > network tried to enforce flow label consistency as a protocol > > requirement. > > You're probably right in that respect. And, in retrospective, I think it > would have been better if we had specified the FL to be unmutable. > > > > > As I said, it is prudent to try to be consistent with > > flow labels and the default behavior in Linux should be changed, > > Sorry: is the current Linux behavior to modulate the FL? > > > > however I do not believe there's a valid claim of non-conformance that > > motivates removal of the feature that is already deployed. > > I personally consider the changing the FL for a flow to be a bug. That > said, if the default setting is the correct/compliant behavior, at the > end of the day we're all adults, and whoever overrides the default > behavior is supposed to know what he/she does -- and if they don't, they > get what they deserve ;-) > > So, in that light, I wouldn't push to remove the optional behavior, > *provided* the default behavior is correct. > > 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 Fri Nov 27 16:32:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068923A091C; Fri, 27 Nov 2020 16:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACLvHYowSiE4; Fri, 27 Nov 2020 16:32:28 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE713A080A; Fri, 27 Nov 2020 16:32:28 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id n11so6114479ota.2; Fri, 27 Nov 2020 16:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lJdZkoENN4nHZDUXLR5mmCBIff5HJLIMuuKUOEUIh+I=; b=WbNVCEw1fSUZdoKYBMhCwKTSJ+iqlluGp0e506Kzgz61XEg1lrUaUIMp2NAQNw2/hA EGtg7eDH3j6N0IXPHPd5FjKMfiWMVdTmxhDkEBA7OliBM5bsjJqs4sRqJ/biPrHnqLg5 Jyhy0HORHn/UHy2yQrvCEk5UcBH65kga4esUPJ5f2HMVKF1v7u7uHHRN/689AG/3Nkr9 GjDtQJjboJ9iu/o0WvllGmzMW7qWTx+tiC67nF945A09Q6SDeWw5bJWDzow4oc9nBbnY 4SF4WO803RbsLKh3nKOzYhuYZnmJoUXsmrudNfRhsoJvbSn4e074Zu4hAFjw+xwfq1UF IBXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lJdZkoENN4nHZDUXLR5mmCBIff5HJLIMuuKUOEUIh+I=; b=dtuvatoQIWmHViF5+riOuaPUthzMFEEjQhwUE2u8+Fp/Q5r2+FFhAnx1PLd/IKKDD1 XUY6v4fpBPg2OQ9Zc6DFPVXct099nWda6q0BkUL7PNTrp8nRp+o7hDuDTRIarbviHdin szl+WuQwZOT9RsqAf98AHH5AbJBeiDCsNACfewzXPwM73xOpoqaxblXs7C6bqEghmWa3 qvNmJFgD5q79uH7o583VsgYGJ6pIGnwn1WwviN6cq/vJtm5r7DXiV8s4DceJjGxTHfzq r9Gzpc95vf97oCr/FqEUUxhat+V17gHiUfa0pYpPZZBXpMHCrrQ1PAha1gPLT48tktG8 YNbw== X-Gm-Message-State: AOAM532C7/sQcjpViDADVpqsbctg605Q1j47Rb3zXBTK929gcDipa25D dGhC2QjJCK1VNqdl4WSZqGxdKElBnicUKeoUAU3MS+3v X-Google-Smtp-Source: ABdhPJxsW03VUVHB6PEpJ9nomQfw1NCSK+HtRHkkAqswTeprA5JEUWIG9lS/kR8YLk8qkhDTp1svTR5liCovaSrreUQ= X-Received: by 2002:a05:6830:160d:: with SMTP id g13mr8680090otr.74.1606523547462; Fri, 27 Nov 2020 16:32:27 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> In-Reply-To: From: Mark Smith Date: Sat, 28 Nov 2020 11:32:14 +1100 Message-ID: To: Tom Herbert Cc: Fernando Gont , IPv6 Operations , tcpm Content-Type: multipart/alternative; boundary="0000000000005eae5b05b51fe993" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 00:32:31 -0000 --0000000000005eae5b05b51fe993 Content-Type: text/plain; charset="UTF-8" On Sat, 28 Nov 2020, 10:32 Tom Herbert, wrote: > On Fri, Nov 27, 2020 at 1:41 PM Fernando Gont > wrote: > > > > Hello, Tom, > > > > On 25/11/20 16:35, Tom Herbert wrote: > > > Hi Fernando, comments in line... > > > > > > On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont > wrote: > > >> > > >> Hi, Tom, > > >> > > >> On 24/11/20 16:43, Tom Herbert wrote: > > >> [....] > > >>> Modulating the flow label is a means to affect the routing of packets > > >>> through the network that uses flow labels as input to the ECMP hash. > > >> > > >> What's the point? > > >> > > >> 1) You cannot tell *if* the FL is being used. > > >> > > > Generally true, but in a limited domain this information could be > > > discerned. I'd note that it's also generally true that we don't know > > > if there is a load balancer or stateful firewall in the path that > > > requires consistent routing, but in a limited domain we could know > > > that also. > > > > Exactly. So my take is that the drawbacks for the general case outweigh > > the benefits of the specific case. > > > > > > > > >> 2) Changing the FL does not necessarily mean that packets will employ > a > > >> different link. > > > > > > It's an opportunistic mechanism. If a connection is failing and we get > > > a better path that fixes it by simply changing the flow label then > > > what's the harm? > > > > Complexity, and the possible negative implications for the general case. > > > > That said, why don't you fix the problem where you should (i.e., > routing)? > > > > > > > > >> 3) If the network is failing, shouldn't you handle this via routing? > > >> > > > Sure, but then that requires an out of band feedback loop from a TCP > > > implementation to the network infrastructure to indicate there is a > > > problem and then the network needs to respond. > > > > Not really. TCP does not deal with paths (not should it). If the network > > detects a link is failing, it should route around the problem. > > > > Fernando, > > All we know in this case is that *TCP* has detected a connection is > failing and there may be a potential problem with a path, we don't > know that the network has detected any problems like some link is > failing or will ever detect any problem. So in such a scenario, what > recourse does the host have to try to salvage its connections? Retransmit their packets, let the network take care of trying to deliver them again. If the > answer is that the host should always patiently wait for the network > to figure out what is happening, Yes. Steering packets is the network's job. People like me who run the network expect to be in charge of that. We have fancy mechanisms that mean alternate paths are switched to very quickly. The trouble with having two parties trying to solve the same problem at the same time without coordination is they're just as likely to work against each other as they are inadvertently to work with each other. If hosts want the network to respect the flow label, then hosts need to ensure that the a flow label value for a flow of packets with the same source and destination address consistently represents a flow. If hosts start trying to take control of steering traffic by varying the flow label value within a flow, making the network's job harder, and the network being blamed for the possibility bad network performance that may result, the response will be both quick and easy - network operators will switch off looking the Flow Label. The Flow Label is the IPv6 header analogue for transport layer protocol ports, so that load balancing mechanisms don't have to dig further into the packet. Can or are transport layer ports varied in TCP SYNs, SYN/ACKs and ACKs within the same TCP connection? then that's going to be a hard sell > to application and host stack developers (remember the network is a > black box from their perspective that they really don't trust). If the > answer is that the host is supposed to inform the network of issues > with it's connections and then host and network work together to solve > then that's great; but then what is the general protocol that has been > established to facilitate that and solved the problem of how hosts and > network work together in concert to solve user's problems? > > Tom > > > > > > > > That's significant > > > infrastructure and higher reaction time than doing something in TCP > > > and IP. Think of modulating the flow label is an inexpensive form of > > > source routing within a limited domain that doesn't need any > > > infrastructure or heavyweight protocols or something like segment > > > routing. > > > > Downsides: > > > > * It breaks load balancing > > * It depends on the source doing something -- but you don't necessarily > > control the source -- and you cannot tell if the source implements it > > * It doesn't solve the problem for nodes that do not behave as expected > > > > My take is that if you really care about this, you're already (or > > should!) be solving the problem in a different (and more general) way. > > > > > > > > >>> The basic idea is that the flow label associated with a connection is > > >>> randomly changed when the stack observes that the connection is > > >>> failing (e.g. and an RTO). There is nothing in the specs that > prevents > > >>> this since the source is at liberty to set the flow label as it sees > > >>> fit. > > >> > > >> The FL is expected to remain constant for the life of a flow. A > > >> retransmitted packet is part of the same flow as the > > >> originally-transmitted packet. So this seems to be contradicting the > > >> very specification of the FL. > > >> > > >> For instance, If a RTO for a flow causes the FL to change, then one > may > > >> possibly argue that the FL is not naming/labeling what is > said/expected > > >> to be anming/labeling. > > > > > > Specifically, RFC6437 states: > > > > > > "It is therefore RECOMMENDED that source hosts support the flow label > > > by setting the flow label field for all packets of a given flow to the > > > same value chosen from an approximation to a discrete uniform > > > distribution." > > > > > > So that is clearly a just recommendation, and not a requirement (and > > > definitely not a MUST). Furthermore, RFC6437 states: > > > > > > "A forwarding node MUST either leave a non-zero flow label value > > > unchanged or change it only for compelling operational security > > > reasons as described in Section 6.1." > > > > My concern is that we may leave the FL unusable. > > > > > > > > > > > So there's no guarantee in the protocol specs that flow labels are > > > consistent for the life of the connection, which means that the > > > network cannot assume that and thus it would be incorrect if the > > > network tried to enforce flow label consistency as a protocol > > > requirement. > > > > You're probably right in that respect. And, in retrospective, I think it > > would have been better if we had specified the FL to be unmutable. > > > > > > > > > As I said, it is prudent to try to be consistent with > > > flow labels and the default behavior in Linux should be changed, > > > > Sorry: is the current Linux behavior to modulate the FL? > > > > > > > however I do not believe there's a valid claim of non-conformance that > > > motivates removal of the feature that is already deployed. > > > > I personally consider the changing the FL for a flow to be a bug. That > > said, if the default setting is the correct/compliant behavior, at the > > end of the day we're all adults, and whoever overrides the default > > behavior is supposed to know what he/she does -- and if they don't, they > > get what they deserve ;-) > > > > So, in that light, I wouldn't push to remove the optional behavior, > > *provided* the default behavior is correct. > > > > Thanks, > > -- > > 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 > --0000000000005eae5b05b51fe993 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 28 Nov 2020, 10:32 Tom Herbert, <tom@herbe= rtland.com> wrote:
On Fri, = Nov 27, 2020 at 1:41 PM Fernando Gont <fernando@gont.com.ar= > wrote:
>
> Hello, Tom,
>
> On 25/11/20 16:35, Tom Herbert wrote:
> > Hi Fernando, comments in line...
> >
> > On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont <f= ernando@gont.com.ar> wrote:
> >>
> >> Hi, Tom,
> >>
> >> On 24/11/20 16:43, Tom Herbert wrote:
> >> [....]
> >>> Modulating the flow label is a means to affect the routin= g of packets
> >>> through the network that uses flow labels as input to the= ECMP hash.
> >>
> >> What's the point?
> >>
> >> 1) You cannot tell *if* the FL is being used.
> >>
> > Generally true, but in a limited domain this information could be=
> > discerned. I'd note that it's also generally true that we= don't know
> > if there is a load balancer or stateful firewall in the path that=
> > requires consistent routing, but in a limited domain we could kno= w
> > that also.
>
> Exactly. So my take is that the drawbacks for the general case outweig= h
> the benefits of the specific case.
>
>
>
> >> 2) Changing the FL does not necessarily mean that packets wil= l employ a
> >> different link.
> >
> > It's an opportunistic mechanism. If a connection is failing a= nd we get
> > a better path that fixes it by simply changing the flow label the= n
> > what's the harm?
>
> Complexity, and the possible negative implications for the general cas= e.
>
> That said, why don't you fix the problem where you should (i.e., r= outing)?
>
>
>
> >> 3) If the network is failing, shouldn't you handle this v= ia routing?
> >>
> > Sure, but then that requires an out of band feedback loop from a = TCP
> > implementation to the network infrastructure to indicate there is= a
> > problem and then the network needs to respond.
>
> Not really. TCP does not deal with paths (not should it). If the netwo= rk
> detects a link is failing, it should route around the problem.
>

Fernando,

All we know in this case is that *TCP* has detected a connection is
failing and there may be a potential problem with a path, we don't
know that the network has detected any problems like some link is
failing or will ever detect any problem. So in such a scenario, what
recourse does the host have to try to salvage its connections?
=

Retransmit their = packets, let the network take care of trying to deliver them again.


If the
answer is that the host should always patiently wait for the network
to figure out what is happening,
=
Yes.

Steering packets is the network's job. People like me who run= the network expect to be in charge of that. We have fancy mechanisms that = mean alternate paths are switched to very quickly.
<= br>
The trouble with having two parties trying to so= lve the same problem at the same time without coordination is they're j= ust as likely to work against each other as they are inadvertently to work = with each other.

If host= s want the network to respect the flow label, then hosts need to ensure tha= t the a flow label value for a flow of packets with the same source and des= tination address consistently represents a flow.
If hosts start trying to take control of steering = traffic by varying the flow label value within a flow, making the network&#= 39;s job harder, and the network being blamed for the possibility bad netwo= rk performance that may result, the response will be both quick and easy - = network operators will switch off looking the Flow Label.

The Flow Label is the IPv6 header analogu= e for transport layer protocol ports, so that load balancing mechanisms don= 't have to dig further into the packet. Can or are transport layer port= s varied in TCP SYNs, SYN/ACKs and ACKs within the same TCP connection?=C2= =A0


then t= hat's going to be a hard sell
to application and host stack developers (remember the network is a
black box from their perspective that they really don't trust). If the<= br> answer is that the host is supposed to inform the network of issues
with it's connections and then host and network work together to solve<= br> then that's great; but then what is the general protocol that has been<= br> established to facilitate that and solved the problem of how hosts and
network work together in concert to solve user's problems?

Tom

>
>
> > That's significant
> > infrastructure and higher reaction time than doing something in T= CP
> > and IP. Think of modulating the flow label is an inexpensive form= of
> > source routing within a limited domain that doesn't need any<= br> > > infrastructure or heavyweight protocols or something like segment=
> > routing.
>
> Downsides:
>
> * It breaks load balancing
> * It depends on the source doing something -- but you don't necess= arily
> control the source -- and you cannot tell if the source implements it<= br> > * It doesn't solve the problem for nodes that do not behave as exp= ected
>
> My take is that if you really care about this, you're already (or<= br> > should!) be solving the problem in a different (and more general) way.=
>
>
>
> >>> The basic idea is that the flow label associated with a c= onnection is
> >>> randomly changed when the stack observes that the connect= ion is
> >>> failing (e.g. and an RTO). There is nothing in the specs = that prevents
> >>> this since the source is at liberty to set the flow label= as it sees
> >>> fit.
> >>
> >> The FL is expected to remain constant for the life of a flow.= A
> >> retransmitted packet is part of the same flow as the
> >> originally-transmitted packet. So this seems to be contradict= ing the
> >> very specification of the FL.
> >>
> >> For instance, If a RTO for a flow causes the FL to change, th= en one may
> >> possibly argue that the FL is not naming/labeling what is sai= d/expected
> >> to be anming/labeling.
> >
> > Specifically, RFC6437 states:
> >
> > "It is therefore RECOMMENDED that source hosts support the f= low label
> > by setting the flow label field for all packets of a given flow t= o the
> > same value chosen from an approximation to a discrete uniform
> > distribution."
> >
> > So that is clearly a just recommendation, and not a requirement (= and
> > definitely not a MUST). Furthermore, RFC6437 states:
> >
> > "A forwarding node MUST either leave a non-zero flow label v= alue
> > unchanged or change it only for compelling operational security > > reasons as described in Section 6.1."
>
> My concern is that we may leave the FL unusable.
>
>
>
>
> > So there's no guarantee in the protocol specs that flow label= s are
> > consistent for the life of the connection, which means that the > > network cannot assume that and thus it would be incorrect if the<= br> > > network tried to enforce flow label consistency as a protocol
> > requirement.
>
> You're probably right in that respect. And, in retrospective, I th= ink it
> would have been better if we had specified the FL to be unmutable.
>
>
>
> > As I said, it is prudent to try to be consistent with
> > flow labels and the default behavior in Linux should be changed,<= br> >
> Sorry: is the current Linux behavior to modulate the FL?
>
>
> > however I do not believe there's a valid claim of non-conform= ance that
> > motivates removal of the feature that is already deployed.
>
> I personally consider the changing the FL for a flow to be a bug. That=
> said, if the default setting is the correct/compliant behavior, at the=
> end of the day we're all adults, and whoever overrides the default=
> behavior is supposed to know what he/she does -- and if they don't= , they
> get what they deserve=C2=A0 ;-)
>
> So, in that light, I wouldn't push to remove the optional behavior= ,
> *provided* the default behavior is correct.
>
> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@s= i6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--0000000000005eae5b05b51fe993-- From nobody Fri Nov 27 16:38:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520523A097E; Fri, 27 Nov 2020 16:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxLz0qNCyTee; Fri, 27 Nov 2020 16:38:39 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 EEA9C3A097B; Fri, 27 Nov 2020 16:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qYDeYqGvc4mP5lAu9gL9lz0FLtNfydMAsQBWgZsnP90=; b=Qs56f/cQD8vMQ/zb0LSoSvhmb xiBishrKNOiR3i713iX6defy52LjXRc9Z1ebzrGtOhpqEAqj0p7vNgv03yuehadcK4Qz3DtEhxAU2 AyncXeD448+zynmiTh24Oy1C9Rbf2cwb2123Zl2LMn1wOdNhDlRw5IQO6Tcz5uDGX4hinczqfUZqT 20hAkfZYpVKG5Pqc+bLyMcklnVNAEHsaWbUaNsmSR+AmMXLMXpnI5a8u6UPluyJ9kuXnq3cKZNGHz 5q6FihjKOZUBRNzgBDAFF6IJVEwqZ873ELiHcO1toQ9u4x9ev71e1nd4fBFjCEGH6W5io5P8I6cQ2 cpCVUThRw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59617 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kioFn-001EKs-23; Fri, 27 Nov 2020 19:38:23 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_44B5C294-B782-46B8-80C6-5F938156FF6E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Fri, 27 Nov 2020 16:38:18 -0800 Cc: Tom Herbert , IPv6 Operations , tcpm , Fernando Gont Message-Id: <2DA153B5-1F7B-40CF-85F9-1BB3CAEF2E1E@strayalpha.com> References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> To: Mark Smith X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 00:38:40 -0000 --Apple-Mail=_44B5C294-B782-46B8-80C6-5F938156FF6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 27, 2020, at 4:32 PM, Mark Smith = wrote: >=20 > Steering packets is the network's job. +1 > The Flow Label is the IPv6 header analogue for transport layer = protocol ports, so that load balancing mechanisms don't have to dig = further into the packet. +1 > Can or are transport layer ports varied in TCP SYNs, SYN/ACKs and ACKs = within the same TCP connection? In general, no. I proposed a method to decouple the SYN destination port (which = currently is both part of the connection ID *and* identifies the = service) from the port used for the rest of the connection, but largely = to provide a separate service ID (originally draft-touch-tcp-portnames, = later recast as a service name option in draft-touch-tcpm-sno). But that = didn=E2=80=99t as much use different ports as decouple the service from = connection ID number. Joe --Apple-Mail=_44B5C294-B782-46B8-80C6-5F938156FF6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 27, 2020, at 4:32 PM, Mark Smith <markzzzsmith@gmail.com> wrote:

Steering packets is the network's job. =

+1

The Flow Label is the IPv6 header analogue for = transport layer protocol ports, so that load balancing mechanisms don't = have to dig further into the packet.

+1

Can or are transport layer ports = varied in TCP SYNs, SYN/ACKs and ACKs within the same TCP = connection?

In = general, no.

I proposed a method to = decouple the SYN destination port (which currently is both part of the = connection ID *and* identifies the service) from the port used for the = rest of the connection, but largely to provide a separate service ID = (originally draft-touch-tcp-portnames, later recast as a service name = option in draft-touch-tcpm-sno). But that didn=E2=80=99t as much = use different ports as decouple the service from connection ID = number.

Joe

= --Apple-Mail=_44B5C294-B782-46B8-80C6-5F938156FF6E-- From nobody Fri Nov 27 19:50:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93B83A0DEA; Fri, 27 Nov 2020 19:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Eb-n3T9NpCMH; Fri, 27 Nov 2020 19:50:21 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6843A0DE8; Fri, 27 Nov 2020 19:50:12 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B7F0D2845F1; Sat, 28 Nov 2020 03:50:08 +0000 (UTC) To: Tom Herbert Cc: Alexander Azimov , tcpm , IPv6 Operations References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> From: Fernando Gont Message-ID: Date: Sat, 28 Nov 2020 00:49:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 03:50:25 -0000 On 27/11/20 20:31, Tom Herbert wrote: [....] > > All we know in this case is that *TCP* has detected a connection is > failing and there may be a potential problem with a path, we don't > know that the network has detected any problems like some link is > failing or will ever detect any problem. So in such a scenario, what > recourse does the host have to try to salvage its connections? None. TCP times out and restransmits. And *the network* routes around failing paths. > If the > answer is that the host should always patiently wait for the network > to figure out what is happening, then that's going to be a hard sell > to application and host stack developers (remember the network is a > black box from their perspective that they really don't trust). Either that, of you switch to a different destination address if the transport protocol allows. > If the > answer is that the host is supposed to inform the network of issues > with it's connections and then host and network work together to solve > then that's great; The only thing the host can do is to switch to a different transport protocol if it allows. > but then what is the general protocol that has been > established to facilitate that and solved the problem of how hosts and > network work together in concert to solve user's problems? They don't really work together (modulo congestion control, one might argue), but rther complement each other (TCP times out and retransmits, and the network routes around failing paths). 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 Fri Nov 27 19:52:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F063A0DEC; Fri, 27 Nov 2020 19:52:48 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 uVi5Btv9E5tD; Fri, 27 Nov 2020 19:52:46 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA86A3A0DEA; Fri, 27 Nov 2020 19:52:45 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 512EA2845F1; Sat, 28 Nov 2020 03:52:42 +0000 (UTC) To: Mark Smith , Tom Herbert Cc: IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> From: Fernando Gont Message-ID: Date: Sat, 28 Nov 2020 00:52:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 03:52:48 -0000 On 27/11/20 21:32, Mark Smith wrote: > > On Sat, 28 Nov 2020, 10:32 Tom Herbert, > wrote: [....] > > If hosts start trying to take control of steering traffic by varying the > flow label value within a flow, making the network's job harder, and the > network being blamed for the possibility bad network performance that > may result, the response will be both quick and easy - network operators > will switch off looking the Flow Label. THat is *exactly* why I noted that I'm concerned that we seem to be on the path of making the FLow Label unusable. 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 Fri Nov 27 22:42:36 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3EF3A0C4C; Fri, 27 Nov 2020 22:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpLQ6e7oJDdU; Fri, 27 Nov 2020 22:42:33 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAD53A0C3A; Fri, 27 Nov 2020 22:42:33 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id v202so8232261oia.9; Fri, 27 Nov 2020 22:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mls8hKOkaDFJeKzYEIPlR9kLFnDA6/K7gXNXn/1CPK0=; b=TUWncmNeKVWQHjTRQHG6+jeU1+rE99koDeADd3RGHo4XHKI+3gbvo/I1N5bBzj4OnA r59xxcAiIAcTMOwPYpCmx2/JIyT1Wl1dVNNf52myZnl05REzRyCgiD1WwJqiW/dCxncx ygS8i6vLghUaMOZLcugejtgzZFn3h8NgTyWBhU6N1cT2AMS5GjFXW/RPweIcbtEJHCBA 2HhZx/niZh/G9iu/ePduxVtPrwxLGhkN4nWofwBPn4Ye/3FRJBYB5y7+Tuw2mzmDKi+j /us8VnB++3SnZVEgA5vqOSIZ6oGu0BRWVj0VePCjXqX1Vkyhbf/CPbVBcxPmHVrsB+CH pTZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mls8hKOkaDFJeKzYEIPlR9kLFnDA6/K7gXNXn/1CPK0=; b=lDH6eOescL4e6z8I1d0lqNptgZYqeWmcPowXkpUjhnzNIkNLmkp3InyTsi6iGesap+ l7qoEM+3+ghSWRJjvB45SffUhCVN34d3uAYv6uKmMyZaZue8+AjlkYnBsCg3GQt4W1PW CImNCtdIKs9mdN6OADeky0ejPqPcUmRGH5CmQTSJ70gLrHP2Ac7Hvw6eMJAQt7+S7sZi e4CgmuwlLCxZ8QaQX2MjTY663/0OnhUylXZkv3hpboBRqOPPwqKiW6Mz/3hsX/yERyrb nHdtsHRwmflek7bx3rpU5/h5WFcKmLvXxMX1vmZ4yBB13EjgY1ur6QvoH0RjTgriJb5F V0zA== X-Gm-Message-State: AOAM531R9LdsKE1HHsSesPYfGmDczcZQFM/lg+D76SRaEwZYMNyNSNoF sAm5YxAbu0YFGkM9B4Un7v26fC/Mfxpg6zh+LZFE3+iQ X-Google-Smtp-Source: ABdhPJzeP1w0ZuWCXyA8QXpxAqEodGa7Ikotu2dRtTd037Kz4wVOm9Q00n37Bb5wGBeyofKPrlnswZFRyy0q4nqtrnk= X-Received: by 2002:aca:534f:: with SMTP id h76mr8042040oib.60.1606545752887; Fri, 27 Nov 2020 22:42:32 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> In-Reply-To: From: Mark Smith Date: Sat, 28 Nov 2020 17:42:20 +1100 Message-ID: To: Fernando Gont Cc: Tom Herbert , IPv6 Operations , tcpm Content-Type: multipart/alternative; boundary="000000000000ea965605b5251478" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 06:42:35 -0000 --000000000000ea965605b5251478 Content-Type: text/plain; charset="UTF-8" On Sat, 28 Nov 2020, 14:52 Fernando Gont, wrote: > On 27/11/20 21:32, Mark Smith wrote: > > > > On Sat, 28 Nov 2020, 10:32 Tom Herbert, > > wrote: > [....] > > > > If hosts start trying to take control of steering traffic by varying the > > flow label value within a flow, making the network's job harder, and the > > network being blamed for the possibility bad network performance that > > may result, the response will be both quick and easy - network operators > > will switch off looking the Flow Label. > > THat is *exactly* why I noted that I'm concerned that we seem to be on > the path of making the FLow Label unusable. > I see the Flow Label as a hint, but only a hint, of what the hosts wants from the network. It's useful as an expression of what the host would like to have. However, if that hint causes me any trouble, I'll ignore it and then devolve to trying to deliver the packet based just on its destination address. > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > --000000000000ea965605b5251478 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 28 Nov 2020, 14:52 Fernando Gont, <ferna= ndo@gont.com.ar> wrote:
On 2= 7/11/20 21:32, Mark Smith wrote:
>
> On Sat, 28 Nov 2020, 10:32 Tom Herbert, <tom@herbertlan= d.com
> <mailto:tom@herbertland.com>> wrote:
[....]
>
> If hosts start trying to take control of steering traffic by varying t= he
> flow label value within a flow, making the network's job harder, a= nd the
> network being blamed for the possibility bad network performance that =
> may result, the response will be both quick and easy - network operato= rs
> will switch off looking the Flow Label.

THat is *exactly* why I noted that I'm concerned that we seem to be on =
the path of making the FLow Label unusable.

I see the Flow Label as a hint, = but only a hint, of what the hosts wants from the network. It's useful = as an expression of what the host would like to have.

However, if that hint causes me any trouble, = I'll ignore it and then devolve to trying to deliver the packet based j= ust on its destination address.



Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6net= works.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



--000000000000ea965605b5251478-- From nobody Sat Nov 28 00:42:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6203A1001; Sat, 28 Nov 2020 00:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CQYkQX6_Rhn8; Sat, 28 Nov 2020 00:42:32 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58E93A0FFA; Sat, 28 Nov 2020 00:42:27 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D94F7283B75; Sat, 28 Nov 2020 08:42:23 +0000 (UTC) To: Mark Smith Cc: Tom Herbert , IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> From: Fernando Gont Message-ID: <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> Date: Sat, 28 Nov 2020 05:01:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 08:42:37 -0000 On 28/11/20 03:42, Mark Smith wrote: > > > On Sat, 28 Nov 2020, 14:52 Fernando Gont, > wrote: > > On 27/11/20 21:32, Mark Smith wrote: > > > > On Sat, 28 Nov 2020, 10:32 Tom Herbert, > > >> wrote: > [....] > > > > If hosts start trying to take control of steering traffic by > varying the > > flow label value within a flow, making the network's job harder, > and the > > network being blamed for the possibility bad network performance > that > > may result, the response will be both quick and easy - network > operators > > will switch off looking the Flow Label. > > THat is *exactly* why I noted that I'm concerned that we seem to be on > the path of making the FLow Label unusable. > > > I see the Flow Label as a hint, but only a hint, of what the hosts wants > from the network. It's useful as an expression of what the host would > like to have. As you correctly noted, it's supposed to be an identifier of the flow, because it's hard to get for the port numbers. I don't think it can bee seen as ad expression of what the host wants to ahve, because the Flow ID has no semantics, and the host doesn't even know what's in the network. > However, if that hint causes me any trouble, I'll ignore it and then > devolve to trying to deliver the packet based just on its destination > address. If you *needed* (or could make use of) the FL, then, if it causes trouble, you either resort to finding the five-tuple, or quite likely end of dropping packets. 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 Sat Nov 28 02:15:12 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121263A09CF; Sat, 28 Nov 2020 02:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCLBI1v714-W; Sat, 28 Nov 2020 02:15:06 -0800 (PST) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ABD3A09D1; Sat, 28 Nov 2020 02:15:05 -0800 (PST) Received: by mail-oi1-x243.google.com with SMTP id w15so8581353oie.13; Sat, 28 Nov 2020 02:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbbSXTw6J2WlwBxKU5jp8a9Qh4yv9XE2pdrbPYNjLYw=; b=JYYpTQDlk7uZCVbajlVoKu/lqtTbwV2h9rZpefklzIhNiFu9RZ65W/Hhi9lHGl6VV6 ecdQlOpHLgD5AdAtiAwB1N4otAI4H8fZgMLIxKT+JaS03wLI/SkwyliOaliJK25lEHSc yKN5Vd836wcRqdRlkzgE1LTTxa2l2/U6UwZEaUVegZLhY+7YxScnjRMEpAHshYHzLgzh tNYWvzLmxRrNZ4lWyXt6J5+DC+sf8zM+ulS5bMzHjKeo8JdIiLXxJXOEs6sHw4ZQh5gn Zmt6GO4Ha0Mn+6ywECr9dwrEjQcRGrxC7gpavJJkn4tbaaLbVXlAGuiHiZYZgnHq/u9S //zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbbSXTw6J2WlwBxKU5jp8a9Qh4yv9XE2pdrbPYNjLYw=; b=UOAt08Cl2Uef41CkURhOBB6pU6XmBvBvvf9dOyqdetBehAbUwyiIVeelve0GSXwgmC e7buq0vyAvFLLnGdTF5dCSmn0YHNUN7e7DYaV+PfftDRZxS/PgiWBmOv9rpa7QeKftz9 kfX9oK2zzubEYN2ty8Mf8W2gpFiMpAoIgGViEMoTQ3W0ePGW3eK4rxY8+SZhhKm1bGlt 7FuQYzk0TSy0u+/TX5l9eJa6zNh1B7VEsNxqV3STKFDf+iVxMjWe+/Wwnjw21OxYDIy7 5YWNfVQ5pVF2B7s5ZVsTPLgcnuSPlu8JxDQLSY/6+tbNRlwQ6WZN/VvCAl9LajVS/Hle Dw3Q== X-Gm-Message-State: AOAM530nOpHkH/U8XrmBoNL0TukiD/S01dbAXXEsAHBxXfFmSB3rsKA1 NtdZIpU19s7jIf9/f5gk85o284VtxtO8YeS6Yls= X-Google-Smtp-Source: ABdhPJzln2y//E7MWV1jfqXR2XXNBZmg9TR1Zwc5yDCgAbkseGhcHON7c8UiC0mYNpoVilNfMwplm5AXNoupTJyYg9c= X-Received: by 2002:aca:55cb:: with SMTP id j194mr8397781oib.4.1606558505002; Sat, 28 Nov 2020 02:15:05 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> In-Reply-To: <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> From: Alexander Azimov Date: Sat, 28 Nov 2020 13:14:51 +0300 Message-ID: To: Fernando Gont Cc: Mark Smith , Tom Herbert , IPv6 Operations , tcpm Content-Type: multipart/alternative; boundary="000000000000006b8e05b5280dd0" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 10:15:08 -0000 --000000000000006b8e05b5280dd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gentlemen, At the very least, one should analyze the case where in #1, a packet > gets delayed, you change the FL and retransmit, and finally you get a > response to the original packet (and/or to both packets). As the suggestion strictly speaks about changing FL upon RTO timeouts I don't see how it differs from getting two responses in case of RTO without FL change. Nothing special here. If you have two links, then, upon change of the FL, you have 50% change > that the path will be different -- not good. What would you do if the > failure continues? -- keep changing the FL? Yes, and if only one path is affected - you have a chance of hitting a good path with 1 - (1/2)^n. And it's much better than nothing. > If a retransmitted SYN goes to another server/anycast point this won't > bring much harm. At least we haven't experienced such problems in our > datacenters. > I think depends on details that are definitively out of the IETF's scope. > When exactly does the load balancing system assign a session to a given > server, how much state does that create, what resources does it reserve, > and when are the state and the reserved resources released? > Also, in some cases, I could imagine that the data centre will not see a > problem, but the client might see one that they would not otherwise have > seen. I can't say that these details look convincing to me. I also can't agree that operational considerations are out of IETF's scope. The protocols are designed with real operations in mind, aren't they? Steering packets is the network's job. People like me who run the network > expect to be in charge of that. We have fancy mechanisms that mean > alternate paths are switched to very quickly. While not questioning innovative technologies that take care of traffic, a 'good' repair time counts in seconds. 'Bad' repair time, when the control plane becomes broken or a famous silent drop happens counts in minutes and requires a network engineer to be summoned. If TCP can fix itself in milliseconds - it's great. And it is needed by real operations. You also missing part when something happens outside of your domain, where you can't instantly summon an engineer. If you tell me that you've been never affected by the network outage of your peering partner I will be greatly suprised. =D1=81=D0=B1, 28 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 11:42, Ferna= ndo Gont : > On 28/11/20 03:42, Mark Smith wrote: > > > > > > On Sat, 28 Nov 2020, 14:52 Fernando Gont, > > wrote: > > > > On 27/11/20 21:32, Mark Smith wrote: > > > > > > On Sat, 28 Nov 2020, 10:32 Tom Herbert, > > > > >> wrote= : > > [....] > > > > > > If hosts start trying to take control of steering traffic by > > varying the > > > flow label value within a flow, making the network's job harder, > > and the > > > network being blamed for the possibility bad network performance > > that > > > may result, the response will be both quick and easy - network > > operators > > > will switch off looking the Flow Label. > > > > THat is *exactly* why I noted that I'm concerned that we seem to be > on > > the path of making the FLow Label unusable. > > > > > > I see the Flow Label as a hint, but only a hint, of what the hosts want= s > > from the network. It's useful as an expression of what the host would > > like to have. > > As you correctly noted, it's supposed to be an identifier of the flow, > because it's hard to get for the port numbers. > > I don't think it can bee seen as ad expression of what the host wants to > ahve, because the Flow ID has no semantics, and the host doesn't even > know what's in the network. > > > > > However, if that hint causes me any trouble, I'll ignore it and then > > devolve to trying to deliver the packet based just on its destination > > address. > > If you *needed* (or could make use of) the FL, then, if it causes > trouble, you either resort to finding the five-tuple, or quite likely > end of dropping packets. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --=20 Best regards, Alexander Azimov --000000000000006b8e05b5280dd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gentlemen,

At the very least, one should analyze the case where in #1= , a packet
gets delayed, you change the FL and retransmit, and finally y= ou get a
response to the original packet (and/or to both packets).=C2=A0= =C2=A0
As the suggestion strictly speaks about changing FL= upon RTO timeouts I don't see how it differs from getting two response= s in case of RTO without FL change. Nothing special here.

If you have two links,= then, upon change of the FL, you have 50% change
that the path will be = different -- not good.=C2=A0 What would you do if the
failure continues?= -- keep changing the FL?
Yes, and if only one path is aff= ected - you have a chance of hitting a good path with 1 - (1/2)^n. And it&#= 39;s much better than nothing.

> If a retransmitted SYN goes to another server/anycast point this = won't bring much harm. At least we haven't experienced such problem= s in our datacenters.
I think depends on details that are definit= ively out of the IETF's scope. When exactly does the load balancing sys= tem assign a session to a given server, how much state does that create, wh= at resources does it reserve, and when are the state and the reserved resou= rces released?
Also, in some cases, I could imagine that the data centre= will not see a problem, but the client might see one that they would not o= therwise have seen.=C2=A0=C2=A0
I can't say that these= details look convincing to me. I also can't agree that operational con= siderations are out of IETF's scope. The protocols are designed with re= al operations in mind, aren't they?

Steering packets is the network'= s job. People like me who run the network expect to be in charge of that. W= e have fancy mechanisms that mean alternate paths are switched to very quic= kly.
While not questioning innovative technologies that ta= ke care of traffic, a 'good' repair time counts in seconds. 'Ba= d'=C2=A0repair time, when the control plane becomes broken or a famous = silent drop happens counts in=C2=A0minutes and requires a network=C2=A0engi= neer to be summoned. If TCP can fix itself in milliseconds - it's great= . And it is needed by real operations. You also missing part when something= happens outside of your domain, where you can't instantly summon an en= gineer. If you tell me that you've been never affected by the network o= utage of your peering partner I will be greatly suprised.=C2=A0
<= br>


=D1=81=D0=B1, 28 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0= =B3. =D0=B2 11:42, Fernando Gont <fernando@gont.com.ar>:
On 28/11/20 03:42, Mark Smith wrote:
>
>
> On Sat, 28 Nov 2020, 14:52 Fernando Gont, <fernando@gont.com.ar
> <mailto:f= ernando@gont.com.ar>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 27/11/20 21:32, Mark Smith wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Sat, 28 Nov 2020, 10:32 Tom Herbert, <<= a href=3D"mailto:tom@herbertland.com" target=3D"_blank">tom@herbertland.com=
>=C2=A0 =C2=A0 =C2=A0<mailto:tom@herbertland.com>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:tom@herbertland.com <mailto:tom@herbertland.com>>>= wrote:
>=C2=A0 =C2=A0 =C2=A0[....]
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > If hosts start trying to take control of stee= ring traffic by
>=C2=A0 =C2=A0 =C2=A0varying the
>=C2=A0 =C2=A0 =C2=A0 > flow label value within a flow, making the ne= twork's job harder,
>=C2=A0 =C2=A0 =C2=A0and the
>=C2=A0 =C2=A0 =C2=A0 > network being blamed for the possibility bad = network performance
>=C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 > may result, the response will be both quick a= nd easy - network
>=C2=A0 =C2=A0 =C2=A0operators
>=C2=A0 =C2=A0 =C2=A0 > will switch off looking the Flow Label.
>
>=C2=A0 =C2=A0 =C2=A0THat is *exactly* why I noted that I'm concerne= d that we seem to be on
>=C2=A0 =C2=A0 =C2=A0the path of making the FLow Label unusable.
>
>
> I see the Flow Label as a hint, but only a hint, of what the hosts wan= ts
> from the network. It's useful as an expression of what the host wo= uld
> like to have.

As you correctly noted, it's supposed to be an identifier of the flow, =
because it's hard to get for the port numbers.

I don't think it can bee seen as ad expression of what the host wants t= o
ahve, because the Flow ID has no semantics, and the host doesn't even <= br> know what's in the network.



> However, if that hint causes me any trouble, I'll ignore it and th= en
> devolve to trying to deliver the packet based just on its destination =
> address.

If you *needed* (or could make use of) the FL, then, if it causes
trouble, you either resort to finding the five-tuple, or quite likely
end of dropping packets.

Thanks,
--
Fernando Gont
e-mail: fernando@= gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



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


--
Best regards,
Alexander Azi= mov
--000000000000006b8e05b5280dd0-- From nobody Sat Nov 28 10:09:25 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1667F3A0E08; Sat, 28 Nov 2020 10:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 KcEylFFdyPxD; Sat, 28 Nov 2020 10:09:17 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9880F3A0DFC; Sat, 28 Nov 2020 10:09:15 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:813c:9bb5:ab11:9982] (unknown [IPv6:2a02:8109:1140:c3d:813c:9bb5:ab11:9982]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 6B18372246344; Sat, 28 Nov 2020 19:09:11 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Michael Tuexen In-Reply-To: Date: Sat, 28 Nov 2020 19:09:08 +0100 Cc: Fernando Gont , IPv6 Operations , tcpm Content-Transfer-Encoding: quoted-printable Message-Id: <80E049A2-534C-4D89-B67D-4384A6CFA8B6@lurchi.franken.de> References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> To: Tom Herbert X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 18:09:20 -0000 > On 28. Nov 2020, at 00:31, Tom Herbert wrote: >=20 > On Fri, Nov 27, 2020 at 1:41 PM Fernando Gont = wrote: >>=20 >> Hello, Tom, >>=20 >> On 25/11/20 16:35, Tom Herbert wrote: >>> Hi Fernando, comments in line... >>>=20 >>> On Wed, Nov 25, 2020 at 12:13 AM Fernando Gont = wrote: >>>>=20 >>>> Hi, Tom, >>>>=20 >>>> On 24/11/20 16:43, Tom Herbert wrote: >>>> [....] >>>>> Modulating the flow label is a means to affect the routing of = packets >>>>> through the network that uses flow labels as input to the ECMP = hash. >>>>=20 >>>> What's the point? >>>>=20 >>>> 1) You cannot tell *if* the FL is being used. >>>>=20 >>> Generally true, but in a limited domain this information could be >>> discerned. I'd note that it's also generally true that we don't know >>> if there is a load balancer or stateful firewall in the path that >>> requires consistent routing, but in a limited domain we could know >>> that also. >>=20 >> Exactly. So my take is that the drawbacks for the general case = outweigh >> the benefits of the specific case. >>=20 >>=20 >>=20 >>>> 2) Changing the FL does not necessarily mean that packets will = employ a >>>> different link. >>>=20 >>> It's an opportunistic mechanism. If a connection is failing and we = get >>> a better path that fixes it by simply changing the flow label then >>> what's the harm? >>=20 >> Complexity, and the possible negative implications for the general = case. >>=20 >> That said, why don't you fix the problem where you should (i.e., = routing)? >>=20 >>=20 >>=20 >>>> 3) If the network is failing, shouldn't you handle this via = routing? >>>>=20 >>> Sure, but then that requires an out of band feedback loop from a TCP >>> implementation to the network infrastructure to indicate there is a >>> problem and then the network needs to respond. >>=20 >> Not really. TCP does not deal with paths (not should it). If the = network >> detects a link is failing, it should route around the problem. >>=20 >=20 > Fernando, >=20 > All we know in this case is that *TCP* has detected a connection is > failing and there may be a potential problem with a path, we don't Hi Tom, it is perfectly fine that if a TCP connection fails and the application triggers a setup of a new TCP connection, the new TCP connections uses a flowlabel different from the one used for the old TCP connection. However, a single RTO does not indicate a connection failure. Normally you would need several consecutive RTOs to happen before TCP declares the connection to be failed. Best regards Michael > know that the network has detected any problems like some link is > failing or will ever detect any problem. So in such a scenario, what > recourse does the host have to try to salvage its connections? If the > answer is that the host should always patiently wait for the network > to figure out what is happening, then that's going to be a hard sell > to application and host stack developers (remember the network is a > black box from their perspective that they really don't trust). If the > answer is that the host is supposed to inform the network of issues > with it's connections and then host and network work together to solve > then that's great; but then what is the general protocol that has been > established to facilitate that and solved the problem of how hosts and > network work together in concert to solve user's problems? >=20 > Tom >=20 >>=20 >>=20 >>> That's significant >>> infrastructure and higher reaction time than doing something in TCP >>> and IP. Think of modulating the flow label is an inexpensive form of >>> source routing within a limited domain that doesn't need any >>> infrastructure or heavyweight protocols or something like segment >>> routing. >>=20 >> Downsides: >>=20 >> * It breaks load balancing >> * It depends on the source doing something -- but you don't = necessarily >> control the source -- and you cannot tell if the source implements it >> * It doesn't solve the problem for nodes that do not behave as = expected >>=20 >> My take is that if you really care about this, you're already (or >> should!) be solving the problem in a different (and more general) = way. >>=20 >>=20 >>=20 >>>>> The basic idea is that the flow label associated with a connection = is >>>>> randomly changed when the stack observes that the connection is >>>>> failing (e.g. and an RTO). There is nothing in the specs that = prevents >>>>> this since the source is at liberty to set the flow label as it = sees >>>>> fit. >>>>=20 >>>> The FL is expected to remain constant for the life of a flow. A >>>> retransmitted packet is part of the same flow as the >>>> originally-transmitted packet. So this seems to be contradicting = the >>>> very specification of the FL. >>>>=20 >>>> For instance, If a RTO for a flow causes the FL to change, then one = may >>>> possibly argue that the FL is not naming/labeling what is = said/expected >>>> to be anming/labeling. >>>=20 >>> Specifically, RFC6437 states: >>>=20 >>> "It is therefore RECOMMENDED that source hosts support the flow = label >>> by setting the flow label field for all packets of a given flow to = the >>> same value chosen from an approximation to a discrete uniform >>> distribution." >>>=20 >>> So that is clearly a just recommendation, and not a requirement (and >>> definitely not a MUST). Furthermore, RFC6437 states: >>>=20 >>> "A forwarding node MUST either leave a non-zero flow label value >>> unchanged or change it only for compelling operational security >>> reasons as described in Section 6.1." >>=20 >> My concern is that we may leave the FL unusable. >>=20 >>=20 >>=20 >>=20 >>> So there's no guarantee in the protocol specs that flow labels are >>> consistent for the life of the connection, which means that the >>> network cannot assume that and thus it would be incorrect if the >>> network tried to enforce flow label consistency as a protocol >>> requirement. >>=20 >> You're probably right in that respect. And, in retrospective, I think = it >> would have been better if we had specified the FL to be unmutable. >>=20 >>=20 >>=20 >>> As I said, it is prudent to try to be consistent with >>> flow labels and the default behavior in Linux should be changed, >>=20 >> Sorry: is the current Linux behavior to modulate the FL? >>=20 >>=20 >>> however I do not believe there's a valid claim of non-conformance = that >>> motivates removal of the feature that is already deployed. >>=20 >> I personally consider the changing the FL for a flow to be a bug. = That >> said, if the default setting is the correct/compliant behavior, at = the >> end of the day we're all adults, and whoever overrides the default >> behavior is supposed to know what he/she does -- and if they don't, = they >> get what they deserve ;-) >>=20 >> So, in that light, I wouldn't push to remove the optional behavior, >> *provided* the default behavior is correct. >>=20 >> Thanks, >> -- >> 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 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Nov 28 10:27:56 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80973A0E85 for ; Sat, 28 Nov 2020 10:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwRN3cNgvd0D for ; Sat, 28 Nov 2020 10:27:46 -0800 (PST) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5663A0E0A for ; Sat, 28 Nov 2020 10:27:46 -0800 (PST) Received: by mail-ej1-x643.google.com with SMTP id qw4so2322808ejb.12 for ; Sat, 28 Nov 2020 10:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wWl/NMyNYxy387O+iIu6O4b8CdadQrZa/jeMx3Om5tg=; b=dNgTTawMw7VpBXjsMXb8333PuiTIN6tthkD5Ce1+L1hE+f5KpmZwout31RmBskI+1o b0ZTql8dcOy1NJ/B1mZwKFgGlxCxSvikm0sOY+/vH6j8EhZUoHXNI2Ebc7e0hp2BG6z/ y91bbKqEkVXzRxR4JLSuLFnYJUBZeHZ2Y7925uVMA+ZAttlrbCXr9AlTXcIeSdDvaQVc aWmEo3l4sgMgugqf/VB89gX24ZpKHjo2u8R0St0XsGwz9cuhAGlfFXbhcHXFblYxZFBd XeMmsFsEQNn1cP2JrZG7i8SRFEzqb0ul9AUXmqlgLewRl9NHhAoLS3xiXOb9NODVC8Wm ICEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wWl/NMyNYxy387O+iIu6O4b8CdadQrZa/jeMx3Om5tg=; b=HWU7NdGLBqXCsbMYZAnVX9oXI/5kLUP73RgBeUGq2OUfbEWGqVXcEA8R69I73s04FD 2mZt+kSm06rVbf0EsFbpiLjMSIbQYDNNKi4+PlcxnJU6pB1U7Gj7pKYOVKnUBWoFN4HX DMVcWJLGk2CKwwdp7J+O2oIWhzDRTCQog4UszbVsVsakbvtx6ZXXQmbonkR3igtD7D6Y 2T7x6GYYcQZEPhXu1R33Wo7bnJ9MuNGcN5IvZRbd0wCVtLVafKrz699RVJ+EfVsRbIi5 2Jb1Qb9LzJtOgGKBXnlnoTLAL9R8LCiUDOjxK6G/0/YaqvD1/iySq5qdYBmb7bhpICso 8TOw== X-Gm-Message-State: AOAM533CYKRCj2nmJTwWskdwV+0/0N6mWSEG1Y7DBCJTYbljMJKxd09w FblbrwD2I0avT2ZMGsT4TpR40Rhe6DSzCpKttNXh+Q== X-Google-Smtp-Source: ABdhPJzZZSeTYj48bvJ9nSIQ7zcFM6+A+2Wb+/H6bNI7joGqmXwJYywQ0bf2CQxfAQ178s1cPq0FN2S0iiRn/6dTPlg= X-Received: by 2002:a17:906:f153:: with SMTP id gw19mr1182793ejb.272.1606588064811; Sat, 28 Nov 2020 10:27:44 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> In-Reply-To: From: Tom Herbert Date: Sat, 28 Nov 2020 11:27:33 -0700 Message-ID: To: Alexander Azimov Cc: Fernando Gont , Mark Smith , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 18:27:51 -0000 On Sat, Nov 28, 2020 at 3:15 AM Alexander Azimov wro= te: > > Gentlemen, > >> At the very least, one should analyze the case where in #1, a packet >> gets delayed, you change the FL and retransmit, and finally you get a >> response to the original packet (and/or to both packets). > > As the suggestion strictly speaks about changing FL upon RTO timeouts I d= on't see how it differs from getting two responses in case of RTO without F= L change. Nothing special here. > >> If you have two links, then, upon change of the FL, you have 50% change >> that the path will be different -- not good. What would you do if the >> failure continues? -- keep changing the FL? > > Yes, and if only one path is affected - you have a chance of hitting a go= od path with 1 - (1/2)^n. And it's much better than nothing. > >> > If a retransmitted SYN goes to another server/anycast point this won't= bring much harm. At least we haven't experienced such problems in our data= centers. >> I think depends on details that are definitively out of the IETF's scope= . When exactly does the load balancing system assign a session to a given s= erver, how much state does that create, what resources does it reserve, and= when are the state and the reserved resources released? >> Also, in some cases, I could imagine that the data centre will not see a= problem, but the client might see one that they would not otherwise have s= een. > > I can't say that these details look convincing to me. I also can't agree = that operational considerations are out of IETF's scope. The protocols are = designed with real operations in mind, aren't they? > >> Steering packets is the network's job. People like me who run the networ= k expect to be in charge of that. We have fancy mechanisms that mean altern= ate paths are switched to very quickly. > > While not questioning innovative technologies that take care of traffic, = a 'good' repair time counts in seconds. 'Bad' repair time, when the control= plane becomes broken or a famous silent drop happens counts in minutes and= requires a network engineer to be summoned. If TCP can fix itself in milli= seconds - it's great. And it is needed by real operations. You also missing= part when something happens outside of your domain, where you can't instan= tly summon an engineer. If you tell me that you've been never affected by t= he network outage of your peering partner I will be greatly suprised. > +1 I would also point out this feature has been in deployment for at least five years in at least two hyperscalers-- there has been no major meltdown. We'll make the feature opt-in because we may be exposed to non-conformant devices in the network that make incorrect assumptions, but I have yet to see any convincing argument that we should remove the feature becauses it's fundamentally harmful or not providing benefits. As for the mentality of "the network will fix the problem", that's obviously an easy statement to make from a router vendor point of view, but that luxury simply doesn't match the realities of how host stacks are implemented deployed at global scale. This starts with the fact that there is no such thing as "the network"; Linux stack for instance needs to run on every network on Earth and I have no idea which of these networks provides adequate security, fault detection and repair, are well managed, or even have devices that conform to the standards (non-conformant network devices are common). The only recourse we, i.e. host side developers, have is to stick with the least common denominator in the general case, and allow optional, but still protocol conformant, features in limited use cases such as limited domains (hence why the flow label modulation feature should be optional as we've already established in this thread). Tom > > > =D1=81=D0=B1, 28 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 11:42, Fer= nando Gont : >> >> On 28/11/20 03:42, Mark Smith wrote: >> > >> > >> > On Sat, 28 Nov 2020, 14:52 Fernando Gont, > > > wrote: >> > >> > On 27/11/20 21:32, Mark Smith wrote: >> > > >> > > On Sat, 28 Nov 2020, 10:32 Tom Herbert, > > >> > > >> wrot= e: >> > [....] >> > > >> > > If hosts start trying to take control of steering traffic by >> > varying the >> > > flow label value within a flow, making the network's job harder= , >> > and the >> > > network being blamed for the possibility bad network performanc= e >> > that >> > > may result, the response will be both quick and easy - network >> > operators >> > > will switch off looking the Flow Label. >> > >> > THat is *exactly* why I noted that I'm concerned that we seem to b= e on >> > the path of making the FLow Label unusable. >> > >> > >> > I see the Flow Label as a hint, but only a hint, of what the hosts wan= ts >> > from the network. It's useful as an expression of what the host would >> > like to have. >> >> As you correctly noted, it's supposed to be an identifier of the flow, >> because it's hard to get for the port numbers. >> >> I don't think it can bee seen as ad expression of what the host wants to >> ahve, because the Flow ID has no semantics, and the host doesn't even >> know what's in the network. >> >> >> >> > However, if that hint causes me any trouble, I'll ignore it and then >> > devolve to trying to deliver the packet based just on its destination >> > address. >> >> If you *needed* (or could make use of) the FL, then, if it causes >> trouble, you either resort to finding the five-tuple, or quite likely >> end of dropping packets. >> >> Thanks, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > Best regards, > Alexander Azimov From nobody Sat Nov 28 21:53:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9140F3A11AA; Sat, 28 Nov 2020 21:53:32 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 04Z64h8ti81m; Sat, 28 Nov 2020 21:53:28 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9DC3A11A9; Sat, 28 Nov 2020 21:53:13 -0800 (PST) Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 69F7B280878; Sun, 29 Nov 2020 05:53:09 +0000 (UTC) To: Tom Herbert , Alexander Azimov Cc: Mark Smith , IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> From: Fernando Gont Message-ID: Date: Sun, 29 Nov 2020 02:53:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 05:53:33 -0000 Tom, On 28/11/20 15:27, Tom Herbert wrote: [....] >> While not questioning innovative technologies that take care of traffic, a 'good' repair time counts in seconds. 'Bad' repair time, when the control plane becomes broken or a famous silent drop happens counts in minutes and requires a network engineer to be summoned. If TCP can fix itself in milliseconds - it's great. And it is needed by real operations. You also missing part when something happens outside of your domain, where you can't instantly summon an engineer. If you tell me that you've been never affected by the network outage of your peering partner I will be greatly suprised. >> > +1 > > I would also point out this feature has been in deployment for at > least five years in at least two hyperscalers-- there has been no > major meltdown. We'll make the feature opt-in because we may be > exposed to non-conformant devices in the network that make incorrect > assumptions, but I have yet to see any convincing argument that we > should remove the feature becauses it's fundamentally harmful or not > providing benefits. It breaks FL-based load-sharing. > As for the mentality of "the network will fix the problem", that's > obviously an easy statement to make from a router vendor point of > view, but that luxury simply doesn't match the realities of how host > stacks are implemented deployed at global scale. Not sure what you mean. We rely on that for the current Internet (hosts do not do source-routing). > This starts with the > fact that there is no such thing as "the network"; Linux stack for > instance needs to run on every network on Earth and I have no idea > which of these networks provides adequate security, fault detection > and repair, are well managed, or even have devices that conform to the > standards (non-conformant network devices are common). The only > recourse we, i.e. host side developers, have is to stick with the > least common denominator in the general case, and allow optional, but > still protocol conformant, features in limited use cases such as > limited domains (hence why the flow label modulation feature should be > optional as we've already established in this thread). Modulo the comments I've already made, I'm afraid we might be in the path of making the FL unusable... 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 Nov 29 08:26:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116CF3A098E for ; Sun, 29 Nov 2020 08:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFpqNBdcounN for ; Sun, 29 Nov 2020 08:26:13 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F2C3A0991 for ; Sun, 29 Nov 2020 08:26:13 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id m16so11908976edr.3 for ; Sun, 29 Nov 2020 08:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4nl8RWUyjAga5aJnJqFHpeZR5YaJoGcPySw6TFLDQYM=; b=RhHJn99s6A/08Hcn9dK+jJifriDjIwn5CxKmNsgO3AWBlhdi5+55F21nWyvHrhfzVo lK8LbKJ3y4Af8zMf1/53SM4/Zov+FzDQrdGyY1d/LyhYrjSHLIpCt1I5O6kcGST+kyxF YtxWdhDV+uWRDymRt+d2fwggj3n4ZnlefLPo7nn7r1I58aZAhUv6du7c2jWj+EdJEdsM BMmPKT+veYl0YgAQcpG1svYesFGz53vGzy8Yk0ZDAOt1RIMWuLMcv1WS5yNmWiY4kwZ7 m9M4F94RymBZyz3SF1Y9tU7ZryFtzfeQ7pRYTK0tkxAI/fGC2G6w5vyTGpyqcJ3U0qkL 0E1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4nl8RWUyjAga5aJnJqFHpeZR5YaJoGcPySw6TFLDQYM=; b=i4stFsdXvX40qsKwh0d9bvpuybHY3KHalltkKJqAuJ2bRzufdkjDwCN4bdJhDiU+mP LHmj+mCr7D6e7dHk2B2EokjAL4c8rD29I97yoEVsFO+JcVSK+1rvAwy4WOrlwESjj/QK +Yy7JLnhHKSw3mfzk9vEunqD5FwuSqS9vn4r8D0XsdfM4/GT0dPZgPcGnDAhG8eBZBJM 3JDLltZbuvHmUxL1NXGi3QKii5z2IC5eBeW19RsubCxKa2Z7DWbFQfUnKKnR/cn/yXHd zKLsLEMxE4fy+ElNm8iEIzZCVh9PF0EP5hrVzTDhHc8F4cNuH29dCewQJyX3YkGjWo+2 tomg== X-Gm-Message-State: AOAM533gmbENqexgeRsUSXyoT6MB4APc6c/EGWFu3ILZCiJkvUvwTPaZ C8+v8ZJ29nqEnJ3C06ytPZSj7pvxeG841He+LCa/Ww== X-Google-Smtp-Source: ABdhPJx9ImKGbB+SwsnYzYtsUAtryedC9qBssWQQMBqqzsQ92sbx0l9c//dzyrGoO1RK3B4tTNnHfEirb+P78EsJFVU= X-Received: by 2002:aa7:dd52:: with SMTP id o18mr2084264edw.177.1606667171298; Sun, 29 Nov 2020 08:26:11 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> In-Reply-To: From: Tom Herbert Date: Sun, 29 Nov 2020 09:25:59 -0700 Message-ID: To: Fernando Gont Cc: Alexander Azimov , Mark Smith , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 16:26:18 -0000 > Modulo the comments I've already made, I'm afraid we might be in the > path of making the FL unusable... > Fernanda, I really don't understand how this makes the flow label "unusable", to the contrary this is a useful case with good effect and justifies the work in the host to set the field. In any case, it would be great if you could provide the draft with the normative requirements that would make the flow label "usable". Please include requirements for both hosts and network nodes. If there is going to the be a requirement that hosts MUST make a 1:1 mapping to a transport connection and the flow label MUST be consistent for the life of connection, then I would expect there to also be a requirement that the flow label MUST be immutable by all devices in the path-- in particular the requirement of RFC6437 would need to be updated: "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons..."-- if hosts are not allowed to change a field they are primarily responsible for setting, then the network should not be allowed to modify it either. Additionally, if the underlying design principle is that flow identification in a packet is immutable and persistent, then I'd like to see the discussion on how that rectifies with NAT where intermediate nodes routinely change IP addresses and transport port numbers without the host endpoints' knowledge-- unlike the flow label, port numbers are formally part of the transport connection identification, so changing them in flight is far more invasive and potentially harmful than changing the flow label (we've seen far more problems caused by NAT than flow label due to NAT state evictions, packets of a flow being re-routed to not hit the same NAT device, etc.). Tom > 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 Mon Nov 30 08:57:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199CD3A0B6D for ; Mon, 30 Nov 2020 08:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=eScvFBrD; dkim=pass (1024-bit key) header.d=juniper.net header.b=PDs7OwyO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhF11z5YAGQI for ; Mon, 30 Nov 2020 08:57:35 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 304463A0EBF for ; Mon, 30 Nov 2020 08:57:35 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0AUGtD7r013190 for ; Mon, 30 Nov 2020 08:57:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=vDIPyVecewqHScqWTCKyW6KtpVwZoalJg85uk47V5+c=; b=eScvFBrDBZwWjGvTc/rb5NTtzfQbooPr5n/f/eyx6r5gdm9kYLWZhK+ifHe98tPEUvOK jrRfZWIXAPOGvqzm0KETn88EEfVzPH+9dcYN+gyOtJcThok4IFweyMxrle4GkpFuyOHe Z9R9b5wO5NOkWFYMZkcFy0Aoje0Yb6ckzDe7JSRsWH8mMSl/Xoy3t2IKAvn6pzo89OR+ tyXGji09xUcrzt00ks+ltdU3+iu7CpCJfUE84U+CSN2tidcL8v2uRnHrUur6NkbH9BGs 5XrZ3CLSLoJz2XuntW0wVqEqrfa8YOz/cNhxaOLvG4T+xPbQ8ihrxYwNfpuITmEKSto5 fw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2174.outbound.protection.outlook.com [104.47.55.174]) by mx0b-00273201.pphosted.com with ESMTP id 353pj3jhbj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Nov 2020 08:57:32 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D/5GS9dZlK67i8NTW0ldziwVU+o7LekVgtdekQ6GYgZBhPDENbuOhsXemQBBXz/zR1Tz9e162R0+rxvT8QMQ3YxfwgLpfOqqI3FgTWb2TyNFN7fSxI+G8T2AvHbrsp2zBhgjL2WTXrMKPsryHxF/yPbFeU29KrqWbntuANXVJE0SND+YrEfqZ540IaCvTbj+c81+gJ8wxstedGaeoUeF2Dl2vHwuHL/VrBpY7+wi6SLU2OKzlKn0iWIm8eFbdPq1Bu5i+3/SMVqum8QCEiW8M0bytNbQLhzv7JaM0BrCdGjc8eIBXr4E2v2gFD0Q2VFh5j5e5MISqXoXPBmkxcOBKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vDIPyVecewqHScqWTCKyW6KtpVwZoalJg85uk47V5+c=; b=KYcSGpaKjzGIteYBDmjr3zvtDq+Y2BC3iqLJ6CXWyq8HJFcWTTaS4kpMq7E089fZiepSb++DfIQUINJ8fzbIE2FJ43vYl3J4uiH8jvW6wqrnFRqpoDB6Y+xsjnGDKpii/lhO4maO8ZhJRy3DO4PXHIONB9Odd+JmYJbSh4xLNsnUrkErXRPLPuGsEcgqvVoudXTSGav/OS94PQxTkbG3aOilB6KjCnEffZijP7hcxz4RCYSA6ca8S2ga2F9gTx6id/xjiMsgjTyERSbeIAPYzTlkxeZU8PLQYDCKq/p5u4ma/WSnfKM/doJA+n9MaDXXMWSr5LR9XfVbLfKaMzYE7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vDIPyVecewqHScqWTCKyW6KtpVwZoalJg85uk47V5+c=; b=PDs7OwyOVpw+isA4QvZOECZwCm2KtApDFzJNUcfCwIGi9FhMuZKvTfOMNOz0mM1lm70XSzG1gY5K+8nw6FvhS8HWFIV6zSPHNdokQaQ3H0nJpfyW/vTx6WSEVMaF2JXSMU7qoUhCEgnQpA0Rwu80iFhcKaoSLyfOm6sS+23+r2s= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB6186.namprd05.prod.outlook.com (2603:10b6:5:11e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Mon, 30 Nov 2020 16:57:31 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6%5]) with mapi id 15.20.3632.016; Mon, 30 Nov 2020 16:57:31 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: IETF109:: IPv6-only adoption challenges and standardization requirements Thread-Index: AdbHOV0tF6kYnd7MT7ym2VWuD7UZWw== Date: Mon, 30 Nov 2020 16:57:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-11-30T16:57:29Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=8044e9ba-3619-4d4f-ba3b-15bdcb4a8984; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d87c1690-565b-4507-1261-08d8955106cb x-ms-traffictypediagnostic: DM6PR05MB6186: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ghe0P6yiW6bckG+JuWlocmRnzBZTOJzjbQa6xz81QO2Mt2F5SJssspwfKVD3n/5CwRpkx2XFyQ+eSDsusl87mI9NiUVF/TouRsCJIxYYBSPkmIyiV9II6BNyLod+MnLSlbFJoiJ8Dz6PnSPOSEuuOYOCdIQOvAlYsLaFOpXu2m3blcfvT97rfMvoOI7W9SFlcpIvAR6QMJUOZzRa2yZuEs3YpeuL3Kek+bo5MBWyTeOINejuM655wV8LcL1ZzeUfUK/J+ZJvutJUGEJKFxUHdTROtbEOdaGeU//OmZTG4eMgQePLFgXlLDgJV2YGc46Cl9VYz0q8ydQVH3NdeglldVZlLU5dWb7Hq+WyAbPX9UBB91IewaWCkzpDQNb6igIDXWP8EfKJxW+kkw/zlKb+iw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(316002)(71200400001)(52536014)(4744005)(55016002)(478600001)(5660300002)(166002)(8676002)(9686003)(66946007)(2906002)(76116006)(66446008)(66476007)(66556008)(64756008)(8936002)(26005)(6506007)(7696005)(86362001)(33656002)(6916009)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?HV/CWKIFn+xaus8E4950eoGOvnSNJpVsoUSxpm90CijnsU8a8LG1dlGA/YZJ?= =?us-ascii?Q?zpGAE++DnKQWR2nU5F8OvQw93ZgmfTOgysMtzcm7+eED2V79IKAquaHcEtRg?= =?us-ascii?Q?bGZCKUi+UOxNJSVoerhP2D0E/6yfqn1giyflN6RO30LFjnWUCkMTeabBfgYk?= =?us-ascii?Q?3hes2PyHXMKea1y89S+gYvk/lmXjaJ+JShfpawp1wRp1w5dk8HSNk+xPcXQ4?= =?us-ascii?Q?AceQaFY6dMoO1/WW8d/2ED7qvd/w49uai/TH9RZq0DyIcKbGU9AtHBXMyKUH?= =?us-ascii?Q?sImxkXTTxFo4lUg8GayWDryKFTskPQVSQEIUNGDkn3g3m92ViIiz4CPvBUdj?= =?us-ascii?Q?JezrcBvityWI9kzXwD3ih4r5/KAc6r4eGEHBwc3ITvKX8XipW7F5okLhsYgZ?= =?us-ascii?Q?syKg4eO4S8lBCHkZhFADu0l+e1yPz80tTGUeeWv04MOk67eZa7BVz1PSSZuu?= =?us-ascii?Q?heJFQSUsBd3pSKu2nk2EtVXeVhCa828CB5Hg9t+u1/V5xFogSUTVDgp0xdGL?= =?us-ascii?Q?lvZUVytCG+XQQ46qLLuft7hLi2ubAHUaftGXKXv5wOFBU/DGLuUshgc5P+bg?= =?us-ascii?Q?dHvyTrASCHw3MVVx0AN9fkiMVQnUSvVJwPekcE+UjD+0FLElH9Y/a5+64Wv8?= =?us-ascii?Q?w2Jyh90at6g5jJcn2FlKs2qIJwyFCt5H7880Yrj2lmXXqwWumWUh8xGolyQR?= =?us-ascii?Q?wL+KbYMRJ26f0kVidL8BtMkI+ojx6z4K1ek6dqh563tkhCByr9nHj9QjerBh?= =?us-ascii?Q?m1/DuMmqVKH/9un615zdroVYEulTtM9oL1O5KssOObs1dVvmZcVlDbF0GwQw?= =?us-ascii?Q?kiQV/GR/o3Y9mLWAh50X5WvvvhAxMCPfT4zt46PMXHHbINI09bgkmci75K8S?= =?us-ascii?Q?nNKWw9Q1UBbfQwqs9psKOSdgSxrQgInnY42RHKxYdiHYgDx9aS4K7LlaQ62W?= =?us-ascii?Q?pZrp+37IBKPTGttDEwCCiWhnRg2l5PMyzOLGqg2ylwU=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB634846E24826EF244B6AD4B8AEF50DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d87c1690-565b-4507-1261-08d8955106cb X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 16:57:31.0907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dC7DIuvTLfZT2arQcvJwmX1rPzoqF2/hpGPgitNiEJgDncNL1zA47RoC4S0OhLAMp8VWIycIBnP55qrinYCpgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-30_06:2020-11-30, 2020-11-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 priorityscore=1501 clxscore=1011 suspectscore=0 mlxlogscore=952 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011300109 Archived-At: Subject: [v6ops] IETF109:: IPv6-only adoption challenges and standardization requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 16:57:37 -0000 --_000_DM6PR05MB634846E24826EF244B6AD4B8AEF50DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We didn't have much time to discuss presentations at IETF 109. So, this wee= k, the chairs invite discussion of Ramesh Chandra's presentation IPv6-only = adoption challenges and standardization requirements. We will discuss each remaining presentation in the weeks to come. Ron Juniper Business Use Only --_000_DM6PR05MB634846E24826EF244B6AD4B8AEF50DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We didn’t have much time to discuss presentati= ons at IETF 109. So, this week, the chairs invite discussion of Ramesh Chan= dra’s presentation IPv6-only adoption challenges and standardization requirements.

 

We will discuss each remaining presentation in the w= eeks to come.

 

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

 


Juniper Business= Use Only

--_000_DM6PR05MB634846E24826EF244B6AD4B8AEF50DM6PR05MB6348namp_-- From nobody Mon Nov 30 09:47:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AD3A0FF7 for ; Mon, 30 Nov 2020 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 C-ClSkDXFzsd for ; Mon, 30 Nov 2020 09:47:33 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 D69153A0FD5 for ; Mon, 30 Nov 2020 09:47:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AUHlUVh014096 for ; Mon, 30 Nov 2020 18:47:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C4D57207F0D for ; Mon, 30 Nov 2020 18:47:30 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BA4A2207EFE for ; Mon, 30 Nov 2020 18:47:30 +0100 (CET) Received: from [10.11.244.229] ([10.11.244.229]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0AUHlUh6007656 for ; Mon, 30 Nov 2020 18:47:30 +0100 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <38cb7e50-a44f-0fa8-dd70-8caa7846cb78@gmail.com> Date: Mon, 30 Nov 2020 18:47:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IETF109:: IPv6-only adoption challenges and standardization requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 17:47:42 -0000 Le 30/11/2020 ŕ 17:57, Ron Bonica a écrit : > Folks, > > We didn’t have much time to discuss presentations at IETF 109. So, this > week, the chairs invite discussion of Ramesh Chandra’s presentation > IPv6-only adoption challenges and standardization requirements > . > > We will discuss each remaining presentation in the weeks to come. Hi, Thank you for pointing this. During the online meeting I remarked that the Page 4 says: "IPv6-only for 4G VVM User Equipment (UEs): - 90% get IPv6-only (/64 prefix) for VoLTE" I wanted to get confirmation that is the way that it is? UEs getting IPv6-only is a great step forward. But the /64 prefix for an UE might be a relatively limiting aspect if considering mobile hotspots. Alex > >                                                    Ron > > > Juniper Business Use Only > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 30 11:22:47 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797813A109A for ; Mon, 30 Nov 2020 11:22:46 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 mAD2bq_yaeXj for ; Mon, 30 Nov 2020 11:22:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ED93A1084 for ; Mon, 30 Nov 2020 11:22:36 -0800 (PST) Received: from [IPv6:2800:810:464:8164:2a:4307:16da:8e67] (unknown [IPv6:2800:810:464:8164:2a:4307:16da:8e67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C7E64283C5B; Mon, 30 Nov 2020 19:22:33 +0000 (UTC) To: Alexandre Petrescu , v6ops@ietf.org References: <38cb7e50-a44f-0fa8-dd70-8caa7846cb78@gmail.com> From: Fernando Gont Message-ID: <0c7c442e-a128-2ed4-4ef0-b1a56411990c@si6networks.com> Date: Mon, 30 Nov 2020 15:54:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <38cb7e50-a44f-0fa8-dd70-8caa7846cb78@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IETF109:: IPv6-only adoption challenges and standardization requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 19:22:47 -0000 On 30/11/20 14:47, Alexandre Petrescu wrote: [....] > > I wanted to get confirmation that is the way that it is? > > UEs getting IPv6-only is a great step forward. > > But the /64 prefix for an UE might be a relatively limiting aspect if > considering mobile hotspots. That's already the case for e.g. many fixed-line (e.g. Cable) ISPs. e.g., I get a /64 from my ISP. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492


Gyan Mish= ra

Network So= lutions Archi= tect=C2=A0

M 301 502-1347
13101 C= olumbia Pike=C2=A0
Silver Spring, MD


=
--0000000000003281f905b47ce63a-- From nobody Thu Nov 19 14:14:05 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78353A12D8; Thu, 19 Nov 2020 14:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuFCgNZTKqzv; Thu, 19 Nov 2020 14:14:02 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 2F1F63A12D0; Thu, 19 Nov 2020 14:14:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CcYqY6WhJz1ntJ8; Thu, 19 Nov 2020 14:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1605824041; bh=i1fwwOzHV/Qy+2suUqXueNe5zix60EVmY9zoMgOnyYU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=U/dw1FYA2pfdKXoCl1/el5Aa/NNmwyVC5N1mJkr7Po/2Aw8jYCigdd0TZzcU+Uf/8 btDYlTLMb1z4yE7UaKxrNGtWl6JttJzMS+7MKmhtHT0Xu3hb5pMJcG5JTrNLSlPdN8 7r0EYdx0KriEecAb0yeFkuWcfZRFJMU/MIc4aXeU= X-Quarantine-ID: <5S7UdWmAHS0A> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4CcYqY13Srz1nt3h; Thu, 19 Nov 2020 14:14:00 -0800 (PST) To: Gyan Mishra , otroan@employees.org Cc: IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> From: "Joel M. Halpern" Message-ID: Date: Thu, 19 Nov 2020 17:13:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 22:14:04 -0000 I am missing something in your reasoning. You seem to say at one point that (to paraphrase) "we can't do this because it does not work with the existing UE software". Any new solution where a UE delegates based on any change of any kind (including lengthening the prefix, shortening the prefix, or magically incanting new prefixes) requires that the UE be upgraded to know what to do with the information. I do not see how that differentiates any of the solutions. (Except "don't do anything", which I think we do not want to take.) Yours, Joel On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > On Thu, Nov 19, 2020 at 10:33 AM > wrote: > > > > > On 19 Nov 2020, at 14:58, Gyan Mishra > wrote: > > > > You would need a new option. It would likely be useful for the > requesting router to indicate interest in the option. Even hinting > at what prefix size it was expecting. > > Now can you explain to me again the reasons why this approach is > better than using the existing DHPCv6 protocol packets? > > > >     3GPP gateway does not support DHCPv6 > > 3GPP gateway doesn't support new option. What's your point? > > > >     The point of the v6ops presentation and this email thread is how to > “extend a /64” in the 3GPP use case  in slide 1 of the deck you compiled > a list of options and of the two I had highlighted in red were the > 64share v2 Cameron’s option and the variable slaac option.  So on the > call this morning Lorenzo shot down 64share v2 shorter prefix option as > even if the 3GPP architecture was updated to support longer prefixes and > even is the 3GPP gateway was able to send a shorter prefix with A flag > not set, all mobile devices per Lorenzo’s point would be broken as they > would not accept the shorter let’s say /56 prefix to build the slaac 128 > bit address.  So the bottom line is the 64share v2 won’t work unless we > update RFC 4291 and remove the 64 bit boundary. > >  So we are back to square uno - no viable solution > >  So now we had thrown out the longer >64 due to race to bottom worries > which I and others believe is Fud and as described in slide 10 of the > v6ops “race to the bottom slide”. > > So a happy medium /80 fixed boundary I came up with that I think solves > a lot of the issue and not just the 3GPP initial segmentation of > downstream devices problem statement. > > Since we have to update RFC 4291 for 64share v2 to work anyways to allow > for shorter prefixes, why not instead create a new bottom at /80 giving > 16 bits more of prefix length and shrinking the IID down to 48 bits. > Doing so you would not even have to update the 3GPP architecture as I > don’t know if that would fly or not.  Also this solves a few other > problems at the same time. > > > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > mainstream for operators for static addressing on router and switch > infrastructure and dhcpv6 subnets longer prefixes for network > infrastructure appliance clusters, NFV/VNF virtualization and server > farms.  On host subnets where there is a chance of mix of slaac hosts > with dhcpv6  devices the prefix length is stuck at /64.  So on these mix > addressing host subnets we cannot do longer prefixes following our ND > cache hard limit mantra to prevent ND cache exhaustion issues as > described in RFC 6164. > > So with the /80 new fixed boundary shifting prefix length 16 bits longer > and shortening the IID by 16 bits gives resolved the 3GPP issue which > 64share can work as is and subtending to downstream devices will now > work as a /64 is now equivalent to a /48 with 64k /80s.  Also BCP-690 > for broadband not all operators have adopted the shorter prefix lengths > /56 or /48 recommendations  and now that’s not an issue as the /64 would > now suffice. > > From an operators perspective that gain allows at least for 3GPP > massive growth and subtending with a single /64 allows the operators > such as Verizon with massive subscriber base worldwide can stay with > current allocations and don’t have to ask for /10. > > As 5G gets rolled out with Enhanced VPN framework and Network slicing > paradigm, the demand for shorter blocks and wearable multiple /48 will > be our new reality. > > Making that 16 bit shift now to /80 making a /64 the new /48 will give > broadband and 3GPP subscribers a ton of space to subtending their > networks we would be set for the future.  Especially with IOT the demand > for subtending will continue to grow astronomically. > > Also IANA does not have to get start in allocating the other /3 and > other available blocks. > > Lots of problems being solved here with a fixed /80 new boundary. > > Also with the existing random IID generation schemes which we have > tested on Linux kernel can do longer prefixes using RFC 4941 privacy > extension or RFC 7217 stable IID. > > Win-Win for all. > > Ole > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 19 14:50:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44493A0DD2; Thu, 19 Nov 2020 14:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rpo1QWypHN4; Thu, 19 Nov 2020 14:50:47 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D489B3A0DBC; Thu, 19 Nov 2020 14:50:02 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id t21so5593768pgl.3; Thu, 19 Nov 2020 14:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XgLKnd1QsHaZjHy6NDppQlytopPp/eWdELaajtbPNqA=; b=TDxJPBgBGP8nliOZVQl16AbAQRBRBj/Re0s23BwPHHJJLNslSZuPY0P2NS22P7WvbI 8Bk6q6qaRTbF2eFQEJWFDA0XX50BXzMCbLcyZ/ozHvy5FMM1X/lXoERGeXEq+CpdyTl1 8LDWsefZ/np2qJpWLsNoHYAeB0z/rvTOmVqD4qcyj2rcgNa/MgF2RL6qhyL5WL2aVtNl lC2POotOpFhB3O9XpSR2yumMm6U7dq6HrtvpHqiNYxgjyBaevz5Ayo+bG+hNDnajIksS WJsSUGCyc7y7017oXtBXPET8zkhqByiCRaywJErRWQTMJPl3cbBAizO/LM9hIMzkEwza pIlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XgLKnd1QsHaZjHy6NDppQlytopPp/eWdELaajtbPNqA=; b=nWFSrCvJHyhVSRdKp2GOE2hMQawpgUkqtufOyztzTO2ZOrrKokVguI7taTeBZi6aT6 UV1kKuBCB16cdtAzc2c19EX1xU26IrF6r9Zhp4x9jMN0k2G18gU5VBUW8eEoljgQi1Mj KRGCSOSZMq9pURAzetjethIShLe+u3nqkwxQNrOlvnnaCpWFDXgPyqxyP2nHGG88gxS5 J8tnD0RFewzlHT5eTWOjoBqzzUpZqnT80s5otOPItU80rm86tigtYAQDiSrbU1gzSrnr bhGMBf0s5TFxh8oawlybep0VFkpq7qgVjsUQs88Bj3X94xgjwZ5ZRgNt59zNrUnPcfae g8UQ== X-Gm-Message-State: AOAM533wmhEs+4qGKtbhhMV8zwuKZQ5OUfhrZOcrvUbaKp11I9Hu1DyI itHRvzEcBn0gaIq3p60EQZo/KLLjSnS/ew== X-Google-Smtp-Source: ABdhPJw5tH6JdWKYtbSBDAtVxN1X81yg/SjZXT+6blGCnW59KWH3W4YgQG5wdg8lwieqzNbc99g8aA== X-Received: by 2002:aa7:8c55:0:b029:18c:45ed:d87e with SMTP id e21-20020aa78c550000b029018c45edd87emr11076044pfd.76.1605826202269; Thu, 19 Nov 2020 14:50:02 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id q6sm960424pfu.23.2020.11.19.14.49.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 14:50:01 -0800 (PST) To: Gyan Mishra , otroan@employees.org Cc: IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> From: Brian E Carpenter Message-ID: Date: Fri, 20 Nov 2020 11:49:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 22:50:49 -0000 And if we had left the boundary at /80, as it was in 1995 (RFC1884), woul= d you now be arguing for /96, since in that case 3GPP would have settled = on /80? Sorry, but this is exactly and precisely a 16-bit jump in the race to the= bottom. And it breaks all existing SLAAC hosts on the way. The problem here is caused by 3GPP, but a solution like Cameron's should = work for everybody with minimal changes. Regards Brian On 20-Nov-20 11:03, Gyan Mishra wrote: >=20 >=20 > On Thu, Nov 19, 2020 at 10:33 AM > wrote: >=20 >=20 >=20 > > On 19 Nov 2020, at 14:58, Gyan Mishra > wrote: > > > > You would need a new option. It would likely be useful for the re= questing router to indicate interest in the option. Even hinting at what = prefix size it was expecting. > > Now can you explain to me again the reasons why this approach is = better than using the existing DHPCv6 protocol packets? > > > >=C2=A0 =C2=A0 =C2=A03GPP gateway does not support DHCPv6 >=20 > 3GPP gateway doesn't support new option. What's your point? >=20 >=20 >=20 > =C2=A0 =C2=A0 The point of the v6ops presentation and this email thread= is how to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case =C2=A0in s= lide 1 of the deck you compiled a list of options and of the two I had hi= ghlighted in red were the 64share v2 Cameron=E2=80=99s option and the var= iable slaac option.=C2=A0 So on the call this morning Lorenzo shot down 6= 4share v2 shorter prefix option as even if the 3GPP architecture was upda= ted to support longer prefixes and even is the 3GPP gateway was able to s= end a shorter prefix with A flag not set, all mobile devices per Lorenzo=E2= =80=99s point would be broken as they would not accept the shorter let=E2= =80=99s say /56 prefix to build the slaac 128 bit address.=C2=A0 So the b= ottom line is the 64share v2 won=E2=80=99t work unless we update RFC 4291= and remove the 64 bit boundary. >=20 > =C2=A0So we are back to square uno - no viable solution=C2=A0 >=20 > =C2=A0So now we had thrown out the longer >64 due to race to bottom wor= ries which I and others believe is Fud and as described in slide 10 of th= e v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. =C2=A0 >=20 > So a happy medium /80 fixed boundary I came up with that I think solves= a lot of the issue and not just the 3GPP initial segmentation of downstr= eam devices problem statement. >=20 > Since we have to update RFC 4291 for 64share v2 to work anyways to allo= w for shorter prefixes, why not instead create a new bottom at /80 giving= 16 bits more of prefix length and shrinking the IID down to 48 bits.=C2=A0= Doing so you would not even have to update the 3GPP architecture as I do= n=E2=80=99t know if that would fly or not.=C2=A0 Also this solves a few o= ther problems at the same time. >=20 >=20 > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is mainst= ream for operators for static addressing on router and switch infrastruct= ure and dhcpv6 subnets longer prefixes for network infrastructure applian= ce clusters, NFV/VNF virtualization and server farms.=C2=A0 On host subne= ts where there is a chance of mix of slaac hosts with dhcpv6 =C2=A0device= s the prefix length is stuck at /64.=C2=A0 So on these mix addressing hos= t subnets we cannot do longer prefixes following our ND cache hard limit = mantra to prevent ND cache exhaustion issues as described in RFC 6164. >=20 > So with the /80 new fixed boundary shifting prefix length 16 bits longe= r and shortening the IID by 16 bits gives resolved the 3GPP issue which 6= 4share can work as is and subtending to downstream devices will now work = as a /64 is now equivalent to a /48 with 64k /80s.=C2=A0 Also BCP-690 for= broadband not all operators have adopted the shorter prefix lengths /56 = or /48 recommendations =C2=A0and now that=E2=80=99s not an issue as the /= 64 would now suffice. >=20 > From an operators perspective that gain allows at least for 3GPP massiv= e growth and subtending with a single /64 allows the operators such as Ve= rizon with massive subscriber base worldwide can stay with current alloca= tions and don=E2=80=99t have to ask for /10. =C2=A0 >=20 > As 5G gets rolled out with Enhanced VPN framework and Network slicing p= aradigm, the demand for shorter blocks and wearable multiple /48 will be = our new reality. =C2=A0 >=20 > Making that 16 bit shift now to /80 making a /64 the new /48 will give = broadband and 3GPP subscribers a ton of space to subtending their network= s we would be set for the future.=C2=A0 Especially with IOT the demand fo= r subtending will continue to grow astronomically. >=20 > Also IANA does not have to get start in allocating the other /3 and oth= er available blocks. >=20 > Lots of problems being solved here with a fixed /80 new boundary.=C2=A0= >=20 > Also with the existing random IID generation schemes which we have test= ed on Linux kernel can do longer prefixes using RFC 4941 privacy extensio= n or RFC 7217 stable IID. >=20 > Win-Win for all. >=20 > Ole >=20 > --=20 >=20 > >=20 > *Gyan Mishra* >=20 > /Network Solutions A//rchitect=C2=A0/ >=20 > /M 301 502-1347 > 13101 Columbia Pike=C2=A0 > /Silver Spring, MD >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Nov 19 15:02:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96C3A134B; Thu, 19 Nov 2020 15:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czp2J__4pEOj; Thu, 19 Nov 2020 15:02:35 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C8D3A1348; Thu, 19 Nov 2020 15:02:35 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id s13so8182139wmh.4; Thu, 19 Nov 2020 15:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uZKNLsrLzlVnIgBJl7wj+Lc5CeyH3Mc29QFqa9Af+P8=; b=GCO6xpH1V6GzWNc9BbJkDqKNpsXhQKy9y6zQNUqUgXPc6RA38IaGGCcqBt1nzn643t ujzyIQBUltlG9eYp+he3LvPQISav9rbw9UYJJOjzMR2n2oRB6zezTB0T+ukgyDjGkbWH RPgIdG1MmhIBQMS4TvveuogJZJs7q+93HKrXdXyhvtlLB15bA52WAP3+xAn1x7yRNzeE EDqWyG1GsbTRL1nk67fZoSPV7QxZd4Z45dtikaowaZaMdPM5OQqvrwxjfJ2JkoQz3q5+ ISiZPmpLeWV/h8lc8lfMK/u45N9mAfLQ0CN4UsDFvrz98IE6R66RQD3DDHjjp5wWdQSh KdPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uZKNLsrLzlVnIgBJl7wj+Lc5CeyH3Mc29QFqa9Af+P8=; b=lGFoeFbZFxFBl94NJS4GH4uyhOOjLkfZTMn9d+3p0jIHJSpaHuDFpTRgpxXHECYCCj GrAJj7TEn9bzi/ZvqQ1ySKAsR8hnLZ8zbOR7aPwYXxSiZ6z24tNaM9r2zkn1Fr71WySo C8HB3X2LsQ21UDvsTZofHMPnG8gF0FjFwRxuZQFjF6lK1C0+gmbuOH7CNFgPRgI4VFOZ ee8oCaYcTjkfJ67i9OOyIT8Vg/lB+tFaWXhap2xr5nVaFPtZHqhk9e5D/Xls1iGS+bhU yV4xNmTep7vAHT57cosdL4Zqj7iiQewFubNM6TRp1iMxOu+CFoX5dOdsjIBhH3a4blmr SBWw== X-Gm-Message-State: AOAM530jvKbOC+SGa01igEFKW5YbfY9jkzY6YKFcwR3yWXgsiU/Sev9V 9LHcZfeTZjVFqtahdHwW62Q= X-Google-Smtp-Source: ABdhPJz0//ButhS9Nlgby13f20Aio8MkNC66HQ3MS/EjgVDJYU15UONFTY0VEFt6zv42nMOKA35EHw== X-Received: by 2002:a1c:c909:: with SMTP id f9mr6595753wmb.87.1605826953540; Thu, 19 Nov 2020 15:02:33 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:c48f:7b8d:7703:cdf4? ([2601:647:5a00:ef0b:c48f:7b8d:7703:cdf4]) by smtp.gmail.com with ESMTPSA id q5sm2302654wrf.41.2020.11.19.15.02.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 15:02:32 -0800 (PST) From: Bob Hinden Message-Id: <92CD1CEE-4453-4739-8418-34D20F350244@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1D49112C-0D0C-495F-B841-CD10EE135873"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 19 Nov 2020 15:02:28 -0800 In-Reply-To: Cc: Bob Hinden , Gyan Mishra , =?utf-8?Q?Ole_Tr=C3=B8an?= , IPv6 Operations , 6MAN <6man@ietf.org>, JORDI PALET MARTINEZ To: Brian Carpenter References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] The bottom is /112 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 23:02:37 -0000 --Apple-Mail=_1D49112C-0D0C-495F-B841-CD10EE135873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Nov 19, 2020, at 2:49 PM, Brian E Carpenter = wrote: >=20 > And if we had left the boundary at /80, as it was in 1995 (RFC1884), = would you now be arguing for /96, since in that case 3GPP would have = settled on /80? >=20 > Sorry, but this is exactly and precisely a 16-bit jump in the race to = the bottom. And it breaks all existing SLAAC hosts on the way. >=20 > The problem here is caused by 3GPP, but a solution like Cameron's = should work for everybody with minimal changes. +100 Either something like Cameron=E2=80=99s draft or a very minimal DHCPv6 = PD implementation that can run in a 3GPP environment. It doesn=E2=80=99t= need to be a full DHCPv6 server. Bob >=20 > Regards > Brian >=20 > On 20-Nov-20 11:03, Gyan Mishra wrote: >>=20 >>=20 >> On Thu, Nov 19, 2020 at 10:33 AM > wrote: >>=20 >>=20 >>=20 >>> On 19 Nov 2020, at 14:58, Gyan Mishra > wrote: >>>=20 >>> You would need a new option. It would likely be useful for the = requesting router to indicate interest in the option. Even hinting at = what prefix size it was expecting. >>> Now can you explain to me again the reasons why this approach is = better than using the existing DHPCv6 protocol packets? >>>=20 >>> 3GPP gateway does not support DHCPv6 >>=20 >> 3GPP gateway doesn't support new option. What's your point? >>=20 >>=20 >>=20 >> The point of the v6ops presentation and this email thread is how = to =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of = the deck you compiled a list of options and of the two I had highlighted = in red were the 64share v2 Cameron=E2=80=99s option and the variable = slaac option. So on the call this morning Lorenzo shot down 64share v2 = shorter prefix option as even if the 3GPP architecture was updated to = support longer prefixes and even is the 3GPP gateway was able to send a = shorter prefix with A flag not set, all mobile devices per Lorenzo=E2=80=99= s point would be broken as they would not accept the shorter let=E2=80=99s= say /56 prefix to build the slaac 128 bit address. So the bottom line = is the 64share v2 won=E2=80=99t work unless we update RFC 4291 and = remove the 64 bit boundary. >>=20 >> So we are back to square uno - no viable solution >>=20 >> So now we had thrown out the longer >64 due to race to bottom = worries which I and others believe is Fud and as described in slide 10 = of the v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. >>=20 >> So a happy medium /80 fixed boundary I came up with that I think = solves a lot of the issue and not just the 3GPP initial segmentation of = downstream devices problem statement. >>=20 >> Since we have to update RFC 4291 for 64share v2 to work anyways to = allow for shorter prefixes, why not instead create a new bottom at /80 = giving 16 bits more of prefix length and shrinking the IID down to 48 = bits. Doing so you would not even have to update the 3GPP architecture = as I don=E2=80=99t know if that would fly or not. Also this solves a = few other problems at the same time. >>=20 >>=20 >> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is = mainstream for operators for static addressing on router and switch = infrastructure and dhcpv6 subnets longer prefixes for network = infrastructure appliance clusters, NFV/VNF virtualization and server = farms. On host subnets where there is a chance of mix of slaac hosts = with dhcpv6 devices the prefix length is stuck at /64. So on these mix = addressing host subnets we cannot do longer prefixes following our ND = cache hard limit mantra to prevent ND cache exhaustion issues as = described in RFC 6164. >>=20 >> So with the /80 new fixed boundary shifting prefix length 16 bits = longer and shortening the IID by 16 bits gives resolved the 3GPP issue = which 64share can work as is and subtending to downstream devices will = now work as a /64 is now equivalent to a /48 with 64k /80s. Also = BCP-690 for broadband not all operators have adopted the shorter prefix = lengths /56 or /48 recommendations and now that=E2=80=99s not an issue = as the /64 would now suffice. >>=20 >> =46rom an operators perspective that gain allows at least for 3GPP = massive growth and subtending with a single /64 allows the operators = such as Verizon with massive subscriber base worldwide can stay with = current allocations and don=E2=80=99t have to ask for /10. >>=20 >> As 5G gets rolled out with Enhanced VPN framework and Network slicing = paradigm, the demand for shorter blocks and wearable multiple /48 will = be our new reality. >>=20 >> Making that 16 bit shift now to /80 making a /64 the new /48 will = give broadband and 3GPP subscribers a ton of space to subtending their = networks we would be set for the future. Especially with IOT the demand = for subtending will continue to grow astronomically. >>=20 >> Also IANA does not have to get start in allocating the other /3 and = other available blocks. >>=20 >> Lots of problems being solved here with a fixed /80 new boundary. >>=20 >> Also with the existing random IID generation schemes which we have = tested on Linux kernel can do longer prefixes using RFC 4941 privacy = extension or RFC 7217 stable IID. >>=20 >> Win-Win for all. >>=20 >> Ole >>=20 >> -- >>=20 >> >>=20 >> *Gyan Mishra* >>=20 >> /Network Solutions A//rchitect / >>=20 >> /M 301 502-1347 >> 13101 Columbia Pike >> /Silver Spring, MD >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_1D49112C-0D0C-495F-B841-CD10EE135873 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+2+YQACgkQrut0EXfn u6iFFAf+LmLVF6xtGhEU9yzbedWyUbfSVx1b7cv6fL1AQh7nPsfRms9z7Dmkb9ee /bW0B6azn6JErOY9ynphNMPQRcKMf+0SMY5f5qjkDGrgSMXU8K8Mnw1ztHquy+3W pf32woNIeZZ+J8OFyG/Y3ssZWLXoYCdnpd9otf91Yv8V74v5UzV0Z8NlYjw4rHIm 4DkNVG2dNydWSfzxne5yh74EtdaTrhavwq0AbkKB9IXk6YvY50JyVNaXPrH+X5ej d1v4ok8R/3fkLCdyMvX+0Uq+ml9aNuZF74crQQSlJgz1JZOrRPepOAAeE4PPdcF6 eJYNy5ZpLi9ORmD94WFuzcTjalTsbg== =fIEo -----END PGP SIGNATURE----- --Apple-Mail=_1D49112C-0D0C-495F-B841-CD10EE135873-- From nobody Fri Nov 20 01:05:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E6B3A1ADE; Fri, 20 Nov 2020 01:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKjEFUJ-NYld; Fri, 20 Nov 2020 01:05:53 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4B33A1ADD; Fri, 20 Nov 2020 01:05:53 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id d17so4537924plr.5; Fri, 20 Nov 2020 01:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:reply-to :content-transfer-encoding:message-id:references:to; bh=DfLDR+xS3Yf0OdmsNb0j+UKqpBf041DtC9gHmmXWvsc=; b=i2HQ6nJFVErAZv7vm5S0LBtDEsf4VgnadXgiecVDfYKlLyZh7L/xPHQ2K3tnNI0D+B g3quFyUFWgZU9zoEbtOpXm8xyX1fy8ti/XS95mqD5VT+JM/xE3jtT8YOdtM6oHb7WW5K /tfC97FoY4zbuiYpVpDQLSCWmi5EJxRyF2KHvdXsCsoWu/H2mYEsPLzrYRbTKvd0wB9b JUVsanSjikbx4O3/vbjeixzSNBF49TQ/1SE7y5w6LfF+ON0nj2WhriMxmosvHi5sdHap xOpPrc8P0Q4yYP6FFwxrh172IIK4/Emhmt8c0LHOuvMCWBBg5Nr1Eyuo8YM/fii5+D2A WEKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :reply-to:content-transfer-encoding:message-id:references:to; bh=DfLDR+xS3Yf0OdmsNb0j+UKqpBf041DtC9gHmmXWvsc=; b=GFtAaeOOowDEBiiYTbl+X4v2iEYR4LJ8ezvCgReORDKWjCR4UGY0Mw8juw6aMCUjs9 64Tk5MXLSh/WbEJugflYTKUD6TNhqfGQAJ5cTYynVxf+fgTIDCB1G3fRa2k+ozsvGt3H i/sx0zfZkzBpCZLQswCXLMSuXwpl8EplHOfUtpq/rOxARJc/OOAUyLoyTKwHQ58GgzAl RVcDht3YBngjiOMXu/+WdJ0QCoeRPvY16b62MS9prj055rbViG9VT3AU9ACtZeURQbDu 7vedOxh0uAUTsPflu7JRSi+hiigicfySekxkzFsN8DTVZ3tm1062mx+R6CFPrIXCfymm EGIg== X-Gm-Message-State: AOAM531zV9vlpbwctQj2DGUa7TXN/X1HyQR9DmrVaH+8JDTTo+0hPup4 Anc/utfhWC4mhd0dWR8++KmcKwevwYU= X-Google-Smtp-Source: ABdhPJyP97ImFrDDSYVw7NeJz2WxtBKDLpD+hgurCvJtbFfExlLJ5rpd4j9ThyHRqC2Z6sL8ttrviA== X-Received: by 2002:a17:902:9689:b029:d8:e310:2fa2 with SMTP id n9-20020a1709029689b02900d8e3102fa2mr13424794plp.42.1605863152779; Fri, 20 Nov 2020 01:05:52 -0800 (PST) Received: from ?IPv6:2600:8802:5800:1963::1043? ([2600:8802:5800:1963::1043]) by smtp.gmail.com with ESMTPSA id h16sm2523989pgd.62.2020.11.20.01.05.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 01:05:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.21\)) From: Fred Baker In-Reply-To: <9C2200A8-AB79-4A14-9B90-22771752D337@gmail.com> Date: Fri, 20 Nov 2020 01:05:50 -0800 Reply-To: V6Ops-Chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C2200A8-AB79-4A14-9B90-22771752D337@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.3654.40.0.2.21) Archived-At: Subject: Re: [v6ops] Followup from Ietf 109 v6ops meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 09:05:55 -0000 I'm not at all sure I understand what happened with last night's = meeting. I had meetecho issues - For me, it only worked on Chrome, and = failed completely on Safari and Firefox. In addition, there was the = Jabber problem when the meeting started, and several points at which = speakers - especially Ramesh - couldn't be heard or otherwise = experienced failures. I spend much of my time on Zoom or Webex, and = don't experience these issues there. <> Ramesh's talk was interrupted or delayed several times, and as he was an = invited speaker and his content ("issues with IPv6-only deployment in = India") was, I should think, very interesting in the context of "so = what's between us and turning IPv4 off" (I was surprised by the extent = to which he in fact runs IPv6-only as a service provider). I reminded = him that he was on the clock and otherwise let him talk. The effect was, = though, that we didn't have a lot of discussion with him or with the = remaining speakers. I'd like to remedy that with open-mike-on-the-list. Ron and I plan to go through all five talks (including Ramesh's, which = has no draft) a week at a time and simply invite list discussion. The = time of year is bad - we have US Thanksgiving next week, Christmas/New = Years in December, and Chinese New Years in January. As such, we plan to = run the agenda in sequence, asking for comments starting on 29 November = and again on 6 and 13 December and then on 10 and 17 January. In each = case, we plan to point people to the posted draft and the posted slides. = I haven't received the a/v file yet, but with any luck we can also point = to that. FYI, there are, at this instant, 76 countries from which Google reports = that it receives >5% of its requests using IPv6. A graphic regarding = them is at = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,in= ,de,my,gr,tw,yt,gf,vn,ch,fr,us,lu,mx,pt,br,jp,th,ae,hu,mq,lk,uy,fi,gb,ec,e= e,ca,nl,sa,gp,re,ie,tt,au,nz,ro,bo,ga,pe,at,no,cz,il,ph,tg,sg,ar,si,gt,pl,= mo,om,pr,np,mm,kr,co,sx,fo,bt,li,ke,md,lv,zw,is,am,rw,sr,se,sk,jo,ru,py,it= . India, and especially Reliance Jio, shows up at = https://stats.labs.apnic.net/ipv6/AS55836?c=3DIN&p=3D1&v=3D1&w=3D30&x=3D1 = (APNIC numbers). If anyone has issues with that plan, please drop a note to = v6ops-chairs@ietf.org. From nobody Fri Nov 20 01:06:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D6F3A1AEA; Fri, 20 Nov 2020 01:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmiyMDZw35W1; Fri, 20 Nov 2020 01:06:00 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B00D3A1B1F; Fri, 20 Nov 2020 01:05:59 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 92so5033909otd.5; Fri, 20 Nov 2020 01:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=agEg0jGErrQU2uilzY71nL9vrFGMYJJmt9ZMWE4illA=; b=eWvGGkdwyHMOt7yaqDvOt7D1r5r6784HDjt0JMbI24RIzakYNV1303KlBF+k/kgb+9 uMssSGKp25lMcCjQiltLnXU3K0OB4kjbtAfglZXTtIdT7qkdn2R691fJ6WpvHBbespeV mO8xLchVxO++UviJHTw1py3JZWIvmAqkxZZuqT9tx6ERB2Ta9cOm8NVwsNIJmRV/MOTi +ZqIAN97YgBe+5zRKtydu/xaJy+lAKqIDDaFVyoZIkBFS6+ZT3YgUiIVok530hiApUtY gx+Oq6C7lgELu8FdV3ZXPnXNS2HIxqmhn/UMAkOUDIbzBpZm/PTMi9fGIi3MLJLkUWp5 eaqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=agEg0jGErrQU2uilzY71nL9vrFGMYJJmt9ZMWE4illA=; b=NtRPn+q8enWDQ9pmc1NeVpLuTXzQWZIDZtqmC6PfMsVhOUayzgr4S6nPV3XYKCdOGF syW5bsUT6anR7XrM1jyIOJ+s5mn2WVBubSCGBsscAxXtiAvep8gBFhNRyV6n8icwIZsz b00BECP5DNHiuNDLJY8gV9s0Bs7BbpAwvYSJ9me+2qwDy/MmvXTK366QflhxaX3PAPg4 7bT2dnsr+tX/o6ti4njnS8+AjstEwmR/sYTTE0c3mW/VbPfn7yz1pLfoQOq6XnU+tTvF aqOCLojnMB7v6Rjrm6M8U6camcKctx0vMfdVNIq+HbFN7SFTd3tGxm8C1RnJ89z+OwNs Rb9g== X-Gm-Message-State: AOAM532+f2HfKgfb4/6O/a5dQBfV4gTG1mx7FOtubVcTK0unPC28pNXR n4/StRUDMaSQc0xWtDmEwOlmvEOsXjTU3cE3+HBI60lkjPg= X-Google-Smtp-Source: ABdhPJzaQgRtXz4bVzyB3AOgxLbJjdAx98U5VdH4vO+hPDjg/7jkOljQKU223cG2vFug/+MXdEXlcNNWZwSGeTsT23c= X-Received: by 2002:a9d:4c92:: with SMTP id m18mr13553418otf.248.1605863158810; Fri, 20 Nov 2020 01:05:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Fri, 20 Nov 2020 12:05:46 +0300 Message-ID: To: Tom Herbert Cc: tcpm , IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000002389c305b4862791" Archived-At: Subject: Re: [v6ops] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 09:06:06 -0000 --0000000000002389c305b4862791 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tom, As far as I know, the auto_flowlabels default is 1, which stands for: > 1: automatic flow labels are enabled by default, they can be disabled on = a > per socket basis using the IPV6_AUTOFLOWLABEL socket option And you get it all-in-one: FL changes after both SYN_RTO and RTO events. The change after SYN_RTO looks safe and can bring benefit for the end-user experience, while the FL change after the RTO outside of a controlled environment is causing a problem. And yes, we were able to detect it on a working system. One of the developers contacted NOC team that he has constant connection failures while pushing a significant amount of data, and it began when he started working from home. It proved out that there was RTO happening during the lifetime of the TCP session, the session jumped to another stateful L4 balancer and, as a result, the session got a timeout. At the moment we had to disable FL load balancing at our border routers and DCI - this solved the issue at the moment. If it is possible to remove from the default behavior change of flow label after RTO event, while keeping it for SYN_RTO would be great. =D1=87=D1=82, 19 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 18:36, Tom H= erbert : > On Thu, Nov 19, 2020 at 3:49 AM Alexander Azimov > wrote: > > > > Dear colleagues, > > > > I have added in the cc both v6op and tcpm for a reason and let me > explain why. > > > > It's clear that we are moving forward with load balancing that uses flo= w > label (FL). And the pressure will increase with SRv6 adoption. But at the > moment wide adoption of FL-based load-balancing may create significant > issues for TCP Anycast services. > > > > RFC6437 suggests putting hash from 5-tuple into FL value. And as far as > I know, there is no document that updates this behavior. This description > is perfectly fine, but what is implemented in the Linux kernel is > different: FL is carrying hash from 5-tuple with an additional seed, and > this seed is randomly changed after each RTO/SYN_RTO event. Here are > related patches: > > > > > https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.m= tv.corp.google.com/ > > > https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@he= rbertland.com/ > > https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/ > > > Alexander, > > The initial intent of the Linux flow label code was that the hash was > persistent for the lifetime of the connection; in fact we fixed a > nasty bug where the hash would change when a connection moved to TW > state causing some firewalls not to see the final ACK so they can > remove state. The feature where the flow hash is recalculated for a > failing connection should be optional and not the default behavior. If > this isn't what the implementation is doing I can take it up on Linux > netdev to fix it. > > Have you been able to show this behavior is actually happening on a > running system? > > Tom > > > > > This is a great thing by the way because in the data center environment > with multiple equal paths it gives a way to have pseudo-multipath TCP whi= ch > jumps between paths in case of an outage. There might be interest to writ= e > down an informational document for this. > > > > But the problem happens when TCP flows start jumping between anycast > points. If anycast service provides connection tracking (L7/TCP proxy, > stateful L4 balancer) the 'jump' may redirect traffic to another point, a= nd > with the adoption of FL load balancing by the transit providers - to > another location, where no TCP state is available. In other words, an > established TCP session breaks after RTO event. And it's not just a theor= y > - we already faced this kind of issue in our network, and it is really ha= rd > to debug. > > > > I wonder what you think is a proper solution: > > > > Making FL related RTO change as knob instead of default behavior; > > Adding negotiation behavior in TCP; > > Something else? > > > > I'm looking forward to your advice. If there is a document that > describes the above problem - please give me a reference. > > > > -- > > Best regards, > > Alexander Azimov > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Best regards, Alexander Azimov --0000000000002389c305b4862791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tom,

As far as I know, the auto_flowlab= els default is 1, which stands for:
1: automatic flow labels are enabled by default, they can b= e disabled on a per socket basis using the IPV6_AUTOFLOWLABEL socket option=

And you get it all-in-one: FL changes afte= r both SYN_RTO and RTO events. The change after SYN_RTO looks safe and can = bring benefit for the end-user experience, while the FL change after the RT= O=C2=A0outside of a controlled environment is=C2=A0causing a problem.=C2=A0=

And yes, we were able to detect it on a working s= ystem. One of the developers contacted NOC team that he has constant connec= tion failures while pushing a=C2=A0significant=C2=A0amount of data, and it = began when he started working from home. It proved out that there was RTO h= appening during the lifetime of the TCP session, the session jumped to anot= her stateful L4 balancer and, as a result,=C2=A0the session got a timeout. = At the moment we had to disable=C2=A0FL load balancing at our=C2=A0border r= outers and DCI - this solved the issue at the moment.=C2=A0

If it is= possible to remove from the default behavior change of flow label after RT= O event, while keeping it for SYN_RTO would be great.

=D1=87=D1=82= , 19 =D0=BD=D0=BE=D1=8F=D0=B1. 2020 =D0=B3. =D0=B2 18:36, Tom Herbert <<= a href=3D"mailto:tom@herbertland.com">tom@herbertland.com>:
On Thu, Nov 19, 2020 at = 3:49 AM Alexander Azimov <a.e.azimov@gmail.com> wrote:
>
> Dear colleagues,
>
> I have added in the cc both v6op and tcpm for a reason and let me expl= ain why.
>
> It's clear that we are moving forward with load balancing that use= s flow label (FL). And the pressure will increase with SRv6 adoption. But a= t the moment wide adoption of FL-based load-balancing may create significan= t issues for TCP Anycast services.
>
> RFC6437 suggests putting hash from 5-tuple into FL value. And as far a= s I know, there is no document that updates this behavior. This description= is perfectly fine, but what is implemented in the Linux kernel is differen= t: FL is carrying hash from 5-tuple with an additional seed, and this seed = is randomly changed after each RTO/SYN_RTO event. Here are related patches:=
>
> htt= ps://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.mtv.co= rp.google.com/
> https://= lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@herbertland.= com/
> https://lore.kernel.org/n= etdev/20160928020337.3057238-1-brakmo@fb.com/
>
Alexander,

The initial intent of the Linux flow label code was that the hash was
persistent for the lifetime of the connection; in fact we fixed a
nasty bug where the hash would change when a connection moved to TW
state causing some firewalls not to see the final ACK so they can
remove state. The feature where the flow hash is recalculated for a
failing connection should be optional and not the default behavior. If
this isn't what the implementation is doing I can take it up on Linux netdev to fix it.

Have you been able to show this behavior is actually happening on a
running system?

Tom

>
> This is a great thing by the way because in the data center environmen= t with multiple equal paths it gives a way to have pseudo-multipath TCP whi= ch jumps between paths in case of an outage. There might be interest to wri= te down an informational document for this.
>
> But the problem happens when TCP flows start jumping between anycast p= oints. If anycast service provides connection tracking (L7/TCP proxy, state= ful L4 balancer) the 'jump' may redirect traffic to another point, = and with the adoption of FL load balancing by the transit providers - to an= other location, where no TCP state is available. In other words, an establi= shed TCP session breaks after RTO event. And it's not just a theory - w= e already faced this kind of issue in our network, and it is really hard to= debug.
>
> I wonder what you think is a proper solution:
>
> Making FL related RTO change as knob instead of default behavior;
> Adding negotiation behavior in TCP;
> Something else?
>
> I'm looking forward to your advice. If there is a document that de= scribes the above problem - please give me a reference.
>
> --
> Best regards,
> Alexander Azimov
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops


--
Best regards,
Alexander Azi= mov
--0000000000002389c305b4862791-- From nobody Fri Nov 20 14:27:33 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D073A0ABC; Fri, 20 Nov 2020 14:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J071vGl2vVof; Fri, 20 Nov 2020 14:27:24 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDBA3A0AB9; Fri, 20 Nov 2020 14:27:24 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id t8so9227926pfg.8; Fri, 20 Nov 2020 14:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MF+VbQm7YxmoAuwF53T0mNj3jYTNsrsf/Qj7HOyEfFs=; b=kDOZdlkaKzEFpZaffmBV+7Z8CCDjJ+RCbeK7bFbxXz837LhH+mdi6QdSy2y0OxIamv XvAD7QtDrLQZdNLWSSGNXLFh3bYkpE9Niyh0vv8B1YDUkqTBZ8uVgiMMs/yT4IjCVPud VKafzaCDIg6DxlHEAAAoHhhLHmnFL/CFfEG2YO6foQbyN8Qyce3zrLpOKlujgP969IOi j0X6AFSjIgY3X1ySaQmhgkbco2OVGG6s5ycPeHHim1lmuy+YffrtO1KfaEqMpa5aQu9h szVZxkFM3a6o73lOPR84UHZQiEZRX5ocGsStWJrP4PZBwDWbvSi1878Sdd+e3mBEMBfk 87DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MF+VbQm7YxmoAuwF53T0mNj3jYTNsrsf/Qj7HOyEfFs=; b=YnY8Mr2tIeSzFTGrMvbeydOL6zeioq04YOBhAvgE6T4Vozt1MDz/Db5zlNlZX8ZVXn T5VSmNTI3XwaFYx1Ee0wxx3QIJhmHT+u98ndITAxqIAClFE+/YSjdjHBNOHURB0teFFq 9iHfWIgCPGDri23Ywg/yMvtxKjgsNJcZ1V80LW8iVYcsYb8CWJn96AKFYZxvw2QLXjK5 ypBSU+dNfMnkjFYTp8ENk3sSOmtDzm3mDVLTJherzQ3Jfe56vpjXSKmTZ1KZQlkvVuYL zFrkeaDsMulNPYXILMF+N0W1svSUK9sWfwiGPneKjIRCCHUckCuwc/1DRp0KI66i4Cgn qM+w== X-Gm-Message-State: AOAM530ouU2wJfeQnDmFnZJSjTfcnawcFnDITk2eWeUyLDFYsX7wjvtp /SXfLBHSMfxdn+VqdUuUxdvcFe+t1J1/1RgGlTAPImv2t18= X-Google-Smtp-Source: ABdhPJxvCxZ5K82hkN6sUp5dMR038852MP7JYV5WeCyLwxx/Numvj2ZdImDBIfwWIpBHA7rstSCYf3CHlKmBiBsv5f0= X-Received: by 2002:a63:9d01:: with SMTP id i1mr6508941pgd.50.1605911243964; Fri, 20 Nov 2020 14:27:23 -0800 (PST) MIME-Version: 1.0 References: <7ED24CC7-A719-4E9B-A5DC-3BA8EA7E3929@consulintel.es> <0F78C18B-7AD6-4AC7-AF1F-CA1ADCDEA6AB@employees.org> <9D7C4A75-ABB6-4194-9834-9BC898EAC8A9@employees.org> In-Reply-To: From: Gyan Mishra Date: Fri, 20 Nov 2020 17:27:13 -0500 Message-ID: To: "Joel M. Halpern" Cc: 6MAN <6man@ietf.org>, IPv6 Operations , JORDI PALET MARTINEZ , otroan@employees.org Content-Type: multipart/alternative; boundary="0000000000003cc5a505b4915965" Archived-At: Subject: Re: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 22:27:28 -0000 --0000000000003cc5a505b4915965 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (top posting) As I would like to clear the air as well as get to the crux of the v6ops presentation development results as well as next steps for this draft and the 6man variable slaac solutions draft: This thread was in light of Lorenzo kindly pointing out that upgrading 3GPP is not all that needs be done for Cameron=E2=80=99s 64share v2 to work - as= all mobile devices would stop working- as slaac would not would be effectively broken. The mobile device would receive a shorter prefix let=E2=80=99s say /56 but = not know what to do with it since it=E2=80=99s expecting a /64. So that a major gap and the only solution is updating RFC 4291 removing the 64 bit boundary allowing for shorter prefix and now as well longer prefixes to work and in that respect now provide the much needed parity with static and DHCPv6 which can do any prefix length. So that is a drastic change to RFC 4291. However, in light of this development on the v6ops 109 call, my balancing act of best of both worlds and also to keep everyone happy to make this a WG effort for this change by proposing in the subject heading /80 fixed boundary and not a variable slaac change allowing all bits vlsm. Basically stealing 16 bits for network prefix out of the IID, still keeping the fixed boundary so longer than 80 would NOT be allowed. A /64 would now be equivalent to a /48 with now 64k /80=E2=80=99s. This /80 would keep the operators and law enforcement happy as now 16 bits less helps traceability but is still long enough for 48 bits of privacy to IP correlation by attackers. This /80 would be a nice optimal balance as it would keep wired broadband and mobile handset customers happy respecting their privacy as the 16 bits less of heuristics is minimal change that will impact IP correlation by attackers. The IID as it=E2=80=99s less than the current 64 bit cannot use MAC based E= UI64 IID, which is not a problem as Mac based IID is not recommended as most all manufacturers use RFC 4941 and I believe Linux flavors some use stable IID RFC 7217. So now the 48 bit IID would require a random IID generation schema so can use either RFC 4941 privacy extension or RFC 7217 stable IID to generate the 48 bit IID. 3GPP subtending would now work issue mentioned in the problem statement draft without even having to use 64share as now longer prefixes up to /80 would be supported allowing for further segmentation of downstream devices. This also would help wired broadband and soon fixed 5G broadband proliferation where operators in light of BCP RIPE-690, are sill allocation via BNG gateways a /64, now operators can stay as-is, as the /64 would now be allowed to be further segmented supporting 64k /80s, way more then enough for SOHO. This would allow 64share if used by 3GPP operators to work and would not require the 3GPP specification to be updated. We don=E2=80=99t know even i= f the 3GPP architecture specification can be updated to support shorter prefixes and if the 3GPP consortium of operators would agree to it. So that is all theoretical of that change is possible. As with 5G with Enhanced VPN framework SR steering of high priority traffic, traffic isolation and Network slicing capabilities becomes mainstream and will soon be a real world reality and as fixed 5G broadband proliferation takes off and mobile 5G =3D=3D the idea of a wearable /48 wil= l really be many /48s. As this paradigm shift takes place, operators around the world will be clamoring after the RIR for massive blocks, I would say less than /8 more like a /5 or /4. If you do the math on the way high side a /10 yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is tiny number with the number of large size operators worldwide. With the massive proliferation of IOT devices and just about every home or office appliance on 5G, the problem now gets way exacerbated. As this evolution unfolds IANA will be scrambling to release all remaining /3 as well as all unallocated blocks to subvert RIR IPv6 address space depletion. Playing Monday night quarterbacking in hindsight we would never think this would happen in a million years, but we would see IPv6 on the verge of address space depletion. Unheard of but it can happen as the saying goes =E2=80=9Cwhen you build - they will come=E2=80=9D. It is true as history has taught that very important lesson. The answer to this real world problem is in the subject heading of this thread. This would also fix the day 1 issue I mentioned allowing mix of slaac devices with static and DHCPv6 up to /80. The variable slaac solution draft proposes a new RA PIO flag that would be used to signal longer prefixes, and would provide backwards compatibility so that devices not supporting woud ignore the flag and devices on newer code supporting would use the flag. We definitely don=E2=80=99t want to im= pact any existing devices on the existing 64 bit slaac boundary standard. Dmytro has tested the solution on Linux kernel signaling RA PIO flag and was able to successfully test any length mask and random IID generation both RFC 4941 privacy extension as well as stable IID RFC 7217. https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ If everyone is in agreement with what I have stated on this thread, I would like to ask the chairs for WG adoption as this is a WG effort. I would like to garner support from all 6MAN members with full consensus to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary. Kind Regards Gyan On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern wrote= : > I am missing something in your reasoning. > You seem to say at one point that (to paraphrase) "we can't do this > because it does not work with the existing UE software". > Any new solution where a UE delegates based on any change of any kind > (including lengthening the prefix, shortening the prefix, or magically > incanting new prefixes) requires that the UE be upgraded to know what to > do with the information. I do not see how that differentiates any of > the solutions. (Except "don't do anything", which I think we do not want > to take.) > > Yours, > Joel > > On 11/19/2020 5:03 PM, Gyan Mishra wrote: > > > > > > On Thu, Nov 19, 2020 at 10:33 AM > > wrote: > > > > > > > > > On 19 Nov 2020, at 14:58, Gyan Mishra > > wrote: > > > > > > You would need a new option. It would likely be useful for the > > requesting router to indicate interest in the option. Even hinting > > at what prefix size it was expecting. > > > Now can you explain to me again the reasons why this approach is > > better than using the existing DHPCv6 protocol packets? > > > > > > 3GPP gateway does not support DHCPv6 > > > > 3GPP gateway doesn't support new option. What's your point? > > > > > > > > The point of the v6ops presentation and this email thread is how t= o > > =E2=80=9Cextend a /64=E2=80=9D in the 3GPP use case in slide 1 of the = deck you compiled > > a list of options and of the two I had highlighted in red were the > > 64share v2 Cameron=E2=80=99s option and the variable slaac option. So = on the > > call this morning Lorenzo shot down 64share v2 shorter prefix option as > > even if the 3GPP architecture was updated to support longer prefixes an= d > > even is the 3GPP gateway was able to send a shorter prefix with A flag > > not set, all mobile devices per Lorenzo=E2=80=99s point would be broken= as they > > would not accept the shorter let=E2=80=99s say /56 prefix to build the = slaac 128 > > bit address. So the bottom line is the 64share v2 won=E2=80=99t work u= nless we > > update RFC 4291 and remove the 64 bit boundary. > > > > So we are back to square uno - no viable solution > > > > So now we had thrown out the longer >64 due to race to bottom worries > > which I and others believe is Fud and as described in slide 10 of the > > v6ops =E2=80=9Crace to the bottom slide=E2=80=9D. > > > > So a happy medium /80 fixed boundary I came up with that I think solves > > a lot of the issue and not just the 3GPP initial segmentation of > > downstream devices problem statement. > > > > Since we have to update RFC 4291 for 64share v2 to work anyways to allo= w > > for shorter prefixes, why not instead create a new bottom at /80 giving > > 16 bits more of prefix length and shrinking the IID down to 48 bits. > > Doing so you would not even have to update the 3GPP architecture as I > > don=E2=80=99t know if that would fly or not. Also this solves a few ot= her > > problems at the same time. > > > > > > As I mentioned in the v6ops deck presented that vlsm 0 to 128 is > > mainstream for operators for static addressing on router and switch > > infrastructure and dhcpv6 subnets longer prefixes for network > > infrastructure appliance clusters, NFV/VNF virtualization and server > > farms. On host subnets where there is a chance of mix of slaac hosts > > with dhcpv6 devices the prefix length is stuck at /64. So on these mi= x > > addressing host subnets we cannot do longer prefixes following our ND > > cache hard limit mantra to prevent ND cache exhaustion issues as > > described in RFC 6164. > > > > So with the /80 new fixed boundary shifting prefix length 16 bits longe= r > > and shortening the IID by 16 bits gives resolved the 3GPP issue which > > 64share can work as is and subtending to downstream devices will now > > work as a /64 is now equivalent to a /48 with 64k /80s. Also BCP-690 > > for broadband not all operators have adopted the shorter prefix lengths > > /56 or /48 recommendations and now that=E2=80=99s not an issue as the = /64 would > > now suffice. > > > > From an operators perspective that gain allows at least for 3GPP > > massive growth and subtending with a single /64 allows the operators > > such as Verizon with massive subscriber base worldwide can stay with > > current allocations and don=E2=80=99t have to ask for /10. > > > > As 5G gets rolled out with Enhanced VPN framework and Network slicing > > paradigm, the demand for shorter blocks and wearable multiple /48 will > > be our new reality. > > > > Making that 16 bit shift now to /80 making a /64 the new /48 will give > > broadband and 3GPP subscribers a ton of space to subtending their > > networks we would be set for the future. Especially with IOT the deman= d > > for subtending will continue to grow astronomically. > > > > Also IANA does not have to get start in allocating the other /3 and > > other available blocks. > > > > Lots of problems being solved here with a fixed /80 new boundary. > > > > Also with the existing random IID generation schemes which we have > > tested on Linux kernel can do longer p > refixes > using RFC 4941 privacy > > extension or RFC 7217 stable IID. > > > > Win-Win for all. > > > > Ole > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000003cc5a505b4915965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(top posting)=C2=A0

As I would like to clear the air as well as ge= t to the crux of the v6ops presentation development results as well as next= steps for this draft and the 6man variable slaac solutions draft:


This= thread was in light of Lorenzo kindly pointing out that upgrading 3GPP is = not all that needs be done for Cameron=E2=80=99s 64share v2 to work - as al= l mobile devices would stop working- as slaac would not would be effectivel= y broken.

The mobile dev= ice would receive a shorter prefix let=E2=80=99s say /56 but not know what = to do with it since it=E2=80=99s expecting a /64.
So that a major gap and the only solution is upda= ting RFC 4291 removing the 64 bit boundary allowing for shorter prefix and = now as well longer prefixes to work and in that respect now provide the muc= h needed parity with static and DHCPv6 which can do any prefix length.

So that is a drastic change = to RFC 4291.=C2=A0 However, in light of this development on the v6ops 109 c= all, my balancing act of best of both worlds and also to keep everyone happ= y to make this a WG effort for this change by proposing in the subject head= ing /80 fixed boundary and not a variable slaac change allowing all bits vl= sm.

Basically stealing 1= 6 bits for network prefix out of the IID, still keeping the fixed boundary = so longer than 80 would NOT =C2=A0be allowed.

A /64 would now be equivalent to a /48 with now 64k /= 80=E2=80=99s. =C2=A0

Thi= s /80 would keep the operators and law enforcement happy as now 16 bits les= s helps traceability but is still long enough for 48 bits of privacy to IP = correlation by attackers.

This /80 would be a nice optimal balance as it would keep wired broadband= and mobile handset customers happy respecting their privacy as the 16 bits= less of heuristics is minimal change that will impact IP correlation by at= tackers.

The IID as it= =E2=80=99s less than the current 64 bit cannot use MAC based EUI64 IID, whi= ch is not a problem as Mac based IID is not recommended as most all manufac= turers use RFC 4941 and I believe Linux flavors some use stable IID RFC 721= 7.

So now the 48 bit IID= would require a random IID generation schema so can use either RFC 4941 pr= ivacy extension or RFC 7217 stable IID to generate the 48 bit IID.

3GPP subtending would now work i= ssue mentioned in the problem statement draft without even having to use 64= share as now longer prefixes up to /80 would be supported allowing for furt= her segmentation of downstream devices.

This also would help wired broadband and soon fixed 5G broa= dband proliferation where operators in light of BCP RIPE-690, are sill allo= cation via BNG gateways a /64, now operators =C2=A0can stay as-is, as the /= 64 would now be allowed to be further segmented supporting 64k /80s, way mo= re then enough for SOHO.

This would allow 64share if used by 3GPP operators to work and would not r= equire the 3GPP specification to be updated.=C2=A0 We don=E2=80=99t know ev= en if the 3GPP architecture specification can be updated to support shorter= prefixes and if the 3GPP consortium of operators would agree to it.=C2=A0 = So that is all theoretical of that change is possible.

As with 5G with Enhanced VPN framework SR st= eering of high priority traffic, traffic isolation and Network slicing capa= bilities becomes mainstream and will soon be a real world reality and as fi= xed 5G broadband proliferation takes off and mobile 5G =3D=3D the idea of a= wearable /48 will really be many /48s.=C2=A0