5 ms·

IPv4 flag day (in 2030-02-01)

19 points by zinekeller 4y ago

ddtaylor 4y ago
Would be awesome. Likely won't happen though.
csande17 4y ago
The author of this page seems to have just added a bunch of company logos to the "Supporters" section at random, with no indication that those companies actually support this or are planning to remove IPv4 support on February 1st, 2030.
- bombcar 4y ago
  > Supporters > They don’t endorse anything on this page, but they love the internet. This is ... as the kids say, sus.
- deleted 4y ago
  [deleted]
LinuxBender 4y ago
I think this is a good movement and a decent timeline goal. In my personal opinion, as a suggestion I believe the Site Operators section could use a link to a detail page that offers additional tips such as ensuring that equivalent firewall rules and kernel settings are applied to ipv6 settings to match ipv4. e.g. sysctl, iptables, firewalld, nftables, ipsets, dns blocklists Site operators should also ensure that whatever protections they have added to ipv4 have a corresponding protection on ipv6. Always test your migration on a test/staging/beta version of your sites first and keep DNS TTL low prior to and just after testing. Or in the case of datacenters, add a new ipv6 vip on your load balancers for testing using a unique endpoint name to avoid your production clients finding it by mistake before you are ready. Additionally there are DNS propagation validators [1] to verify DNS settings for ones test/staging sites. Qualys [2] has a tester for checking that both ipv4/ipv6 https settings match. Qualys also have a test [3] for clients. [Edit] As others noted the sites that are purported to support this movement should have a corresponding page on their site linking back to this domain otherwise they should be removed. The CTO of Cloudflare [4] frequents HackerNews so that should be easy to bring to closure. [1] - https://www.whatsmydns.net/ https://www.whatsmydns.net/ # Note: their web client does not wait long enough at times and may fail until you hit refresh on some probes. [2] - https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ [3] - https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.htm... [4] - https://news.ycombinator.com/user?id=jgrahamc https://news.ycombinator.com/user?id=jgrahamc @jgrahamc
dpedu 4y ago
> The current IPv4 is unnecessarily slow I've never heard of IPv6 being faster than IPv4. Does anybody know what they're talking about?
- LinuxBender 4y ago
  Not sure. The only thing that comes to mind are clients that prefer ipv6 over ipv4. In Linux this is defined or defaulted via /etc/gai.conf. If the file is absent ipv6 will be preferred by some DNS libraries and applications. Those clients will try ipv6 DNS lookups and if that does not exist will retry with ipv4. That adds the delay of RTT of the DNS server combined with cache or lack thereof.
  - chomp 4y ago
    I guess SLAAC is faster than DHCP also?
- fweimer 4y ago
  IPv6 was optimized for simple software forwarding implementations. For example, the header checksum was eliminated, so that the TTL (or hop limit) update does not need to recompute the checksum. But the IPv4 header checksum is so weak that it is entirely possible to update the checksum directly without full recomputation across the entire header, so this was only a significant win compared to an unoptimized IPv4 implementation. More importantly, IPv6 requires a linked list traversal to find the TCP/UDP port numbers, rather than a simple computation of a variable offset. Maybe it was difficult to predict in the 1990s that hardware implementations that need to look at port numbers would be common by the end of the decade. But the claim that the IPv6 header was optimized for efficient forwarding stuck around even after it became clear that the increased flexibility really interfered with hardware implementations of packet filters.
- duskwuff 4y ago
  Routing for IPv6 traffic is sometimes marginally faster than v4 (cf. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html), but this is probably more a matter of v6 traffic not using some older, slower v4-only networks.
jl6 4y ago
Is this just a lone wolf hoping to crowdsource this event into existence or has there been some actual planning by major players?
- hotpotamus 4y ago
  This looks slightly more serious than my attempt to move on from the whole IPv6 fiasco by skipping it and going directly to IPv7 in that he made a website and I did not.
  - LinuxBender 4y ago
    Surprised you didn't fast forward to ipv10 [1] [1] - https://datatracker.ietf.org/doc/html/draft-omar-ipv10-06.html https://datatracker.ietf.org/doc/html/draft-omar-ipv10-06.ht...
