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

[Brian E Carpenter <[e-mail]>]

On 18-Sep-24 14:29, Daryll Swer wrote:
>     Issue -#2
> 
> 
> I see no reason to ever go smaller than a /64. A statement in issue #1 chiefly “waste of address space” suggests, IPv4-centric thinking is driving this idea, to my understanding.
> 
>     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.
> 
> Many ISPs are still stuck on IPv4-centric mindset, this percolates down to their IPv6 deployment, I've seen strange deployments where for example, they don't do ia_pd, only do ia_na with a /128 GUA address and asks the customer to NAT66.
> 
> Then there are ISPs that do obscure subnetting models in their IPAM, like using a /120 as “large prefix delegation” because apparently a /64 or /56.
> 
> Recently I was contacted by an ISP, whose franchisee did something even stranger, they used ULA for the “WAN” side of the CPE and a /64 that changes every few minutes on the “LAN” side (ia_pd) and it lead to unpredicable behaviour on the CPE side (IPv6 connectivity didn't work at all).

As I said earlier, foolish people will do foolish things, and no RFC can stop that.

> 
> The /64 vs /56 issue is a problem already as many ISPs have locked down to single /64-only preventing multi-VLAN usage of IPv6, 

So what is your suggestion for their customers, if for some reason they cannot easily change to a less annoying ISP?

    Brian

> going smaller than /64 will only encourage the IPv4-centric mindset.
> 
>     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.
> 
> 
> In my opinion, this is a non-issue, because most network devices have default ICMPv4/v6 rate-limiting applied out of the box, this includes popular host OSes that are Linux-based for example. In addition to control plane rate-limiting out-of-the-box, if someone is trying to DDoS your network or specific IPv6 addresses (perhaps rDNS scraping?) to try and “exhaust” the NDP table, your internal DDoS protection systems will kick-in and scrub/re-route traffic anyway. And you can always configure a size for the NDP table, that you think is reasonable for your specific use-case.
> 
> Implementation details may also come into play, for example, if the link is P2P, and we use a /64, ::1 and ::2 on each device respectively and NDP learning has taken place and these two entries are on each respective device's table, they likely will remain in the table, even if you intentionally flood the NDP Table (ICMPv6 again has rate limiting on the control plane) as they were previously and still are “REACHABLE” state, they wouldn't just get removed from the table and the system will continue to probe it, therefore connectivity isn't affected.
> 
> I've stopped doing /126s-/127s for any network that I do IPv6 deployment for, /64 minimum, everywhere, including PtP, no complaints so far, from small networks to semi-large networks.
> 
> *--*
> Best Regards
> Daryll Swer
> Website: daryllswer.com <https://mailtrack.io/l/c173a9ccbcd36d8ae273cceaadfe8b0a3af00038?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=168cd34c0f2644db>
> 
> 
> On Wed, 18 Sept 2024 at 03:45, Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Dear v6OPS
> 
>     Here is a list of issues that were brought up during IETF 120.
> 
>     Right now we are picking up where 6man discussion left off on Issue #2 race to the bottom.
> 
>     Many Thanks!!
> 
>     Gyan
> 
>     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: *Gyan Mishra* <[e-mail] <mailto:[e-mail]>>
>     Date: Sat, Jul 27, 2024 at 3:12 AM
>     Subject: Fwd: [E] New Version Notification for draft-mishra-v6ops-variable-iids-problem-statement-01.txt
>     To: IPv6 Operations <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>>
> 
> 
> 
>     ---------- Forwarded message ---------
>     From: <[e-mail] <mailto:[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] <mailto:[e-mail]>>, Alexandre Petrescu <[e-mail] <mailto:[e-mail]>>, Dmytro Shytyi <[e-mail] <mailto:[e-mail]>>, Dusan Mudric <[e-mail] <mailto:[e-mail]>>, Gyan Mishra <[e-mail] <mailto:[e-mail]>>, Naveen Kottapalli <[e-mail] <mailto:[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= <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= <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= <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= <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
> 
> 
>     _______________________________________________
>     v6ops mailing list -- [e-mail] <mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]