That is the exact opposite off what it says. The US government has actually mandated IPV6 only networks in the next few years.
>At least 20% of IP-enabled assets on Federal networks are IPv6-only by the end
of FY 2023;9
>b. At least 50% of IP-enabled assets on Federal networks are IPv6-only by the end
of FY 2024;
>c. At least 80% of IP-enabled assets on Federal networks are IPv6-only by the end
of FY 2025
Aren't these comments getting a bit old at this point? Running dual-stack should not be any more difficult than just running IPv4. There is a plethora of automated deployment tools and I'd hardly think people are DHCP'ng addresses to their servers. You don't have to use SLAAC and can statically assign addresses just like IPv4. Even for your dual stacked devices getting IPv6 addresses via RA can be tracked back to their IPv4 DHCP bootp requests.
I'm making the assumption here that anyone concerned about their network attack surface is actively capturing network or netflow data in which tools like openargus[1] or Arkime[2] make all of this collectable/searchable. Additionally most network devices support mirror/monitoring to offload data if you aren't working on the scale of needed dedicated taps/aggregators.
Realistically though what information can you glean from a hosts IPv6 address that wouldn't already be part of WHOIS? With IPv4 you already know there are only (3) rfc1918 reserved ranges. Anyone can use them as they see fit so seeing a 10/8 address in a email header doesn't automatically mean the company is huge its just what they picked. Myself, i've just never really bought into the whole "dns naming" or discovering private address ranges giving anything away. With existing NAT device tracking moved onto more unique features such as browser, screen size, etc. such that IP address tracking is probably not as accurate.
> A transition from IPV4 to IPV6 creates a new per device tracking capability that leaks internal network structure.
I doubt it. Your load balancers will be the only addresses that will be addressable anyway. Your IPv4 load balancers will also be "leaking" IP addresses.
Clients that aren't misconfigured will use random IPv6 addresses that rotate. The usual default is once per day but that's a mere preference, you can make your computer take a new IP every minute if you want.
They do feel a bit old. Especially considering that is not the "TL;DR" of the paper. The paper makes no statement on whether or not it is a good idea to use ipv6, only that the US Government is transitioning and some guidelines on how to do that.
You are getting downvoted but ipv6 was ratified in 1998. The sunken cost fallacy is real here. At what point or threshold should there be a proposal for a simple address length extension of IPv4. Even in cloud providers who have an army of sysadmins and netadmins they don't support v6 in private networks.
Let's be very honest here, does anyone have a good reasom to believe another 25 years would mean ipv6 would displace ipv4 or even solve the address shortage when cgnat and other workarounds are profitable to network vendors?
My controversial solution is to stop using numbers for addressing on layer3. A new IP protocol should have hierarchial domain name addressimg. So google.com would have .com as the top domain you would have routes for each TLD with non-ISPs default routing tlds like .com, ISP networks would resolve the route for .google under the .com routing table and so on. Upper layers would be oblivious except that you have less code now. On LANs you can create whatever domain hierachy works for you so long as the TLD is part of a predefined list. TLDs will have a fixed maximum length of 128bits for routing performance amd such. PKI/TLS would work just fine except now you have an extra layer of security in that ISP routing tables would have to also route to the wrong AS and can implement source route (customer1244.telecast.isp) validation to make mitm only slightly harder and address spoofing ddos impossible. So forget about numbers, ascii is also numbers. You are already doing this with v6 and 2600:: and other prefixes. As for layer3 translation, I have an even more controversial idea that will also solve wifi security and lan based mitms for good but for another comment.
While this is true World IPv6 Launch Day in 2012 is the date most people point to for earnest IPv6 deployments. It was also not completely ratified until 2017.
> At what point or threshold should there be a proposal for a simple address length extension of IPv4.
If you pass a IPv4v2 packet it will not be routed. You'll need to replace all networking equipment to support IPv4v2...which is what we've done/currently doing w.r.t. IPv6. The engineers who wrote the spec were very much aware of how much "we've got one shot at this" was.
> another 25 years would mean ipv6 would displace ipv4
We're at over 50% deployment in the US. Again, it's closer to 10 years.
The IETF has a two-level standards system consisting of "Proposed Standard" and "Internet Standard". IPv6 was first published as "Proposed Standard" in 1998 and finally transitioned to Internet Standard in 2017. Although officially Proposed Standards are supposed to be treated as "immature specifications", as a practical matter, people routinely deploy on them. Whether an RFC is advanced to Internet Standard is less a question of whether it is mature than whether the editors and/or WG bother to advance it. Here are a number of examples of widely deployed protocols that never advanced beyond Proposed (1) all versions of TLS (2) HTTP/2 (3) SIP (4) QUIC.
I think choosing 2012 as your start date is pretty generous. Proponents of IPv6 were telling people to start deploying long before that. In fact, the IETF sunsetv4 WG, dedicated to sunsetting IPv4, was formed in 2012 several months before World IPv6 launch day. Arguably, World IPv6 Launch Day was a reaction to the failure of v6 to get large-scale organic deployment 12ish years in.
> If you pass a IPv4v2 packet it will not be routed. You'll need to replace all networking equipment to support IPv4v2...which is what we've done/currently doing w.r.t. IPv6
That was never the difficult part. Mosr corr routers and expensive gear supported ipv6 many years ago.
> We're at over 50% deployment in the US. Again, it's closer to 10 years.
That means almost nothing. Even if you have 100% deployment, it is more expensive to maintain v6 by server admins,developers and consumers alike, especially in the not so rich countries. It just adds more maintenance cost, it isn't economically practical to expect it to hit critical mass and the everyone stops writing v4 specific code and config. IPv42 or whatever will be a good solution will be economically viable requiring the smallest change by end users and producers. V6 was developed by a committee of network engineers that only saw things from a network operator and vendor perspective. The lesson from sunken cost fallacy is that existing investment cannot be used to justify continued investment and in this case the problem of v4 shortage has been addressed by other means in a way that will keep it alive for decades more.
In my opinion, a solutiom that requires a firmware update that can work with existing ASIC and is economically viable is possible but the discussion about that isn't even happening. Billions will be wasted on the hopes that decades from now ipv6 can stand on its own.
>At least 20% of IP-enabled assets on Federal networks are IPv6-only by the end of FY 2023;9 >b. At least 50% of IP-enabled assets on Federal networks are IPv6-only by the end of FY 2024; >c. At least 80% of IP-enabled assets on Federal networks are IPv6-only by the end of FY 2025
https://www.cio.gov/assets/resources/internet-protocol-versi...