zinekeller 4y ago
OP here, I thought that this is like DNS Flag Day (https://dnsflagday.net/2020/ https://dnsflagday.net/2020/, https://dnsflagday.net/2019/ https://dnsflagday.net/2019/) which is a real thing (which resulted, notably, on musl begrudgingly adding TCP support for its DNS resolver). As pointed by several comments (https://news.ycombinator.com/item?id=31521868 https://news.ycombinator.com/item?id=31521868, https://news.ycombinator.com/item?id=31521924 https://news.ycombinator.com/item?id=31521924) it seems that they are trying to fake it until it became real, but personally I think 2030 is still too wishful.
- AnIdiotOnTheNet 4y ago
  > I think 2030 is still too wishful No shit. The ISP my company pays a boatload of money to get a connection from still doesn't support IPv6 in any meaningful way.
- rascul 4y ago
  > which resulted, notably, on musl begrudgingly adding TCP support for its DNS resolver Do you have a reference for this? The HN thread about musl not supporting TCP for DNS wasn't that long ago. https://news.ycombinator.com/item?id=30642632 https://news.ycombinator.com/item?id=30642632 Edit: I did glance at musl's change log but I didn't notice anything. It's possible I missed it.
matthewmacleod 4y ago
This is just some kind of weird rip-off of https://dnsflagday.net https://dnsflagday.net – an actual thing – by someone who has no idea what they're talking about.
mattl 4y ago
Yeah, I call bullshit. Cloudflare is not about to stop supporting IPv4 in seven years.
jka 4y ago
Anyone feel like ratcheting up the optimism in the room for a change and trying to make this happen? (upvote, share with your network operator friends, ISP friends, mention it at relevant meetups, and so on) Yes, maybe it's a slightly ridiculous site, but I doubt you'll regret being involved if you do promote the switch to IPv6 and it becomes feasible as a result of that.

19 points by zinekeller 4y ago

Would be awesome. Likely won't happen though.

The author of this page seems to have just added a bunch of company logos to the "Supporters" section at random, with no indication that those companies actually support this or are planning to remove IPv4 support on February 1st, 2030.

bombcar 4y ago
> Supporters > They don’t endorse anything on this page, but they love the internet. This is ... as the kids say, sus.
deleted 4y ago
[deleted]

LinuxBender 4y ago

I think this is a good movement and a decent timeline goal. In my personal opinion, as a suggestion I believe the Site Operators section could use a link to a detail page that offers additional tips such as ensuring that equivalent firewall rules and kernel settings are applied to ipv6 settings to match ipv4. e.g. sysctl, iptables, firewalld, nftables, ipsets, dns blocklists Site operators should also ensure that whatever protections they have added to ipv4 have a corresponding protection on ipv6. Always test your migration on a test/staging/beta version of your sites first and keep DNS TTL low prior to and just after testing. Or in the case of datacenters, add a new ipv6 vip on your load balancers for testing using a unique endpoint name to avoid your production clients finding it by mistake before you are ready. Additionally there are DNS propagation validators [1] to verify DNS settings for ones test/staging sites. Qualys [2] has a tester for checking that both ipv4/ipv6 https settings match. Qualys also have a test [3] for clients. [Edit] As others noted the sites that are purported to support this movement should have a corresponding page on their site linking back to this domain otherwise they should be removed. The CTO of Cloudflare [4] frequents HackerNews so that should be easy to bring to closure. [1] - https://www.whatsmydns.net/ https://www.whatsmydns.net/ # Note: their web client does not wait long enough at times and may fail until you hit refresh on some probes. [2] - https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/ [3] - https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.htm... [4] - https://news.ycombinator.com/user?id=jgrahamc https://news.ycombinator.com/user?id=jgrahamc @jgrahamc

dpedu 4y ago

> The current IPv4 is unnecessarily slow I've never heard of IPv6 being faster than IPv4. Does anybody know what they're talking about?

LinuxBender 4y ago
Not sure. The only thing that comes to mind are clients that prefer ipv6 over ipv4. In Linux this is defined or defaulted via /etc/gai.conf. If the file is absent ipv6 will be preferred by some DNS libraries and applications. Those clients will try ipv6 DNS lookups and if that does not exist will retry with ipv4. That adds the delay of RTT of the DNS server combined with cache or lack thereof.
- chomp 4y ago
  I guess SLAAC is faster than DHCP also?
fweimer 4y ago
IPv6 was optimized for simple software forwarding implementations. For example, the header checksum was eliminated, so that the TTL (or hop limit) update does not need to recompute the checksum. But the IPv4 header checksum is so weak that it is entirely possible to update the checksum directly without full recomputation across the entire header, so this was only a significant win compared to an unoptimized IPv4 implementation. More importantly, IPv6 requires a linked list traversal to find the TCP/UDP port numbers, rather than a simple computation of a variable offset. Maybe it was difficult to predict in the 1990s that hardware implementations that need to look at port numbers would be common by the end of the decade. But the claim that the IPv6 header was optimized for efficient forwarding stuck around even after it became clear that the increased flexibility really interfered with hardware implementations of packet filters.
duskwuff 4y ago
Routing for IPv6 traffic is sometimes marginally faster than v4 (cf. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html), but this is probably more a matter of v6 traffic not using some older, slower v4-only networks.

jl6 4y ago

Is this just a lone wolf hoping to crowdsource this event into existence or has there been some actual planning by major players?

hotpotamus 4y ago
This looks slightly more serious than my attempt to move on from the whole IPv6 fiasco by skipping it and going directly to IPv7 in that he made a website and I did not.
- LinuxBender 4y ago
  Surprised you didn't fast forward to ipv10 [1] [1] - https://datatracker.ietf.org/doc/html/draft-omar-ipv10-06.html https://datatracker.ietf.org/doc/html/draft-omar-ipv10-06.ht...

zinekeller 4y ago

OP here, I thought that this is like DNS Flag Day (https://dnsflagday.net/2020/ https://dnsflagday.net/2020/, https://dnsflagday.net/2019/ https://dnsflagday.net/2019/) which is a real thing (which resulted, notably, on musl begrudgingly adding TCP support for its DNS resolver). As pointed by several comments (https://news.ycombinator.com/item?id=31521868 https://news.ycombinator.com/item?id=31521868, https://news.ycombinator.com/item?id=31521924 https://news.ycombinator.com/item?id=31521924) it seems that they are trying to fake it until it became real, but personally I think 2030 is still too wishful.

AnIdiotOnTheNet 4y ago
> I think 2030 is still too wishful No shit. The ISP my company pays a boatload of money to get a connection from still doesn't support IPv6 in any meaningful way.
rascul 4y ago
> which resulted, notably, on musl begrudgingly adding TCP support for its DNS resolver Do you have a reference for this? The HN thread about musl not supporting TCP for DNS wasn't that long ago. https://news.ycombinator.com/item?id=30642632 https://news.ycombinator.com/item?id=30642632 Edit: I did glance at musl's change log but I didn't notice anything. It's possible I missed it.

matthewmacleod 4y ago

This is just some kind of weird rip-off of https://dnsflagday.net https://dnsflagday.net – an actual thing – by someone who has no idea what they're talking about.

mattl 4y ago

Yeah, I call bullshit. Cloudflare is not about to stop supporting IPv4 in seven years.

jka 4y ago

Anyone feel like ratcheting up the optimism in the room for a change and trying to make this happen? (upvote, share with your network operator friends, ISP friends, mention it at relevant meetups, and so on) Yes, maybe it's a slightly ridiculous site, but I doubt you'll regret being involved if you do promote the switch to IPv6 and it becomes feasible as a result of that.