Re: IPv6 prefix lengths - how long?
Gyan Mishra <hayabusagsm@gmail.com> Mon, 10 June 2019 05:34 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8612004D for <ipv6@ietfa.amsl.com>; Sun, 9 Jun 2019 22:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 DnAa0P9S6_Oc for <ipv6@ietfa.amsl.com>; Sun, 9 Jun 2019 22:34:30 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 703E3120045 for <ipv6@ietf.org>; Sun, 9 Jun 2019 22:34:30 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id e3so5900133ioc.12 for <ipv6@ietf.org>; Sun, 09 Jun 2019 22:34:30 -0700 (PDT)
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=uUC9GnGuwb10RlJPV8ZdJyEP2icQr4EHhQ2BAwEi6/s=; b=HIpIv7R0U8UspTw/YzkPKGU5Bj05CpHfiBLwexs5wA0Wewl5RQxkZ4akTol6Y9FX7n KyBsJD/GDSFO4N6+uNfPbGnE4MMDGGvEigwbJcQEgQa4r9yGz6/ahW/mMPwNKKE4p2o/ ndc0Yijc5RoXQ3lQVwfd5QWH0KREMWZNO1syS2BbMXLGGDaiPEpfa/zayM3E/jd1GRzo eEFg2oICvxBaBXZUOIoggB2yolU4HGreMAzWLgxIRgMeERGdi79Kzdc2771MXIYB+JXI rsZmnEswM/vzftHHJ4QDqO57PH+0HE9y78xmqG3KTWVngurHEjG5xRT9JhnJO9eqAG0C F6Kg==
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=uUC9GnGuwb10RlJPV8ZdJyEP2icQr4EHhQ2BAwEi6/s=; b=R4WmInNgcJaIbA2JGcF6YbcjJMQzaJctMNGYG+l6oFwTASLpIc6Zw4vd/dGuvYHCSz u0MSjz+t3hZjD8BQyZDg8lmjkQHHDmdeT4L0Hdcs296K2B7/vrNj8PVju1CO7uyvP9cR cbL/zOYBAWnB5FOmjFuUEuxmZw9gVYDDAo3LYZ/akb9Hgf+5LwF0IJ/+wWkzTEJc4rtV oegjFTfqx6w6cmS1UcclO5GBPf4w7gRse8vRIrL9MLqpUVz2hAwRhXwVKwj35gw8bkiw VswWQh8c0kKlk2iVa/TjYhMWSLI2+jEUAIn1WlLLH4UOses4NK/lBAuLtkFIBqlmm0aV 2WcA==
X-Gm-Message-State: APjAAAWECQv62OJn3aZ3B/yftA9fJxwO/oCmz/zVmtOU8AfLWtCj8RH1 64SA9QXR9nSViR/FcbUVOfdoMga+ksa+rypzxTg=
X-Google-Smtp-Source: APXvYqzlpoYdX8+iQE4Qk79af0/aNGLev91cPJ0ppZrCafgqy/+DWsz1MX2z3oFFG/XZzijnnpQvyVmL9aRtosq0ZkQ=
X-Received: by 2002:a6b:b488:: with SMTP id d130mr35197207iof.58.1560144869501; Sun, 09 Jun 2019 22:34:29 -0700 (PDT)
MIME-Version: 1.0
References: <ee811897e2d2438e9c3592012b725ac3@boeing.com> <CAO42Z2xyenxV+z58VW_h4skbWz14hyVt2pUd32tLZ826UoZKZA@mail.gmail.com> <9826C993-3670-4D7B-8709-B3FDE2A79359@gmail.com> <EEBC9697-18A1-41DF-95FB-33D0F5098620@consultant.com> <CABNhwV2fX9LrwzuJX297CoF1XNNM2U=m22QSVWEtaS9PQkM3Dg@mail.gmail.com>
In-Reply-To: <CABNhwV2fX9LrwzuJX297CoF1XNNM2U=m22QSVWEtaS9PQkM3Dg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 10 Jun 2019 01:34:17 -0400
Message-ID: <CABNhwV3hA27hmdi4+WfK5ZhNPvta_d9anZA0+TJ2Uuj78kx4Cg@mail.gmail.com>
Subject: Re: IPv6 prefix lengths - how long?
To: James R Cutler <james.cutler@consultant.com>, Bob Hinden <bob.hinden@gmail.com>, Ole Troan <otroan@employees.org>
Cc: Mark Smith <markzzzsmith@gmail.com>, IPv6 IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000beb0bd058af18853"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IDpZH3EcW_EtCY7OQVRY0FlfcfI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2019 05:34:33 -0000
6MAN chairs - Ole & Bob I would like to volunteer in writing the draft to increase the prefix length. Please let me know if you agree with the basic content and premise of what I have stated below so I can get started on the draft. One of the technical justifications behind this MAJOR change in IPv6 addressing architecture RFC 4291 is that the current 64 bit iid is very wasteful and that many bits should be reallocated for the prefix reducing the size of the iid. The only justification that did exist for the 64 bit iid but I don't think is valid is with RFC 4941 SLAAC privacy extensions which given the issue with network administrators being able to track malicious hosts now with RFC4941 ends up protecting the end user with the pseudo random station id but at the same time protects the attacker as well. So in my opinion network administrators and for that matter law inforcement has a critical security requirement to track all addresses allocated and with address changing makes that impossible to track thus creating an attack vector for malicious activity. Not good at all for IPv6 security. RFC 7217 Semantically Opaque Interface Identifiers addresses this concern by making the SLAAC address stable so it does not change when on the same network and only changes when the host moves between networks. This RFC eliminates the major security hole created by RFC 4941 privacy extension with the changing pseudo random iid. The proposed iid size /82=48 bit iid /96= 32 bit iid /112-16 bit iid would use the RFC7217 Semantically Opaque Interface Identifiers - random but stable IPv6 address that does not change unless the prefix changes (Host moves to a different network) We have the option to increase on any nibble boundary /64, /68, /72, /76, /80, /84, /88, /92, /96, /100, /104, /108, /112, /116, /120, /124. I propose in the draft that this is done on any of the three 16 bit boundaries /82 /96 /112 to have a clear delineation between prefix & iid and that we would make this backwards compatible and would be disabled by default similar to the ipv6-only flag per OS vendor implementation and enabled only through RFC 5175 Reserved flag bit when the router sets the flag it would be cached by the host similar to the other RFC 5175 flags. Current Router Advertisement Flags Currently, the NDP Router Advertisement message contains the following one-bit flags defined in published RFCs: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |M|O|H|Prf|P|R|R| +-+-+-+-+-+-+-+-+ Figure 1: Router Advertisement Flags o M - Managed Address Configuration Flag [RFC4861] o O - Other Configuration Flag [RFC4861] o H - Mobile IPv6 Home Agent Flag [RFC3775] o Prf - Router Selection Preferences [RFC4191] o P - Neighbor Discovery Proxy Flag [RFC4389] o R - Reserved - bit 6 - IPv6 only flag - draft-ietf-6man-ipv6only-flag-05 o R - Reserved - bit 7 - Prefix length flag ===========> New option = Gyan draft So if this bit is set then the /82 /96 /112 prefix advertised on the router would get advertised down to the host in the RA advertisement below: EUI64 - Default - Router sets bit 7 - EUI48 format - /112 SLAAC prefix sent to host Router sets bit 7 - EUI32 format - /96 SLAAC prefix sent to host Router sets bit 7 - EUI16 format - /82 SLAAC prefix sent to host No change to LL format which would be still default /64 EUI64 iid. The IANA RIR's would not change what they are doing for now with the standard allocations to Service Providers. Service Providers would start advocating to customers to start using the new IPv6 addressing format at a major cost savings which would push them to migrate towards the new standard. /48. *How the new numbering schema stacks up as far ad space savings: (Pretty amazing when you look at the numbers below)* /48 Default Customer allocation = 64k /64's = Default /64 EUI64 / Privacy Ext = 64 bit ssid /96 Default Customer allocation = 64k /112's = Equivalent to the number of /64 subnets in a /48 ==========> Instead of SP's allocating /48's to customers would be able to allocate /96 to customers /82 Default Customer allocation = 64k /96's = Equivalent to the number of /64 subnets in a /48 ==========> Instead of SP's allocating /48's to customers would be able to allocate /82 to customers /82 Default Customer allocation = 4.2 Billion /112's = SP allocation /32 4.2 billion /64 subnets ==========> Instead of the RIR allocating /32's to ISP's would be able to allocate /82's to ISP's So this would be for the future for future SP's and Enterprises migrating to IPv6 now have the option of getting smaller registered blocks. Also existing SP's & Enterprises also have the opportunity to switch gears and change to the new addressing schema to save on address space. This would be a MAJOR game changer for IPv6 and really would ensure that IoT and other devices as we proliferate dolling out /48's and /32s as if the their is no end in sight given the massive size of the IPv6 space that at least we know that we are not being wasteful in our addressing architecture. Thank you Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT On Sun, Jun 9, 2019 at 9:25 PM Gyan Mishra <hayabusagsm@gmail.com> wrote: > > I concur with you on the cost benefit trade off. > > However I would like to state that there have been many tweaks to RFCs > written across the board across all IETF workgroups and cost has nevet > been a factor in the consideration since when you add a new feature or > change its really the developers doing the coding to determine feasablility > and cost as every draft proposed is new or change that is Depricates an old > RFC and there is always cost involved no matter how minor the change is but > just because there is cost involved does not mean you don't move forward > with the change or move forward with the change. > > If what you are staying that the cost would out weight the benefit we > would have to truly do a cost benefit analysis on every draft that is > approved and I don't think the IETF had the man power to do so. > > Of all the IETF WGs that I have been part of for many years cost had not > been the factor for that reason that determines wheathet the change is > approved or not. > > The major factor is if the change makes sense and if their is a problem > or gap or issue or problem or defect we are trying to solve and if we are > able to get consensus by the WG and chairs and ISG for approval. > > Gyan > > > On Sun, Jun 9, 2019, 11:54 AM James R Cutler <james.cutler@consultant.com> > wrote: > >> On Jun 9, 2019, at 10:07 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote: >> >> >> All your concerns are duly noted. >> >> As far as changing the prefix length I understand that with IPV6 it seems >> and maybe true that IPv6 exhaustion is not possible but that is what we >> said about IPv4 but that does not give reason to be wasteful. I believe 64 >> bits iid is wasteful. >> >> From many views, I must agree with you about “wasteful”. >> >> Where we part company is that the costs involved in changing away from 64 >> bits is more wasteful than your proposal. The especially applies to time >> (labor) costs, both for new RFPs, design and prototyping, and deployment >> costs. It has take around two decades to get this far with IPv6. Adding yet >> another detour to this journey is not an improvement. >> >> James R. Cutler >> James.cutler@consultant.com >> GPG keys: hkps://hkps.pool.sks-keyservers.net >> >> >> >> -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
- IPv6 prefix lengths - how long? Templin (US), Fred L
- Re: IPv6 prefix lengths - how long? Fred Baker
- Re: IPv6 prefix lengths - how long? Michael Richardson
- Re: IPv6 prefix lengths - how long? Michael Richardson
- Re: IPv6 prefix lengths - how long? Nick Hilliard
- Re: IPv6 prefix lengths - how long? Michael Richardson
- Re: IPv6 prefix lengths - how long? Brian E Carpenter
- Re: IPv6 prefix lengths - how long? David Farmer
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- Re: IPv6 prefix lengths - how long? Philip Homburg
- Re: IPv6 prefix lengths - how long? James R Cutler
- Re: IPv6 prefix lengths - how long? Mark Smith
- Re: IPv6 prefix lengths - how long? Mark Smith
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- Re: IPv6 prefix lengths - how long? James R Cutler
- Re: IPv6 prefix lengths - how long? Mark Smith
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- RE: IPv6 prefix lengths - how long? Templin (US), Fred L
- Re: IPv6 prefix lengths - how long? Yucel Guven
- Re: IPv6 prefix lengths - how long? David Farmer
- Re: IPv6 prefix lengths - how long? Mark Smith
- RE: IPv6 prefix lengths - how long? Manfredi (US), Albert E
- Re: IPv6 prefix lengths - how long? Mark Smith
- Re: IPv6 prefix lengths - how long? Fred Baker
- Re: IPv6 prefix lengths - how long? JORDI PALET MARTINEZ
- Re: IPv6 prefix lengths - how long? JORDI PALET MARTINEZ
- Re: IPv6 prefix lengths - how long? Alexandre Petrescu
- Re: IPv6 prefix lengths - how long? Alexandre Petrescu
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- Re: IPv6 prefix lengths - how long? Gyan Mishra
- Re: IPv6 prefix lengths - how long? Mark Smith
- Re: IPv6 prefix lengths - how long? Mudric, Dusan (Dusan)
- Re: IPv6 prefix lengths - how long? Gyan Mishra