Re: IPv6 prefix lengths - how long?

[Gyan Mishra <[e-mail]>]

Sorry my math was off on the bit offset for /82 should be /80

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 - /80 SLAAC prefix sent to host

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

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


On Mon, Jun 10, 2019 at 1:34 AM Gyan Mishra <[e-mail]> wrote:

> 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: [phone]
>
> Email: [e-mail]
>
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>
>
>
> On Sun, Jun 9, 2019 at 9:25 PM Gyan Mishra <[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]>
>> wrote:
>>
>>> On Jun 9, 2019, at 10:07 AM, Gyan Mishra <[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]
>>> 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]
>
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>
>

-- 

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