DevContainers allow for setting up your IDE with extensions, rules, and other configuration. They also support Docker compose so migration shouldn't be that bad
> DevContainers allow for setting up your IDE with extensions, rules, and other configuration.
Are people sharing their editor configs with this? I thought it was a way of getting a development environment setup, but those shouldn't have editor extensions and configuration.
IIRC there was some hullabaloo made with RIPE in ~2017. Half of it was "go to IPv6 and it isn't a problem" and the other half was "or also log the source ports so we can complete the identification through CG-NAT".
It's nearly 8 years later, we haven't moved to IPv6, and they stopped making noise so I'm left to assume they either got more source port logging or found some other method?
There is people using chef/kitchen knifes for murder too. That doesn't mean we should regulate them for army use and monitor all cooks.
Yet this is what many but certainly not all decision makers are doing.
Good, fundamental, stuff is happening too, such as RPKI for example.
Some "politics" is definitely not happy about that, but its good for the internet.
Not sure what you mean you can't use the Internet without IPv4. Yes some sites won't work but some sites don't work with https but that doesn't mean you can't use https on the internet
All those sites you mention work with IPv4 just fine. When you shut off IPv4 in favour of IPv6 you shut off access to probably 70% of the Internet. Let's see what happens when you don't enable IPv6? Oh nothing... that's right, the Internet will remain working just fine. There's very little incentive to support IPv6 when all that is required to connect to the Internet is IPv4. Which comes to the fundamental issue with the deployment and transition with IPv6, it will always remain a second class citizen until we no longer need to rely on IPv4.
>it will always remain a second class citizen until we no longer need to rely on IPv4
At $DAYJOB we are already running some services on IPv6 only to save costs, and if our IPv6 connectivity drops people notice it immediately. Is IPv6 still considered a second class citizen when this is the case?
Here's a reminder that "the Internet" is not just Google, Facebook, and Amazon.
Literally the one job it had, to prevent address depletion on the Internet. Just to be clear, we're talking about the Internet here, and not some IPv6 island.
I don't get you. We are running dual stack for the time being, and indeed we cannot solve address depletion this way, but that doesn't mean we are doing it forever.
At some point -- maybe when 60%, 70%, or 80%, or 90% of the Internet is running on IPv6 -- Internet services at a large scale will begin to deem IPv4 as a liability, and drop IPv4 support along with the addresses they are holding.
I am not talking about a distant future either. We already have IPv6-only servers up and running, mine included, and we haven't even reached the 50% milestone. In a way, the existence of IPv6-only servers meant that IPv6 is _already_ preventing IPv4 address depletion, because those servers would otherwise have to compete for IPv4 addresses with the other servers too.
Furthermore, I find "I hate IPv6 because it hasn't eliminated IPv4" a really weird opinion (it's not exactly what you said, but it is how I interpret your first few comments combined) because it's sort of recursive: hate IPv6 -> continues to use IPv4 -> IPv6 is unable to eliminate IPv4 -> hate IPv6??? Perhaps you can elaborate on it further, but I don't think it will be agreeable either way.
IPng was meant to avert the IPv4 address exhaustion crisis. IPv6 was chosen as the way forward. A transition group (ngtrans) was formed and instead of taking the time to consider how to integrate IPv6 into the existing landscape it decided to create a separate island. We now have a hodgepodge of transition plans and umpteen different transition mechanisms of which none make IPv6 first class.
What do I mean by making IPv6 first class? Basically a transition plan/mechanism where IPv6 is interoperable with IPv4. This was one of the primary considerations at the time when IPng were still deciding, where other contenders at the time had a better transition plan story. Instead the IPng group chose the technology that didn't have any transition plan because they liked the shiny new features that were irrelevant to averting the address exhaustion situation. Their failure to address the transition back then is why we're in this IPv6 adoption bottleneck.
Can you tell us what the better transition story was? As far as I can tell, v6 is already approximately as interoperable with v4 as it's possible to be.
I don't get your claim that it's a separate island at all. It's not. This machine is v6-only and isn't on an island, it has full access to the entire Internet.
TUBA had a sane transition story [1] although I do not know of the mailing lists these were discussed (probably done in in-person IETF meetings).
For IPv6 transition mechanism you can look into the ngtrans mailing list regarding AutoIPv6 which is basically an extension of 6to4 but instead of connecting IPv6 networks over IPv4 it would extend to IPv4 hosts. There's also an archive link in my post history which you can lookup (on phone).
As for current v6 being interoperable with v4, that is patently false.
I think you are having a very romanticized view of 6to4 and its derivatives.
By the late 2000s it was clear as day that 6to4 wasn't working out (the design rationales of contemporary IPv4<->IPv6 transition technologies will tell you why [0]). By extension, AutoIPv6 which was building on 6to4 was also unlikely to work out. Even worse, AutoIPv6 relies at least partially on anycast 6to4 which was later deprecated due to operational problems [1].
The only surviving 6to4 derivative is 6rd and even that is mostly phased out.
>As for current v6 being interoperable with v4, that is patently false.
You need to define your scope. Are you talking about programming? Or ability for IPv6 clients to talk to IPv4 servers? Or...?
IPv6 is interoperable with IPv4 from a programmer's perspective, once you upgrade your sockets from accepting sockaddr_in to accepting sockaddr_in6, your program automatically receives both IPv4 and IPv6 packets with IPv4 addresses represented as ::ffff:x.y.z.w.
And from a client's perspective, IPv6 clients absolutely can connect to IPv4 servers through a border relay of some sort, typically NAT64. But you can do SIIT as well if you are feeling fancy. Note that this is not much different from 6to4 and its derivatives.
As for the perspective of a server, indeed this is unsolved but again AutoIPv6 doesn't solve the issue as well since the server still needs a public IPv4 address.
Hm... according to that draft, TUBA's transition story is dual stack, which is the same as the main transition approach for v6. How come it's sane for TUBA but not sane when v6 does it?
> As for current v6 being interoperable with v4, that is patently false.
This machine is v6-only and can reach the entire Internet, including v4-only hosts. It clearly has more interoperability than you're claiming or this wouldn't be possible.
Interoperability would be the ability to use either IPv4 or IPv6 and talk to each other seamlessly. This is clearly not the case for IPv4 clients talking to IPv6 servers. This is clearly not the case for IPv6 servers accepting IPv4 connections.
As for TUBA, the transition plan incorporated tunneling, with a bit more thought put into this we could've had something similar to AutoIPv6. That document was just a starting point and outlined some important aspects of the criteria such as low administrative overhead for transitioning IPv4 networks to IPng, something which IPv6 falls completely flat on.
I've talked from v4 clients to v6 servers before, and I've accepted v4 connections to v6 servers. How can it be so clear that it's not possible when I've done it before?
> As for TUBA, the transition plan incorporated tunneling
The transition plan for v6 also incorporates tunneling (6in4 is the same thing as the EON tunneling described in the draft you linked), so again I ask why TUBA counts as having a sane transition plan when doing the same things in v6 doesn't.
There's not much administrative overhead involving in transitioning a network to v6. For most people it involves doing exactly no extra work beyond what they already do to deploy v4. Of course, you do need to reconfigure anything that's been configured such that it can only work with v4 (and this might be quite a lot of stuff), but that was always going to be necessary no matter what you're transitioning to.
It's a tp-link Archer, and since it supports Wi-Fi 6 it must have been from 2019 or later.
Hmm, I just went deep into the settings and there's an IPv6 toggle (disabled by default, and requires playing with menus to make it actually work) now. I don't remember seeing that (and I explicitly checked) when we switched the ISP-side last April. But the firmware is dated after that, so I choose to trust my memory.
Actually trying to connect to ipv6 stuff besides the router itself (in fd00::/8, that's good) just gives "Destination unreachable: Beyond scope of source address" though (probably because I only have an fe80 link-local address though?). If I play with the settings some more I get a ::/64 address, but that just gives me a black hole ... wait, is that even a legitimate address? Do I need to fill in the prefix manually or something?
I'll play with this some more in the morning I guess. But I certainly wouldn't expect a normal user to get IPv6 working under these circumstances if I haven't figured it out yet ...
That's a leftover from back when IPv6 was very new (yes these utilities are that old), and the networking utilities (ping, traceroute, etc) understood only IPv4. It's no longer necessary, all relevant networking utilities have since been upgraded to work with both IPv4 and IPv6; you can use just "ping" with a IPv6 address and it should work.
> You can use just "ping" with a IPv6 address and it should work
Not on BSD-derived operating systems (macOS included). You must use ping6 to ping an IPv6 address (including a hostname that only publishes AAAA records.)
From `man ping6` on macOS Sonoma:
> There have been many discussions on why we separate ping6 and ping(8). Some people argued that it would be more convenient to uniform the ping command for both IPv4 and IPv6.
> The following are an answer to the request:
> From a developer's point of view: since the underling raw sockets API is totally different between IPv4 and IPv6, we would end up having two types of code base. There would actually be less benefit to uniform the two commands into a single command from the developer's standpoint.
> From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands.
Interesting. I’ve tried macOS and OpenBSD and they both require using ping6 to ping IPv6 addresses. I wonder if FreeBSD changed this recently or if it was always that way. Regardless, macOS is the elephant in the room here as it’s a lot more popular than any of the (other) BSD’s.
I often use ping to check if a machine is alive or is reachable at large. Then it might be more informative if ping tried all addresses the name resolves to. You wouldn't need to specify the protocol version.
ping6 and ping4 are symlinks to ping on my system, and are equivalent to passing -4 or -6 to force a specific version. The default behavior negotiates either fine.
I'm testing with `ping ipv6.google.com` as well as the router IPs. Between each change, I disconnect from wifi.
The router itself has a ping tool and can ping ipv6.google.com just fine. So I assume the upstream options are correct.
For the LAN, I have 4 options:
* ND Proxy gives me an fd/8 address. I can ping the router via its fd/8 or fe80 address, google blackholes.
* DHCPv6 gives me an ::/64 address. I can ping the router via its fd/8 or ::/64 addresses, google blackholes
* SLAAC + Stateless DHCP does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address
* SLAAC + RDNSS does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address
In all cases, the IPv6 addresses the router says are its DNS servers blackhole. I do have working DNS returning IPv6 address for google though; presumably because the ipv4 DNS server it advertises (which is the router itself) still works.
If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80. The ISP router is really bad, all it has is an "it's connected" indicator and a bunch of phone numbers and URLs for support.
Still bypassing, pinging `ip6-allnodes` gives me 3 responses, all with fe80::/64 addresses: my computer, an unknown, and the wifi router; I can ping those addresses, as well as the wifi router's fd/8 address.
Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address.
Hm, I just noticed that the last bit of the router's address varies between some of its addresses ...
fd::/8 addresses (really fc00::/7) are ULA addresses [0], defined as non-routable local addresses, so it’s expected that you can’t get out to the internet through just that address.
Do you have any smart home devices? Protocols like Thread and HomeKit establish their own randomly-generated ULA prefixes and advertise them through RA’s (router advertisements) and correctly-configured devices in your LAN will observe the RA for that network and generate a local address for it (including your router.) So just seeing a fd/8 address doesn’t mean your actual router gave you it, it just means that something on your network is using a ULA prefix.
Basically, it’s possible the real problem is that you’re not actually seeing an RA from a “real” (routable) IPv6 subnet when behind your router.
> If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80
When you do this, can you ping out? (`ping6 2607:f8b0:4004:c17::65` or something to rule out DNS issues.)
> Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address
What you want here is dhcpv6 and prefix delegation. This will make your router ask the ISP for a real IPv6 network to use, and upon receiving this from your ISP, will send RA’s out to your local network for a “real” (2607/16 or whatever) network. A prefix length of 64 should do it, unless you need multiple subnets inside your router. (People say dhcpv6 is obsolete by SLAAC, but prefix delegation is a different thing… if you want to have your own router obtain a network prefix from an ISP, DHCPv6+PD is the only way to do this.)
reply