Comcast has been doing this for a while, at least in SF. I first noticed, through gmail as well, that I was using ipv6 for atleast 2 years now. I think they started rollout back in 2013.
The biggest that comes to mind is that with dual stack IPv6 all the people running through IPv4 anonymizing VPNs will be bypassed for sites that support IPv6. Oops.
IPv6 has some minor privacy extensions too, but likely still allow you to be geolocated.
This is something the VPN providers need to fix, either by setting a default IPv6 route that doesn't go anywhere so happy eyeballs will follow IPv4 or by adding IPv6 to their proxies.
I've had native IPv6 in Alameda for a couple of years now. I've had literally no problems, ever, with it and haven't once disabled it or otherwise adjusted my configuration to make a service work.
In Germany, Unitymedia - the largest cable ISP - did so as well. You don't even get a public IPv4 anymore unless you call them and beg, and apparently they stopped doing even that.
The standard is called Dual-Stack Light, which means you are getting a native IPv6 adress and your IPv4 traffic runs through a carrier-grade NAT.
This is necessary, because the cable-providers here in Germany came to late to the Game and got to little IPv4 Chuncks.
For normal users this is a good solution, when the NATing service is stable enough. (Sometimes the server is down and you are forced to IPv6 only..) But throug the carrier-grade NAT, you can not run your own services, like a teamspreak server etc.
Nope, at least not for Unitymedia. There's a IPv6 firewall, but without rules - you can just switch it on or off, making it unsuitable for pretty much any service hosting - you either have to expose your entire network, or you cannot access anything at all.
For 5€/month, they will issue a better router with a full-features firewall, though.
justincormack: Yes, you can set up an IPv6 service on your connection if you like. The only problem for IPv4 services is the lack of your own global IPv4 address.
I would recommend sshguard [1] as a fail2ban replacement. It does much of what fail2ban used to do out of the box and has supported ipv6 for a long, long time.
It is packaged in debian, ubuntu and probably other major distros these days.
shrug I would recommend deactivating password logins and using only key-based logins.
In the many, many, many months I've had my internet-facing IPv6-enabled SSH servers online, I've only received one bogus SSH connection attempt from an IPv6 address at the University of Michigan.
That will change though. I receive hundreds of IPv4 connection attempts every day, as more systems move to IPv6 so will the attacks.
Interesting though is that covering the entire IPv6 space is a much larger task. That should hold down the volume of random attempts for a while, just by dilution effect.
You're going to need to start testing both IPv6 and IPv4 on your servers. An nginx misconfiguration on my server gave clients a redirect loop, but only for IPv6 clients. Analytics show ~15% IPv6 penetration for the last app I made, and it was a bit embarrassing that it was broken at first. Reverse DNS on IPv6 client addresses gave me Comcast host names.
If you've a correctly configured network, you can disable IPv6 without screwing with DNS. All you have to do to your IPv4-only network is... absolutely nothing.
I have Comcast (Oregon), but right now I block all IPv6 at my firewall. If/when it's available here, why should I enable it? Why would I care?
This isn't a troll. I'm ignorant of the practical advantages as it has actually been deployed so far. I'd like to know how it improves my life. E.g. will I get a block of addresses, instead of just 1?
BTW, apropos of nothing, we would have never needed IPv6 if there was a charge for IPv4 addresses. Assume $1 per month. Do you think MIT would pay $16,000,000+ per month? Assume $1 per year. Do you think MIT would pay $16,000,000 per year? In either case I think the clear answer would be: NO!
You can probably get almost all the ipv6 addresses you want. I am not sure why you would block ipv6 exactly, but the saddest thing is that I can't really point you to a good reason to implement ipv6 on a server, seeing as everything has to work with ipv4.
And we can't charge MIT for the ips because they were given away way back when (so they are legally the property of MIT).
For like, all of the frameworks that the cool kids are using, IPv6 is handled transparently and out of the box.
For the C++ programmer, both the various libcs and Boost have handled IPv6 for a very long time. It's the same story with C#. I would expect it to be similar for other CLR languages. Java? Erlang? Same story.
It took a while, Twisted in Python seemed to have issues with code I was using (buildbot), although the upstream issues are now closed, so maybe I should try again.
That is true, but even the effort to source an IPv6 (probably just a few clicks on your providers website) and configure the firewall correctly isn't worth the effort.
Jeez. That golang bug is pretty bad. I'd like to know why it seems that the devs are acting like it's a difficult problem to solve; clearly I'm missing something.
But, uh, the presence of that bug doesn't invalidate my statement. IPv6 support works out of the box in Go and -if you're on a dual-stack host-[0] everything works great!
[0] So, if you're like not on a cell network with a modern smartphone, or like in an area served by APNIC [1], you're fine! ;)
[1] Because, like, pff, how many people could be served by the networks numbered by that organization? ;)
No golang application works, on any of my machines.
This bug is so incredibly critical is actually means that almost every program that depends on golang will not work on any of my machines, or any new machine added to my network.
Why should use enable it? For one, its faster generally, for two it gets more throughput.
If those two aren't enough for you I'm at a loss. Honestly I don't see a future for ipv4, ipv6 simplifies so much. Watch that nanog video posted in this thread, you might be surprised at the view of ipv6.
I've been using ipv6 for years now, zero issues. Also ipv4 charging for addresses is a complete economic hack around a technical issue. Ipv6 gets us away from the hacks, technical or not. Unless you like stuff like carrier grade nats making things like p2p video harder than it need be.
Honestly the inverse should be happening more, drop ipv4 and start doing nat for ipv4 at the gateways that matter.
If the answer to either of those questions is "Yes", then you should consider activating IPv6, if your ISP supports it.[0]
The most tight-assed ISPs give you a /64 allocation. Because most machines use something called SLAAC, this means that this /64 is enough for a single subnet. The IETF strongly recommends that ISPs hand out at least a /56, but really wants to see /52s being handed out to each customer.
In San Francisco, it seems that Comcast Residential connections get handed out at most a /60. Comcast uses DHCPv6-PD, so your DHCPv6 client needs to ask for the larger allocation. On routers that support IPv6, configuring your client to do this is typically very easy.
As an aside, if you enable IPv6, please don't filter ICMP. ICMP was pretty important in IPv4, and has become absolutely critical in IPv6.
[0] If you use uPnP, you're relying on firewalls on your endpoints for your security anyway -because any host can poke a hole in the NAT at any time-, so activating IPv6 doesn't substantially change your security situation.
>The IETF strongly recommends that ISPs hand out at least a /56
I never really understood that. IPv6 has 128 bit addresses, so even at /96 every single customer will have as many addresses as the entire IPv4 space. Why is /64 considered "tight-assed"?
Right now SLAAC (Stateless address autoconfiguration) needs at least a /64 to work properly, thus only giving the customer a /64 means they can't run autoconfig on more than one broadcast segment.
It seems more complex, and I don't see any advantages. SLAAC is like the "default" for IPv6, while DHCP is something on top of it. Plus it's usually not enable out-of-the-box on all devices.
So, I'm speaking from a position of ignorance. My questions aren't rhetorical: they're me actually asking for more information. Also, some of my footnotes might contain information that you already know well. I apologize in advance.
* How do you reliably send down DNS information with just router advertisements? [0] AIUI, and the last time I checked, Debian, Gentoo, and Ubuntu Linux, and Windows 7 and earlier versions of Windows all fail to add the contents of RDNSS advertisements to their list of DNS servers to be contacted. (You can configure Linux to put RDNSS info in /etc/resolv.conf, but -when I was testing-, none of the Linuxes I used were configured this way out of the box.)
* I have my ISP-delegated /60 sliced up into a few subnets. If Comcast changes the prefix delegated to me, my subnet configuration is automatically maintained [1]. If an ISP uses only router advertisements to assign IPv6 prefixes, how can the ISP retain the ability to shuffle customer prefixes around while allowing the customer to automatically maintain his subnet layout in the face of such prefix changes?
* Relatedly, is there routing software that you can configure to automatically slice -say- a /48 advertised from upstream via router advertisements into /64's that are then advertised on a LAN?
To directly answer the question you posed: "I don't know why an ISP would pick DHCPv6-PD over SLAAC, but DHCPv6-PD does seem to solve some problems.".
[0] I run my own DNS server, but others care about their ISP's DNS information. So, the answer to this question doesn't matter to the operation of my network, but the answer does interest me.
[1] Assume that my ISP delegates to me 2001:1:1::/48. From that, I slice two networks: 2001:1:1:1::/64 and 2001:1:1:2::/64. I specify this by saying "Gimmy two networks from the /48 that I will be handed down to you. Number the first network $PREFIX:1::/64 and the second $PREFIX:2::/64." With my setup, my ISP can change the prefix it delegates to me to 2001:1:2::/48, and my network will automatically renumber itself. This is a bit of a pain for me, as I have to update DNS, but far less of a pain than having to update the configuration for the software that defines my subnets.
You should get a /64, ie a gigantic lot of addresses, or more, by default. So all machines are directly addressable. If you eg open the ssh port, you can log in to anywhere directly. eg all my machines at home have AAAA addresses, and so do my VMs hosted externally, and I can log in directly which is much easier.
A /56 is the recommendation (and what my ISP gives me), though I wouldn't be surprised if a lot actually use /64 blocks. There's still an enormous amount left anyway.
this makes me jealous... In Australia all the mobile networks are using carrier grade NAT to avoid using IPv6 ... And there's only one ISP with IPv6 and the others don't care because they already acquired enough IPv4 addresses they can probably survive another decade on IPv4
53 comments
[ 3.6 ms ] story [ 129 ms ] thread[1]: https://www.youtube.com/watch?v=EfjdOc41g0s&app=desktop
IPv6 has some minor privacy extensions too, but likely still allow you to be geolocated.
The problem I've found is that too many CPE's allow IPv6 inbound without a firewall, so it exposes end clients directly to the internet.
With IPv4 generally there is a default drop all firewall rule.
For 5€/month, they will issue a better router with a full-features firewall, though.
I'd like to use IPv6 on my servers but I need fail2ban support first.
It is packaged in debian, ubuntu and probably other major distros these days.
[1] http://www.sshguard.net/
In the many, many, many months I've had my internet-facing IPv6-enabled SSH servers online, I've only received one bogus SSH connection attempt from an IPv6 address at the University of Michigan.
Interesting though is that covering the entire IPv6 space is a much larger task. That should hold down the volume of random attempts for a while, just by dilution effect.
I do that when I can, but sometimes it's not possible.
Also, fail2ban works for other things besides ssh, which I need.
This isn't a troll. I'm ignorant of the practical advantages as it has actually been deployed so far. I'd like to know how it improves my life. E.g. will I get a block of addresses, instead of just 1?
BTW, apropos of nothing, we would have never needed IPv6 if there was a charge for IPv4 addresses. Assume $1 per month. Do you think MIT would pay $16,000,000+ per month? Assume $1 per year. Do you think MIT would pay $16,000,000 per year? In either case I think the clear answer would be: NO!
And we can't charge MIT for the ips because they were given away way back when (so they are legally the property of MIT).
For the C++ programmer, both the various libcs and Boost have handled IPv6 for a very long time. It's the same story with C#. I would expect it to be similar for other CLR languages. Java? Erlang? Same story.
I'm also suspicious that you're not arguing in good faith.
Yeah, except for golang. go applications don't work on IPv6-nodes, and issues have been open for almost two years now.
ELB?
But, uh, the presence of that bug doesn't invalidate my statement. IPv6 support works out of the box in Go and -if you're on a dual-stack host-[0] everything works great!
[0] So, if you're like not on a cell network with a modern smartphone, or like in an area served by APNIC [1], you're fine! ;)
[1] Because, like, pff, how many people could be served by the networks numbered by that organization? ;)
No golang application works, on any of my machines.
This bug is so incredibly critical is actually means that almost every program that depends on golang will not work on any of my machines, or any new machine added to my network.
Can you tell me why the golang folks are acting like solving the underlying problem is so terribly difficult?
[0] To the downvoters: golang-nuts is the name of the official golang general discussion list. "gonuts" is used lovingly in this context.
The issue si reproducible on any device, not just smartphones. I hit it constantly on ArchLinux/amd64.
If those two aren't enough for you I'm at a loss. Honestly I don't see a future for ipv4, ipv6 simplifies so much. Watch that nanog video posted in this thread, you might be surprised at the view of ipv6.
I've been using ipv6 for years now, zero issues. Also ipv4 charging for addresses is a complete economic hack around a technical issue. Ipv6 gets us away from the hacks, technical or not. Unless you like stuff like carrier grade nats making things like p2p video harder than it need be.
Honestly the inverse should be happening more, drop ipv4 and start doing nat for ipv4 at the gateways that matter.
If the answer to either of those questions is "Yes", then you should consider activating IPv6, if your ISP supports it.[0]
The most tight-assed ISPs give you a /64 allocation. Because most machines use something called SLAAC, this means that this /64 is enough for a single subnet. The IETF strongly recommends that ISPs hand out at least a /56, but really wants to see /52s being handed out to each customer.
In San Francisco, it seems that Comcast Residential connections get handed out at most a /60. Comcast uses DHCPv6-PD, so your DHCPv6 client needs to ask for the larger allocation. On routers that support IPv6, configuring your client to do this is typically very easy.
As an aside, if you enable IPv6, please don't filter ICMP. ICMP was pretty important in IPv4, and has become absolutely critical in IPv6.
[0] If you use uPnP, you're relying on firewalls on your endpoints for your security anyway -because any host can poke a hole in the NAT at any time-, so activating IPv6 doesn't substantially change your security situation.
I never really understood that. IPv6 has 128 bit addresses, so even at /96 every single customer will have as many addresses as the entire IPv4 space. Why is /64 considered "tight-assed"?
It seems more complex, and I don't see any advantages. SLAAC is like the "default" for IPv6, while DHCP is something on top of it. Plus it's usually not enable out-of-the-box on all devices.
* How do you reliably send down DNS information with just router advertisements? [0] AIUI, and the last time I checked, Debian, Gentoo, and Ubuntu Linux, and Windows 7 and earlier versions of Windows all fail to add the contents of RDNSS advertisements to their list of DNS servers to be contacted. (You can configure Linux to put RDNSS info in /etc/resolv.conf, but -when I was testing-, none of the Linuxes I used were configured this way out of the box.)
* I have my ISP-delegated /60 sliced up into a few subnets. If Comcast changes the prefix delegated to me, my subnet configuration is automatically maintained [1]. If an ISP uses only router advertisements to assign IPv6 prefixes, how can the ISP retain the ability to shuffle customer prefixes around while allowing the customer to automatically maintain his subnet layout in the face of such prefix changes?
* Relatedly, is there routing software that you can configure to automatically slice -say- a /48 advertised from upstream via router advertisements into /64's that are then advertised on a LAN?
To directly answer the question you posed: "I don't know why an ISP would pick DHCPv6-PD over SLAAC, but DHCPv6-PD does seem to solve some problems.".
[0] I run my own DNS server, but others care about their ISP's DNS information. So, the answer to this question doesn't matter to the operation of my network, but the answer does interest me.
[1] Assume that my ISP delegates to me 2001:1:1::/48. From that, I slice two networks: 2001:1:1:1::/64 and 2001:1:1:2::/64. I specify this by saying "Gimmy two networks from the /48 that I will be handed down to you. Number the first network $PREFIX:1::/64 and the second $PREFIX:2::/64." With my setup, my ISP can change the prefix it delegates to me to 2001:1:2::/48, and my network will automatically renumber itself. This is a bit of a pain for me, as I have to update DNS, but far less of a pain than having to update the configuration for the software that defines my subnets.
It's shit.
I suspect they will after they realise you can't tie things down in CGNAT
Appears to be affecting DSLR[2] users too. Anyone else observe this?
[1] https://gist.github.com/1cec3537f61aefd1d6bc
[2] https://www.dslreports.com/forum/r30112054-IPv6-IPv6-prefix-...