Re: IPv6 prefix lengths - how long?

Mark Smith <markzzzsmith@gmail.com> Sun, 16 June 2019 15:15 UTC

Return-Path: <markzzzsmith@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 6E7E01201CF for <ipv6@ietfa.amsl.com>; Sun, 16 Jun 2019 08:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DklEExaxyVeL for <ipv6@ietfa.amsl.com>; Sun, 16 Jun 2019 08:15:12 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 5B8C71201CA for <ipv6@ietf.org>; Sun, 16 Jun 2019 08:15:12 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id 65so5263921oid.13 for <ipv6@ietf.org>; Sun, 16 Jun 2019 08:15:12 -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=X+V8UyGnuarvahjDiARwwgVP7scw0zNQG0yp8FfQXZg=; b=ZjDp3hp3wqS2lDebKbeehnzUuSOLGuxXji4M7uDu/u/apYQw0hPbRNrJ7nu9p1DpAr Q1euOg8gOnUTFZXhZl6pydJ0t90UM0qYyPGklYFiczlHYS1T9WPE2JHT26KwVyDO6nCN Cc3sS2B6CE5GevE9AjfYmGy/daVW6VRMXbvNwuKCPq1XpjKMBZW0iNt29YyOFyccJmlp 51D0tyrwj7NNXjzMPYTgrdZfQ2lH65LnzUkBcvj868DGk7DrJocyrapxn9VjIbmzTZFd zbMMLoA6p3x09c87ph3/miQXV1XYK3FjrlQr4V0AP0yyebdzqpJp+cFZvBgWj1iJDBGJ Flkg==
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=X+V8UyGnuarvahjDiARwwgVP7scw0zNQG0yp8FfQXZg=; b=C06sXv/yarP5HhJY7nRcb0rQmFInnUw+h6jgMCW478bnUu1chqop888aQA1PekQcaI F6RXCpXnZ9KFRrX/QlGNq6QXdHyBYdm2pNA4j0AgTpNF0rzff6vP7vR3DXPleMlunvwx qPIULcdoIi2OWW0OvLiFHSNN37i4/Iu5hhuwDxMh2viAiWkyQm1HRNNNhvAxZyEutST4 bfmhtq82O6vxfFLhanJCyHN8SrpGNR5mFI6hTzucF0ufaZiH0YFqrA9fG8Suh9W/kNe2 AVpfxvEdubzPi6IMmEQciC+FmKBqLeDt/DK7f2TQbGQYRDiFGJhHSqEA3rZ3OJ0DM/bf /qiA==
X-Gm-Message-State: APjAAAULgR0UduXXIgPYsLvO1qePkiYYm5dUzvU5JRoGEOH2n1itY1IT ZsQmCdFe6qEEwD54mV9d3Bb3SRaNo4sE0m1e1Lc=
X-Google-Smtp-Source: APXvYqx9ZnzvQe3YaLC46SnnJldficYAdq7BIYgrdz64/YDHbX6fbdSx7hJLg5ibvOa0n4b3yjTpCZ7jeGu7J1WMKPY=
X-Received: by 2002:aca:4bce:: with SMTP id y197mr8103163oia.38.1560698111341; Sun, 16 Jun 2019 08:15:11 -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> <CABNhwV3hA27hmdi4+WfK5ZhNPvta_d9anZA0+TJ2Uuj78kx4Cg@mail.gmail.com> <e2b733c7-f6ca-bda2-5493-72ed14a4cfa9@gmail.com> <CABNhwV35OEcD9Ote-bHEM5c_yhb2_sSpRec++g-bKC5L6pW1og@mail.gmail.com>
In-Reply-To: <CABNhwV35OEcD9Ote-bHEM5c_yhb2_sSpRec++g-bKC5L6pW1og@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 17 Jun 2019 01:14:58 +1000
Message-ID: <CAO42Z2zaLQE6uixXMK3J60Q=E8zB9dZm4-nxkpyGHDWhd9=Y4A@mail.gmail.com>
Subject: Re: IPv6 prefix lengths - how long?
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000873963058b7258ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HZENAT8QMXyiCjJnn_OKKxY6Axc>
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: Sun, 16 Jun 2019 15:15:17 -0000

