Comcast Automatically Enabling IPv6 in San Francisco
blog.kylemanna.com
blog.kylemanna.com
[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.
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-...
For 5€/month, they will issue a better router with a full-features firewall, though.
It's shit.
I suspect they will after they realise you can't tie things down in CGNAT
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.
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.