451–460 of 496 posts
Earlier quoted context omitted.
It's good to support it to resolve the chicken egg problem. If no service supports it, there is no sense in deploying it to the customers and the other way around. Also you made the life better of people who have DS lite. They only get a public IPv6 and all their IPv4 traffic goes through a CGNAT.
For people like me: DS Lite stands for "IPv6 dual-stack lite". My mind went directly to Nintendo and I was confused.
Earlier quoted context omitted.
You are right, but ISPs will tell you that you're not allowed to host servers anyway. Most have it in the AUP.
1. Is trying to use Xbox/PS2 multi-player functionality "hosting"? 2. Perhaps our expectations of what you should be allowed to do is too low?
Earlier quoted context omitted.
Yes, it's called contract law. If you don't pay HE, you don't get a connection to them. I forgot one detail: your ISP could pay a different tier-1 ISP, as they all interconnect. Nonetheless, your ISP pays top rates for that traffic - tier-1 routes are usually last-resort routes.
Are we talking about the same thing here? I was thinking of https://tunnelbroker.net/ Obviously if the ISP is buying transit from HE, they'd have to pay for it, but it'd be surprising if HE was strongarming their customers by adding a clause that's like "oh also, if any of your customers use our ipv6 tunnel, we'll charge you $x/user/month" or whatever.
HE in particular likes to set up incentives to draw more traffic through themselves. They do free peering to small networks at many IXPs (this doesn't give you full internet access like transit does) and tunnelbroker is also one of these things.
Earlier quoted context omitted.
> NAT is not a firewall, I've only read that on HN, I've never heard this anywhere else. Since it's been a good 20+ years since my CCNA (and haven't needed to renew it since), could you please offer a real-world example where NAT is not a firewall w/ practical examples relating to 99.9% of cases of home use? I just can't get why people say this a lot here. NAT works and passes the grandma test. If grandma buys a crap…
I agree. NAT, while occasionally limiting, was a godsend. Just imagine how the world would look if everyone out there was at the mercy of a well configured router with firewall.
Earlier quoted context omitted.
Why the double standard? v6 already gives you what you're asking for here: you can turn it on without thinking about it, but actually using the extra addresses from it requires reconfiguring some things (not everything, mind). Why is that bad when it's v6 doing it, but good when it's your 5-byte thing doing it? Or did you just not think through this enough to realize you were asking for something we already have?
Because you can't generally turn on v6 without thinking about it. Maybe consumers can, even then not always cause it messes random things up. Power users and offices maybe can't. Service operators really can't. If it were as easy as you're saying, all those things like Github would already at least support v6.
> If it were as easy as you're saying, all those things like Github would already at least support v6.
This isn't the "turn it on" stage, it's the "people can start putting something besides 0 into that last byte" stage.
Earlier quoted context omitted.
What's the par time for L3 protocol migrations on the Internet at its current size? Bear in mind we've never done a project of this complexity and scale before. I'm sure we all wish it had been faster, but how can you possibly evaluate whether this is a failure or not without knowing how long it normally takes?
The vast majority of the current size of the Internet, basically 100%, was built after IPv6 was ratified and indeed became a normal part of equipment.
Earlier quoted context omitted.
On IPv6 we're not. Are you saying it's weird we still use IPv4 in addition?
So when I go to hn.com I’m on v4?
Earlier quoted context omitted.
Yes, we want ipv5 that just does 1, 2, 3 instead of ipv6 which does the most complicated variants of those and more. We didn't have requirements 4. change all the pre-existing addresses 5. make addresses randomly assigned 6. make routers accept inbound connections by default 7. give every device its own public IP by default. Ipv6 did those anyway. Like I own 8.8.8.8. You want to add more bits, fine, I'm 8.8.8.8.0.0.0…
The problem with IPv6 is really not the changes it made. Support was flaky for a while but that is pretty much over. The problem is that you have to deploy it. You have to handle the bigger IP space safely, you have to assign the IPs, add DNS records, routing, etc. All this is work and the pressure is low. NAT has mostly taken that away. Nothing would have saved us from that. There is no way to expand the number of a…
The other less important problem with v6 is that it's inherently less user-friendly. There's unclear guidance about firewall defaults that in practice has led to security issues vs just using NAT. The spec has the kitchen sink in it that aren't broadly supported, like DHCP6 and NAT6. SLAAC meant privacy issues that they had to resolve way later with the privacy extension, even though it's more technically elegant in other ways. And people don't like the long :: hex addrs, partially a consequence of using SLAAC.
Earlier quoted context omitted.
Because you can't generally turn on v6 without thinking about it. Maybe consumers can, even then not always cause it messes random things up. Power users and offices maybe can't. Service operators really can't. If it were as easy as you're saying, all those things like Github would already at least support v6.
Windows, Linux, OSX, Android and iOS all ship with v6 enabled by default out of the box, so it's already turned on without you needing to think about it. You have to deliberately go out of your way for this not to be the case. > If it were as easy as you're saying, all those things like Github would already at least support v6. This isn't the "turn it on" stage, it's the "people can start putting something besides 0…
Earlier quoted context omitted.
this keeps coming up, if you add a byte to ipv4 you still have a transition problem. 5 byte machines can't talk to 4 byte machines. pretty much the only thing that solves is people not liking the :: syntax. the only other change is auto configuration, which...kind of doesn't matter? is that really causing problems?
I think the addresses are a big issue. The address space is just stupid big, I don't understand why we need to prepare for every grain of sand on Earth having a WiFi chip in it. Most people can pick up calculating subnets in their head in ipv4 pretty quickly and ipv4 addresses are easy to memorize on accident. My brain turns to mush as soon as I start seeing hexadecimal characters in addresses.