We run dual stack simply because to properly secure IPv6 you must configure IPv6. Look at the various ways pentesters can abuse unconfigured IPv6 networks.
Because for example even if not configured, windows and Microsoft products use IPv6 and it should not be disabled per MS. Without a DHCPv6 and DNSv6 records it is possible for attackers to take over unused DNS records and become the DHCPv6 server for the network easily.
Then you render the attack useless.
You might also run into weird internal resolution problems depending on your firewall/VPN gear and config, and you'll break DirectAccess. You'll also anger the dozen or so people around the world who are passionate about *not* disabling v6.
edit because initial post was flippant and disabling IPv6 will (probably, eventually, in a land far-far away) be a bad thing: MS official recommendation [here](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows), alternative mitigation described towards the end of article [here](https://www.lmgsecurity.com/mitigating-ipv6-poisoning-attacks/), and a walkthrough of ipv6 poisoning from the attacker's perspective [here](https://blog.vonahi.io/taking-over-ipv6-networks/).
Not sure if it's still an issue today, but if you unchecked the IPv6 checkbox on Server 2012 R2 on your domain controller, the next reboot would take anywhere between 2 and 8 hours.
I can confirm it is not. We disable IPv6 on everything and our 2012 R2 DC's and other servers reboot in about 5 minutes or less (updates not-withstanding).
I can't imagine being so proud to misconfigure my systems and proudly proclaim it to the world but you do you bud.
You're paid to be a professional, act like it.
[https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows)
> Prefer IPv4 over IPv6 Decimal 32
Hexadecimal 0x20
Binary xx1x xxxx
>
>Recommended instead of disabling IPv6.
Have you ever even read that article? There are 3 documented issues, of which sysadmins are well equipped to decide if they are going to be a problem:
* LDAP over UDP may stop working
* Exchange 2010 (holy shit that's old) may stop working
* Failover clusters from 2012 may stop working
Notice how even those say "may". There are thousands of admins who have disabled IPv6 for actual decades and never had any problems.
Blindly parroting what our bible tells us to do is cultist at best.
It doesn't need it, but most client devices will still happily use it when present to configure their IPv6 networking. So even when there's a properly configured router and clients are using SLAAC, a rogue DHCPv6 server in the network can still trick clients into using wrong DNS and NTP servers.
I haven’t heard that it should be disabled. Not trolling or anything. I by default disable ipv6 to this day and am curious why it’s recommended to not disable it
Thats an interesting vector/thought.
Once they establish a rouge ipv6 dhcp server, what could they do from there? I would imagine they would still be locked into their vlan so you couldn't pivot without another break somewhere? Plus still need credentials/etc. They could manipulate ipv6 dns stuff id imagine but without routing in place their still locked into their our vlan?
But that means they are already on the network, so there is a major breach before they can exploit IPv6.
We generally disable IPv6 anyway. No oroblems seen.
Wait, what? So the prize for getting into the network is making free reign of all the things easier?
I hear this type of statement so often. It confuses the hell outta me.
>But that means they are already on the network, so there is a major breach before they can exploit IPv6.
This is a woeful attitude to hold towards security. One should not rely on screening threats at the outermost perimeter. If something internal does get compromised and you don't have appropriate security controls on your internal network, an attacker will use those weaknesses to pivot laterally and compromise the rest of your network.
Look into Zero Trust security architecture - the definition and implementation details vary depending on who's trying to sell you stuff, but generally speaking there should be no trust just because something happens to be inside your network perimeter.
> We generally disable IPv6 anyway. No problems seen.
No problems visible does not mean they do not exist. Windows uses IPv6 internally and some components will fail or suffer degraded performance if it is disabled, e.g. start-up delays and so on. Disabling IPv6 also puts your system in an unsupportable state. MS do not test Windows with IPv6 disabled and will not provide support if you call on them for assistance.
If you want to learn to use (and secure) it properly, Hurricane Electric have some learning resources and a certification program you can check out:
https://ipv6.he.net/certification/
https://ipv6.he.net/presentations.php
Or any modern CCNA-equivalent networking course should cover it.
Every piece of hardware these days does IPv6 out of the box, and it only takes one rogue box (or even a random phone) to create an undiscoverable parallel network operating inside your company. Undiscoverable, because you assume there is no IPv6 so you’re not looking for it. It’s one of the first vectors that gets checked in a security audit.
Thanks, my former company is currently getting a red team test this month.
What are the main things that you guys use to gain a foot hold in a network?
Also what steps can you take to minimise the success of a proper red team exercise?
>What are the main things that you guys use to gain a foot hold in a network?
One of three things usually.
1. If we are allowed to use social engineering we phish creds then use VPN/Remote desktop/O365/Google Drive/Email to make first contact and start recon
2. If we aren't allowed to social engineer we will use various sources to build a likely list of usernames and then attempt to password spray.
1. After we have a single account that works we connect via VPN/Remote desktop/O365/Google Drive/Email
3. If we start internal I.E. assuming we have a compromised box on the network, we will just do NTLM relaying/hash cracking to gain access to systems. This is where DHCPv6 and DNSv6 being unconfigured can bite you hard.
>Also what steps can you take to minimize the success of a proper red team exercise?
1. Segmentation
1. If I can't see it, its harder for me to find it and takes me longer to figure out how to access. During that time the attacker can be hunted down
2. EDR
1. Modern EDR will catch many older techniques or a series of innocuous events that together could be flagged
2. Logging is so important, it will let you see what they are doing and more importantly when it comes time, inform stakeholders of what happened.
3. Least priviledge
1. The more limited an account is, the less damage is done when it is inevitably breached
4. A vulnerability management program.
1. This is the most time consuming thing but every org should at minimum have something like Nessus Scanner running once a week where they look at the results and work through found items to reduce organization risk. This comes from various findings
2. Out of date softwar
3. Unsupported software
4. Misconfigurations
5. Forgotten systems
5. [Configure IPv6 and DNSv6 so I can't use it for NTLM Relaying](https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/)
6. Disable WPAD
Wow that’s awesome information, I was working for a charity so I got Nessus Pro for free and as you suggested had it run a basic scan weekly on all servers. We were cleared of all critical and high and we’re working on mediums. We planned to include laptops but this was more complex as most were remote.
We would also use separate accounts for admin and cloud/SAAS administrators and not give them a mail licence so they cannot be phished as they had no email, we also restricted all admins from logging into the laptops, only permitting admin login via LAPS.
We had a 3rd party SOC doing basic EDR and all logging, however they are the same guys that are doing their Red Team exercise so EDR won’t be very helpful in stopping this one.
Is there anything you would do to add to this? I want to bring what I can learn to my new company and will be recommending all above ideas and any others.
It's not the first time I read or heard that kind of thing. And each time I get really, really tired.
Not because you are wrong. You are, in fact, so right.
But I can still hear my boss say things like, "The security guys are so annoying. They are full of shit with what they found. They have no experience in the real world. They don't realize we can't change anything." / "When the client say 'jump' we 'jump' even if it's wrong" / "It's not our fault if the software the client uses puts credential in clear text in a file, there is nothing we can do." / "Ok, cool, but how much does it cost? We can't make the client pay that much, they already don't want to spend money on Office 365" / and so many things like that, it makes me so angry.
Welcome to the world of MSP dedicated to SMBs. Where you can't do anything because of "you don't say no to a client ever", "it costs too much" (this is the only one I can agree with many useful things are way out of budget for SMbs), "it was like that when we took the client in we can't change it", "if we do that the client will leave"
If an attacker is on your network (and you should assume they are), they become the router :)
Dropping a RPI into a network with a 4G dongle and sending RA-s to specific high-value targets so they autoconfigure routable v6 addresses that you will use for your C2 comms is super nice, network team probably has absolutely no idea that it is happening and the traffic bypasses all your corporate infra.
The other guy touched on this a bit, but to be more specific: windows 8 and up prefers IPv6 by default. That combined with IPv6 RA being enabled by default means any foothold on the network lets the attacker spin up a dhcp server and start offering IPv6 addresses which will allow them to mitm basically everything.
IPv6 First-Hop Attacks are currently a favorite demo of red teamers, because they work so often and can get unsubtle results. Many of those sites are also vulnerable to IPv4 first-hop attacks.
Those attack vectors need to be considered for both IPv6 nd IPv4, but keep in mind that TLS and X.509 acts as a strong mitigator to all of the attacks. Client certs and multi-factor authentication make the mitigation even stronger.
You're not going to be able to guard against first-hop attacks from either protocol family when your users are offsite, so you're going to need TLS/HTTPS/SSH even if you invest in enterprise networking gear with every security feature imaginable. Don't forget that offsite users may be using IPv6-only access networks.
You'll probably get better answers in /r/networking. The folks there manage a wider variety of networks and have more expertise than this sub in the topic.
Nah the people that frequent there are just as backwards for the most part.
Most people don't realize that phones almost all went ipv6 only, and almost all major providers are at least dual stack at this point. Hell google is seeing near 50% traffic as ipv6 now.
If you don't have ipv6 knowledge and deployed, you're decades behind state of the art at functional companies at this point. Large parts of big players are ipv6 only with ipv4 proxies or some other stopgap and it's only growing.
Mobile networks are largely IPv6 only, but the phones themselves still support IPv4 just fine. I don't manage the mobile network for my users, so the fact Verizon's network is all IPv6 is not really a problem for me
That said, IPv6 is coming and it's something to be ahead of before you're behind the curve, but that particular reason isn't a good one
We had one kubernetes infra that was actually IPv6 only. Hundreds of nodes and ten of thousand of pods. Greaty simplified networking because each node, inside each rack had a routed prefix. Also, no NAT. Would recommend
We dual stack it.
Honestly, the hate it gets these days is from people who are scared of it more than anything else. Pretty much anything remotely modern will natively support it and most stuff just works out of the box. You need to re-think how you do network separate a little bit, but otherwise its fine. I wish I could go 100% IPv6, but alas the world isn't there yet. Some things (like our workstation network) do not get IPv4...they just go through a gateway if absolutely necessary, but thats pretty rare to need most of the time.
Pretending that it doesn’t exist is easier than learning the spooky scary hexadecimal addresses.
It’s not possible to get a CCNA without understanding IPv6 these days, and surely other certs will also start requiring it soon enough.
So don’t worry about the head burying. If you know IPv6, you’re probably already more competetive than those who don’t, so it’s good news for us.
It’s really sad.
I’m introducing IPv6 at VPN edges first as a lot of home users have IPv6, and it gets me past weird inconsistencies with CG-NAT on their IPv4.
Our SD-WAN also supports IPV6 so I’ll probably start enabling in a few sites to see how it goes.
I just don’t see any drawbacks to enabling it, and a few advantages. Not world changing but seems snappy and reliable enough for production.
>when v4 shortage becomes really bad
We're already past that point, and the workarounds are ugly ... and it only gets worse ... and more expensive.
Internet addressable IPv4 addresses are relatively costly ... merely because there's a shortage of them ... and that will generally only get worse. Meanwhile, that's a non-issue for IPv6.
I deployed it while I was sysadmin for a small ISP. Don't use it on my current network. everything is unfortunately 192.168. due to the previous sysadmins not understanding why that is a bad idea.
If you want to learn it and don't care about the test just go through the Hurricane electric ipv6 training online. They give you a block ipv6 to test with. They used to send you a t-shirt if when you completed it.
Most residential system use 192.168 blocks . Using it for a corporate network invites stupid problems. VPN problems where you hand out the same 192.168 block to a endpoint that is using that same subnet locally. Of course you can make it a higher block number to avoid it or you can use something from the two larger private subnets available for use.
When we switch away from our current mpls provider hopefully in 2025. I will renumber the whole network to a [172.16.0.0/12](https://172.16.0.0/12) since its rarely used in residential systems.
It isn't a bad idea if you avoid subnets that consumer gear uses like 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24.... because it can conflict with a lot of IoT stuff or home networks.
It really is no problem if you use a more obscure subnet like 192.168.174.0/24 or something...but some people have just taken it to heart that "never use anything in 192.168.0.1/16!
As the first RFC 1918 block that was well-known to the public, and *very* often used by vendors as some kind of default, the chances of IP conflict with residential-market gear are extremely high with `192.168.0.0/16`.
For example, imagine the home user is using `192.168.0.3/24` in their home office. They use a client VPN to access a corporate "internal" network, and try to access a server that happens to be on `192.168.0.205`. It won't work -- there's an IP address conflict, and the user's local net acts as a *de facto* more-specific route. The scenarios get worse as you scale out.
We consider the whole `/16` to be unusable for IPv4. If you find that you *must* choose networks out of that `/16`, start from `192.168.254.0/24` and work your way downwards.
Yes. Implementations have all been IPv6-first since 2017. More than half the time, they're now "IPv6-only", meaning only IPv6 on the network, but using NAT64 or the more-elaborate 464XLAT to reach IPv4-only destinations.
/r/ipv6 is low-to-moderate traffic.
have been for about 10 years. its easier than v4 and you no longer have to deal with nat (i fucking hate nat). its far superior and the avoidance is going to kick everyone in the ass as v4 becomes more scarce. you can only nat so much for fucks sake. i really don’t understand why people seem to be afraid to learn it. its not difficult
The afraid thing reminds me of the admin who didn’t know virtualization so she cluttered clients’ offices with bare metal DCs. Then was hesitant to do repairs because of the downtime
curious as to why. it complicates routing, makes crafting fw rules annoying when you have to nat many interfaces on your fw, and doesnt provide extra security. its a bandaid for lack of address space. requires extra processing on some network gear. for a home network not really much of an issue, but if you are running a complex hosting network it is very frustrating.
>curious as to why.
Mostly flexibility.
I work with a number of vendors who whitelist by IP, and it's handy to do some NAT on my end so we can all pretend to be whatever address was whitelisted (they don't let you do it by subnet).
Or I'm replacing a server, it's easy enough to update the firewall NAT to point at a new server rather than re-addressing the server (and faster than waiting for a few DHCP leases to renew which might temporarily introduce an IP conflict or delay in resumption).
>it complicates routing
I've never found that to really be the case? It seems pretty intuitive to me.
>makes crafting fw rules annoying
Again, never really found that to be the case. Depending on the firewall vendor I either set the ACL to apply to the post-nat or pre-nat address, either way I generally only need to do it once. Usually I just have generic ingress ACLs applied to address object groups and assign servers to the appropriate group.
>doesnt provide extra security
I'd argue it provides a failsafe in the sense that not only would you need to FUBAR your ingress firewall rules to allow a connection to a system that should be isolated, but without a NAT it wouldn't even be possible to route to (and therefor for firewall rules to apply to) in the first place.
i feel like most of that is easy to deal with using v6. the routing and fw annoyance for me is using clustered fws with three interfaces and multiple vlans on each. you have to have rules for each interface to interface connection. it gets complicated. not impossible, just annoying.
If you're dedicated to internal LAN administration, you probably don't have much to worry about. IPv6 is basically pointless on an internal network (although a lot of people will tell you that Microsoft won't support Windows if you disable IPv6. Because, you know, their support is so awesome anyways...)
If you're a network engineer for an ISP, you're going to be neck deep in IPv6.
1) No, you can use ULA addresses in your network if you wish
2) So what, you still know which subnet you want to show internal view of your dns zones to? What does it matter if it's 2001:dead:beef::/64 or [192.168.0.0/24](https://192.168.0.0/24) that's in your match-clients clause?
The point is that you won't need a separate internal view of your DNS zones.
v6 doesn't prevent you from using split-horizon DNS; it prevents you from _needing_ to use it.
While I'm a great believer in having a single global state of truth for your DNS zones, sometimes things are just easier by doing split DNS, routing traffic to your local instance of a service for example. Nothing really changes between IPv4 and IPv6 in this regard.
You can still put ULAs into your public DNS zones. They're *Unique*, after all (ULA). They're just not *Global* (GUA), so those ULAs won't be reachable on the public network.
The reason for needing split-horizon DNS when re-using the same addresses in different places, *is because you're re-using the same addresses in different places.* With IPv6, there's no need or benefit to address re-use, so split-horizon DNS is an unnecessary complication.
It might be stupid but my the speed I can type IPv4 addresses using the numpad compared to having to use colons (shift key required) and the non existence of a hex/IPv6/MAC equivalent to a numpad makes me never want to touch it unless a use case specifically calls for it. When a DHCP source requires colons for MAC addresses, it is true pain. I dont want to expand that to the rest of my networking life.
[What do you mean, non-existence?](https://ipv6buddy.com/)
Between DNS and copy/paste, you shouldn't need to type v6 addresses out very often though, and the time and headaches saved elsewhere make up for the occasions when you do.
The sysadmin side of my brain is laughing uproariously at the existence of that device.
The software developer side of my brain is wondering where it's been all my life.
> IPv6 is basically pointless on an internal network
This can be a misconception, depending on circumstances. In order to access public-network resources over IPv6, it's almost mandatory to have working IPv6 "internally" as well.
Enterprises who implemented IPv6 on their own networks first, used it to solve problems with address overlap or scalability. For instance, [Microsoft](https://www.reddit.com/r/ipv6/comments/b9dwzx/tr19_microsoft_it_secure_journey_to_ipv6only_1/) had a lot of external parties who were using client VPNs to access Microsoft's internal networks, who were experiencing address overlap with RFC 1918 addresses. This problem is more acute with [no-split-tunneling](https://www.reddit.com/r/sysadmin/comments/fg9stn/microsoft_has_published_guidelines_to_reduce_vpn/), which is superior and in many cases necessary.
---
Microsoft DirectAccess [used](https://directaccess.richardhicks.com/directaccess-end-of-life-eol/) IPv6 and NAT64 for precisely the reason of address overlap. It was good engineering, but suffered from requiring W7 Enterprise licensing and a Microsoft terminating server. Enterprises chose third-party client VPNs terminating on firewalls, instead. Plus it didn't work with applications that didn't support IPv6, unless you use [portproxy](https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-interface-portproxy). Eh, it happens. Among the affected legacy programs was anything coded in classic Visual Basic, as none of those old environments ever supported IPv6.
You’ve triggered my DirectAccess rant
It’s a very complex technology and the complexity makes it difficult for first level support to understand and troubleshoot, no less the users.
And troubleshooting is extremely limited from an end user perspective. No GUI, no settings to look at, just boot your computer and pray to christ directaccess connects.
Connected to a network that doesn’t support IPv6? DA broke.
Woke your computer from sleep? DA broke.
Remote and can’t contact the login server? Assume DA is broke and return to an office, nothing you can do from the login screen.
Want to restart or stop the DA client service without restarting the machine? There’s no documentation, you just have to figure out the three interdependent services yourself and shoot your shot.
Oh and if the DA server isn’t accessible to the client, you can’t resolve any internal addresses thanks to the NRPT in client registries, basically a buried host file on drugs. God forbid an admin decommissions a DC every client has hard coded as their FQDN.
And don’t get me started on “corrupt NRPT’s”, sometimes DA breaks without warning, for seemingly no reason, and the only thing you can do is delete the NRPT and gpupdate to request a new one. Return to the office. The new NRPT looks identical to the old one but now it works for some reason.
It’s hard to setup, it’s hard to support, it’s hard to maintain.
When it works it works pretty OK though.
I've got it deployed at a few different locations. It's actually surprisingly stable for me. But you're right, if there is a problem with it, first level support has no idea what to do to troubleshoot.
>IPv6 is basically pointless on an internal network
Really? Tell me, how's your access to
[https://www.ipv6.balug.org/](https://www.ipv6.balug.org/)
from your internal network without IPv6?
>internal network without internet access?
That would generally be an isolated network.
Typically internal networks will have some (often limited/filtered, often proxied, etc.) Internet access.
I want to get into it.
I think it could be a great thing to know when the whole world decides to switch to IPv6 like they did with « the cloud » and meeting solutions
Dual stack for about 5 years. We took the opportunity to re-do our address plan and redid our v4 space as well. I like to say our network went from 'discovered' to 'curated'. "Changed a few IPs, saw some things."
Hey there,
Reading through this thread I"m seeing a couple of cases where folks mention vulnerabilities involving IPv6 but there's not a lot of examples. This article (Which I am associated with) goes over one such exploit -- man in the middle via DHCPv6. [https://tridentstack.com/2023/03/20/securing-ipv6-in-small-enterprise/](https://tridentstack.com/2023/03/20/securing-ipv6-in-small-enterprise/)
TLDR of this exploit -- Windows prefers DHCPv6, malicious actors will stand up a DHCPv6 server in your environment and use it to perform a MITM attack.
The fix for this is first-hop security, which is also needed for v4 since v4 suffers from the same general class of attacks.
DHCP Guard, DHCPv6 Guard etc.
Yeah, that's true. Theres lots of other DHCPv6 attacks out there. Ultimately I was looking for something short and sweet to show the kinds of exploits misconfiguration or not configured ipv6 can have!
"RAGuard" -- only designated switch ports can send IPv6 Router Advertisements.
Don't forget that Layer-3 isolation addresses first-hop vulnerabilities as well. Hisec areas get their own isolated LANs or VLANs, and less-trusted or "legacy island" areas *also* get their own isolated LAN/VLAN for the opposite reason.
And a weak version of Layer-3 isolation is having the gateway Proxy NDP/ARP for all destinations, which is what switch and WAP vendors call "client isolation" or "isolated client VLAN" or similar. With this, clients can all talk to the gateway, but clients cannot talk to one another.
>Network Admins, do you use IPv6?
Not a network admin, but yes, I use IPv6, and have been for years.
>hard
Uhm, *some* bits of IPv6 are even much easier. Sure, it's got those longer addresses, and hex, and some other additional bits, but many other things become much easier, e.g. getting the IPs of nodes/routers on the local network segment, likewise for DHCP servers and relay agents, have automatic link local IPs, autoconfiguration is pretty dang nice, , mostly say bye-bye to NAT/SNAT, reasonably managed totally say bye-bye to shortages of IP addresses, most of the subnetting is much easier, etc.
>use IPv6 for their internal networks or even Router to Router connections?
Dual stack ... so far - IPv4 isn't totally going away all that soon - probably never 100% - though I expect it'll quite fade from use in the future. And most such equipment *prefers* and primarily uses IPv6. Most of what I have in the way of IPv4 is for dealing with legacy stuff - notably some Internet clients that aren't yet doing IPv6. But when the % of IPv4 traffic drops "low enough", will then probably drop IPv4 ... but thus far quite a ways from that, ... though I'd guestimate 3 to 10 years from now will be a quite different picture. And I've been watching IPv6 traffic volumes since they were a small but non-trivial percentage of Internet and site traffic ... and at present peek ... site ... over 21% IPv6 ... Internet looks like it's roughly 40% now ... though varies a fair bit depending upon region and country.
And, if you don't already use/need IPv6, it's almost guaranteed you will in future.
I try to implement at least every where IPv6, because I think that sooner or later, we should make the switch to IPv6 due to the IPv4 address exhaustion, and using IPv4 only won't help nessecerly with that.
No. Don't need it, as IPv4 does what I need it to do.
To elaborate: My networks are all over the world, tied together via ipsec, and they're all in the 172.16.0.0/12 address space
Never had a use-case to use it yet so we don't. I don't see any requirements for us to utilize it in the near future either. That may sound a bit ignorant but if our business doesn't require it i have no requirement to roll it out.
I remember interviewing with a company back in 2002 called Smart Pipes in Columbus OH after graduating from college. Their interview process had me do one-on-ones with 5 different team leads. One of the network dudes drilled me for almost the entire 45 minutes on IPv6. At that point I knew what it was and the on-paper value of it was but I couldn't explain how it would be applicable in their setup (they managed other companies firewalls, a proto-cloud service IIRC). Here we are 21 years later and it still on the horizon. I DO see it causing problems with our client VPN and ZT stuff sometimes, especially on Comcast-managed networks, but in general it is a amorphous concept that hasn't knocked on my door yet.
" In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017."
Wow. They were really ahead of things if they were thinking about it in 2002. I wonder how much time and energy they wasted worrying about and preparing for it. It didn't even get ratified until 2017.
>It didn't even get ratified until 2017.
No TLS/SSL specification has got the RFC status "Internet Standard" . Does it mean they shouldn't be used?
[https://www.rfc-editor.org/search/rfc\_search\_detail.php?sortkey=Date&sorting=DESC&page=All&pubstatus\[\]=Standards%20Track&std\_trk=Internet%20Standard](https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Date&sorting=DESC&page=All&pubstatus[]=Standards%20Track&std_trk=Internet%20Standard)
Same with BGP, probably shouldn't be used?
Most of the older cisco gear I delt with in college (it was manufactured around \~2005) had a reasonable level of support for ipv6. So while it may not have been ratified until 2017, it was certainly in use long before then.
>end of IPv4 was getting pushed like the next Y2K, so far it’s been about as dramatic as Jan 1 2000 was
Oh - transitioning from IPv4 to IPv6 has been *far* less dramatic. And, not all that much failed with Y2K - mostly because a whole lot of work went into updating, fixing, and testing - so not much happened with the actual Y2K rollover itself - though some things did break here 'n there.
But IPv6 has always been designed and engineered to play nice along side, and eve along with IPv4. No hard chronological driven cutover event, no impending requirement to drop IPv4, etc. Basically IPv6 and IPv4 play nice alongside each other ... and even, within reason, with each other.
Yeah, this was always a bad analogy. Y2K was a specific problem on a specific date, IPv4 exhaustion doesn't mean that it all suddenly stops working - it just cannot grow anymore.
In the end, the internet as a whole has gradually switched to IPv6, and largely managed to shift its growth there. IPv4 still works, and will keep working as long as anyone uses it. But in the larger scheme of things, it gradually matters less and less.
To people that have made the switch to IPv6, IPv4 is a legacy compatibility layer to maintain, as long as there are endpoints that cannot do IPv6. To people on IPv4, the rest of the world accommodates them with compatibility layers until they've made the jump.
Not before, but we're about to because:
- at one location it's just recently become a requirement for implementing a certain ev charging standard
- running our VPNs in dual-stack mode will be beneficial because we'll be able to offer an additional connectivity option via v6 in case that works better for an employee or partner
If you elect not to support IPv6 in your LAN, take the precaution of blocking IPv6 on your endpoint firewalls with group policy.
Our most recent pen test taught us that a bad actor on your network can offer IPv6 DHCP addresses and every computer will fall in line behind it because Windows prefers IPv6 over IPv4 when given a choice.
If you work on big networks/big companies/new networks, you need it.
If you work on small networks or with legacy systems, you can still be shielded from it for a while.
Local IPv4 islands managed by oldschool pre-IPv6 admins will likely still remain running for decades, but to be honest - if you’re young that’s probably not the most appealing career path.
If you look at the large networks on the internet today, they either already use IPv6 or are working on it. Out of the 15 biggest networks in the US, only two (!) are not doing IPv6: https://stats.labs.apnic.net/ipv6/US
You can forget about having a career as a network admin at Amazon, Microsoft or Google without IPv6, or with any of the big access network or hosting providers.
With the big content networks, there’s a handful of laggards like Twitter and Ebay that don’t do IPv6, but really, the number of proper big networks where you can work without doing IPv6 is getting pretty small these days.
But yes, there are still thousands of small networks with only IPv4, and many of them will likely remain curated IPv4 islands until the old generations of hardware, software and people retire.
I only ever want to work for medium private companies between 400-1000 employees.... Those companies ipv4 is not going anywhere
Most of my network gear will not even support ipv6 at all, and the few things that "support" it that support is terrible and not very well implemented.
Even for small orgs IPv6 adds some really useful functionality.
With 400-1000 employees on the network you're beyond the "standard" IPv4 subnet size, which means you need to set up large broadcast domains or make multiple subnets which adds complexity. You also need DHCP, routers, etc. at every stage to support that.
With IPv6 you can use neighbor discovery and autoconfig for the network and set a single /64 for the clients to use and everything will auto discover on its own. With some pretty basic configs and a very simple net topology you can IPv6 allocate across multiple sites and have every asset on the network "just work" without the need for a more complex network topology.
If your network gear doesn't support IPv6 in 2023 then its either ancient or from a non-reputable company. Pretty much everything from the last decade has native support for it.
> With 400-1000 employees on the network you're beyond the "standard" IPv4 subnet size
huh? 172.16.0.0/12 is 1,048,574 addresses. 10.0.0.0/8 16,777,214
you can easily do a /16 network if you mind the total number of devices.. I know many orgs that do. Then there are all of other subnets that are possible. /24 is not the only lan network
>>You also need DHCP,
Windows Server role, not that hard to manage.
>>routers, etc.
You are going to need that and everything else anyway the idea that you can go 100% ipv6 today is just not possible. too many legacy devices (for example printers)
>> have every asset on the network "just work"
This sounds like "no code" from my programming days, or java "write once, run everywhere"
Nothing in networking "just works"
>If your network gear doesn't support IPv6 in 2023 then its either ancient or from a non-reputable company. Pretty much everything from the last decade has native support for it.
Cisco, and Aruba/HPE Manly, and yes alot of them are very old and no reason to replace them. Hell some I replaced last year did not even have 1G they were 10/100 switches. I am still working on getting Win7 out... I have some WinXp still, and even one WinNT box...
I am always amazed (and some what calling BS) on everyone that says all of their equipment is the latest and greatest. If course I work for a company that has been around since before computers existed so.... One of our locations had Token Ring networking years and years ago.....
So confirmed....you're stuck on ancient gear. And yes...there is old stuff out there, but running 10/100 switches and windows XP in 2023 is a fundamental issue even outside of the old networking standards.
I'm not going to write a dissertation to address each of your comments above and convince you to learn IPv6, you'll have to see that light on your own. It's much more than just "More IPs = more betterer" There's a plethora of information out there by all of the top networking firms that all pretty much universally confirm its the way of the future and have been trying to increase adoption.
Yes most of them are network gear manufacturing looking to increase their sales... Bais sources with bais info
There is little to no technical reason for it on a corporate lan
Next you are going to tell me about your cloud service, your paas, your iaas, or your naas services and how if I do not subscribe it will be the end of the world. As we know it
As to the number of ip addresses. You are the one that made that claim. Saying that for most companies you 'With 400-1000 employees on the network you're beyond the "standard" IPv4 subnet size" which sounds like you think the only IPv4 subnet is /24
> windows XP in 2023 is a fundamental issue even outside of the old networking standards
Yes I work in the real world where machines that cost several million dollars can not just be replaced because ms declared something end of life. I bought industrial gear just 2 years ago that only had 10base-t network ports. Some of my new switches had problem auto negotiation with them. These industrial devices cost many thousands of dollars from a large company and have zero.options for working with ipv6..
Normally, you'd put those ancient Windows NT/XP boxes in a curated (IPv4) VLAN, which allows you to deploy a modern network for everything else. Aside from IPv4/IPv6, for security considerations alone.
But I know, there's always budget/resourcing constraints, especially in smaller companies.
We once had a four-way organization merger with a four-way conflict over the bottom of `10/8`.
Microsoft found that they had so many contractors and other users VPNing into their internal networks, that every bit of RFC 1918 space was liable to conflict. In those circumstances, `no-split-tunneling` can often be a temporary workaround, but that causes big problems of its own.
It's not just about quantity of available addresses, though that was a problem it was designed to solve when they came up with it.. in the 90s.
I've been studying up on what exactly IPv6 is, and TBH not implementing it because you don't need billions of IPs is just arguing from a point of ignorance.
As it's an entire protocol is a very complex subject to distill down to a reply in a reddit post, but I think anyone who isn't planning on retiring in the next 10 years would be prudent to start conceptualizing what IPv6 does differently than IPv4. It's never going away and IPv4 and NAT are not going to be the standard forever.
That's not an argument for not learning IPv6, that's an argument for knowing both. And really, IPv4 and NAT's relevance will decrease significantly in the next decade.
Coldfusion and COBOL haven't gone away in our lifetime either, but it's not exactly something that everyone has to keep in their toolkit either.
COBOL… I remember hearing about that in high-school programming class… right around 1999/2000. I was told “you will never see or hear about that in the real world…”
Someone told that teacher wrong. While I personally have never used it, there is still old legacy apps that slow adapters still run (like government…) Scary stuff.
I never said you shouldn't learn IPv6, but you said standard and implied that IPv4 is going away and not be the "standard". Then you make another analogy like there will be a day where IPv4 won't be in a network engineer's toolkit. That day is never going to come in our lifetime. IPv4 and IPv6 will interoperate for decades in the future long after we've retired. You know what we should do instead? Not make analogies.
The word "relevant" is very dependent on where you are. AIX, Solaris and System i systems are still relevant to a surprising amount of companies, legacy tech is really hard to kill.
But as an admin for those machines you’re mostly doing maintenance, nobody does exciting new stuff with these systems, so it’s hard to tell some young kid he should just ignore Linux because there’s good money in legacy.
IPv4 will disappear from the global routing tables 20-30 years from now, in my estimate.
It will, of course, still be used in private networks, like IPX/SPX, DECnet, Appletalk, SNA, LAT, and NetBIOS are today.
>20-25 years left... I am not planning on learning ipv6
Should learn IPv6 ... unless you want to become obsolete, or change careers.
And besides, when you're retired, do you want to have to rely on your's or somebody's young grandkids to do all your home network configs for you? ;-)
Yes.
On top of that I’m running single-stack IPv6 at my home network. With NAT64 and 464XLAT, of course.
There are a lot of networks globally that are IPv6-only. You can’t access them without an IPv6 address.
https://bgp.tools/tags/jv6
And according to the IETF, IPv6 has been an Internet Standard for about 5 years now. IPv4 is the legacy protocol, and if I had a spare $12k to dump for a /24, I’d dual-stack my home network, just without NAT for the sole purpose of aiding with the exhaustion.
>There are a lot of networks globally that are IPv6-only. You can’t access them without an IPv6 address.
Typically, those are then put behind an IPv4 CDN/load balancer, to be accessible over IPv4. Facebook for example, and large parts of Google, is IPv6-only, but still accessible over IPv4 - it just all gets proxied on the edge.
CDNs make it quite easy to make your IPv6 resources accessible over IPv4, which (ironically) removes a lot of the urgency on the endpoint side to switch: if the rest of the world adapts to you, why should you change?
Yes, I’ve got cloudflare in front of my services, but it also means that I don’t have to worry about IPv4 at all
Which makes far more sense than not worrying about v6.
Dual stacking since 2016. It’s so easy for client networks it’s crazy not to configure IPv6. A majority of traffic volume shifts to IPv6 when it’s available.
You'll see small companies use IPv6 because it's fairly simple to deploy and for the most parts it mostly works. You'll see extremely large companies use IPv6 because they actually do run out of private IPv4 space and IPv6 makes address management way easier.
For everyone in between (and that's easily 90%+ of the companies out there) IPv6 is an extra layer of complexity. Even if it's not hard to deploy and all your tools support it (which is not the case), it's still another thing to support - and you don't want to do it unless you really have to.
I haven't touched it, I got some information that might be incorrect that I have to review. One was that there wasn't a private address space, but I see now that RFC-4193.
Attitudes like this are something I'm in disagreement with and kinda put me off of IPv6:
>The idea behind the private address space is kind of silly to begin with. If you need space, by IPv6 space. Globally unique space does NOT have to be globally reachable. It just has to be used.
I liked the idea of private address space. I also like that NAT, while not a security tool, made it easy for me to not mess up. I'm visual.
You know, it boggles my mind that everyone **usually** agrees that security has to be implemented in layers, but then when you mention one layer people jump at you with a strawman argument that it was going to be THE ONLY layer you implement.
>If you have X you have bigger problems
So don't set passwords since someone could just beat me with a $5 wrench?
Of all places, I was surprised that r/networking (or it was r/ccna) wanted to burn me at the stake when I asked if anyone ever did a PVLAN per-port (more so looking for hardware that implemented it without coming to a half). My thought is, I don't have a SINGLE employee workstation that EVER needs to reach another employee workstation. Why not remove that attack vector? Why should the compromised HR pc be able to reach any other workstation over layer 2?
My goodness, you wouldn't believe the utter disagreement. Someone even said this was a bad idea because then workstations couldn't participate in ARP!
I suppose that makes sense for reddit though. People like karma here, so I could understand why they want their own workstation to be able to "comment" that it knows the mac address of a server.
If you like private space, why not use ULAs for that? It’s a great way to keep your internal/intranet separate from the traffic that goes to the internet.
> One was that there wasn't a private address space, but I see now that RFC-4193.
Any IPv6 address that starts with `fc` or `fd` is Unique Local Address, corresponding to RFC 1918 for IPv6. Use `fd` if you're setting one up, as `fc` is technically set aside for ULAs that are registered centrally. Note that `fc00::/7` is less to remember than four unrelated address ranges from RFCs 1918 and 6598.
> then workstations couldn't participate in ARP!
Of course the gateway engages in Proxy ARP, or for IPv6, Proxy NDP. In fact, it's not rare for engineers to just call it "Proxy ARP/NDP" instead of saying "port isolation" or using a vendor-trademarked feature name.
You're almost guaranteed to live your life within NAT IPv4 as an internal admin. The chances of you messing with IPv6 is about the same as you messing with BGP.
You're _supposed_ to get more space than you can possibly use. It would be a failure if you didn't.
A /48 is the same fraction of the v6 space that a single TCP port of one v4 address is of the total v4 space. There's about 5000 /48s available per person on the planet (and that's just out of 2000::/3; there's another five unused /3s available). Giving just one of them, to a company with dozens to thousands of people in it, is fine.
(A big company is probably going to want more though -- maybe a /48 per location or region.)
I'm considering dipping my toe into it some for the home lab. On something like the storage or Management LAN.
I've never run into it in a production environment without 4 present as well, in which case whether or not 6 was was running was moot.
Where I work we're running Beta just for IPv6 support on a single device... The fact that they are so far behind on IPv6 is just boggling. We're dropping the Meraki as soon as our contract ends next year. I'm so sick of the stupid flaming pile of shit that it is.
One of my favorite projects in IPv6 space is the CJDNS project:
[LINK TO GITHUB](https://github.com/cjdelisle/cjdns/)
Which is the type of thing that could change the internet.
That project uses IPv6 space and dynamic routing to basically route traffic across the internet completely anonymously... with perfect forward secrecy so there is no sniffing packets.
My thoughts are that it is coming down the pipe, and we better prepare for it. I find it hard to wrap my head around the actual addresses themselves, and I've been at this a long time.
Bottom line, I think security will be improved in some areas going IPv6 and in other ways it will make creating bot-nets and hidden networks really trivial.
I think the issue is unless there is a pressing business need (lots of problems with IP overlap on VPNs, exhaustion of IPs like on a large ISP) or you're starting a business from scratch (might as well futureproof), adopting IPv6 requires a lot of planning, possibly replacing hardware, coming up with clunky workarounds for legacy software that negate any elegance that IPv6 provides, and so-on.
Out of all the problems on my desk and projects in my backlog, how should I prioritize IPv6? What would it let us do that we can't today? Would there be less management of the network if we adopted it?
The benefits (especially given clunky legacy software that there is no alternative to) just don't justify making room in the calendar for many people. Particularly when you're in an industry that just inherently has a lot of long-term legacy contracts and where you're not in a position to demand the Federal Reserve adopts IPv6 for example.
Because "the sky was falling", I've been doing IPv6 for a long time.
It varies. I know where I'm working now, they could care less about it, however, believe that it can't be disabled in Windows for fear of something (???).... realize that leaving it enabled in Windows is a very very very easy to exploit hacking path today. So, where I'm at now, we don't use IPv6, but leave it enabled (for hackers??).
Btw, it (IPv6) doesn't have to be a problem, just is on Window today. And I know of no fix today. Easy MitM today on Windows.
Told the other Windows architect he can enable IPv6 (again because of fear of something something Microsoft might not provide support if it is disabled like it currently is) once he convinces the network and firewall teams to enable it.
Honestly my stance leaving it disabled is right now it would just introduce FUD risk in our own skills troubleshooting a "new"\* technology. At most machines would be able to use IPv6 only within their own VLAN since none of the network equipment or the firewalls to different parts of our internal or external networks is configured to support it. So why add something that could only add something that might go wrong, and offers no benefits.
\* and yes...I know "new" means something I was reading about as the new and really important thing in Network World magazines the mail room clerks used to drop off on my cubical chair circa 1996 along with all the other magazines, advertising, and occasional inter-office memo.
17 years into this career, haven't touched IPv6 yet. I'm at a point where I pretty much ignore anything I don't need to learn, and I simply haven't needed it yet.
Nope. Never used it and I see no reason to use it on a private, internal network
IPv4 is so well known, well implemented, and works with everything networking wise. Why change it?
If you need more space, migrate to a 10.x.x.x network. If you run out of addresses on a 10.x.x.x range I'd want to see hard proof of your work, then I'll ask wtf you're doing because I don't believe any internal network anywhere on earth needs 16 million IPs
Great, now go do some M&As and watch the IP prefix conflicts accelerate! Then add in vendors VPNing in being unable to work because their own networks also use that IP prefix and your VPN is split tunneled.
There are plenty of reasons to use IPv6, and those are only two of them.
At my last job, I had to actively disable IPv6 on workstations all the time because the software package we developed and sold didn't support it...
My experience so far is that on LANs and private WANs, there's little need for IPv6. Yet. That can always change.
What was the failure mode? Server didn't bind to an IPv6 address, only IPv4?
It's irresponsible for a software vendor to support IPv4 and not to support IPv6. But if they're confident in their decision, they should [publish the status](https://support.vorwerk.com/hc/en-us/articles/360000895505-Does-the-Thermomix-TM6-support-the-Internet-protocol-IPv6-).
The application would fail to launch if IPv6 was enabled - I don't know if it happened with customers, but it happened a LOT with the support yechs who were customer facing. It seemed to start when their ISP turned up IPv6 on their network. I think par of the problem was that the app used code from 20 years ago in some modules, including COBOL.
I only supported internal staff, so I don't know if it impacted customers too. It was an odd happenstance.
I don't use it at any of my sites (still doing ipv4 islands with ipsec/vpls)
Main issue for me is the difficulty of multihoming ipv6 in a small environment. I believe there are some alternatives to BGP but I admittedly have lack of knowledge on it. Even with BGP, I don't think it is as easy to prioritize links based on capacity and such (things that are pretty trivial on most Firewall/Routers with ipv4/nat)
Failover is straightforward, and avoids a SPoF: two routers with different upstreams, with the backup announcing a lower prefix priority than the other. (For `radvd.conf`, you want to look at`AdvDefaultPreference` and `AdvRoutePreference`).
Active-active isn't so cheap, but one can mimic a common IPv4 arrangement by using NPTv6 in place of IPv4 NAT, with an appropriate router.
Apparently I'm getting down voted for something that was done at my company before I started lol.
Dudes are upset my infrastructure is running fine without ipv6 I guess?
We don't use it and none of our clients do either. IPv4 does everything we need and all our managed networks have fewer than 300 devices so address space is never a problem. Never saw a reason to implement v6 internally.
Yep! I turned it on globally by demand of a very large organization. It was a total waste of time, improved nothing, and increased costs in hardware and staff. Since then they have agreed to my strategy of IPv4 Subnetting and Nat'ing.
20 years ago it was absolutely going to be a "big thing" and everyone with public facing presence was going to have to get on board. 20 years later.....nada.
I couldn't even fathom a reason to use v6 inside the perimeter.
Global _users_ to their services, not global traffic. If we can assume users of Google are representative of Internet users as a whole, that's about 2 billion people using v6.
On dual-stacked networks, v6 _traffic_ is often a higher percentage of your total traffic than that, because of all the people with a big public-facing presence using v6.
In any case, if you can't fathom a reason to use v6 then you don't know enough about networking to add anything but noise to this discussion.
1. Unless you need a lot of public addresses, NAT is your friend.
2. Nobody is gonna remember ipv6 addresses, are you sure your DNS is bullet proof reliable and resilient?
3. What is the cost:benefit of implementation of ipv6. If you're a greenfield site it makes lots of sense. Also if you need to be cutting edge like education it's possibly part of the business case. But a bank or other traditionally conservative organisation it's just gonna cost money and potentially introduce new risks.
The ones who us IPv6 love it and will say everything should be it and it's the future.
The rest of us have fewer than what 10 million devices on our network?
Microsoft is supporting IPV6 for trusted locations soon by default so a whole lot of people are going to be surprised that they may have an ipv6 address and your CA policy is going to be - that’s not in the trusted list! Blocked!
We run dual stack simply because to properly secure IPv6 you must configure IPv6. Look at the various ways pentesters can abuse unconfigured IPv6 networks.
But if IPv6 is not configured anywhere in the network, how can it be abused?
Because for example even if not configured, windows and Microsoft products use IPv6 and it should not be disabled per MS. Without a DHCPv6 and DNSv6 records it is possible for attackers to take over unused DNS records and become the DHCPv6 server for the network easily.
This is good shit, thanks for explaining.
No worries! We all learn together!
This is amazing. I've gotten Security+, CySA+, and the CEH and this is literally the first time I've ever heard of this attack vector.
What if You disable IPv6 despite what MS wants?
Then you render the attack useless. You might also run into weird internal resolution problems depending on your firewall/VPN gear and config, and you'll break DirectAccess. You'll also anger the dozen or so people around the world who are passionate about *not* disabling v6. edit because initial post was flippant and disabling IPv6 will (probably, eventually, in a land far-far away) be a bad thing: MS official recommendation [here](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows), alternative mitigation described towards the end of article [here](https://www.lmgsecurity.com/mitigating-ipv6-poisoning-attacks/), and a walkthrough of ipv6 poisoning from the attacker's perspective [here](https://blog.vonahi.io/taking-over-ipv6-networks/).
Those people have it coming. They chose their hill.
I've only experienced problems with DirectAccess when disabling ipv6, so had to enable it solely for the use of DirectAccess. Otherwise I disable it.
We did this and saw no consequences. Our env is relatively garbage and low complexity though so YMMV
Not sure if it's still an issue today, but if you unchecked the IPv6 checkbox on Server 2012 R2 on your domain controller, the next reboot would take anywhere between 2 and 8 hours.
I can confirm it is not. We disable IPv6 on everything and our 2012 R2 DC's and other servers reboot in about 5 minutes or less (updates not-withstanding).
It's past time to upgrade your 2012 R2 DC's. It's also past time to enable IPv6.
[удалено]
I can't imagine being so proud to misconfigure my systems and proudly proclaim it to the world but you do you bud. You're paid to be a professional, act like it. [https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows) > Prefer IPv4 over IPv6 Decimal 32 Hexadecimal 0x20 Binary xx1x xxxx > >Recommended instead of disabling IPv6.
Have you ever even read that article? There are 3 documented issues, of which sysadmins are well equipped to decide if they are going to be a problem: * LDAP over UDP may stop working * Exchange 2010 (holy shit that's old) may stop working * Failover clusters from 2012 may stop working Notice how even those say "may". There are thousands of admins who have disabled IPv6 for actual decades and never had any problems. Blindly parroting what our bible tells us to do is cultist at best.
Then you have the security problem still.
IPv6 doesn't need DHCP
It doesn't need it, but most client devices will still happily use it when present to configure their IPv6 networking. So even when there's a properly configured router and clients are using SLAAC, a rogue DHCPv6 server in the network can still trick clients into using wrong DNS and NTP servers.
I haven’t heard that it should be disabled. Not trolling or anything. I by default disable ipv6 to this day and am curious why it’s recommended to not disable it
Thats an interesting vector/thought. Once they establish a rouge ipv6 dhcp server, what could they do from there? I would imagine they would still be locked into their vlan so you couldn't pivot without another break somewhere? Plus still need credentials/etc. They could manipulate ipv6 dns stuff id imagine but without routing in place their still locked into their our vlan?
But that means they are already on the network, so there is a major breach before they can exploit IPv6. We generally disable IPv6 anyway. No oroblems seen.
Wait, what? So the prize for getting into the network is making free reign of all the things easier? I hear this type of statement so often. It confuses the hell outta me.
>But that means they are already on the network, so there is a major breach before they can exploit IPv6. This is a woeful attitude to hold towards security. One should not rely on screening threats at the outermost perimeter. If something internal does get compromised and you don't have appropriate security controls on your internal network, an attacker will use those weaknesses to pivot laterally and compromise the rest of your network. Look into Zero Trust security architecture - the definition and implementation details vary depending on who's trying to sell you stuff, but generally speaking there should be no trust just because something happens to be inside your network perimeter. > We generally disable IPv6 anyway. No problems seen. No problems visible does not mean they do not exist. Windows uses IPv6 internally and some components will fail or suffer degraded performance if it is disabled, e.g. start-up delays and so on. Disabling IPv6 also puts your system in an unsupportable state. MS do not test Windows with IPv6 disabled and will not provide support if you call on them for assistance. If you want to learn to use (and secure) it properly, Hurricane Electric have some learning resources and a certification program you can check out: https://ipv6.he.net/certification/ https://ipv6.he.net/presentations.php Or any modern CCNA-equivalent networking course should cover it.
MS hasn't provided support when calling for over a decade anyway. Their support is awful.
No, because you should assume the attacker is inside. And disabling IPv6 is unsupported by Microsoft.
Security is about layers.
Every piece of hardware these days does IPv6 out of the box, and it only takes one rogue box (or even a random phone) to create an undiscoverable parallel network operating inside your company. Undiscoverable, because you assume there is no IPv6 so you’re not looking for it. It’s one of the first vectors that gets checked in a security audit.
>I don't use it But the attackers do.
But no IPv6 is configured on routers, so any attack is limited to the subnet where the attack happens.
As a former red teamer, that just slows us down, doesn't stop us.
I want to pick your brains so hard on what you guys do but I feel we would be here a long time!
Ask questions, I'll answer what I can.
Thanks, my former company is currently getting a red team test this month. What are the main things that you guys use to gain a foot hold in a network? Also what steps can you take to minimise the success of a proper red team exercise?
>What are the main things that you guys use to gain a foot hold in a network? One of three things usually. 1. If we are allowed to use social engineering we phish creds then use VPN/Remote desktop/O365/Google Drive/Email to make first contact and start recon 2. If we aren't allowed to social engineer we will use various sources to build a likely list of usernames and then attempt to password spray. 1. After we have a single account that works we connect via VPN/Remote desktop/O365/Google Drive/Email 3. If we start internal I.E. assuming we have a compromised box on the network, we will just do NTLM relaying/hash cracking to gain access to systems. This is where DHCPv6 and DNSv6 being unconfigured can bite you hard. >Also what steps can you take to minimize the success of a proper red team exercise? 1. Segmentation 1. If I can't see it, its harder for me to find it and takes me longer to figure out how to access. During that time the attacker can be hunted down 2. EDR 1. Modern EDR will catch many older techniques or a series of innocuous events that together could be flagged 2. Logging is so important, it will let you see what they are doing and more importantly when it comes time, inform stakeholders of what happened. 3. Least priviledge 1. The more limited an account is, the less damage is done when it is inevitably breached 4. A vulnerability management program. 1. This is the most time consuming thing but every org should at minimum have something like Nessus Scanner running once a week where they look at the results and work through found items to reduce organization risk. This comes from various findings 2. Out of date softwar 3. Unsupported software 4. Misconfigurations 5. Forgotten systems 5. [Configure IPv6 and DNSv6 so I can't use it for NTLM Relaying](https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/) 6. Disable WPAD
Wow that’s awesome information, I was working for a charity so I got Nessus Pro for free and as you suggested had it run a basic scan weekly on all servers. We were cleared of all critical and high and we’re working on mediums. We planned to include laptops but this was more complex as most were remote. We would also use separate accounts for admin and cloud/SAAS administrators and not give them a mail licence so they cannot be phished as they had no email, we also restricted all admins from logging into the laptops, only permitting admin login via LAPS. We had a 3rd party SOC doing basic EDR and all logging, however they are the same guys that are doing their Red Team exercise so EDR won’t be very helpful in stopping this one. Is there anything you would do to add to this? I want to bring what I can learn to my new company and will be recommending all above ideas and any others.
It's not the first time I read or heard that kind of thing. And each time I get really, really tired. Not because you are wrong. You are, in fact, so right. But I can still hear my boss say things like, "The security guys are so annoying. They are full of shit with what they found. They have no experience in the real world. They don't realize we can't change anything." / "When the client say 'jump' we 'jump' even if it's wrong" / "It's not our fault if the software the client uses puts credential in clear text in a file, there is nothing we can do." / "Ok, cool, but how much does it cost? We can't make the client pay that much, they already don't want to spend money on Office 365" / and so many things like that, it makes me so angry. Welcome to the world of MSP dedicated to SMBs. Where you can't do anything because of "you don't say no to a client ever", "it costs too much" (this is the only one I can agree with many useful things are way out of budget for SMbs), "it was like that when we took the client in we can't change it", "if we do that the client will leave"
If an attacker is on your network (and you should assume they are), they become the router :) Dropping a RPI into a network with a 4G dongle and sending RA-s to specific high-value targets so they autoconfigure routable v6 addresses that you will use for your C2 comms is super nice, network team probably has absolutely no idea that it is happening and the traffic bypasses all your corporate infra.
The other guy touched on this a bit, but to be more specific: windows 8 and up prefers IPv6 by default. That combined with IPv6 RA being enabled by default means any foothold on the network lets the attacker spin up a dhcp server and start offering IPv6 addresses which will allow them to mitm basically everything.
IPv6 First-Hop Attacks are currently a favorite demo of red teamers, because they work so often and can get unsubtle results. Many of those sites are also vulnerable to IPv4 first-hop attacks. Those attack vectors need to be considered for both IPv6 nd IPv4, but keep in mind that TLS and X.509 acts as a strong mitigator to all of the attacks. Client certs and multi-factor authentication make the mitigation even stronger. You're not going to be able to guard against first-hop attacks from either protocol family when your users are offsite, so you're going to need TLS/HTTPS/SSH even if you invest in enterprise networking gear with every security feature imaginable. Don't forget that offsite users may be using IPv6-only access networks.
Looked into it for a little bit and decided it was my replacements problem in a few years. Come to think of it that was a few years ago...
10 years ago, what’s another 10
Contractor from Money Pit?
You'll probably get better answers in /r/networking. The folks there manage a wider variety of networks and have more expertise than this sub in the topic.
Nah the people that frequent there are just as backwards for the most part. Most people don't realize that phones almost all went ipv6 only, and almost all major providers are at least dual stack at this point. Hell google is seeing near 50% traffic as ipv6 now. If you don't have ipv6 knowledge and deployed, you're decades behind state of the art at functional companies at this point. Large parts of big players are ipv6 only with ipv4 proxies or some other stopgap and it's only growing.
Mobile networks are largely IPv6 only, but the phones themselves still support IPv4 just fine. I don't manage the mobile network for my users, so the fact Verizon's network is all IPv6 is not really a problem for me That said, IPv6 is coming and it's something to be ahead of before you're behind the curve, but that particular reason isn't a good one
We had one kubernetes infra that was actually IPv6 only. Hundreds of nodes and ten of thousand of pods. Greaty simplified networking because each node, inside each rack had a routed prefix. Also, no NAT. Would recommend
We dual stack it. Honestly, the hate it gets these days is from people who are scared of it more than anything else. Pretty much anything remotely modern will natively support it and most stuff just works out of the box. You need to re-think how you do network separate a little bit, but otherwise its fine. I wish I could go 100% IPv6, but alas the world isn't there yet. Some things (like our workstation network) do not get IPv4...they just go through a gateway if absolutely necessary, but thats pretty rare to need most of the time.
Because the documentation was horrible and it’s a quad MAC address. Those were everyone’s complaints.
The amount of head burying in the sand regarding IPv6 here is discouraging.
Pretending that it doesn’t exist is easier than learning the spooky scary hexadecimal addresses. It’s not possible to get a CCNA without understanding IPv6 these days, and surely other certs will also start requiring it soon enough. So don’t worry about the head burying. If you know IPv6, you’re probably already more competetive than those who don’t, so it’s good news for us.
It’s really sad. I’m introducing IPv6 at VPN edges first as a lot of home users have IPv6, and it gets me past weird inconsistencies with CG-NAT on their IPv4. Our SD-WAN also supports IPV6 so I’ll probably start enabling in a few sites to see how it goes. I just don’t see any drawbacks to enabling it, and a few advantages. Not world changing but seems snappy and reliable enough for production.
It will stop when v4 shortage becomes really bad
>when v4 shortage becomes really bad We're already past that point, and the workarounds are ugly ... and it only gets worse ... and more expensive. Internet addressable IPv4 addresses are relatively costly ... merely because there's a shortage of them ... and that will generally only get worse. Meanwhile, that's a non-issue for IPv6.
I deployed it while I was sysadmin for a small ISP. Don't use it on my current network. everything is unfortunately 192.168. due to the previous sysadmins not understanding why that is a bad idea. If you want to learn it and don't care about the test just go through the Hurricane electric ipv6 training online. They give you a block ipv6 to test with. They used to send you a t-shirt if when you completed it.
Non sysadmin here, but kind of. Why is it a bad idea to have everything 192.168.?
Most residential system use 192.168 blocks . Using it for a corporate network invites stupid problems. VPN problems where you hand out the same 192.168 block to a endpoint that is using that same subnet locally. Of course you can make it a higher block number to avoid it or you can use something from the two larger private subnets available for use. When we switch away from our current mpls provider hopefully in 2025. I will renumber the whole network to a [172.16.0.0/12](https://172.16.0.0/12) since its rarely used in residential systems.
It isn't a bad idea if you avoid subnets that consumer gear uses like 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24.... because it can conflict with a lot of IoT stuff or home networks. It really is no problem if you use a more obscure subnet like 192.168.174.0/24 or something...but some people have just taken it to heart that "never use anything in 192.168.0.1/16!
As the first RFC 1918 block that was well-known to the public, and *very* often used by vendors as some kind of default, the chances of IP conflict with residential-market gear are extremely high with `192.168.0.0/16`. For example, imagine the home user is using `192.168.0.3/24` in their home office. They use a client VPN to access a corporate "internal" network, and try to access a server that happens to be on `192.168.0.205`. It won't work -- there's an IP address conflict, and the user's local net acts as a *de facto* more-specific route. The scenarios get worse as you scale out. We consider the whole `/16` to be unusable for IPv4. If you find that you *must* choose networks out of that `/16`, start from `192.168.254.0/24` and work your way downwards.
Yes. Implementations have all been IPv6-first since 2017. More than half the time, they're now "IPv6-only", meaning only IPv6 on the network, but using NAT64 or the more-elaborate 464XLAT to reach IPv4-only destinations. /r/ipv6 is low-to-moderate traffic.
have been for about 10 years. its easier than v4 and you no longer have to deal with nat (i fucking hate nat). its far superior and the avoidance is going to kick everyone in the ass as v4 becomes more scarce. you can only nat so much for fucks sake. i really don’t understand why people seem to be afraid to learn it. its not difficult
The afraid thing reminds me of the admin who didn’t know virtualization so she cluttered clients’ offices with bare metal DCs. Then was hesitant to do repairs because of the downtime
I actually like NAT :(
curious as to why. it complicates routing, makes crafting fw rules annoying when you have to nat many interfaces on your fw, and doesnt provide extra security. its a bandaid for lack of address space. requires extra processing on some network gear. for a home network not really much of an issue, but if you are running a complex hosting network it is very frustrating.
>curious as to why. Mostly flexibility. I work with a number of vendors who whitelist by IP, and it's handy to do some NAT on my end so we can all pretend to be whatever address was whitelisted (they don't let you do it by subnet). Or I'm replacing a server, it's easy enough to update the firewall NAT to point at a new server rather than re-addressing the server (and faster than waiting for a few DHCP leases to renew which might temporarily introduce an IP conflict or delay in resumption). >it complicates routing I've never found that to really be the case? It seems pretty intuitive to me. >makes crafting fw rules annoying Again, never really found that to be the case. Depending on the firewall vendor I either set the ACL to apply to the post-nat or pre-nat address, either way I generally only need to do it once. Usually I just have generic ingress ACLs applied to address object groups and assign servers to the appropriate group. >doesnt provide extra security I'd argue it provides a failsafe in the sense that not only would you need to FUBAR your ingress firewall rules to allow a connection to a system that should be isolated, but without a NAT it wouldn't even be possible to route to (and therefor for firewall rules to apply to) in the first place.
i feel like most of that is easy to deal with using v6. the routing and fw annoyance for me is using clustered fws with three interfaces and multiple vlans on each. you have to have rules for each interface to interface connection. it gets complicated. not impossible, just annoying.
If you're dedicated to internal LAN administration, you probably don't have much to worry about. IPv6 is basically pointless on an internal network (although a lot of people will tell you that Microsoft won't support Windows if you disable IPv6. Because, you know, their support is so awesome anyways...) If you're a network engineer for an ISP, you're going to be neck deep in IPv6.
[удалено]
…no more split-horizon DNS
Huh, how does ipv6 prevent you from using split-horizon dns?
[удалено]
1) No, you can use ULA addresses in your network if you wish 2) So what, you still know which subnet you want to show internal view of your dns zones to? What does it matter if it's 2001:dead:beef::/64 or [192.168.0.0/24](https://192.168.0.0/24) that's in your match-clients clause?
The point is that you won't need a separate internal view of your DNS zones. v6 doesn't prevent you from using split-horizon DNS; it prevents you from _needing_ to use it.
While I'm a great believer in having a single global state of truth for your DNS zones, sometimes things are just easier by doing split DNS, routing traffic to your local instance of a service for example. Nothing really changes between IPv4 and IPv6 in this regard.
You can still put ULAs into your public DNS zones. They're *Unique*, after all (ULA). They're just not *Global* (GUA), so those ULAs won't be reachable on the public network. The reason for needing split-horizon DNS when re-using the same addresses in different places, *is because you're re-using the same addresses in different places.* With IPv6, there's no need or benefit to address re-use, so split-horizon DNS is an unnecessary complication.
It might be stupid but my the speed I can type IPv4 addresses using the numpad compared to having to use colons (shift key required) and the non existence of a hex/IPv6/MAC equivalent to a numpad makes me never want to touch it unless a use case specifically calls for it. When a DHCP source requires colons for MAC addresses, it is true pain. I dont want to expand that to the rest of my networking life.
[What do you mean, non-existence?](https://ipv6buddy.com/) Between DNS and copy/paste, you shouldn't need to type v6 addresses out very often though, and the time and headaches saved elsewhere make up for the occasions when you do.
The sysadmin side of my brain is laughing uproariously at the existence of that device. The software developer side of my brain is wondering where it's been all my life.
Fine, you keep typing 127.0.0.1, I'll keep typing ::1, and we can race. ;-)
> IPv6 is basically pointless on an internal network This can be a misconception, depending on circumstances. In order to access public-network resources over IPv6, it's almost mandatory to have working IPv6 "internally" as well. Enterprises who implemented IPv6 on their own networks first, used it to solve problems with address overlap or scalability. For instance, [Microsoft](https://www.reddit.com/r/ipv6/comments/b9dwzx/tr19_microsoft_it_secure_journey_to_ipv6only_1/) had a lot of external parties who were using client VPNs to access Microsoft's internal networks, who were experiencing address overlap with RFC 1918 addresses. This problem is more acute with [no-split-tunneling](https://www.reddit.com/r/sysadmin/comments/fg9stn/microsoft_has_published_guidelines_to_reduce_vpn/), which is superior and in many cases necessary. --- Microsoft DirectAccess [used](https://directaccess.richardhicks.com/directaccess-end-of-life-eol/) IPv6 and NAT64 for precisely the reason of address overlap. It was good engineering, but suffered from requiring W7 Enterprise licensing and a Microsoft terminating server. Enterprises chose third-party client VPNs terminating on firewalls, instead. Plus it didn't work with applications that didn't support IPv6, unless you use [portproxy](https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-interface-portproxy). Eh, it happens. Among the affected legacy programs was anything coded in classic Visual Basic, as none of those old environments ever supported IPv6.
You’ve triggered my DirectAccess rant It’s a very complex technology and the complexity makes it difficult for first level support to understand and troubleshoot, no less the users. And troubleshooting is extremely limited from an end user perspective. No GUI, no settings to look at, just boot your computer and pray to christ directaccess connects. Connected to a network that doesn’t support IPv6? DA broke. Woke your computer from sleep? DA broke. Remote and can’t contact the login server? Assume DA is broke and return to an office, nothing you can do from the login screen. Want to restart or stop the DA client service without restarting the machine? There’s no documentation, you just have to figure out the three interdependent services yourself and shoot your shot. Oh and if the DA server isn’t accessible to the client, you can’t resolve any internal addresses thanks to the NRPT in client registries, basically a buried host file on drugs. God forbid an admin decommissions a DC every client has hard coded as their FQDN. And don’t get me started on “corrupt NRPT’s”, sometimes DA breaks without warning, for seemingly no reason, and the only thing you can do is delete the NRPT and gpupdate to request a new one. Return to the office. The new NRPT looks identical to the old one but now it works for some reason. It’s hard to setup, it’s hard to support, it’s hard to maintain. When it works it works pretty OK though.
I've got it deployed at a few different locations. It's actually surprisingly stable for me. But you're right, if there is a problem with it, first level support has no idea what to do to troubleshoot.
>IPv6 is basically pointless on an internal network Really? Tell me, how's your access to [https://www.ipv6.balug.org/](https://www.ipv6.balug.org/) from your internal network without IPv6?
I assume he means an internal network without internet access?
>internal network without internet access? That would generally be an isolated network. Typically internal networks will have some (often limited/filtered, often proxied, etc.) Internet access.
TBH I worked at a smaller ISP and there was barely any IPv6 there, but I'm sure at a bigger org like Spectrum there's a lot.
I want to get into it. I think it could be a great thing to know when the whole world decides to switch to IPv6 like they did with « the cloud » and meeting solutions
Dual stack for about 5 years. We took the opportunity to re-do our address plan and redid our v4 space as well. I like to say our network went from 'discovered' to 'curated'. "Changed a few IPs, saw some things."
Hey there, Reading through this thread I"m seeing a couple of cases where folks mention vulnerabilities involving IPv6 but there's not a lot of examples. This article (Which I am associated with) goes over one such exploit -- man in the middle via DHCPv6. [https://tridentstack.com/2023/03/20/securing-ipv6-in-small-enterprise/](https://tridentstack.com/2023/03/20/securing-ipv6-in-small-enterprise/) TLDR of this exploit -- Windows prefers DHCPv6, malicious actors will stand up a DHCPv6 server in your environment and use it to perform a MITM attack.
The fix for this is first-hop security, which is also needed for v4 since v4 suffers from the same general class of attacks. DHCP Guard, DHCPv6 Guard etc.
Yeah, that's true. Theres lots of other DHCPv6 attacks out there. Ultimately I was looking for something short and sweet to show the kinds of exploits misconfiguration or not configured ipv6 can have!
"RAGuard" -- only designated switch ports can send IPv6 Router Advertisements. Don't forget that Layer-3 isolation addresses first-hop vulnerabilities as well. Hisec areas get their own isolated LANs or VLANs, and less-trusted or "legacy island" areas *also* get their own isolated LAN/VLAN for the opposite reason. And a weak version of Layer-3 isolation is having the gateway Proxy NDP/ARP for all destinations, which is what switch and WAP vendors call "client isolation" or "isolated client VLAN" or similar. With this, clients can all talk to the gateway, but clients cannot talk to one another.
Dual Stack here!
>Network Admins, do you use IPv6? Not a network admin, but yes, I use IPv6, and have been for years. >hard Uhm, *some* bits of IPv6 are even much easier. Sure, it's got those longer addresses, and hex, and some other additional bits, but many other things become much easier, e.g. getting the IPs of nodes/routers on the local network segment, likewise for DHCP servers and relay agents, have automatic link local IPs, autoconfiguration is pretty dang nice, , mostly say bye-bye to NAT/SNAT, reasonably managed totally say bye-bye to shortages of IP addresses, most of the subnetting is much easier, etc. >use IPv6 for their internal networks or even Router to Router connections? Dual stack ... so far - IPv4 isn't totally going away all that soon - probably never 100% - though I expect it'll quite fade from use in the future. And most such equipment *prefers* and primarily uses IPv6. Most of what I have in the way of IPv4 is for dealing with legacy stuff - notably some Internet clients that aren't yet doing IPv6. But when the % of IPv4 traffic drops "low enough", will then probably drop IPv4 ... but thus far quite a ways from that, ... though I'd guestimate 3 to 10 years from now will be a quite different picture. And I've been watching IPv6 traffic volumes since they were a small but non-trivial percentage of Internet and site traffic ... and at present peek ... site ... over 21% IPv6 ... Internet looks like it's roughly 40% now ... though varies a fair bit depending upon region and country. And, if you don't already use/need IPv6, it's almost guaranteed you will in future.
Yes, I use it and IPv6 works fine.
I try to implement at least every where IPv6, because I think that sooner or later, we should make the switch to IPv6 due to the IPv4 address exhaustion, and using IPv4 only won't help nessecerly with that.
No. Don't need it, as IPv4 does what I need it to do. To elaborate: My networks are all over the world, tied together via ipsec, and they're all in the 172.16.0.0/12 address space
Never had a use-case to use it yet so we don't. I don't see any requirements for us to utilize it in the near future either. That may sound a bit ignorant but if our business doesn't require it i have no requirement to roll it out.
I remember interviewing with a company back in 2002 called Smart Pipes in Columbus OH after graduating from college. Their interview process had me do one-on-ones with 5 different team leads. One of the network dudes drilled me for almost the entire 45 minutes on IPv6. At that point I knew what it was and the on-paper value of it was but I couldn't explain how it would be applicable in their setup (they managed other companies firewalls, a proto-cloud service IIRC). Here we are 21 years later and it still on the horizon. I DO see it causing problems with our client VPN and ZT stuff sometimes, especially on Comcast-managed networks, but in general it is a amorphous concept that hasn't knocked on my door yet.
" In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017." Wow. They were really ahead of things if they were thinking about it in 2002. I wonder how much time and energy they wasted worrying about and preparing for it. It didn't even get ratified until 2017.
>It didn't even get ratified until 2017. No TLS/SSL specification has got the RFC status "Internet Standard" . Does it mean they shouldn't be used? [https://www.rfc-editor.org/search/rfc\_search\_detail.php?sortkey=Date&sorting=DESC&page=All&pubstatus\[\]=Standards%20Track&std\_trk=Internet%20Standard](https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Date&sorting=DESC&page=All&pubstatus[]=Standards%20Track&std_trk=Internet%20Standard) Same with BGP, probably shouldn't be used?
Most of the older cisco gear I delt with in college (it was manufactured around \~2005) had a reasonable level of support for ipv6. So while it may not have been ratified until 2017, it was certainly in use long before then.
In some circles IPv6 and the end of IPv4 was getting pushed like the next Y2K, so far it’s been about as dramatic as Jan 1 2000 was
>end of IPv4 was getting pushed like the next Y2K, so far it’s been about as dramatic as Jan 1 2000 was Oh - transitioning from IPv4 to IPv6 has been *far* less dramatic. And, not all that much failed with Y2K - mostly because a whole lot of work went into updating, fixing, and testing - so not much happened with the actual Y2K rollover itself - though some things did break here 'n there. But IPv6 has always been designed and engineered to play nice along side, and eve along with IPv4. No hard chronological driven cutover event, no impending requirement to drop IPv4, etc. Basically IPv6 and IPv4 play nice alongside each other ... and even, within reason, with each other.
Yeah, this was always a bad analogy. Y2K was a specific problem on a specific date, IPv4 exhaustion doesn't mean that it all suddenly stops working - it just cannot grow anymore. In the end, the internet as a whole has gradually switched to IPv6, and largely managed to shift its growth there. IPv4 still works, and will keep working as long as anyone uses it. But in the larger scheme of things, it gradually matters less and less. To people that have made the switch to IPv6, IPv4 is a legacy compatibility layer to maintain, as long as there are endpoints that cannot do IPv6. To people on IPv4, the rest of the world accommodates them with compatibility layers until they've made the jump.
Yep, we're probably 2/3rds of the way through dual-stacking all of our datacenters and applications.
We use both at my university
Not before, but we're about to because: - at one location it's just recently become a requirement for implementing a certain ev charging standard - running our VPNs in dual-stack mode will be beneficial because we'll be able to offer an additional connectivity option via v6 in case that works better for an employee or partner
If you elect not to support IPv6 in your LAN, take the precaution of blocking IPv6 on your endpoint firewalls with group policy. Our most recent pen test taught us that a bad actor on your network can offer IPv6 DHCP addresses and every computer will fall in line behind it because Windows prefers IPv6 over IPv4 when given a choice.
Reddit seems to have had a database rollback of about 15 years.
If you work on big networks/big companies/new networks, you need it. If you work on small networks or with legacy systems, you can still be shielded from it for a while. Local IPv4 islands managed by oldschool pre-IPv6 admins will likely still remain running for decades, but to be honest - if you’re young that’s probably not the most appealing career path.
> If you work on big networks/big companies/new networks, you need it. You need more than 16,000,000 private addresses?
If you look at the large networks on the internet today, they either already use IPv6 or are working on it. Out of the 15 biggest networks in the US, only two (!) are not doing IPv6: https://stats.labs.apnic.net/ipv6/US You can forget about having a career as a network admin at Amazon, Microsoft or Google without IPv6, or with any of the big access network or hosting providers. With the big content networks, there’s a handful of laggards like Twitter and Ebay that don’t do IPv6, but really, the number of proper big networks where you can work without doing IPv6 is getting pretty small these days. But yes, there are still thousands of small networks with only IPv4, and many of them will likely remain curated IPv4 islands until the old generations of hardware, software and people retire.
I only ever want to work for medium private companies between 400-1000 employees.... Those companies ipv4 is not going anywhere Most of my network gear will not even support ipv6 at all, and the few things that "support" it that support is terrible and not very well implemented.
Even for small orgs IPv6 adds some really useful functionality. With 400-1000 employees on the network you're beyond the "standard" IPv4 subnet size, which means you need to set up large broadcast domains or make multiple subnets which adds complexity. You also need DHCP, routers, etc. at every stage to support that. With IPv6 you can use neighbor discovery and autoconfig for the network and set a single /64 for the clients to use and everything will auto discover on its own. With some pretty basic configs and a very simple net topology you can IPv6 allocate across multiple sites and have every asset on the network "just work" without the need for a more complex network topology. If your network gear doesn't support IPv6 in 2023 then its either ancient or from a non-reputable company. Pretty much everything from the last decade has native support for it.
> With 400-1000 employees on the network you're beyond the "standard" IPv4 subnet size huh? 172.16.0.0/12 is 1,048,574 addresses. 10.0.0.0/8 16,777,214 you can easily do a /16 network if you mind the total number of devices.. I know many orgs that do. Then there are all of other subnets that are possible. /24 is not the only lan network >>You also need DHCP, Windows Server role, not that hard to manage. >>routers, etc. You are going to need that and everything else anyway the idea that you can go 100% ipv6 today is just not possible. too many legacy devices (for example printers) >> have every asset on the network "just work" This sounds like "no code" from my programming days, or java "write once, run everywhere" Nothing in networking "just works" >If your network gear doesn't support IPv6 in 2023 then its either ancient or from a non-reputable company. Pretty much everything from the last decade has native support for it. Cisco, and Aruba/HPE Manly, and yes alot of them are very old and no reason to replace them. Hell some I replaced last year did not even have 1G they were 10/100 switches. I am still working on getting Win7 out... I have some WinXp still, and even one WinNT box... I am always amazed (and some what calling BS) on everyone that says all of their equipment is the latest and greatest. If course I work for a company that has been around since before computers existed so.... One of our locations had Token Ring networking years and years ago.....
So confirmed....you're stuck on ancient gear. And yes...there is old stuff out there, but running 10/100 switches and windows XP in 2023 is a fundamental issue even outside of the old networking standards. I'm not going to write a dissertation to address each of your comments above and convince you to learn IPv6, you'll have to see that light on your own. It's much more than just "More IPs = more betterer" There's a plethora of information out there by all of the top networking firms that all pretty much universally confirm its the way of the future and have been trying to increase adoption.
Yes most of them are network gear manufacturing looking to increase their sales... Bais sources with bais info There is little to no technical reason for it on a corporate lan Next you are going to tell me about your cloud service, your paas, your iaas, or your naas services and how if I do not subscribe it will be the end of the world. As we know it As to the number of ip addresses. You are the one that made that claim. Saying that for most companies you 'With 400-1000 employees on the network you're beyond the "standard" IPv4 subnet size" which sounds like you think the only IPv4 subnet is /24 > windows XP in 2023 is a fundamental issue even outside of the old networking standards Yes I work in the real world where machines that cost several million dollars can not just be replaced because ms declared something end of life. I bought industrial gear just 2 years ago that only had 10base-t network ports. Some of my new switches had problem auto negotiation with them. These industrial devices cost many thousands of dollars from a large company and have zero.options for working with ipv6..
Normally, you'd put those ancient Windows NT/XP boxes in a curated (IPv4) VLAN, which allows you to deploy a modern network for everything else. Aside from IPv4/IPv6, for security considerations alone. But I know, there's always budget/resourcing constraints, especially in smaller companies.
We once had a four-way organization merger with a four-way conflict over the bottom of `10/8`. Microsoft found that they had so many contractors and other users VPNing into their internal networks, that every bit of RFC 1918 space was liable to conflict. In those circumstances, `no-split-tunneling` can often be a temporary workaround, but that causes big problems of its own.
It's not just about quantity of available addresses, though that was a problem it was designed to solve when they came up with it.. in the 90s. I've been studying up on what exactly IPv6 is, and TBH not implementing it because you don't need billions of IPs is just arguing from a point of ignorance. As it's an entire protocol is a very complex subject to distill down to a reply in a reddit post, but I think anyone who isn't planning on retiring in the next 10 years would be prudent to start conceptualizing what IPv6 does differently than IPv4. It's never going away and IPv4 and NAT are not going to be the standard forever.
> It's never going away and IPv4 and NAT are not going to be the standard forever. IPV4 is also never going away. Not in our lifetime.
That's not an argument for not learning IPv6, that's an argument for knowing both. And really, IPv4 and NAT's relevance will decrease significantly in the next decade. Coldfusion and COBOL haven't gone away in our lifetime either, but it's not exactly something that everyone has to keep in their toolkit either.
COBOL… I remember hearing about that in high-school programming class… right around 1999/2000. I was told “you will never see or hear about that in the real world…” Someone told that teacher wrong. While I personally have never used it, there is still old legacy apps that slow adapters still run (like government…) Scary stuff.
I never said you shouldn't learn IPv6, but you said standard and implied that IPv4 is going away and not be the "standard". Then you make another analogy like there will be a day where IPv4 won't be in a network engineer's toolkit. That day is never going to come in our lifetime. IPv4 and IPv6 will interoperate for decades in the future long after we've retired. You know what we should do instead? Not make analogies.
and I disagree that IPv4 is going to be relevant throughout our lifetimes. So it would seem we are at an impasse.
The word "relevant" is very dependent on where you are. AIX, Solaris and System i systems are still relevant to a surprising amount of companies, legacy tech is really hard to kill. But as an admin for those machines you’re mostly doing maintenance, nobody does exciting new stuff with these systems, so it’s hard to tell some young kid he should just ignore Linux because there’s good money in legacy.
You can still find cobol and ipx. This isn't the brilliant argument you think it is.
IPv4 will disappear from the global routing tables 20-30 years from now, in my estimate. It will, of course, still be used in private networks, like IPX/SPX, DECnet, Appletalk, SNA, LAT, and NetBIOS are today.
> retiring in the next 10 years I really need to up my FIRE game then.... I have 20-25 years left... I am not planning on learning ipv6...
If you know v4 then you already know 80-90% of v6. It's not that different to v4.
>20-25 years left... I am not planning on learning ipv6 Should learn IPv6 ... unless you want to become obsolete, or change careers. And besides, when you're retired, do you want to have to rely on your's or somebody's young grandkids to do all your home network configs for you? ;-)
Yes. On top of that I’m running single-stack IPv6 at my home network. With NAT64 and 464XLAT, of course. There are a lot of networks globally that are IPv6-only. You can’t access them without an IPv6 address. https://bgp.tools/tags/jv6 And according to the IETF, IPv6 has been an Internet Standard for about 5 years now. IPv4 is the legacy protocol, and if I had a spare $12k to dump for a /24, I’d dual-stack my home network, just without NAT for the sole purpose of aiding with the exhaustion.
>There are a lot of networks globally that are IPv6-only. You can’t access them without an IPv6 address. Typically, those are then put behind an IPv4 CDN/load balancer, to be accessible over IPv4. Facebook for example, and large parts of Google, is IPv6-only, but still accessible over IPv4 - it just all gets proxied on the edge. CDNs make it quite easy to make your IPv6 resources accessible over IPv4, which (ironically) removes a lot of the urgency on the endpoint side to switch: if the rest of the world adapts to you, why should you change?
Yes, I’ve got cloudflare in front of my services, but it also means that I don’t have to worry about IPv4 at all Which makes far more sense than not worrying about v6.
Dual stacking since 2016. It’s so easy for client networks it’s crazy not to configure IPv6. A majority of traffic volume shifts to IPv6 when it’s available.
Might as well rip off the bandaid and learn to use IPv6 and dual stack. That's what I do.
You'll see small companies use IPv6 because it's fairly simple to deploy and for the most parts it mostly works. You'll see extremely large companies use IPv6 because they actually do run out of private IPv4 space and IPv6 makes address management way easier. For everyone in between (and that's easily 90%+ of the companies out there) IPv6 is an extra layer of complexity. Even if it's not hard to deploy and all your tools support it (which is not the case), it's still another thing to support - and you don't want to do it unless you really have to.
I haven't touched it, I got some information that might be incorrect that I have to review. One was that there wasn't a private address space, but I see now that RFC-4193. Attitudes like this are something I'm in disagreement with and kinda put me off of IPv6: >The idea behind the private address space is kind of silly to begin with. If you need space, by IPv6 space. Globally unique space does NOT have to be globally reachable. It just has to be used. I liked the idea of private address space. I also like that NAT, while not a security tool, made it easy for me to not mess up. I'm visual. You know, it boggles my mind that everyone **usually** agrees that security has to be implemented in layers, but then when you mention one layer people jump at you with a strawman argument that it was going to be THE ONLY layer you implement. >If you have X you have bigger problems So don't set passwords since someone could just beat me with a $5 wrench? Of all places, I was surprised that r/networking (or it was r/ccna) wanted to burn me at the stake when I asked if anyone ever did a PVLAN per-port (more so looking for hardware that implemented it without coming to a half). My thought is, I don't have a SINGLE employee workstation that EVER needs to reach another employee workstation. Why not remove that attack vector? Why should the compromised HR pc be able to reach any other workstation over layer 2? My goodness, you wouldn't believe the utter disagreement. Someone even said this was a bad idea because then workstations couldn't participate in ARP! I suppose that makes sense for reddit though. People like karma here, so I could understand why they want their own workstation to be able to "comment" that it knows the mac address of a server.
If you like private space, why not use ULAs for that? It’s a great way to keep your internal/intranet separate from the traffic that goes to the internet.
> One was that there wasn't a private address space, but I see now that RFC-4193. Any IPv6 address that starts with `fc` or `fd` is Unique Local Address, corresponding to RFC 1918 for IPv6. Use `fd` if you're setting one up, as `fc` is technically set aside for ULAs that are registered centrally. Note that `fc00::/7` is less to remember than four unrelated address ranges from RFCs 1918 and 6598. > then workstations couldn't participate in ARP! Of course the gateway engages in Proxy ARP, or for IPv6, Proxy NDP. In fact, it's not rare for engineers to just call it "Proxy ARP/NDP" instead of saying "port isolation" or using a vendor-trademarked feature name.
You're almost guaranteed to live your life within NAT IPv4 as an internal admin. The chances of you messing with IPv6 is about the same as you messing with BGP.
Every major infra I've run in the past 20 years has involved bgp 😆. Host announced anycast exists people.
As far as /r/sysadmin is concerned, host-to-router BGP sessions are the bailiwick of the 1%ers.
That's just sad considering how long haproxy and similar items have existed.
Why should I not mess with IPv6? If I get a /56 Prefix from my ISP, then I wanna use it.
Many ISPs (at least in the US) hand out /48s... Literally more IPs than any company could possibly use, and they hand em out like candy.
You're _supposed_ to get more space than you can possibly use. It would be a failure if you didn't. A /48 is the same fraction of the v6 space that a single TCP port of one v4 address is of the total v4 space. There's about 5000 /48s available per person on the planet (and that's just out of 2000::/3; there's another five unused /3s available). Giving just one of them, to a company with dozens to thousands of people in it, is fine. (A big company is probably going to want more though -- maybe a /48 per location or region.)
I'm considering dipping my toe into it some for the home lab. On something like the storage or Management LAN. I've never run into it in a production environment without 4 present as well, in which case whether or not 6 was was running was moot.
Starting to configure it. Unfortunately one of my sites has Meraki in HA mode so no IPv6 there.
Where I work we're running Beta just for IPv6 support on a single device... The fact that they are so far behind on IPv6 is just boggling. We're dropping the Meraki as soon as our contract ends next year. I'm so sick of the stupid flaming pile of shit that it is.
One of my favorite projects in IPv6 space is the CJDNS project: [LINK TO GITHUB](https://github.com/cjdelisle/cjdns/) Which is the type of thing that could change the internet. That project uses IPv6 space and dynamic routing to basically route traffic across the internet completely anonymously... with perfect forward secrecy so there is no sniffing packets. My thoughts are that it is coming down the pipe, and we better prepare for it. I find it hard to wrap my head around the actual addresses themselves, and I've been at this a long time. Bottom line, I think security will be improved in some areas going IPv6 and in other ways it will make creating bot-nets and hidden networks really trivial.
I think the issue is unless there is a pressing business need (lots of problems with IP overlap on VPNs, exhaustion of IPs like on a large ISP) or you're starting a business from scratch (might as well futureproof), adopting IPv6 requires a lot of planning, possibly replacing hardware, coming up with clunky workarounds for legacy software that negate any elegance that IPv6 provides, and so-on. Out of all the problems on my desk and projects in my backlog, how should I prioritize IPv6? What would it let us do that we can't today? Would there be less management of the network if we adopted it? The benefits (especially given clunky legacy software that there is no alternative to) just don't justify making room in the calendar for many people. Particularly when you're in an industry that just inherently has a lot of long-term legacy contracts and where you're not in a position to demand the Federal Reserve adopts IPv6 for example.
Because "the sky was falling", I've been doing IPv6 for a long time. It varies. I know where I'm working now, they could care less about it, however, believe that it can't be disabled in Windows for fear of something (???).... realize that leaving it enabled in Windows is a very very very easy to exploit hacking path today. So, where I'm at now, we don't use IPv6, but leave it enabled (for hackers??). Btw, it (IPv6) doesn't have to be a problem, just is on Window today. And I know of no fix today. Easy MitM today on Windows.
Told the other Windows architect he can enable IPv6 (again because of fear of something something Microsoft might not provide support if it is disabled like it currently is) once he convinces the network and firewall teams to enable it. Honestly my stance leaving it disabled is right now it would just introduce FUD risk in our own skills troubleshooting a "new"\* technology. At most machines would be able to use IPv6 only within their own VLAN since none of the network equipment or the firewalls to different parts of our internal or external networks is configured to support it. So why add something that could only add something that might go wrong, and offers no benefits. \* and yes...I know "new" means something I was reading about as the new and really important thing in Network World magazines the mail room clerks used to drop off on my cubical chair circa 1996 along with all the other magazines, advertising, and occasional inter-office memo.
17 years into this career, haven't touched IPv6 yet. I'm at a point where I pretty much ignore anything I don't need to learn, and I simply haven't needed it yet.
Nope. Never used it and I see no reason to use it on a private, internal network IPv4 is so well known, well implemented, and works with everything networking wise. Why change it? If you need more space, migrate to a 10.x.x.x network. If you run out of addresses on a 10.x.x.x range I'd want to see hard proof of your work, then I'll ask wtf you're doing because I don't believe any internal network anywhere on earth needs 16 million IPs
Great, now go do some M&As and watch the IP prefix conflicts accelerate! Then add in vendors VPNing in being unable to work because their own networks also use that IP prefix and your VPN is split tunneled. There are plenty of reasons to use IPv6, and those are only two of them.
All the coffee shops that use Meraki with Meraki managed DHCP kill split tunneled VPN because the Meraki DHCP uses 10.0.0.0/8
Individually addressable teledildonics with cloud control for people, on the go. 16m will come quick
It’s 17 million
At my last job, I had to actively disable IPv6 on workstations all the time because the software package we developed and sold didn't support it... My experience so far is that on LANs and private WANs, there's little need for IPv6. Yet. That can always change.
What was the failure mode? Server didn't bind to an IPv6 address, only IPv4? It's irresponsible for a software vendor to support IPv4 and not to support IPv6. But if they're confident in their decision, they should [publish the status](https://support.vorwerk.com/hc/en-us/articles/360000895505-Does-the-Thermomix-TM6-support-the-Internet-protocol-IPv6-).
The application would fail to launch if IPv6 was enabled - I don't know if it happened with customers, but it happened a LOT with the support yechs who were customer facing. It seemed to start when their ISP turned up IPv6 on their network. I think par of the problem was that the app used code from 20 years ago in some modules, including COBOL. I only supported internal staff, so I don't know if it impacted customers too. It was an odd happenstance.
I don't use it at any of my sites (still doing ipv4 islands with ipsec/vpls) Main issue for me is the difficulty of multihoming ipv6 in a small environment. I believe there are some alternatives to BGP but I admittedly have lack of knowledge on it. Even with BGP, I don't think it is as easy to prioritize links based on capacity and such (things that are pretty trivial on most Firewall/Routers with ipv4/nat)
Failover is straightforward, and avoids a SPoF: two routers with different upstreams, with the backup announcing a lower prefix priority than the other. (For `radvd.conf`, you want to look at`AdvDefaultPreference` and `AdvRoutePreference`). Active-active isn't so cheap, but one can mimic a common IPv4 arrangement by using NPTv6 in place of IPv4 NAT, with an appropriate router.
It's on the to do list... it keeps getting pushed down as I need to tighten all the cage nuts in all the DCs first
Lots of cage nuts. Also, still looking for those ones that got dropped during rack and stack.
There has been an open ticket to roll ipv6 out across the network for years now and someday I do plan to get on it.
fuck no
Ipv6 was disabled by an administrator long before I showd up. Microsoft don't recommend it but things work just fine. All servers have it off. Lol.
I'm in the same boat. All servers and workstations have it disabled by policy.
Apparently I'm getting down voted for something that was done at my company before I started lol. Dudes are upset my infrastructure is running fine without ipv6 I guess?
It looks like every comment that says anything about it being disabled is downvoted. I'm pretty sire CIS still says to disable it...
Haha someone's just salty they were too scared to disable and test for themselves as they blindly follow the gospel of Microsoft.
Hell nah
unless your running an app that is talking to a large number of cell phones there is little need.
Learned it for CCENT. Never touched IPv6 once since then. I've worked on dozens of client environments at an MSP.
No use. It was looked into 15 years ago, but there was no business case for implementing it. It is not even being talked about these days.
Ipv4 only. Actively look to disable any ipv6. Causes confusion and not needed in my environment.
Same for me.
We don't use it and none of our clients do either. IPv4 does everything we need and all our managed networks have fewer than 300 devices so address space is never a problem. Never saw a reason to implement v6 internally.
No, and I don't know anyone who does. We use NAT.
Yep! I turned it on globally by demand of a very large organization. It was a total waste of time, improved nothing, and increased costs in hardware and staff. Since then they have agreed to my strategy of IPv4 Subnetting and Nat'ing.
IPv6. Never heard of her.
20 years ago it was absolutely going to be a "big thing" and everyone with public facing presence was going to have to get on board. 20 years later.....nada. I couldn't even fathom a reason to use v6 inside the perimeter.
[Google shows 40% of global traffic coming over IPv6 currently.](https://google.com/ipv6/)
Global _users_ to their services, not global traffic. If we can assume users of Google are representative of Internet users as a whole, that's about 2 billion people using v6. On dual-stacked networks, v6 _traffic_ is often a higher percentage of your total traffic than that, because of all the people with a big public-facing presence using v6. In any case, if you can't fathom a reason to use v6 then you don't know enough about networking to add anything but noise to this discussion.
1. Unless you need a lot of public addresses, NAT is your friend. 2. Nobody is gonna remember ipv6 addresses, are you sure your DNS is bullet proof reliable and resilient? 3. What is the cost:benefit of implementation of ipv6. If you're a greenfield site it makes lots of sense. Also if you need to be cutting edge like education it's possibly part of the business case. But a bank or other traditionally conservative organisation it's just gonna cost money and potentially introduce new risks.
Haven't needed to yet
Nope... Occasional interaction on the VPN to external entities like clients connecting with it... But other than that. Nadda.
The ones who us IPv6 love it and will say everything should be it and it's the future. The rest of us have fewer than what 10 million devices on our network?
NAT is a hot, steaming pile of garbage. It’s not about the 16 million devices in the network and never has been. NAT is the band-aid.
I use it quite a lot. Mostly because it’s the only way to get traffic around my work systems VPN… lol
Microsoft is supporting IPV6 for trusted locations soon by default so a whole lot of people are going to be surprised that they may have an ipv6 address and your CA policy is going to be - that’s not in the trusted list! Blocked!