Re: IPv6 prefix lengths - how long?

[Alexandre Petrescu <[e-mail]>]

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
> --------------------------------------------------------------------
>