Re: IPv6 prefix lengths - how long?

[Gyan Mishra <[e-mail]>]

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