As it should. Date notwithstanding, I would actually enjoy if there was a manually induced latency penalty for "legacy IP" that needs to be manually turned off on Linux. I know some people don't care at all, but the internet was made to be addressable. IPv6 is the only shot we have to go back to that.
- I don't want my interfaces to have multiple IP addresses
- I don't want my devices to have public, discoverable IPs
- I like NAT and it works fine
- I don't want to use dynamic DNS just so I have set up a single home server without my ISP rotating my /64 for no reason (and no SLAAC is not an answer because I don't want multiple addresses per interface)
- I don't need an entire /48 for my home network
IPv6 won't help the internet "be addressable." Almost everyone is moving towards centralized services, and almost no one is running home servers. IPv4 is not what is holding this back.
Why don't you want every device to have a public IP? There seems to be a perception that this is somehow insecure, but the default configuration of any router is to firewall everything. And one small bonus of the huge size of a /64 is that port scanning is not feasible, unlike in the old days when you could trivially scan a whole IPv4 /24 of a company that forgot to configure their firewall.
NAT may work fine for your setup, but it can be a huge headache for some users, especially users on CGNAT. How many years of human effort have gone towards unnecessary NAT workarounds? With IPv6, if you want a peer-to-peer connection between firewalled peers, you do a quick UDP hole punch and you're done - since everything has a unique IP, you don't even need to worry about remapping port numbers.
Your ISP shouldn't be rotating your /64, although unfortunately many do since they are still IPv4-brained when it comes to prefix assignment. Best practice is to assign a static /56 per customer, although admittedly this isn't always followed.
And if you don't need a /48... don't use it? 99.99% of home customers will just automatically use the first /64 in the block, and that's totally fine. There's a ton of address space available, there's no drawback to giving every customer a /56 or even a /48.
Great question and my gut is that it makes it that much easier for large, perhaps corporate interests to gain surveillance and control. I'm aware it's possible now, but it really feels like there's some safety in the friction of the possibility that my home devices just switch up IP addresses once in a while.
Like, wouldn't e.g. IPv6 theoretically make "ISP's charging per device in your home" easier, if only a little bit? I know they COULD just do MAC addresses, but still.
You can't correlate the number of addresses with the number of devices because IPv6 temporary addresses exist. If you enable temporary addresses, your computer will periodically randomly generate a new address and switch to it.
I feel like this is a silly narrowing of the problem for normal, retail users. My priority isn't masking "the number of addresses" or devices. My desire is to not have a persistent identifier to correlate all my traffic. The whole idea of temporary addresses fails at this because the network prefix becomes the correlation ID.
I'm not an IPv4 apologist though. Clearly the NAT/DHCP assignments from the ISP are essentially the same risk, with just one shallow layer of pseudo-obscurity. I'd rather have IPv6 and remind myself that my traffic is tagged with my customer ID, one way or another.
Unfortunately, I see no real hope that this will ever be mitigated. Incentives are not aligned for any ISP to actually help mask customer traffic. It seems that onion routing (i.e. Tor) is the best anyone has come up with, and I suspect that in today's world, this has become a net liability for a mundane, privacy-conscious user.
> My desire is to not have a persistent identifier to correlate all my traffic.
Reboot your router. Asus (with the vendor firmware) allows you do this in a scheduled manner. You'll get a new IPv4 WAN IP (for your NAT stuff) and (with most ISPs) a new IPV6 prefix.
As it stands, if you think NAT hides an individual device, you may have a false sense of security (PDF):
But most ISPs aren’t giving out static IPv6 prefixes either. Instead they are collecting logs of what addresses they’ve handed out to which customer and holding on to them for years and years in case a court requests them. Tracking visitors doesn’t need to use ip addresses simply because it’s trivial to do so with cookies or browser fingerprinting. There’s exactly zero privacy either way.
> Instead they are collecting logs of what addresses they’ve handed out to which customer and holding on to them for years and years in case a court requests them.
They are only supposed to hang on to them for a limited time according to the law where I live (six months AFAIK). Courts are also unwilling to accept IPv4 addresses as proof of identity.
> Tracking visitors doesn’t need to use ip addresses simply because it’s trivial to do so with cookies or browser fingerprinting
Cookies can be deleted. Browser fingerprinting can be made unreliable.
Its not zero privacy either way. Privacy is not a binary. Giving out more information reduces your privacy.
> Most home users do not have a static public IPv4 address - they have a single address that changes over time.
I'd be curious to know the statistics on this: I would hazard to guess that for most ISPs, if your router/modem does not reboot, your IPv4 address (and IPv6 prefix) will not change.
"If you enable" is doing ALL THE HEAVY LIFTING THERE.
Again, my point isn't about what is possible, but what is likely. -- which is MUCH MORE IMPORTANT for the real world.
If we'd started out in an IPv6 world, the defaults would have been "easy to discover unique addresses" and it's reasonable to think that would have made "pay per device" or other negatives that much easier.
Temporary addresses are enabled by default in OSX, windows, android, and iOS. That's what, like 95% of the consumer non-server market? As for Linux, that's going to be up to each distro to decide what their defaults are. It looks like they are _not_ the default on FreeBSD, which makes sense because that OS is primarily targeting servers (even though I use it on my laptop).
I haven't done the exhaustive research but props in advance for being the only person shouting in caps on HN. Definitely one way to proclaim one's not AI-ness without forced spelling errors.
I don’t want some of my devices to be publicly addressable at all, even if I mess up something at the firewall while updating the rules. NAT provides this by default.
I don’t want a static address either (although static addresses should be freely available to those who want them). Having a rotating IP provides a small privacy benefit. People who have upset other people during an online gaming session will understand; revenge DDoS is not unheard of in the gaming world.
> I don’t want some of my devices to be publicly addressable at all, even if I mess up something at the firewall while updating the rules. NAT provides this by default.
Do you ever connect your laptop to any network other than your home network? For example, public wifi hotspots, hotel wifi, tech conferences, etc? If so, you need to be running a firewall _on your laptop_ anyway because your router is no longer there to save you from the other people on that network.
It's also a good idea even inside your home network, because one compromised device on your network could then lead to all your other firewall-less devices being exploited.
Not every device can run its own firewall. IoT devices, NVR systems, etc should be cordoned off from the internet but typically cannot run their own firewall.
You must have not read my original post. I said that the NAT provides an additional fallback layer of safety in case you accidentally misconfigure your firewall. (This has happened to me once before while working late and I’ve also seen it in the field.)
Only if they're set up properly, which is quite the gamble. I was recently in a hotel and I listed all the chromecast devices throughout the entire hotel. I could see what everyone was watching and if I was a lesser person I could have controlled their TVs or changed what they were watching.
What about device like those Chromecasts which don't even have firewalls? The only real solution would be to bring your own hardware firewall / access point and connect it as a client off the hotel wifi. Who is really going to do that?
You can have IPv6 firewalls emulate the behavior of NAT so it blocks unsolicited inbound traffic while allowing outbound traffic. If you get a /48 form your ISP you could rotate to a new IP address every second for the rest of your life.
Right, but if you’re messing around as a naive learner it’s easy to accidentally disable that or completely open up an IP or range due to a bad rule. It’s a lot harder to accidentally enable port forwarding on a NAT.
> I don’t want some of my devices to be publicly addressable at all, even if I mess up something at the firewall while updating the rules. NAT provides this by default.
This feels like a strawman. If you are making the sort of change that accidentally disables your IPv6 firewall completely, you could accidentally make a change that exposed IPv4 devices as well (accidentally enabling DMZ, or setting up port forwarding incorrectly for example).
As someone who has done this while tired, it’s a lot easier to accidentally open extra ports to a publicly routable IP (or overbroad range of IPs) than it is to accidentally enable port forwarding or DMZ.
You could accidentally swap ips to one that had a port forward, some applications can ask routers to forward, etc etc. I donmt know how exactly we'd measure the various potential issues but they seem incredibly minor compared to the sheer amount of breakage created by widespread nat.
> Why don't you want every device to have a public IP?
Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.
> With IPv6, if you want a peer-to-peer connection between firewalled peers, you do a quick UDP hole punch and you're done - since everything has a unique IP, you don't even need to worry about remapping port numbers.
There is no guarantee with IPv6 that hole punching works. It _usually_ does like with IPv4.
> Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.
The answer here is kinda that Wi-Fi isn't an appropriate networking protocol for lightbulbs (or most other devices that aren't high-bandwidth) in the first place.
Smart devices that aren't high bandwidth (i.e. basically anything other than cameras) and that don't need to be internet accessible outside of a smart home controller should be using one of Z-Wave/Zigbee/Thread/LoRaWAN depending on requirements, but basically never Wi-Fi.
>> Why don't you want every device to have a public IP?
> Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.
Why would it be "accessible by everyone"? My last ISP had IPv6 and my Asus (with the vendor firmware) didn't allow it. My printer automatically picked up an IPV6 address via SLACC and it was not "accessible by everyone" (I tried connecting to it externally).
It's because router defaults have been bad for a long time and NAT accidentally made them better.
I finally have IPv6 at home but I am being very cautious about enabling it because I don't really know what the implications are, and I do not trust the defaults.
>> Why don't you want every device to have a public IP?
> What would be the advantage in it?
Not having to deal with ICE/TURN/STUN. Being able to develop P2P applications without having to build out that infrastructure (anyone remember Skype's "supernodes"?).
It's about being able to run apps that can operate without have an HQ that needs to be phoned home to for operation, which is currently generally necessary with NAT.
> Anyhow. I'm not confused about NAT vs. firewalling. No one who dislikes IPv6 is confused by this.
"No one"; LOL. I've participated in entire sub-threads on HN with people insisting that NAT = security. I've cited well-regarded network educators/commentators and vendors:
That article is making a narrower claim than you're implying. It argues that NAT is not a security mechanism by design and that some forms of NAT provide no protection, which is true.
It also explicitly acknowledges that NAT has side effects that resemble security mechanisms.
In typical deployments, those side effects mean internal hosts are not directly addressable from the public internet unless a mapping already exists. That reduces externally reachable attack surface.
So, the disagreement here is mostly semantic. NAT is not a security control in the design sense, but it does have security-relevant effects in practice.
I personally do consider NAT as part of a security strategy. It's sometimes nice to have.
Both of those articles are actually wrong. They say "if an unknown packet arrives from the outside interface, it’s dropped" and "While it is true that stateful ingress IPv4 NAT will reject externally initiated TCP traffic" respectively, but this is in fact not true for NAT, which you can see for yourself just by testing it. (It's true for a firewall, but not for NAT.)
The biggest security-relevant effects of NAT are negative. It makes people think they're protected when they aren't, and when used with port forwarding rules it reduces the search space needed to find accessible servers.
I agree it can be a useful tool in your toolbox sometimes, but a security tool it is not.
> Why don't you want every device to have a public IP?
Big companies would abuse that beyond belief. Back around the late 90s ISPs wanted to have everyone pay per device on their local networks. NAT was part of what saved us from that.
IMO, IPv6 should have given more consideration to the notation. Sure, hex is "better in every way" except when people need to use it. If we could just send the IPv6 designers back in time, they could have made everyone use integer addresses.
# IPv4 - you can ping this
ping 16843009
# IPv6 - if they hadn't broke it :-(
ping 50129923160737025685877875977879068433
# IPv7 - what could have been :-(
ping 19310386531895462985913581418294584302690104794478241438464910045744047689
> Back around the late 90s ISPs wanted to have everyone pay per device on their local networks. NAT was part of what saved us from that.
But with IPv6 a single device may have multiple addresses, some of which it just changes randomly. So this idea that they'll then know how many devices you have and be able to pay per device isn't really feasible in IPv6.
A single /64 being assigned to your home gives you over 18 quintillion addresses to choose from.
If the ISP really wanted to limit devices they'd rely on only allowing their routers and looking at MAC addresses, but even then one can just put whatever to route through that and boom it's a single device on the ISP's lan.
NAT is arguably a very broken solution.IPv4 isn't meant to be doing address translation, period. NAT creates all sorts of issues because in the end you're still pretending all communications are end to end, just with a proxy. We had to invent STUN and all sorts of hole punching techniques just to make things work decently, but they are lacking and have lots of issues we can't fix without changing IPv4. I do see why some people may like it, but it isn't a security measure and there are like a billion different ways to have better, more reliable security with IPv6. The "I don't want my devices to have public, discoverable IPs" is moot when you have literally billions of addresses assigned to you. with the /48 your ISP is supposed to assign you you may have 4 billion devices connected, each one with a set of 281 trillion unique addresses. You could randomly pick an IP per TCP/UDP connection and not exhaust them in _centuries_. The whole argument is kind of moot IMHO, we have ways to do privacy on top of IPv6 that don't require fucking up your network stack and having rendezvous servers setting that up.
We may also argue that NAT basically forces you to rely on cloud services - even doing a basic peer to peer VoIP call is a poor experience as soon as you have 2 layers of NAT. We had to move to centralised services because IPv4 made hosting your own content extremely hard, causing little interest in symmetrical DSL/fiber, leading to less interest into ensuring peer to peer connections between consumers are fast enough, which lead to the rise of cloud and so on. I truly believe that the Internet would be way different today if people could just access their computers from anywhere back in the '00s without having to know networking
And the worst part about CGNAT is that you have two bad solutions:
Either EIM/EIF (preferably with hairpinning) where you can practically do direct connections but you have to limit users to a really low number of "connections" breaking power users.
Or EDM/EDF where users have a higher number of "connections" but it's completely impossible to do direct connections (at least not in any video/voice calling system).
Maybe you don't need the addresses, but there are other advantages. If we made the move, I suspect we could give you the experience you want and the one I want. I personally do want to host my own services. My phone is configured to send my pictures to Google and my personal NAS. Centralized services mean you have to trust that provider. These days I don't. I intend to leave centralized services so I know my content isn't training AI or the doorbell isn't spying on me or my neighbors. But, no instead we should force everyone to share the same IP addresses and run less efficient routing.
I mean, so many reasons. Not the least of which is carrier grade NAT is out. And that alone implies so much cost savings, performance increase, and home user flexibility .
I'm struggling to assume good faith on your question, since it's so strange. I feel like I need to start from scratch explaining the internet, since asking this question reveals a lack of knowledge about everything networking.
I don't have CG Nat, I choose a proper ISP. Opening a hole in my ipv6 firewall or forwarding a port in in my ipv4 firewall is effectively the same thing, I define the policy (allow traffic arriving on $address on tcp/1234 to this server on vlan 12) and it goes live.
Away from home, like I am at the moment, I vpn all my traffic back home, to work, or to a mullvad endpoint. Neither the hotel wifi nor tethering off my phone gives me a working ipv6 address (anything other than an fe80::) anyway.
All my workflows work on ipv4 only. Some workflows (especially around the corporate laptop) don't work on ipv6 only - maybe that's a zscaler thing, maybe its a windows thing.
As such the only choice is ipv4 with ipv6 as a nice to have, or ipv4 only.
Personally I prefer the smaller attack surface of a single network protocol.
Sounds like ipv6 is a good solution for people who choose ISPs with CGNat. It doesn't matter to me if I vpn home via my ipv6 endpoint or my ipv4 endpoint, I expose a very minimal set of services.
I guess if I wanted to host more than 4 servers on the same port at home it would be handy, as my ISP will only allow me to have 4 public IPs without paying for more. I don't host anything other than my wireguard endpoint and some UDP forwards which I specific redirect to where I want to go (desktop, laptop, server) - another great feature of nat, but yes nat66 can do that too.
But where's the killer feature of ipv6. Is it just CGNat on poor ISPs?
I'm not sure where that long story is supposed to convey. Cool story, bro.
> Sounds like ipv6 is a good solution for people who choose ISPs with CGNat.
I mean… this is just "not even wrong".
> Is it just CGNat on poor ISPs?
I already said no to this.
Look, like I said, you appear to be unaware of so much about everything about the Internet, running an ISP, running a service provider, corporate networks, ISP-customer relationships, small businesses, BGP viable policies, cloud economics, etc… that it's hard to know where to even start. And while HN is great for some things, HN comments are just not suitable for something that is shaped more like a course or internship. This can't even be described as "gaps" in your knowledge.
I'm put off by your confidence without the knowledge, and of course also by your implication that if you have CGNat then you should have just worked a little harder to not be so poor, to pay a better ISP, or you should move to a more expensive place where other ISP options exist. Of course ignoring that this doesn't scale to the population at all, and extra address bits are very relevant to scaling.
I don't directly deal with public peering, I leave that to my colleagues, my only practical BGP knowlege is on private ASes.
Your shitty ISP doesn't give you an ipv4 access, that's fine. ipv4 address blocks cost $20 an address and are cheaper today in real terms than in 2016, and have been coming down in nominal terms for years.
ipv6 makes sense at a global scale, it still makes no sense for many individuals with a good ISP, mainly because of how it was implemented, too much stuff still relies on ipv4. If you have to also run ipv4 then why run ipv6.
I have no services I use that are ipv6 only
I have services that are ipv4 only, so I have to run a 6:4 nat
I want a stateful firewall because it's not 1999
I want to handoff to multiple consumer ISPs, using PBR, not running BGP, so I need to use NAT66 (changing IPs isn't good enough, I want to round-robin based on various rules, send traffic to dropbox via one ISP, send udp via another, etc)
I have software which doesn't work on ipv6 on a client, so I have to run CLAT on the device
But not all my local devices can run CLAT, I thus have to run dual stack to use ipv6 successfully.
Thus as I'm running ipv4 anyway, and running NAT, there is no benefit over running ipv4 only. IPV6 adds more things to go wrong (NAT64/DNS64), but offers no benefits.
Even without the ipv6 client requirement I still need to run both NAT64 and NAT66. I have an ipv6 only network at home which I put phones on. It works, but there's no benefit other than keeping awareness of ipv6.
Now sure, the reason that ipv4 addresses are cheap is because other people are moving to ipv6 (especially mobile), and relying on 464 gateways, with 46 in their CPE and 64 on the ISP level. That's great.
But that doesn't change the equation for someone with a choice of ISPs, as they can choose an ISP which provides them with static ipv4 addresses.
I recently changed ISPs and have IPv6 for the first time. I mostly felt the same way, but have learned to get over it. Some things took some getting used to.
An "ip address show" is messy with so many addresses.
Those public IPs are randomized on most devices, so one is created and more static but goes mostly unused. The randomly generated IPs aren't useful inbound for long. I don't think you could brute force scan that kind of address space, and the address used to connect to the Internet will be different in a few hours.
Having a public address doesn't worry me. At home I have a firewall at the edge. It is set to block everything incoming. Hosts have firewalls too. They also block everything. Back in the day, my PC got a real public IP too.
NAT really is nice for keeping internal/external separate mentally.
I'm lucky enough my current ISP does not rotate my IPv6 range. This, ironically, means I no longer need dynamic DNS. My IPv4 address changes daily.
A residential account usually gets a /56, what are you talking about? Nowhere near a /48! (I'm just being funny here...)
There are reasons to need direct connectivity that aren't hosting a server. Voice and video calls no longer need TURN/STUN. A bunch of workarounds required for online gaming become unnecessary. Be creative.
I'm not confused about the NAT / firewall distinction, but it might be nice if my ISP didn't have a constant, precise idea of exactly how many connected devices I owned. Can that be _inferred_ with IPv4? Yes, but it's fuzzier.
The ISP still doesn't know how many devices are connected, because a lot of those devices are using randomized and rotating IPs for their outbound connections.
Okay but why does this matter? They're your ISP they also have your address, credit card number and a technician has been in your home and also supplied the router in the common case.
The theoretical vague problem here is being used to defend a status quo which has led to complete centralization of Internet traffic because of the difficulty of P2P connectivity due to NAT.
On Linux, I think the defaults are left up to the distros so there is a chance of a privacy footgun there. Hopefully most distros follow the example set by Apple and Microsoft (a sentence I never thought I would write...)
All desktop/mobile OSes today use "Stable privacy addresses" for inbound traffic (only if you are hosting something long-term) and "Temporary addresses" for outbound traffic and P2P (video/voice calls, muliplayer games...) that change quickly (old ones are still assigned to not break long-lived connections but are not used for new ones).
NAT only matters in so far as you don't technically need a firewall to block incoming traffic since if it fails a NAT lookup you know to drop the traffic.
But from a security standpoint you can just do the same tracking for the same result. That is just technically a firewall at that point.
NAT is a horrible, HORRIBLE hack that makes everything in networking much more complicated. IP networking is very elegant when everyone is using globally unique addresses and a ugly mess when Carrier NAT is used.
NAT demonstrably does not work fine. We have piles of ugly hacks (STUN, etc) that exist only because NAT does. If you really want to keep NAT then nothing stops you from running it on IPv6, but the rest of us shouldn't suffer because of your network design goals.
Only because most people don't know how NAT is hurting them, and because corporations have spent incredible resources on hacking around the problem for when peer to peer is required (essentially only for VoIP latency optimization and gaming).
NAT hurts peer to peer applications much more than cloud services, which are client-server by nature and as such indeed don't care that only outgoing connections are possible.
Even in a NAT-less world, the common advice is to use a firewall rule that disallows incoming connections by default. (And I'd certainly be worried if typical home routers were configured otherwise.) So either way, you'd need the average person to mess with their router configuration, if they want to allow incoming P2P connections without hole-punching tricks. At best, the lack of NAT might save you an address-discovery step.
> the common advice is to use a firewall rule that disallows incoming connections by default.
That's good advice! But firewall hole punching is also significantly easier (and guaranteed to work) compared to NAT hole punching. Address discovery is part of it, but there are various ways to implement a NAT (some inherently un-hole-punch-able) and only really one sane way to do a firewall.
> you'd need the average person to mess with their router configuration,
At least with IPv6, that firewall is likely to exist in the CPE, which sophisticated users can then ideally open ports in (or which can implement UPnP/NAT-PMP or whatever the current name for the "open this port now!!" protocol of the decade is); for CG-NAT, it's often outright impossible.
UPnP has covered a huge percentage of use cases that actual users care about, and those who it doesn't cover are often able to do their own customization.
I used to have it enabled long ago. It's insecure. Random cheap devices will open up ports with upnp without the user noticing. It doesn't work that well either, cause hosts will conflict on ports. P2P applications have better ways to establish connectivity.
How can both be true at the same time: It's insecure for random devices to be able to open up ports, and applications don't even need to open up ports for P2P communication?
If a random device/application wants to insecurely communicate with somebody/something, it will find a way, I agree on that.
As sad as it makes me to admit, I don't think IPv6 is ever going to happen without government intervention. Adoption is flat at under 50% over the past year. IPv6 doesn't benefit big tech. SNI routing and NAT work pretty well for centralized platforms. AWS will gladly rent us IPv4 addresses until the end of time.
For users with IPv6, the v6 path is often less constrained than then v4 path. Serving data faster/more consistently is of benefit to big tech. For a lot of users, v4 and v6 routing are different, which is also helpful for big tech. If you have two paths to the server (and happy eyeballs or something), you have more resiliance to routing issues.
Clouds are slow on v6, but CDNs are not. Adoption on eyeball networks has been very slow, and it's unlikely to speed up much, IMHO. The benefits of v6 for ISPs are not that big for established serviced with large v4 pools. For ISPs running CGNAT, more v6 means less CGNAT and CGNAT is a lot more expensive than plain ip routing. (Doesn't mean all CGNAT providers run v6, but it's an incentive).
SNI routing is such a bad way to do what should be L3 problem that people implemented PROXY protocol to send information about user's endpoint address without doing MITM.
The Internet itself is growing, so "50%" does still represent a growing number of users. Also Google's stats are missing half a billion v6 users from China.
Another way to do ipv6 without government intervention is to make it 1. actually what people want, just v4 with more bits 2. have a reasonable migration path from v4. They made something overcomplicated that disregards all existing users, and now they act like this was the only possible way to avoid address exhaustion and it's everyone's obligation to switch. Even if the govt successfully forced v6, it'd be a downgrade.
v6 mostly is just v4 with more bits, and it has a reasonable migration path from v4 too. I don't think a more reasonable migration path is even possible given the constraints of v4.
About the only thing new in v6 that's not already in v4 is SLAAC, which isn't very complicated. Routing works the same, the addresses work the same, DNS, TCP, firewalling etc all work the same. If anything they removed complexity by dropping broadcast and making NAT unnecessary.
People just have some very weird misconceptions about v6, and will frequently argue that e.g. it was badly designed for not doing a thing that it does actually do, or for not doing something impossible.
The biggest thing is all the v4 addresses are no longer valid in v6. They had a choice and went with making a separate parallel network with new routes. This means DNS DHCP etc work similarly but are completely different, and the separation between DNS v4 and v6 of course is never clear in any router UI, network config file, etc. And the routes themselves are different.
SLAAC itself isn't complicated, but it means introducing multiple kinds of addresses, which is complicated. Privacy addresses were the latest thing. The history of this has left the defaults in a wacky state, like I got a new router and idk what to expect if I enable v6 on it. Even disabled v6 on my laptop cause idk what it'll do when I join someone else's network. Default should've just been DHCP+NAT from the start, not a loaded gun aimed at foot.
And SLAAC means random addresses that are human-unreadable. "Just use DNS" but nah, nobody will do that.
::203.0.113.42 (tunnels to 203.0.113.42 over v4)
::ffff:203.0.113.42 (opens a v4 connection via an AF_INET6 socket)
64:ff9b::203.0.113.42 (translates to v4 at nearest NAT64 point)
What are these then? Also, it's not like they had a choice here. v4 is hardcoded to 32 bits, so the option of making a single network with a bigger address size wasn't available.
I think I can count that as falling under both "something it already does" and "something that's impossible".
Your laptop will just get some IPs as appropriate for the network it's on, and then it'll use them. You don't need to think hard about it.
Annoying things such as paying taxes, recycling/not polluting etc.?
Some things really can only be solved via central coordination, as there is no natural game-theoretic/purely economic path from one local minimum to another. Being able to dig a small trench and letting gravity and water do the rest is great, but sometimes you do need a pump.
I'm not convinced that IPv6 is such a case, but if it is, that's exactly the type of thing governments are much better at than markets.
Odido is the cheapest ISP for a reason. They refuse to implement anything that isn't strictly required.
Perhaps implementing an Odido tax might actually make Odido care enough to throw the switch on IPv6. They bought 2a02:4240::/32, they just refuse to make use of it.
> They refuse to implement anything strictly required
This describes a lot of businesses ngl.
Bell in Canada is one huge head scratcher. They are one of the largest ISPs here and I can even buy 8 gig internet to my house if I want but they don't support IPv6.
Apparently (according to techs) a lot of ISPs are like that - they said they have everything up and running and even tested to turn on IPv6 but they haven't received the go-ahead.
He mentioned this because marking my connection as a "business" one without changing anything else would allow it to get IPv6 (a /64, bah).
Canadian ISPs are also extremely far behind on IPv6. Bell is the largest ISPs in the country and they still don't have IPv6. I'm with one of their wholly owned subsidiaries (EBOX) which offers static /56 allocations, but good luck trying to find anyone in tech support who understands WTF you're talking about.
Why does kph sound like most cursed option. kilo per hour? Kilo what? kilowatt, kilogram? kilolitres? Well it is most likely in context, but still when I stop and think about it it feels icky.. I can accept p instead of /. But just entirely ignoring unit feels wrong... Also is speed of something slow ph?
Both kph and mph sort of follow a pattern of the first letter of each word in the unit being spelled out, but kmph reads ambiguously as k(mph) or (km)ph.
Of course, anyone caring about correctness would use the SI unit symbol, which is m/s.
km is very standard abbreviation for kilometers. Like anyone outside the US would recognize that and consequently kmph. Of course, km/h is very recognizable and k/h looks like nonsense. So I'd say kph is the objectively terrible option.
I don't get why this applies on the Cloudflare outage but not on the AWS ones... I'd argue that the big cloud providers are WAY more impactful when they go down than Cloudflare. The only difference is that the average techie uses Cloudflare more and sees the impact more, but this point was already there before...
but if airdrop as of OS26 uses wifi aware, and the proprietary awdl version has been shuttered due to the eu regulation, how come devices on that software version can still airdrop to older devices?
There's a reason why this went from widely supported/used to... not so much. And even if most people claim it's big-co's locking down their ecosystems (which is partly true), the "extensibility" of XMPP allows for a very convoluted ecosystem with some servers supporting certain XEP and some not. Also, sorry, but XML just sucks to work with nowadays :(
If only it was XML. It's actually something based on a subset of XML for which there were enough constraints than in practice you almost had to write custom parser. XMPP would have been a much nicer protocol if each stanza were independent XML documents IMO.
You need a stream parser like expat. No need to code your custom parser and once you settle at level n+1 in the XML it is just like parsing independent document.
But again, the parsing is hidden by existing XMPP library, so you do not even need to go to that level of details.
I meant for implementing the protocol of course. If you don't have to implement it, then of course it does not matter as much if it's bad or not.
At the time I was looking into it closely, there were issues with XML, like with the starttls messing the original document, there were issues with XML validation (for xml namespaces I think?), and other minors arrangements with the XML spec such that using a normal pull parsing lib was not enough to solve all problems. But it was quite a long time ago (10+ years), possibly that have been solved for a while.
in term of practical impact of using XML like this, at the time, the server has to practically parse everything that was in the content of messages not addressed to the server itself. I would imagine a reasonable protocol should separate addressing from the content in such a way that the router doesn't have to parse all the content to do its job
Certainly XMPP is not perfect but then again, nothing is. The extensibility does make it a bit of a gamble whether any specific server - which can be used for all kinds of purposes, many of which not related to human communication - offers everything a client program expects it to. Then again if your communication/discussion partners all make sure to use servers which support the essentials for the type of use you want to make of it - usually that'll mean those XEPs need for OMEMO, muc and maybe Jingle, the Conversations project publishes a list of what is needed [1] - things work just fine and you'll be communicating without the need for centralised (monetised, censored, monitored, ...) services. I've been running it for decades now, first as a backup "just in case" communication channel but for the last 7 years or so as my main channel to family and friends. We're using mostly the Conversations (-derived) client(s) on mobile, Gajim on desktop and Converse.js on web with servers running on different types of hardware ranging from SBCs (RasPi etc) to ex-lease enterprise hardware. The maintenance burden on the server software is close to zero with Prosody, it hardly takes any resources and has never crashed on me.
There's a whole class of sh*t-software that only exists (and is profitable) because users subscribe to them and then forget – primarily because the subscription fee is charged as "Apple" on their Credit Card. I wonder what's gonna happen with this type of scam.
Easy from your point of view... This is the argument I mostly hear from Apple folks, but my experience (especially with less tech savvy folks) is that they have no idea where or how to cancel a subscription on IAP and they think that the multiple "Apple" charges are just some iCloud thing or something along those lines. With Credit Card flows the alarm bells go off waaaay earlier: when a website asks for their CC data, they immediately scrutinize more (and thus, conversion rates are lower)
There’s a single page in the settings with all the subscriptions, and you can cancel any of them by tapping a button and confirming. You get emails regularly with a link to a page with the subscription information when it is renewed. It really is easy and much, much better than all the alternatives I tried.
I wanted to cancel an Apple subscription recently. I didn't know where to do it. I knew it was coming up because I got an email from Apple to say it was shortly due for renewal.
It took me about 5 seconds to google "cancel subscription apple" and find about a zillion articles on how to do it. Basically open up the App Store, go to your account, click on subscriptions, click on the one in the list you want to cancel. Done.
On the other hand, I also wanted to cancel a pet-locator subscription that was coming up for renewal (we're leaving the country, they don't have coverage outside the US) and I had to go through about 30 layers of "are you sure", "are you really sure", "you know this will stop your service, right?", "we'd sure hate to lose you", "Is there anything we can offer to change your mind", etc. etc.
> If done through third parties directly the scammers will not make unsubscribing easy and it will not be as easy to find out where you are subscribing.
This is fairly quickly resolved though - if anything close to 1% of customers complain to their banks that they don't want this payment and can't cancel it, triggering a chargeback, the scammers end up entirely blocked from the payment networks entirely in pretty short order. If you end up banned from Visa & Mastercard your whole operation is permanently kaput.
Also, this might be a non-US thing, but over here most modern banks (e.g. Revolut) will let you view & block recurring payment authorizations directly from your banking app anyway.
For me to get to it from App Store, I have to click a tiny profile pic (smallest allowed button on iOS?)
The next screen displays Purchase History and other items. However, no way to cancel from this page (insane?)
To get to subscriptions, I have to click my name at the top of that page (which doesn’t even look like a button) which loads for 3 seconds then pops up.
On this hidden account page, it shows Purchase History along with subscriptions list to cancel.
If any other site hid subscription cancelling behind a flat contact header secret account page, it’d be an issue, so yeah it’s an issue for Apple too.
What version are you using?
Click 'Settings' -> 'Profile' (huge button on top) -> 'Subscriptions'. I don't know how it could be easier than that. Ah wait, pull down on the home screen for search, type 'subscriptions' and tap on the result for direct access to the setting.
From there you can see and cancel any subscription made in the App Store.
Apple could have offered APIs for managing 3rd party subscriptions from that screen, but it's more convenient for them to have a closed system, private APIs, and use their own non-extensibility as an excuse for their closed payment system.
It's also Apple's specialty to create false dichotomies and shit sandwich bundles: it's either the 30% cut or daylight robbery. No third option (in reality PayPal is more consumer-friendly and allows managing subscriptions in one place from more than iOS).
The whole App Store model is a false dichotomy between the 30% cut and Disney-like moderation vs raging malware that will take down the whole mobile network. No third option (so you can't have Fortnight, or any app showing a nipple).
Nothing? The ruling is that app developers get to choose how they communicate to users, or how they charge in-app fees. The kind of shady developers you describe would simply continue to use Apple, as it benefits them to do so.
- Most legit services move to a web based Apple Pay (note to the unaware reader: this is NOT In-App Purchases and has never had 30% fees) due to the ease of implementing and lower fee (easier to do cross platform + web)
- Non-legit developers keep the In-App flow
Over time this would skew In-App Purchases to be scammy-only (and therefore, easier to spot). I'm sure people at Apple consider this possibility too – and therefore, now that there's actual competition, IAP flows will probably have to change to prevent this and compete for actual developer preference (and keep it a viable legit-developer choice)
So they should probably just scrap the 30% fee. At the very least scrap it if the user was linked directly to the app. And just make the also huge commission on the payments.
Apple sends a specific, detailed receipt on the billing of every such item. Apple has some of the most user-friendly subscription management options of anyone. Apple lets you cancel a subscription immediately without cancelling the service immediately, and so on.
There is a lot to criticize Apple for -- the 30% fee is disgusting, and the subject of this order where they bar external payments without fees is criminal -- but the subscription complaint has always been weak.
I'm wondering what the "because when we read it in, we mangle it" part really means... does this mean that there's no way to reference the commit (signaling that it's just a reference and has no actual data) without actually reading the contents of it?
-- Update: just realized why it wouldn't make sense: `git push` would send only the delta from the previous commit and the previous commit is... non-existent (we only know it's ID), so we'd be back in square 1 (sending everything).
See my top-level response, but basically nothing is mangled. Instead Git internally treats it as a 'graft' and knows not to look for parents of the prior commit.
I started that comment as a reply to you but I realised that a) it may just have been a bug that might already be fixed and b) it looks like the Stack Overflow answer was speculative and not tested!
Let's go back to each city having its own time. _Because making train companies happy is so much more important than making users happy?_
All jokes and "snarkiness" aside, it's just a matter of habit. If the whole world used UTC and working hours/social time were set differently per-country, I bet we'd get used to it eventually.
You are joking, but I think City-based timezones would work well on today's internet. We have better than ever computers to do time math and scheduling/coordination for us, let's leverage that. It's easier than ever to go to more timezones rather than fewer, because we don't have to make train companies happy anymore and because some people would get better sleep if their local time was closer to their solar time and because DST is easier to get rid of with smaller timezones. (DST is, among other things, a hack around our timezones are too wide.) The IANA timezones are even already primarily city-based, so a lot of software wouldn't even need to update anything but their IANA tzdb.
Now might be a great time to do something like that. It doesn't sound like a serious proposal, but there would be interesting benefits to city-based timezones again in the modern world. We actually have the technology to scale smaller timezones now. We aren't relying on mechanical clocks like the train companies were and paper calendars like early multi-timezone companies like GE were. We could make local time resemble solar time a lot more again, and solve it as a software problem.
I don't know, you'd still need to coordinate based on local time, let's say I want to set up a meeting with colleagues from different time zones at 10. I have no idea what time of day that is for them, are they sleeping, having lunch, etc.
With time zones, I can look up the time offset, with universal time I'd have to check their location and what time of day it is for them, which could be confusing, how do you map it exactly, bed time, lunch time, one hour before lunch time, two hours after bed time?
The other problem is that I don't think habits would be easy to change. Right now people in some european countries want to stay permanently on summer time to have more daylight after work.
We could just as easily stay on winter time and have everyone go to work earlier, shops could open at 7 instead of 8, etc. But for some reason this isn't considered, so I assume it's easier to enact all year DST than to change working hours.
Another thing is that having the change of calendar date in the middle of your waking hours is rather annoying and potentially confusing, and everybody in the world not living near wherever the meridian ends up will be subjected to that. (Because in that case a single calendar date can refer either to solar date A in the afternoon/evening, or solar date B in the morning).
Like should public holidays e.g. start and end right in the middle of the solar day because that's when midnight UTC happens locally? Do you reintroduce time zones by the back door by defining a local start/end time for day-based events to align them back to the solar day?