The thing this reminds me of something that my Father taught me, which is
also well known.

"Just because you can do something doesn't mean you should."


On Sun., 16 Jun. 2019, 16:21 Gyan Mishra, <hayabusagsm@gmail.com> wrote:

> Alex
>
> I will add you to the authors.
>
> 6MAN,
>
> I have had a few requests for authors to help write the draft.  Please
> reply to this thread if you are interested in authoring the draft.
>
> I reviewed the merits of the draft to increase the prefix length with Ole
> & Bob.
>
> So as to the "how" to make this change the idea of how to make this work
> is feasible and can be done by using one of the  RFC 5175 reserved flags.
> This would have to be 100% backwards compatible to any existing deployments
> so  they are not impacted by this change.
>
> 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 variable prefix size 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 so I am
> proposing that we would make this variable and backwards compatible to any
> host that does not support the new flag or existing deployments so they do
> not have to change.
>
> So basically the router would send the RA ICMPv6 type 134 with this flag
> set and the host would see the flag and interpret that to allow any range
> of prefix sizes sent by the router to the host for the SLAAC prefix.  We
> can limit which nibbles would be acceptable or make them all work.  As the
> draft is composed we can dig into that further and how much granularity we
> want and how large do we want to go with the prefix and how small on the
> iid.
>
>   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
>
> As for the problem statement and Why ??? to make this change is really the
> most complex part of the draft that having valid concrete justification to
> make this change as "wasteful" is not a sound reason as the size of the
> just the current global uni space  2001::/3 not including the reserved
> prefixes is so tremendous enough to address the universe a good analogy on
> size is IPv4 is to the earth as IPv6 is to the universe.
>
>
> https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
>
>
> One idea I thought of is related to enterprise scenario with corporate
> intranets and the ability to do port scans on 64 bit iid with random iid
> heuristic which I agree the privacy extension of random iid is critical for
> any device directly connected to the internet but if you are within your
> own corporate intranet do you really need the 64 bit iid and why not give
> bits back to the prefix for that scenario.  There are ways to get around
> the scan question but in general the issue becomes moreso with large
> corporations where small & medium in general may have one IT team that
> handles IT security, desktop and network where large corporations they are
> completely separate organizations and so the IT security & desktop
> organizations do not have access to the routers to access the IPv6 ND cache
> to see active devices on the network.  A workaround is ping ff02::1 all
> hosts to discover all hosts and that does work and could be modified to do
> port scans.  There maybe other ways to get around the scan issue.
>
> I would like to poll 6MAN as to other ideas on the Why?? to make this
> change.
>
> 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
>
>
> https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
>
> On Sat, Jun 15, 2019 at 11:18 AM Alexandre Petrescu <
> alexandre.petrescu@gmail.com <alexandre.petrescu@gmail..com>> wrote:
>
>>
>>
>> Le 10/06/2019 à 07:34, Gyan Mishra a écrit :
>> > 6MAN chairs - Ole & Bob
>> >
>> > I would like to volunteer in writing the draft to increase the prefix
>> > length.
>>
>> If you write one, I would like to help.
>>
>> Alex
>>
>>   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 <mailto:gyan.s.mishra@verizon.com>
>> >
>> > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>> > <http://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
>> > <mailto: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 <mailto:james.cutler@consultant.com>>
>> >     wrote:
>> >
>> >>         On Jun 9, 2019, at 10:07 AM, Gyan Mishra
>> >>         <hayabusagsm@gmail.com <mailto: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 <mailto: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 <mailto:gyan.s.mishra@verizon.com>
>> >
>> > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>> > <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>> >
>> >
>> >
>> > --------------------------------------------------------------------
>> > 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 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>