Re: IPv6 prefix lengths - how long?

[Gyan Mishra <[e-mail]>]

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: [phone]

Email: [e-mail]

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 <
[e-mail]> 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: [phone]
> >
> > Email: [e-mail] <mailto:[e-mail]>
> >
> > 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 <[e-mail]
> > <mailto:[e-mail]>> 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
> >     <[e-mail] <mailto:[e-mail]>>
> >     wrote:
> >
> >>         On Jun 9, 2019, at 10:07 AM, Gyan Mishra
> >>         <[e-mail] <mailto:[e-mail]>> 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
> >         [e-mail] <mailto:[e-mail]>
> >         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: [phone]
> >
> > Email: [e-mail] <mailto:[e-mail]>
> >
> > 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> 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: [phone]

Email: [e-mail]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT