The only case where I care about an IPv6 address is for something I actually want to expose to the internet. A temporary address would be quite annoying in that case.
It's fdac::1. If you're using random 48 bit or 64 bit numbers in your IP address you're doing it wrong.
I have zero concerns that the IPv6 namespace for my home network will conflict with another administrative site during a merger. So.. it works great. Also super handy when the DNS resolver for my local network is down because of power outages or other unrelated failures.
A home network has neither of those, you're running a nerd network. You can set up an mDNS relay, and those devices can use other methods to register their addresses & get DNS updated (DHCPv6, DDNS, random cloud services, etc.).
I think the Matter standard is going to cause IPv6 adoption to increase significantly in the coming years. People will demand it, without even knowing what Matter or IPv6 are. They just want to be able to turn their lights off from their phone without any extra hardware or software.
Matter is only local networking. Essentially everyone has IPv6 on their local network.
That said, I disagree with the parent statement that v6 isn't going to happen. It's already happening at a steady rate. From the Google stats it's steadily rolling out. Some countries are reaching 100% v6 deployment. I wouldn't be surprised if we eventually see some countries with high v6 deployments see services which are v6 only.
They've had years to demand it, I don't see why it would suddenly change. Most users who buy "smart" appliances are not power users, don't set everything up themselves and just rely on manufacturer's servers anyway and don't need a direct connection - and are okay with it.
I’m always bemused when I read comments like this. Regardless of whether you think IPv6 is good or bad, it is happening. IPv6 traffic to Google goes up by a few percentage points a year, steadily, and is at around 50% now.
There’s something to be said for human readable addresses. I’m a little nostalgic of how the .hack world was envisioned, where servers had address names like Hidden Forbidden Holy Ground.
If roughly 10 million words exist, then allowing any three words in order creates a space for 10^21 addresses… five words and you’re close to ipv6 address space, six words and there’s more combinations than ipv6 addresses.
You can set your ULA to something like "fddd:192:168::/48" and then on your vlan you prefix hint, say, "66". Now, any device on that vlan will be addressable by "fddd:192:168:66::$host". For example, your gateway ('router') for that vlan would be "fddd:192:168:66::1".
If you want to be really wonky you can script DHCPv6 to statically assign ULA IPv6 leases that match the IPv4, and expire them when the IPv4 lease expires, but like said upthread, addressing hosts via IPv6 is the wrong way to go about it. On your lan, you really want to be doing ".local" / ".lan" / ".home".
> addressing hosts via IPv6 is the wrong way to go about it. On your lan, you really want to be doing ".local" / ".lan" / ".home".
.local is fine as long as all the daemons work correctly, but AFAIK there's no way to have SLAAC and put hosts in "normal" internal DNS, so .lan/.home/.internal are probably out.
> On your lan, you really want to be doing ".local" / ".lan" / ".home".
The "official" is home.arpa according to RFC 8375 [1]:
Users and devices within a home network (hereafter referred to as
"homenet") require devices and services to be identified by names
that are unique within the boundaries of the homenet [RFC7368]. The
naming mechanism needs to function without configuration from the
user. While it may be possible for a name to be delegated by an ISP,
homenets must also function in the absence of such a delegation.
This document reserves the name 'home.arpa.' to serve as the default
name for this purpose, with a scope limited to each individual
homenet.
It may be the most officially-recommended for home use, but .internal is also officially endorsed for "private-use applications" (deciding the semantics of these is left as an exercise to the reader): https://en.wikipedia.org/wiki/.internal
".home" and ".lan" along with a bunch of other historic tlds are on the reserved list and cannot be registered.
Call techy people pathologically lazy but no one is going to switch to typing ".home.arpa" or ".internal". They should have stuck with the original proposal of making ".home" official, instead of sticking ".arpa" behind it. That immediately doomed the RFC.
I do it by abusing the static slaac address. I have a set of wierd vms where they are cloned from a reference image, so no fixed config allowed. I should have probably just have used dhcp6 but I started by trying slaac and the static address were stable enough for my purposes so it stuck.
How does that work? I initially assumed you meant you just statically assigned machines to addresses, which I think would work courtesy of collision avoidance (and the massive address space), but I can't see how that would work for VMs. Are you just letting VMs pick an IP at random and then having them never change it, at which point you manually add them to DNS?
Pretty much. A given mac address assigned in the vm config maps directly to a static slaac address(the ones they recommend you not use) and those preknown slaac address are in dns, Like I said, I should probably use dhcp6 but it was a personal experiment in cloning a vm for a sandbox execution environment. and those slacc address were stable enough for that. every time it gets cloned to the same mac address it ended up with the same ip6 address. works for me, don't have to faf around with dhcp6, put it in dns. time for a drink.
But the point is that is the address you would put in dns if you also wanted to use slaac. Most of the time however you will just set a manual address. And this was with obsd, where when slaac is setup you get the slaac address and a temporary address. I don't really know what linux does. Might have to try now.
Clarification for others: with privacy extensions disabled, SLAAC'd IPv6 addresses are deterministically generated based on MAC addresses. There's also an inbetween (IPv6 are stable per network by hashing).
You have to take into account seasonal trends. The summer is always higher, so yes, we’re currently below last summer, but we are above last April 1st, and this summer will be higher than last summer.
You can’t compare fall winter and spring to last July. You have to compare last July to this July, which hasn’t happened yet, but when it does, it will be higher than last July. Today (April) is higher than last April.
The reason for this is that more people are on mobile connections during the summer (kids home from school) so the summer (as well as the Christmas/new year week) are the highest points of the year.
The fact that it’s “flat” since last July, the high season, means it’s actually still increasing.
> Regardless, when you extrapolate that curve, when do you estimate hitting 100%?
Never? But what’s your point? IPv6 is a failure if it only replaces IPv4 for 99% of traffic?
They should charge a small annual fee and let people reserve a custom word for a given IP. You could even have a small utility on your computer that automatically queries given names to "resolve" to IPs.
And then if they don't like someone they should revoke their word. And they should make it so words with certain endings are delegated to other countries who can also revoke your word if they don't like you.
To facilitate client to client communications, they should add a who-does-it-serve (short WHO DIS) system to get contact information of already reserved names.
I tried it. Maybe it's easier to speak than hexadecimal is.
But I'm not sure that "How morally the enviable assistances categorize the insistent iodine beyond new time where new systems stalk" has the same memorable quality as "correct horse battery staple" does.
Being essentially impossible to memorize is one of the worst attributes of IPv6. I memorize and manually type IPv4 addresses all the time and it's super useful.
Adding two extra bits to each octet, making each octet range from a still memorable 0-1023 rather than 0-255, would result in an addressing scheme 256x larger than all of IPv4 combined. The entire internet works fine even when IPv4 was nominally exhausted. NAT and CGNAT are not sins, they're not crimes, and there's no rational reason to be as disgusted with them as IPv6 fans are. Even then, IPv4 exhaustion wasn't really a true technical problem in the first place, it was an allocation problem. There are huge /8 blocks of public IPv4 space that remain almost entirely unused to this day.
The reason I'm an IPv4 advocate in the IPv4/IPv6 war is that the problem was "we're out of address", not "your thermostat should be natively routable from every single smartphone on the planet by default and inbound firewalls should become everyone's responsibility to configure for every device they own".
CGNAT is a feature, not a bug. Blending in with the crowd with a dynamic WAN IP is a helpful boost to privacy, even if not a one-stop solution. IPv6 giving everyone a globally unique, stable address by default is a regression in everyone's default privacy, and effectively a death sentence for the privacy of non-technical users who aren't capable of configuring privacy extensions. It's a wet dream for shady data brokers, intelligence agencies, organized crime, and script kiddies alike - all adversaries / attackers in threat modelling scenarios.
IPv6 adds configuration surface I don't want. Privacy extensions, temporary addresses, RA flags, NDP, DHCPv6 vs SLAAC — these are problems I don't have with IPv4. More features means more opportunities to footgun with misconfigurations, being forced to waste my time learning and understanding the nuances of each (in again, what amounts to system I want nothing to do with).
"Reaching your own stuff" is already a solved problem, too. Tailscale/Headscale gives you authenticated, encrypted, NAT-traversing connectivity. It's better than being globally routable. It's also opt-in for anyone who wants it, and not forced on anyone, unlike the IPv6 transition.
I don't have your problems with ipv6, and I'm actively using it.
I don't have to rely on extra commercial entities to be able to reach my network.
I did have a problem with hosting my own shit because my ISP by default does cgnat. That cost me an hour of my life to convince a party to give what used to be normal, end to end connectivity.
yes you do, the control plane is closed. Only reverse engineered by the headscale project. The control plane is necessary for the peers to find each other. If you need to rely on such a crucial part being reverse-engineered, than yes, I think it's fair to say you are ultimately relying on commercial entities.
Highly disagree. Middleboxes are a huge problem on global scale and have frozen any innovation below application layer. TCP and UDP even that they are on software not hardware layer cannot be updated or changed, see MPTCP efforts or QUIC giving up and building on top of UDP.
If this is so much privacy problem, IPv6 is there for many years reaching 50%+ deployments in some countries, I bet there should be concrete examples of such breaches and papers written.
> Reaching your own stuff is already a solved problem, too. Tailscale/Headscale
No address to receive communication - no problem install an app that would proxy it through someone who has the address.
Tailscale/Headscale is great, using it daily, but they are not solution to the huge already build global network created to connect devices not connecting devices because lack of digits. Global is key here.
Wouldn't easy and accessible self-hosting be a major privacy win if that's your primary concern? Sounds much more private to run a Minecraft and Mumble server on an old laptop in a friend group than paying a commercial entity like a hosting provider to know about it and have a back door.
Easy and accessible self hosting isn't the primary concern.
It's much more private and secure to run that Minecraft or Mumble server on an encrypted overlay network like via headscale + tailscale rather than exposing both services directly to the entire planet.
But again, the primary concern was only ever address space.
What I tried to express was privacy being the primary concern. The easy and accessible self-hosting on old hardware would be the uses of a home network beyond superficialities like consumption and commerce. Privacy wise headscale as a solution is still not quite there, because it either necessitates an additional third party to host the headscale server and know about all my friends, or jank like dynDNS.
The additional security gained by getting everyone involved to set up and configure separate VPNs for different community utilities is not worth it.
I wouldn't call port forwarding "huge problems". It's only one minor router setting and if you don't want to deal with it, there's the abomination called upnp.
> I wouldn't call port forwarding "huge problems".
Port forwarding has massive problems if you're running applications expecting certain ports and need multiple hosts to have public access to those ports.
I can't think of any application that needs "certain ports" and it's not a public server application. Why would a home net have a public server app? And why would it have more than one?
Public servers would use a firewall, a load balancer, possibly a reverse proxy that does TLS too, between the internet and real app servers anyway. If anyone needs to host multiple servers from their home net, I would expect them to know this.
Maybe I've got a media server with a web interface, my owncloud instance, a web UI to my SDRs, and some other web app I'd like to have public. Now I need a reverse proxy as well, yet another piece of infrastructure to maintain. Trying to firewall it so only my friend's house can use the media server and I can connect to the owncloud from the office and thenSDR from anywhere is messier and more complicated. Or I can just have each device have its own public firewall rules and not have to maintain a reverse proxy as well and deal with its own complications.
I've had game consoles with matchmaking issues with multiple consoles fighting over the same collection of ports
I can't say anything about consoles. I never had one, but I accept what you say is true.
About the other stuff... well... maybe I'm too old, but I think you're doing it wrong.
1) Those aren't public services and they are NOT expecting certain ports. Public means that a random guy on the internet is able to connect to your service without any prior knowledge about it. HTTP(S) for web pages is one of those services. Owncloud is not, even if it uses HTTPS.
2) Since they're not public, each of those services can have its own port.
3) You shouldn't expose that stuff on the internet, even with a firewall. Use a VPN if you want access when you're away. Or a SSH tunnel. Or at least port knocking.
They're services I wish to consume outside my home
> they are NOT expecting certain ports
Damn near everything expects to be HTTPS/443
> Public means that a random guy on the internet is able to connect to your service without any prior knowledge about it
Public just means I have the option to allowing that traffic or not. I can choose to filter it through a lot of different means. IP filtering, authentication, etc.
> each of those services can have its own port
So I change having easy to remember names for weird odd ports and hope all the other applications handle these changes fine and deal with odd port forwarding issues.
> You shouldn't expose that stuff on the internet, even with a firewall. Use a VPN if you want access when you're away. Or a SSH tunnel. Or at least port knocking.
Wouldn't it be nice to have the option to not have to rely on such things and just be able to connect to things directly? And to have that identity stay consistent both in and out if the "local" network?
> They're services I wish to consume outside my home
Like I said, not public.
> Damn near everything expects to be HTTPS/443
So let it. Forward your own chosen port to 443 of the machine with the service.
> Public just means I have the option to allowing that traffic or not.
Nope. That's not what it means.
> So I change having easy to remember names for weird odd ports [...]
Easy to remember names comes from some DNS service, which can't work unless your public IP address stays the same and you can run your own public NS and can receive recursion from your main NS provider. In most parts of the world, I think, IP changes every time you restart the router, even IPv6. So what you have there isn't exactly typical for home users. That one extra service and complication that you don't actually need.
I don't have to remember anything HTTP(S). No ports, no IPs, no names, nothing. I use bookmarks.
> Wouldn't it be nice to have the option to not have to rely on such things and just be able to connect to things directly?
Wouldn't it be nice if there were no bad guys on the internet, no bots, and no zero days?
> ipv6 is awesome.
For Google and for you, maybe. But let me know how much you like it after your first cryptolocker. I suppose your backup storage is also public on the internet?
Outside the home, in other words in networks other than at home. Potentially without VPNs. Accessible from other public IP addresses, potentially limited scopes of those.
It seems you're thinking that allowing the traffic from other public networks is an all or nothing thing. That either you allow all public network traffic or none of it. That's just not true. If I know my office network is one prefix, and I know my friend's house is another prefix, and I know my cellular carrier in my city is usually this prefix, I can greatly limit the scope of access. It doesn't have to be an all or nothing, either its open to every single other device or only local devices, I can define exactly which networks or devices I want to allow the traffic from or not.
If I wanted to just let my friend's network audio receiver to connect to my music server, I can add it's public ip address and allow that traffic. No VPNs, no tunnels, no proxies, no non-standard port assignments, just directly allowing it to talk to the music server. All through the public internet, but still locking down my music server to just local traffic and his remote network audio receiver.
That's all still "public" networking.
> In most parts of the world, I think, IP changes every time you restart the router, even IPv6.
Often not with IPv6, prefixes stay pretty consistent usually. Not always true, but often true. I've had the same prefix for many, many years at multiple locations and multiple providers without having any kind of payment for static IP addresses.
> So let it. Forward your own chosen port to 443 of the machine with the service.
So now I have to remember the port for local and the port for remote along with different IP addresses for both, or I can just use the normal service port and the same IP address either way, and have one DNS entry for that IP address and it works anywhere I want it to.
> But let me know how much you like it after your first cryptolocker.
Entirely a tangential, unrelated point once you understand how things like "firewalls" actually work.
> I suppose your backup storage is also public on the internet
My most important backups are offline and offsite. But for other stuff, yes, it has a publicly routable IP address. Its not generally accessible publicly though. There are these things called "firewalls", they're really quite neat. One should also think about authn/authz as well next time you're working on your storage solutions as well, it'll do a lot to prevent cryptolocker issues you're so worried about.
For instance, AWS S3 is all technically accessible publicly. Its locked down by policies, not by NAT limitations. And yet its generally seen as a very secure place to store things, assuming one has the right policies in place. It doesn't take it being behind a NAT to be secure, because if that's the major part of your security posture preventing your stuff from getting cryptolocker'd you're doing things very, very wrong.
> I use bookmarks
Ok, and you hop on someone else's computer and...where are my bookmarks? Oops! Or I want to connect back to my media server from a friend's streaming device...where are my bookmarks? Oops!
And once again I bring up things like game consoles and other P2P applications which just work far better with actual publicly routable IP addresses directly. Strict NAT configurations will often cripple these services and good luck trying to have multiple consoles operating at once. CGNAT makes online gaming for some of these consoles just completely unusable, but if we just supported IPv6 it would have no problems.
> If I know my office network is one prefix, and I know my friend's house is another prefix, and I know my cellular carrier in my city is usually this prefix, I can greatly limit the scope of access.
But it's still private use, not a public service. The fact that you access it from the internet side doesn't make it public.
What you are describing here is in stark contradiction with your claimed easy to use IPv6. Why go through all this trouble if you wanted something easy to use as you describe IPv6?
> So now I have to remember the port for local and the port for remote along with different IP addresses for both, or I can just use the normal service port and the same IP address either way, and have one DNS entry for that IP address and it works anywhere I want it to.
No, you remember just your global DNS name which would be independent of ISP, geo location or router used, and work with dynamic allocated IPs too, and remember or bookmark a port number for each service. Reflection in the router would make that combination (name+port) work from inside the LAN too.
>> But let me know how much you like it after your first cryptolocker.
> Entirely a tangential, unrelated point once you understand how things like "firewalls" actually work.
Oh, I know how they work, at least in Linux, I do. It's a 1 (one!) wrong setting away from exposing everything using IPv6 inside the LAN.
> For instance, AWS S3 [...] And yet its generally seen as a very secure place to store things
Do you really belive that? Really?
> Or I want to connect back to my media server from a friend's streaming device...where are my bookmarks?
OMG! And let his favorite cloud providers index my music collection?? No thank you! I ask for the 3.5 jack cable and connect my phone. Or BT pairing code.
> The fact that you access it from the internet side doesn't make it public
A service I'm using its public IP for, routing through public network connections over the public internet, but somehow its not public networking its private networking despite private networks not really being involved. Got it. Having firewall rules suddenly makes it private networking, somehow.
> remember or bookmark a port number for each service
Or just don't, because I've got quintillions of public IP addresses just lying around. I can even have multiple instances of the same service running on the same box all running the same standard port numbers because I can just grab yet another IP address all day long. Why limit myself to having to memorize weird ports when I can just use the standard ones?
> A service I'm using its public IP for, routing through public network connections over the public internet, but somehow its not public networking its private networking despite private networks not really being involved. Got it. Having firewall rules suddenly makes it private networking, somehow.
It's a private service exposed to public networks when it shouldn't be. That's not how it's done. You are taking risks. I'm sure others would agree with me if this article wasn't this old.
> Why limit myself to having to memorize weird ports when I can just use the standard ones?
For the reasons I explained before, mainly LAN security and DNS not working with dynamic IP allocations. But, go ahead, have it your way. Each of us have our own priorities in life. Convenience is a valid choice. Keep those offline backups updated.
Its not how it was done because of NAT. You just couldn't have done it that way for a long time. We don't need NAT anymore.
> For the reasons I explained before, mainly LAN security and DNS not working with dynamic IP allocations
But once again, its not actually changing the security characteristics at all compared to choosing weird ports and having to deal with reflection issues. The service is still opened either way, just one requires you to choose other ports.
Oh yes, that's really convenient for home users. "Install this thing on several computers and keep it in sync or you're not qualified to have a network"
Home users would ideally be served by things like mDNS and LLMNR, which should just work in the background. If I want to connect to the thermostat I should be able to just go to http://honeywell-thermostat and have it work. If I want to connect to the printer it should just be ipp://brother and I shouldn't even need to have a DNS server.
Your interface has a default gateway configured for it, doesn't it? Isn't that default gateway the router? NDP should show the local routers through router advertisements. There is also LLDP to help find such devices. LLMNR/mDNS provides DNS services even without a centralized nameserver (hence the whole "I shouldn't even need to have a DNS server"). So much out there other than just memorizing numbers. I've been working with IPv6 for nearly 20 years and I've never had an issue of "what was the IP address of the local router", because there's so many ways to find devices.
Even then nobody is stopping you from giving them memorable IP addresses. Giving your local router a link-local address of fe80::1 is perfectly valid. Or if you're needing larger networking than just link-local and have memorable addresses use ULAs and have the router on network one be fd00:1::1, the router on network two be fd00:2::1, the router on network three be fd00:3::1, etc. Is fe80::1 or fd00:1::1 really that much harder to memorize than 192.168.0.1 or 192.168.1.1 or 10.0.0.1, if you're really super gung-ho about memorizing numbers?
> My DNS "server" is a router which can "add" static entries...won't work with dynamic addresses.
Sounds like a pretty poor setup, systems which could auto-add DHCP'd or discovered entries have been around for literally decades. You're choosing to live in that limitation.
> What redundancy, multiple servers?
Multicast name resolution is a thing. Hosts can send out queries and other devices can respond back. You don't need a centralized DNS server to have functional DNS.
So just imagine if there was a service that could translate any words you wanted into the IP address instead of relying on some website to generate jibberish. Wouldn't that be cool to use instead? Some kind of name system? Based around domains of authority?
Kind of like what3words, except what3words uses three words which you stand a chance of remembering, whereas this produced, for an address similar to mine, "Miniature nerves eulogize gaily inside erect lion yet able stables hiss the conclusive consultation."
Care to elaborate why? I'm just curious since I didn't know (1) there was actually any kind of serious usage, or (2) there was pushback from rescue team...
W3W is very aggressive about protecting their IP, they don't want it to be a standard anyone can use like lat/long.
They advertise it as being useful for search/rescue as you can provide a precise location over an unclear voice channel. They conveniently ignore that speaking numbers is clearer than speaking random words.
One reason is that there are a lot of similar words in the dictionary. It is easy to mishear the wrong location especially when they are close together. Some of the words are long and complicated. Another is that they are random which means can't navigate from the codes.
They are missing feature of some codes that can have variable length for variable precision.
Basically the company wants to make money off it so are pushing it and it’s problematic due to it being less easy to use then standard gps cords, words sound the same, and most people have no idea what it is (and nor should they learn lat long)
Something that I think was probably once obvious to me but I rediscovered recently is just how intensely wired for song the brain is. If you want to memorize anything, doing it as a song makes it far easier.
I’d really love to see things like this generate little jingles along with the sentence. :)
There actually was an attempt on HN a little while back to use GenAI to convert facts, flashcards, lists, etc. into automated melodic mnemonics. The biggest issue in that particular case was that it was also generating the motif from scratch.
At least for me, part of the reason I can still sing the countries of the world is because the original Animaniacs song was set to a tune that was already familiar: “Jarabe Tapatío” (aka the Mexican Hat Dance).
I memorized that (and several other) Animaniacs songs without being familiar with the melody. Even Tom Lehrer’s The Elements reached me before Pirates of Penzance did. I think the melody just needs to be simple, then it'll become ”familiar” quickly.
However, for the use-case at hand (remembering IPv6 addresses) I don't think I'd use that. I'd just write them down somewhere, like, uh, perhaps, oh I know: the hosts file.
“Catchiness” is probably more important than anything, hence the concept of the earworm aka stuck song syndrome. Even SOTA GenAI like Suno/Udio fall pretty short of generating genuinely engaging melodies.
As anecdotal evidence, I could never remember all the names of the london tube stations as prose, but after listening to Jay Foreman's Every Tube Station song a few times, I cant help but sing it every time I hear a tube station name, and can almost flawlessly list them all off
What is the use-case for this? I’m trying to think of an IPv6 address I would need to remember, and then when I’d have access to this site without having access to a text file where I could have noted the address down. I’m coming up empty.
It'd be nice if simpler addresses gave simpler sentences. fe80::1 translates to "Uninhibited times take now inside new time yet new times take the new year."
I don't understand how the mapping works. An address has 8 parts and produces 16 words, so each part consists of 2 words. If we take the example 2a02, that gets encoded to "how atop", but I don't see how that text helps me that "how atop" means 2a02? Am I suppose to memorize both? How does that help?
You are not supposed worry about the mapping. You trust the website to help decode it. You just remember the sentence. It's a little like what3words for coordinates.
The rationale being you are more likely to remember grammatical cogent sentence, than a random string of alphanumeric characters. Although I will agree that the generated sentences don't seem easy to remember. So I doubt it's utility.
We kind of had the same idea for ECDSA public keys (an imagined solution to zokos triangle -- human readable and decentralized) as well as private keys (BIP39 brain wallets). Honestly it still falls short of truly name-based though.
> How now the smart flies take the new time beyond new time where new times come.
..Nice idea, but it may need some more thought. (Even more so as 2001:db8::1 is much easier to remember than that!) (I wrote that parenthetical from memory on edit, vs. had to copy-paste the sentence when it was my intention to comment on it within seconds.)
Now, if only those people who designed IPv6 were smarter.. Hex aint that bad, LONG hex addresses are pain to use.
Now, lets say you have LAN like this [::1:0:0/56]. So, ::1:0:24 is easy to remember right? Managable? right?.. Also, bonus for :: shortening is, you immediatly know what are you dealing with, ::1 is loopback, ::1:1 is LL, ::1:0:1 is LAN.. everything else is Internet.
The truth is, IPv6 is really 64bit, the other 64bit part is just randomish node address...
I'm fine with 16 but they should have only used the bytes as they were needed, at least for 5 and 6 byte addresses, so those who desire short addresses could buy them.
My vrrp address for my dns server at home is 2001:8b0:abcd::53
It's about as easy to remember as 81.187.123.45//192.168.0.53
Almost all ipv6 addresses I encounter start with 2001, so I just need to remember my home prefix is 8b0:abcd, which is about the same length as my home public IP of 81.187.123.45
::53 means subnet zero host 53, which is easier to remember than which rfc1918 range I used (and basically is the equivalent of remembering the 2001:: prefix)
If I have an internal server I'd have on 192.168.4.12 I could address it with 2001:8b0:abcd:4::12 just as easily, with the "4.12" translating to "4::12", and the "81.187.123.45>192.168.x.y" translating to "2001:8b0:abcd:x::y"
Just because slacc gives you an extra 64 bits of randomness doesn't mean you need to use them.
fe80:: is for link local. You'd want to use something starting fc00:: or fd00::
In your typical home environment, just set your ULA to fd00::12 instead of 192.168.0.12, or fd00:16:34 instead of 192.168.16.34
Yes you'll run into issues if you were to later want to merge your private IPs with someone else, and you should use fd12:3456:7890::12 instead, remembering those extra 10 digits, but its not a problem at home, and no more of a problem with business mergers than ipv4 clashes anyway.
Not too sure of the utility of this. It's not an easy sentence to remember, because while grammatical, it's nonsense—it would take some effort. So if I'm trying to memorize a static IP, setting up a DNS name is likely to be easier. And also if I'm going to be using this to memorize IPs I'd like the algorithm to be open source.
All that being said, I think it's a neat idea and a cool tool!
How could we determine which device on mobile network is a faceless cellphone and which is a proper device needing real sweet Internet connection? And won't that make things more complicated than just v6 deployment?
Can argue that NAT, which interrupt layers ment for end device do basically the same as popular user hostinle unchangable mobile OSes, but I don't think latter is good either.
If you're assigning addresses, you can make the addresses in a ULA as short as you want. You're supposed to use a random 40 bit network id but if you can accept that you may need to renumber at some point there is no reason you can't use fd12:b:a:d::beef or whatever.
https://datatracker.ietf.org/doc/html/rfc8981#name-problem-s...