๐ค I hope you're wrong but also I doubt you are. Ik a lot of people have been making a fuss about Android and DHCP, I do hope Google will stick to their guns on this. I feel like whether they do or not will have a massive impact on the direction v6 goes with subnet sizes in the future. Mostly in business environments which largely haven't deployed v6 yet.
Scoopta
joined 1 year ago
I've been contemplating spinning up lemmy in my infra which is also v6 only...good to know about this gotcha...it blows that this community is on an instance that won't federate over v6 though ://
Yeah but what I'm getting at is that upper router routing /96s shouldn't be impacted. 10 /96s is basically indestinguisable from 10 /64s in terms of memory consumed. If I'm only using 10 subnets it shouldn't matter what the size of those subnets are as long as the count stays the same. It's when you start deagregating blocks into smaller chunks and consuming more of them than you would otherwise that you start eating table space. I can't think of a situation where someone would consume more /96s than /64s given they're both basically infinite addresses.
...you know...that's a really good point. Honestly this whole thought started because I saw someone adamantly defend not wanting to use an entire /64 and being annoyed Android didn't have DHCP and it got me thinking...if someone genuinely didn't care about the design goals of v6 are there good reasons to stick to them if DHCP works everywhere. Like I care about the elegance...but not everyone does. I've never seen ISPs assign a /128 although I have heard about it. I have seen 1x/64 assignments though which is only marginally better...but if you stop caring about clean /64 subnets then it becomes manageable without having to resort to an NDP proxy.
I personally have mixed feelings on Google's decision with DHCP. On the one hand I understand the frustration as it's not their place to dictate your network architecture...on the other hand I think it's admirable because it might be the one thing keeping that part of the v6 design goals alive when some wish it weren't.
Does it conserve router space? I get what you're getting at but if I have 10 subnets it doesn't really matter from a route table perspective if they're /96 or /64. What matters is subnet aggregation but I'm not sure the size matters?
๐ค does it actually break PD?...that's actually not an awful reason if it does. Would actually make sense...outside of this post I fall into the /64 everywhere crowd, minus the cases for /127. Your gripe with point 2 is fair...although I haven't come across any applications that need it...beyond the applications I've written that use it...because again IRL I'm in the /64 everywhere crowd. Thanks for the response though
I'm not looking for this type of answer. I'm aware of why v6 was designed with /64 subnets...I'm also aware we don't need to conserve addresses, both of these reasons are why I prefixed my question with the devils advocate bit. I understand all of this...then I proceed to describe why mac based, or more generally SLAAC, addressing doesn't matter to me because we have DHCP and DHCP works great, who needs SLAAC? You cannot convince me to use SLAAC, SLAAC is not important to me or my hypothetical use cases.
...also yes I'm showing v4 baggage...because again...devils advocate...this is a thought experiment, not a genuine question, in this I just think that a /64 is dumb...a /96 is much nicer because it's still plenty big while not being quite so excessive. Keep in mind, IRL I'm a firm believer of /64 everywhere...I don't carry v4 baggage...hypothetical me from this question does and it's not going away because 4.3B addresses is still PLENTY when you don't care about the purity of v6 design.
It is interesting how we've got this replacement that while slow is clearly taking off and yet people are still out there trying to re-engineer IPv4 as a replacement. Does that qualify as Stockholm syndrome?
This comment needs more upvotes...I did not know this was a thing and I'll try to remember it next time I hit a wall
I don't use pihole...didn't know that was a thing...still don't plan on using pihole but that's cool
I realized I hadn't actually written a reply to this, only to other people's replies.
There's a couple of problems with doing this. First and foremost is one of principals. IPv6 was designed with the explicit goal of killing off NAT, bringing it forward in this way is counter productive. That being said there's a much bigger problem here. IPv4 addresses are 32-bits, IPv6 addresses are 4 times larger at 128-bits. There is simply no way to fit an IPv6 address in an IPv4 packet header, it's simply too big. There are ways to do v6 internal with v4 external but that's only possible because v4 addresses are so small and can easily be fit inside the v6 address header, what you're trying to accomplish just isn't possible from a technical standpoint alone. I would recommend either dual stacking your network, that is running both v4 and v6 at the same time, or if you wish to go single stack you can run pure v6 internally and use NAT64 to get access to v4 services however there are a few caveats with this setup you should be aware of if you want to go down that road.
My guess is because it scares people. I've had other people ask me about it before because they think internal IPv6 is a ridiculous concept and IPv4 just makes so much more sense and is easier to remember. I personally don't get it but that's my guess. Dual stack is definitely the easiest way to go tho.
Me
Me after seeing this
Edit: apparently this only supports TCP for some reason which makes it more or less useless for my use case. I need UDP support as well.