I really don't know where this ridiculous claim comes from. Yes, IPv6 addresses look more complicated but various other things about the protocol are drastically simplified — no more on-path fragmentation, simpler header formats and fewer required header fields, correctly implemented link-local scopes, previously separate ICMP+ARP+IGMP protocols consolidated into ICMPv6 (which handles neighbour discovery, router advertisements, path MTU discovery and multicast group membership amongst others), no more broadcast, and in many cases clients will quite happily get along without DHCP. If anything, it is considerably less complex.
No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems.
Moving fragmentation to an extension header similarly creates problems. Dealing with extension headers is just more code complexity.
Link local does not work (reliably) in browsers: https://[fe80::1]/ doesn't work on most platforms.
ICMP, ARP, and IGMP perform completely separate functions. Putting then all in ICMPv6 doesn't help. In contrast, having ND in ICMPv6 leads to code complexity. In IPv4, ICMP logically uses IP to send packets with uses ARP. In IPv6, ICMPv6 logically uses IPv6 to send packets, which uses ICMPv6 for neighbour discovery.
IPv6 created a lot of flexibily by having multiple addresses per interface created automatically from router advertisements. And multiple routers on a subnet that can each support different prefixes (poor man's multihoming). Net result, certainly with devices that frequently connect to different networks, such as phones and laptops), is way too complex.
That said, the only way forward is IPv6. Putting everything behind multiple layers of NAT is ultimately going to fail.
I thought this was the other way around, IPv4 only guarantees reassembly up to 576 bytes so DNS avoided issues with split UDP datagrams by limiting the payload to 512. Ends stuff got added on once the defacto internet mtu became 1500 and there was more room. Things like 4G have a 1482 MTU though so it may seem frag!mentation helps but in reality most IPv4 routers don't fragment and reassemble anymore they just drop. In practice with DNS this has meant either keeping the packet size closer to 1k or using TCP which negotiates miss and handles correcting/merging lost split payloads.
If anything IPv6 has made the situation cleaner with a minimum supported MTU of 1280 vs IPv4s 68 guaranteeing the 1kish UDP DNS payloads can make it through without relying on pmtud.
1. You have to specify an interface, since fe80::1 may be in use on more than one link (so that becomes https://[fe80::1%en0]/ for instance), 2. that IP address may not be assigned to any devices on the link-local network.
What platforms does it not work on?
I wish. ipv6 under cgnat is a PAIN.
- broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly
- address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one.
- hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts.
- for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses (yes, you can of course manually assign addresses in your prefix and you can just make them low numbers and hide everything else behind a ::, but you still have to remember your prefix which still is impossibly hard and there's no cheating there even if you know somebody at your ISP because it's not entirely under their control either)
- and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks.
- also subnetting: due to many ISPs still doing /64 allocations to their customers, and due to the way how SLAAC works, you often have to decide between subnetting or SLAAC (which still is the default in many OSes). Worse, some ISPs only do a /128 assignment (one address), so now you're back in NAT territory, only that's really, really murky waters because next to nobody is doing this ATM. If your ISP only gives you a single v6 address, you are practically screwed about running v6 internally. If you're given a single v4 address (which is common practice), you can do NAT/RFC1918 addressing and you're fine.
- v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways.
- in home networks where you want devices to be reachable directly (for P2P usages like video calls or gaming), there's no widely-supported equivalent to UPNP or NAT-PMP yet to punch holes into your firewall to make clients reachable. Yes, you don't have to do NAT any more, so clients are potentially reachable, but you really don't want that, so your firewall is still blocking all incoming connections, but now there's no way for an application to still punch temporary holes through which is a solved problem in v4 (where a hole is punched and a temporary port-mapping is created)
There are more issues as your network grows bigger, but this is what I had to deal with in my small networks (<50 hosts) where I can say with certainty that v4 was much more straightforward to get up and running than v6 (though I was much older when I was learning v6 than when I was learning v4, so I might also just be getting old and slow)
Yes. These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable ipv6 rather than learning about all these small issues and working around them.
So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site, but, the internet is as much about the global scale as it's about the local site and when the new thing is much harder to use than the old thing, inertia is even bigger than in the normal "everything is mostly the same" case (where inertia already feels like an insurmountable problem)
So that's me in a nutshell. I've read various things on IPv6 over the years, and I think I might even have the O'Reilly book laying around somewhere. I understand some of the basics, but I don't really "get" IPv6. I'm still at a bit of a loss on how my local network should be configured, and what services are needed for what.
Though I'm really at a loss as far as network security and firewalls go. I've been setting up firewalls with NAT for 20 years, but I'm still not sure how its all going to work with IPv6. In the mean time, I just disable all IPv6 stuff on the firewall machines, and try not to worry about it.
In the age of constant probes, a simple mistake can compromise our entire network, which sounds... unpleasant.
I suppose I'll just keep putting off learning about IPv6 until we get to the point where I can't order a cloud instance from our provider that comes with an IPv4 address.
- network names have been steadily been getting better with mDNS and related tech
- SSDP (the tech underlying UPNP) already covers IPv6, there's no need to add new one (your bigger possible issue is incomplete implementation on v6 side on CPEs)
- home router/CPE vendors are converging on "standard v6 default firewall" ruleset (it's actually something I encountered in random bought AP/router combos from random electronics store, not something techie-oriented). It establishes basic filtering that resembles what people think they get from NAT, and couples well with UPNP's support for IPv6. This also includes proper handling of ICMPv6
- subnetting is a problem, yes. Especially due to SLAAC vs DHCPv6 issues in some OSes.
It's not all nice, but it's getting there.
Multihoming also isn't new and isn't really IPv6-specific. It might be more likely that you'll have multiple IPv6 prefixes but the majority of source address selection rules that you are used to in IPv4 will still apply, and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway.
Subnetting is probably not easier or harder. The address length doesn't change how subnetting or how routing tables work and I am not really convinced that an IPv6 addressing plan should really be any worse or better than an IPv4 addressing plan. The minimum prefix size of /64 for a network segment is about the only extra consideration there, but if anything, it should be simpler than having to manage globally routable address space and private address space separately given that you can now manage address space as a true single hierarchy.
You're right that SLAAC vs DHCP can add a bit of mental overhead, but for most configurations, configuring DHCP and letting RAs be sent automatically in IPv6 is not much different to configuring a default gateway in DHCP on an IPv4 network.
Finally, as for ICMPv6, it has always been bad behaviour to just outright filter ICMP without consideration for what it will break. The stakes are indeed higher than in IPv4, but it seems worth it if we can eliminate two entirely separate protocols in the process and firewall vendors and admins are just going to have to learn that.
I get there are a lot of cognitive factors involved in why people resist IPv6 but it really isn't as alien as most people think and most of the concerns are easily answered.
A thousand times this (and your other points, great reply thank you) - the ergonomics of using IPv6 at a local scale are atrocious for mere mortals. And you didn't touch on "should I use Stable Privacy or EUI64 for my laptop IP?" and other small cuts and bruises which technologists think everyone should "just know".
I am not sure why you think multihoming is a bad thing. That is one of the major things that in my experience makes IPv6 LAN configuration a lot more useful and robust than IPv4 with private addressing. It sounds like you misunderstood some basic IPv6 assumptions - configuring an IPv6 LAN is not that much more difficult than an IPv4 one. I would never go back to IPv4 for my LAN.
The vast majority of IP networking end users only care about their LAN. (Home and business networks.)
Making things easier for ISP's is not what they asked for and not what they want.
My current curiosity is why my DDNS service only allows IPv6 or IPv4 records for a single domain. Why can't I have a dynamic IPv4 record for the one IPv4 address I have and then make many dynamic IPv6 records as subdomains?
Multicast is sent to a broadcast address and replicated to all ports. If the switch doesn't do any IGMP snooping, multicast and broadcast are the exact same thing.
> - address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one.
SLAAC now has support (and all major operating systems support it) for sending DNS servers down as information in the router advertisement. I do not run a DHCPv6 server on my local network and all my systems get my local DNS information without issues
> - hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts.
This was also the case in IPv4, nothing new here.
> - for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses
Even in IPv4 no-one tends to remember IP's, we have solutions for that like systems automatically announcing themselves on the local network using mDNS.
> - and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks.
There is no subnetting. Just give the local network a /64.
> - also subnetting: due to many ISPs still doing /64 allocations to their customers
If you are a home users with a single flat network, that is all you need. If you are a power user and need multiple networks, your ISP probably has a way to do a prefix delegation request that is larger.
> Worse, some ISPs only do a /128 assignment (one address)
Name and shame them... the /128 should only be for the external customer gateway, and is not strictly necessary. Most ISP's allow you to ask for an IA_NA for a single address, and an IA_PD for a prefix delegation.
> - v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways.
v4 also breaks in mysterious ways when you just blindly firewall ICMPv4. It's the reason we have so many dumb work-arounds for MTU issues because "ahhhhh, firewall all the things"
> there's no widely-supported equivalent to UPNP or NAT-PMP
UPnP and NAT-PMP were replaced with https://en.wikipedia.org/wiki/Port_Control_Protocol which was standardized in 2013.
> So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site
I completely disagree. IPv6 is as simple to deploy as IPv4, and in fact because everything now has a globally unique IP address is makes routing so much simpler.
I then set up the firewall to expose one of these addresses and I could ssh to my machine from the outside world. A win!
Unfortunately the win was short lived. Eventually I lost the ability to ssh in. It turned out that the 10 IPv6 addresses were replaced by a different bunch of 10 addresses. So I would have to reconfigure the firewall again. I decided it was too much work for me and disabled IPv6. Maybe some other time.
However, it didn’t turn out that way in the real world. Every time my router resets, all of the IPv6 addresses in my home network change. So, I don’t use IPv6 to connect among computers in my home network; since I also get one IPv4 address from my ISP, I simply use IPv4 NAT so that the addresses in my home network are easily remembered and do not change.
The reason I don’t use IPv6 and 6:6 NAT is because the IPv6 designers feel this makes networking too complicated, never mind that NAT is a solved problem, so 6:6 NAT support just really isn’t there.
Another annoyance I have with IPv6 is that it needs to have more than one localhost IP address, considering that IPv4 has a 24-bit space for localhost. A large number of localhost addresses is useful for network regression tests (e.g. if we have one authoritative DNS server on 127.10.0.1 and one which isn’t responding on 127.10.0.2, does our recursive DNS server on 127.12.0.1 correctly handle an upstream DNS server being down? Nice to be able to run the test using only localhost IPs; also nice to be able to change the IPs each test so we don’t have to wait for the kernel to release TCP sockets for a given IP + port).
For the record, I have gone to a lot of effort to give my open source networking software IPv6 support.
Fair enough. Though you can use private addresses for private networks:
* https://en.wikipedia.org/wiki/Unique_local_address
> The reason I don’t use IPv6 and 6:6 NAT is because the IPv6 designers feel this makes networking too complicated, never mind that NAT is a solved problem
The problems with NAT continue to grow. A whole swath of IPv4 addresses (100.64.0.0/10) were reserved to allow telcos to do CG-NAT. Because folks often used the usual private RFC 1918 at home, ISPs couldn't necessarily assign those address to client equipment because there was the potential for the same range (e.g., 10/8) to be on the "inside" of the user's router/CPE as on the "outside".
* https://datatracker.ietf.org/doc/html/rfc6598
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
Of course now we have double-NATing: once at at the CPE and again at the carrier. Is anyone living with triple-NATing in production?
Yeah, but then they are not addressable outside your network, right?
The way I look at it, IPv6 does the following for me
1. Doubles the number of firewall rules
2. Doubles the attack surface
3. Double the header size in each packet, with no change in MTU this means less space for data.
4. Doubles the number of routes I need to worry about
5. Doubles the points of failure
All for a benefit of ??? to a residential user.
And while I get your "double" theme, most of them are non-points. Header size? Use adblock. Routes? Oh no, a residential router will now have four instead of two!
Yes, it's another addressing scheme and I agree, the benefits for many peoples' usage is low. But it isn't so bad.
Why do you need NAT at all? You can just use IPv4 to communicate among hosts in the network, and use IPv6 for them to communicate with the world. Nothing about IPv6 forbids the existence of IPv4.
Which is now the reality, but at the time IPv6 was created IPv4 was planned to be killed permanently.
Which while impossible in hindsight, the way IPv6 were designed (without even a semblance of a "private" network, even just two IPv6 addresses*) actually raises the question if IPv6 were really that well-designed.
* Okay, link-local addresses do exist, but they're not amenable or even map to how IPv4-style private networks work.
Now with that in mind, the implementations do all kinds of funny things that don’t seem to meet spec when it comes to router advertisement (the dhcp replacement) and routing. Use the wrong kind of address for the gateway and nothing works for instance.
Sure, I could give localhost a lot more addresses in IPv6 with the appropriate `ipconfig` or `ip` command, but that doesn’t work with the testing Docker container whose Dockerfile I share with my users (since their Docker container will have only one IPv6 address; also, you can’t run `ipconfig`/`ip` type stuff in a Docker container).
Isn't this solved by using dynamic dns updates?
I've been running a native ipv6 home network for a few years and have not run into any issues. I access my servers by their hostnames.
For the record, I have written a DNS server from scratch. Three times, actually (try 1, which is still the authoritative DNS server I use for my domains, try 2 which is a tiny caching DNS server, and try 3 -- which, yes, reuses code from try 2 -- is a very flexible DNS server which uses Lua for configuration).
* significant understatement
With IPv6 you can just stick your address on a DHT and peers can connect to you 100% of the time, no matter what.
The only thing that sucks is that you can't count on an internet-connceted device having IPv6 yet.
How do you keep that secure, so that you don't get spammed by any bot on the internet?
It is so refreshing to see this written down somewhere. All of the academic papers I've seen comparing the empirical routing performance between IPv4 and IPv6 show a negligible performance difference. However, in the two states I've lived where I have looked at IPv6 vs IPv4 performance I see consistently higher pings with IPv6. Traceroute reveals that each individual hop adds the about the same amount of latency, but there are ~15% more hops for IPv6.
If I play a competitive game then I don't want to be adding 10 ms of latency unnecessarily. So I just disable IPv6 on my gaming rig? C'mon. We can do better.
What happens is when the large backbone providers have disputes, the de-peer with each other IPv6, which causes rerouting to be visible. They can't "punish" the other with IPv4 depeering, since that would make their own customers angry.
Its a small friction, but it adds up quickly and makes working with ipv6 feel sluggish and painful.
(A common response when i say this is "isn't that what DNS is for?" and yes, it is. That's great once you have DNS and reverse DNS working, but "its always dns" is a meme for a reason).
The internet being a world resource should be of significant concern to every country. The limited number of ipv4 resources is a weakness of the U.S. and othe western countries. As is the lack of "cyber security".
Ipv6 is effectively supported everywhere but the ISP. Again, it's intentional, the only reason they'll change is federal requirements. It's the only reason the ISP here does 25/4. Because broadband requirements. They didn't change anything to do it either, they just flipped the switch. Costed them maybe a couple thousand in labor.
I don't know how valid this argument is in this context. Most ISP clients nowadays are connected 24/7, so they are using an IPv4 anyway. They might as well keep the same IP over a larger period of time.
Vodafone Cable and Telekom VDSL, both in Germany, only change your IP if they have to. You'll usually have the same one for many months.
Also, the NAT you're referring to is the one which runs on the customer's hardware, and usually the customer has the option to set up port forwarding.
All this is in the IPv4 / Dual Stack context.
In Germany, we’ve got enough IPv4s that every customer can have their own one, while e.g. in Asia CGNAT and IPv6 are long common.
My sister and parents are similar. None of our IP addresses have changed in the last 2 years. I know because all of our houses are connected for remote backups and file sharing and I limit access by IP address. I have not had to update my firewall rules in 2 years.
Knowing the historical transition issues collected over the past 20 years, we could, as an industry and society, design a next generation and provide a reasonable rollout target of, say, 2030, and move towards that.
Since 1998/99, there's been an explosion of networking, and large cultural shifts (billions of mobile devices, IoT, etc) which were not around when all this was specced out. No technology adopted IPv6 as a default during that time, and I dare say most things (services, devices, etc) aren't even tested against IPv6.
After 20+ years of this, I see IPv6 as a failure, even if there is 30-50% adoption (or perhaps because of those figures).
We need more addresses. That's the primary problem of IPv4 right now.
So if all the IPv4 code is written to handle 32-bit addresses, how do you create an addressing system that has more than 32-bits of data, but fits with-in a 32-bit data structure?
AFAICT, code updates will needed to occur on every device that needs to talk to the new address scheme. So what's the difference between updating every device to handle IPv6 versus updating every device to handle this hypothetical IPv7?
IETF also asked that for AS numbers (which were only ~60,000 originally!) Sure enough, there were some reserved bits actually on the spec, which they used to add an extended address. Nowadays, the original BGP actually operates on a single number: AS23456 and the actual AS number is on that reserved spot.
What's worse is that it was actually already proposed in 1992 (https://datatracker.ietf.org/doc/html/rfc1347). Did it work? Actually, yes! Why IPv6 then? Because it's shiny!
Prefixing all IPv4 with 0.0, opens up another 64k copies of the 4 billion address space of a.b.c.d. This would have been far easier for everyone (not just a few admins, but everyone that ever has to deal with an IP address) - to understand and deal with. It still could be, with the aforementioned-yet-not-developed-nor-propsed IPv7.
A ipv4-only host cannot ever directly communicate with a IPv6/IPv7/.. host. The issue is simply that you cannot fit more than 32bit of information into 32bit.
There are plenty of migration technologies that exist to integrate IPv4 and IPv6 (NAT64, tunneling ipv6 over ipv4, etc. etc.). And anything like IPv7/IPv6-light will end up with the same issues and solutions you are facing today with IPv6.
Plenty of good migration options exist(ed) that allow for each host to be single stack and still talk to each other while upgrading at different rates. The basic approach was a simpler ipv6 that didn't change all the concepts around with an ipv4 range embeded in it.
Routing then just proceeded as normal, but if an IPv6 host was trying to talk to an IPv4 host, if the next step in route was IPv4, then router drops the extra IPv6 bits (would likely have been hop before server).
Conversely, when IPv4 host is talking to an IPv6 only host, they are routing back, and then when the next link in route is IPv6 only you rehydrate the IPv4 address with the IPv6 IPv4 prefix. The IPv4 network is talking to you using IPv4+PORT. The Port is basically how we get extra address space ALREADY with IPv4 and CGNAT (but to allow transition now you map that inbound IPv4+PORT to an IPv6 address. Being smart you can actually do a predictable mapping here if you wanted).
Other little tweaks make this better - but the key is that I as an end user can go IPv6 only on my network (ideally in a more IPv4 style without the complexity).
Anyways, some networks are already converging / heading this way with things like X64LAT or whatever - allowing devices to basically see an IPv6 only world. But you are still dragging along this insane IPv6 complexity
The counterpoint gets repeated and repeated all over, because it was already done in BGP.
Unfortunately, most are purists who will never look at using TUBA (https://datatracker.ietf.org/doc/html/rfc1347) or something because they want "clean code" or something.
Real world is messy, and code should adopt over it.
literally every single iOS app is required to fully support ipv6 and will not pass apple review if it doesn't.
Some group will not move at all. IPv4 is fine for them.
And the rest of the world will get an endless amount of translation between IPv4 and the new protocol that is a nightmare to debug.
There is also the big question whether there actually exists a better transition path. I have not seen any ideas that are likely to be accepted on a large scale by the networking community.
Name me an existing system where:
a) requires IPv6; but
b) not because of its long address.
Good luck finding such a system.
> You can if you want, but despite what some people will claim, it probably won’t make much difference.
This apathy is exactly why adoption is slow. For all its faults Google needs to be commended for their commitment to IPv6. They are the only large email provider I see sending and receiving email using IPv6 even though "it probably won’t make much difference"
The problem is that (for example) for forums etc., 40-bit addresses (the best-approximation considering that only a slice was allocated and /64 is treated as a single network connection) adds a whole lot of problems when it comes to combating spam etc. 8 bits sounds like nothing to you but you multiplied their problem 256 times. In shorter words, it's not always economical to turn the proverbial switch on. For Google, they can rely on their AIs but for small forums? That's just (unfortunately) an additional attack surface on something that they want to be gone.
Yes, Spectrum should fix their issue and if more of the Internet was IPv6 user facing, they’d have to more urgently, but what will happen instead is companies will just turn off IPv6 for maximum compatibility.
Yeah, so that's overestimating the number of IPv6 addresses by quite a couple of orders of magnitude. This website estimates the number of atoms at 10^49 to 10^50, whereas 2^128 is in the order of 3 * 10^38. https://www.fnal.gov/pub/science/inquiring/questions/atoms.h... Perhaps the writer was thinking of grains of sand instead of atoms? I'm not sure how many sand we have, but it's probably more in the 2^128 ballpark.
* Stars in the Milky Way: 400 Billion
* Galaxes in the universe: 2 Trillion
So (4x10^11)x(2x10^12)=8x10^23 stars in the universe.
* Size of IPv6 address space: 3.4x10^38
Find the ratio between addresses and stars:
* 3.4x10^38 / 8x10^23
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe.
From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study"
On the surface of the Earth, there are 8.4 IPv4 addresses per km^2. Not counting the oceans, that would be 28 IPv4 addresses per km^2 land.
IPv6 gives 10^17 addresses per mm^2 (yes, square millimeter).
In terms of volume, 10^8 IPv6 addresses per mm^3 throughout the Earth.
A very useful site: https://ipv6-test.com/
I wish this were all it did. People can make arguments about IPv6 being "simpler," but it's often not simpler in practice:
- You still need to run dual-stack - You need to re-learn a lot of your networking fundamentals - Despite IPv6 being effectively infinite, most ISPs will not give you a static IP - Most hardware is built for IPv4 and NOT IPv6 - Local subnetting is far more complicated. Not just due to the the length of the address, but due to the fact that you often need to work out SLAAC and/or have a local DNS service to handle the address changes.
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.043 ms
# OK
$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.063 ms
# OK
$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.023 ms
# OK
$ ping6 ::ffff:127.0.0.1
PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
ping6: sendmsg: Invalid argument
# CONFUSING & DANGEROUSJust think how much simpler it would have been to keep all the IPv4 tooling with just an ifdef to make the addresses wider, and a few version changes for IP and ARP.
Part of what makes V6 adoption lag is that it took a while to be supported across the board by router vendors, OS vendors, etc. And a lot of the reason for that is all the gratuitous changes from IPv4.
Then IPng got started and for most of 1990s IETF played with sweeping changes while "temporary solution" that was IPv4 entrenched itself in worse and worse ways.
Mostly I came aware that in IPV4 the router tries to create a local multicast group, using IGMP snooping you can solve some problems to get your broadcast thru multiple devices, but in IPv6 this is kind of confusing to me... does any one has information on this?
Anyone else get a strong climate change parallel vibe from this section? Hopefully the stronger (dis)incentives of a slower rollout of carbon reduction efforts will be able to overcome some of these same obstacles.
ping google.com round-trip min/avg/max/stddev = 5.925/7.695/10.634/2.093 ms
ping6 google.com round-trip min/avg/max/std-dev = 6.348/8.013/10.869/1.965 ms
traceroute and traceroute6 both had 8 hops.
See also: https://en.wikipedia.org/wiki/IPv6_transition_mechanism
To go from 4 to 6, the public WiFi box will need to use a 4 to 6 "broker" and there are surprisingly few of these around and they're not usually free.
So basically, your home network and Pi is future-ready, but public infrastructure might need a moment...
Shoulda gone for 1024 bits and made people really whine
---
From the RFC (emphasis added):
> The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses.
[…]
In §3 Migration:
> Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup.
So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses.
How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing?
In §6 on DNS:
> TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses.
Which is basically describing AAAA records.
---
* https://news.ycombinator.com/item?id=28326806#unv_28328593
As far as I could tell from the RFC, if TUBA counts as v4-compatible then so does v6.