[v6ops] Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-iids-problem-statement-01.txt

[Gyan Mishra <[e-mail]>]

Dear v6OPS

I did not have enough time to respond at the MIC on the questions asked.

So I would like to field some of those questions now and see how everyone
fields about this draft.

Issue #1 Problem statement discussion on fixed /64 provisioning systems as
reason to change the standard

Most against  the idea of changing the standard for the sake of
provisioning systems that are fixed at /64.

Other problems discussed that I think are valid reasons for variable IID -
what does everyone think?

- Requirements for VLSM and on a subnet with mix of SLAAC, DHCPv6 and
static which is almost always the case both static and DHCPv6 are stuck at
the /64 boundary as well.

- waste of address space having a 64 bit IID

- Private and enterprise subnets that don’t have privacy requirements
should be able to  have longer prefixes shorter IID / VLSM capabilities.
This has been a Day 1 ongoing concern and question by engineers deploying
IPv6.

Issue -#2 Race to bottom

Lorenzo Colitti and few others brought up up race to the bottom with the
/80 that ISPs would adjust to /80 as their new allocation.  Lorenzo kept
saying that ISPs would try to push to move the IID  further shorter with
this move opened door to race all the way down which didn’t make sense to
me.

The standard I am proposing would only allow up to /80 length prefix with
48 IID bits.  That would be the standard proposed so ISPs can at most
change their allocations from /64 to /80 but that would be all that’s
allowed since the SLAAC standard for IID length would be minimum of 48
bits.  There are a lot of ISPs that have the fixed /64 provisioning systems
issue so those would all be stuck at /64.

If GUI is a major issue which I don’t we say that ULA can be used for
variable IID and here since there is no race to bottom concern we can use
the entire bit range from /4 - /128

issue #3 Miscellaneous topics

NCE cache exhaust

I mentioned NCE cache exhaustion and Nick and few others said why do we
need VLSM we can address the entire network including P2P with /64 and no
issues in the chat and I mentioned to read /127 RFC 6164.

Issue #4 Technical issues -

technical issue with in draft mentioning that SLAAC is not variable and
that it is variable already and that is not where the fixed /64 boundary
comes which from RFC 4291 section 2.5.1.  I think there a bunch of drafts
that mention the /64 IID boundary mentioned in the draft.

Issue #5 Operational concerns with solution

Bob did not like the implementation issues with mix of modified and
unmodified devices even though not recommending he said it would be
impossible that we would definitely have mix devices and no way to avoid
and was the main reason for not supporting the draft.



Kind Regards

Gyan

---------- Forwarded message ---------
From: Mishra, Gyan S <[e-mail]>
Date: Fri, Jul 26, 2024 at 6:42 PM
Subject: Fwd: [E] New Version Notification for
draft-mishra-v6ops-variable-iids-problem-statement-01.txt
To: Gyan S. Mishra <[e-mail]>



---------- Forwarded message ---------
From: <[e-mail]>
Date: Tue, Jul 23, 2024 at 3:44 PM
Subject: [E] New Version Notification for
draft-mishra-v6ops-variable-iids-problem-statement-01.txt
To: Alexandre Petrescu <[e-mail]>, Alexandre Petrescu <
[e-mail]>, Dmytro Shytyi <[e-mail]>, Dusan Mudric
<[e-mail]>, Gyan Mishra <[e-mail]>, Naveen
Kottapalli <[e-mail]>


A new version of Internet-Draft
draft-mishra-v6ops-variable-iids-problem-statement-01.txt has been
successfully submitted by Gyan Mishra and posted to the
IETF repository.

Name:     draft-mishra-v6ops-variable-iids-problem-statement
Revision: 01
Title:    SLAAC Prefixes with Variable Interface ID (IID) Problem Statement
Date:     2024-07-23
Group:    Individual Submission
Pages:    32
URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Diids-2Dproblem-2Dstatement-2D01.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=yOpsg61LTbRxJVfirFFKnW_889SuNFJeQWVHZYnBPs7SroiFpUYTIAiYneYXFEX6&s=KE68wUuGE8eBtHyZXBH7xy5bkVxyNrwUEV470cRrOfQ&e=
Status:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Diids-2Dproblem-2Dstatement_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=yOpsg61LTbRxJVfirFFKnW_889SuNFJeQWVHZYnBPs7SroiFpUYTIAiYneYXFEX6&s=7I3vuUcKRci0Kx5N6lrk7sD5Xh6c5I8AEV_CvpgOopM&e=
HTMLized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Diids-2Dproblem-2Dstatement&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=yOpsg61LTbRxJVfirFFKnW_889SuNFJeQWVHZYnBPs7SroiFpUYTIAiYneYXFEX6&s=JN176NxWs36PKk_UbEEv9Zw2DuyM0RI4J0mY1c98Nqo&e=
Diff:
https://urldefense.proofpoint.com/v2/url?u=https-3A__author-2Dtools.ietf.org_iddiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Diids-2Dproblem-2Dstatement-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=yOpsg61LTbRxJVfirFFKnW_889SuNFJeQWVHZYnBPs7SroiFpUYTIAiYneYXFEX6&s=ugar0T977pbBkM0q6A8yH6-uF8ufScX6AtiecmpKnT4&e=

Abstract:

   In the past, various IPv6 addressing models have been proposed based
   on a subnet hierarchy embedding a 64-bit prefix.  The last remnant of
   IPv6 classful addressing is a inflexible interface identifier
   boundary at /64.  This document details the 64-bit boundary problem
   statement.



The IETF Secretariat