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

[Daryll Swer <[e-mail]>]

Brian

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

Yeah, I just hope, no RFC draft comes out suggesting /80 or
anything smaller than a /64 as a minimum though.

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

My suggestion, for the place between a rock and a hard place, is typically,
to just tunnel your own PIA v6 prefix, over the internet, this way you
avoid NAT66/ALG nonsense in IPv6. Sure MTU/Performance will drop, but PMTUD
will work correctly, if MTU of underlay PHY on both ends and overlay
interface is configured correctly. If they are enterprise customers, then
typically, they will just run BGP with their own public ASN and handle it
that ways [/44 per site (I don't do /48 per site) is easily doable with v6,
compared to v4, /24 per site, which is financially, not feasible for most
businesses]. If they can't do PIA, typically, most of such folks, will just
disable IPv6 entirely and stick to IPv4. Some may use NAT66, yes.

I've been in situations like this personally, as well, unfortunately, some
ISPs with zero engineering staff (many ISPs do not have engineers working
in/with/for them), insists, they know IPv6 better than I do 🤷‍♂️, so here
I am with WireGuard and 1420 MTU, tunnelling my PIA space, if I'm unable to
secure L2 transport for my personal home to a willing transit provider
thousands of kilometres away from my actual home.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/l/58f0561d2a76ca7b315934f89f12c824232f8fc4?url=https%3A%2F%2Fwww.daryllswer.com&u=2153471&signature=0bc6419e93b1e0c6>


On Wed, 18 Sept 2024 at 09:35, Brian E Carpenter <
[e-mail]> wrote:

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