Sadly, depending on the ISP, the prefix is not necessarily static and may change on reconnect (for example, Deutsche Telekom will only keep the prefix static for business accounts). This is completely arbitrary and makes relying on GUAs for internal addresses problematic.
It’s too bad that we are inheriting the static IP policies from IPv4, because ISPs want to upsell.
My ISP in Japan (NTT Flets) is even weirder. They have sort-of static IPv6 (due to MAP-E[1] require static prefix) and assigns customer a /64, but don't do Prefix Delegation unless a customer also pay for a Fiber landline (Hikari Denwa) in which they will assign /56 and do proper PD. This has been a huge hindrance for anyone wanting to run their own home router their router must bridge IPv6 to ISP router (and thus not able to do their own firewall/DHCPv6/SLAAC)
The only workaround is to use ndppd[1] set to proxy to the upstream router. However ndppd is undergoing a rewrite right now and latest stable release (0.2.5) has few bugs causing ndppd to stop working after a while. So far, the only way to get everything work for me was to build ndppd from master (which was deprecated in favor for a new 1.0, which is still in development).
OpenWRT seems to include a working version of ndppd out of the box, but its MAP-E supports is somewhat broken.
I wish it were even an option to buy a static IPv6 block from my ISP, but they don't even offer it at all.
This is with Bell Canada with 1.5Gbps down/1Gbps up fibre-to-the-home. You'd think if they can support cutting edge last mile connectivity they'd support a 90s IP standard... Instead we're stuck with ephemeral IPv4 addresses that geo-resolve to cities hundreds of kilometres away. I guess they ran out of addresses that are registered to my actual city. Just last week an online purchase I made was flagged for fraud because my IP didn't resolve close enough to my listed address. The support team then asked me to try tethering to my mobile phone, which of course was assigned an IPv4 address that resolved to a different city hundreds of kilometres in the opposite direction.
> Instead we're stuck with ephemeral IPv4 addresses that geo-resolve to cities hundreds of kilometres away.
Yay! This reduces the amount of information mega-corps can glean from me with minimal effort. Given that I'm in Canada, I often get French-language ads served to me because somebody thinks I'm in Quebec (I'm not).
> Why-o-why wasn't IPv4 64 bits long to begin with?
Because it was a research project whose designers didn't expect it to escape the academia and take over the world; Vint Cerf:
> As we were thinking about the Internet (thinking well, this is going to be some arbitrary number of networks all interconnected — we don't know how many and we don't know how they'll be connected), but national scale networks we thought "well, maybe there'll be two per country" (because it was expensive: at this point Ethernet had been invented but it wasn't proliferating everywhere, as it did do a few years later).
> Then we said "how many countries are there?" (two networks per country, how many networks?) and we didn't have Google to ask, so we guessed at 128 and that would be 2 times 128 is 256 networks (that's 8 bits) and then we said "how many computers will there be on each network?" and we said "how about 16 million?" (that's another 24 bits) so we had a 32-bit address which allowed 4.3 billion terminations — which I thought in 1974/3 was enough to do the experiment!
IPv4 with its 32-bit addresses was the "test" system which, if it worked, would then be turned into a production system later. "Later" turned out to be 2012 when World IPv6 Day was announced.
So per Vint Cerf, if you want to run the "production Internet", use IPv6.
And yet, despite far-from optimal allocation, no one is worried about running out of 48-bit MAC addresses, which need to be globally unique. That's because 64K the size of the Internet is more than adequate.
The original (experimental) Ethernet paper published in 1976 only had 8-bit addresses. They then went into 'production' with the DIX Ethernet II standard in 1980 with the now well-known 48-bit MAC, however the standard states that at the Physical Layer the maximum number of stations was 1024 (§1):
So while yes, the address space was bigger, the scope over which Ethernet had to work was much smaller and less ambitious (IMHO). No routing involved for example.
4.3billion computers seemed like it was enough when the world population was 3.6 billion.
But then they started assigning /8 (16.8 million addresses) to companies like Ford Motors.
Another 16.8 million addresses to represent loopback.
IPv6 is assigned similarly like that, for example /64 (18,446,744,073,709,551,616 addresses) is the smallest allocation unit for SLAAC. I'm wondering when we will need IPv7.
At that time computers/servers were immobile installations in large institutions like schools, companies, and other similar facilities.
No one could imagine that this technology basically would shrink and be available to everyone in their pocket connected by widespread and comparatively cheaper cellular technology.
There's also a privacy argument here. Changing prefixes makes user tracking harder. That's about the only win for the user.
I for one would have preferred to have a choice. I would accept the privacy issues for a static prefix in return. Supporting a dynamic prefix in a not so typical home setup is a PITA.
Honest question: What is the practical problem with having an IP address from one's ISP that changes from day to day? Dynamic seems to be a privacy win with little to no downside.
If I expect incoming connections and need to tell others how to connect to my machine, that's solved by DNS. I have a script that edits my DNS record any time it detects that my public IP changes, so it's automatic.
If you have any IoT devices that you would like to connect to, like security cameras, then a dynamic IP means that you need an intermediary like a cloud service of some kind to be able to reach those.
That's a serious down side. DNS can serve as that intermediary (I use it that way for my cameras) but there will be some time between an IP adjust and the DNS update, so it's a bit flaky.
I am on IPv6 and access IPv4 through bridges. For anonymity purposes I vastly prefer to have dynamic IPs to be honest.
Imagine all the tracking nightmare if we all had static IPs. All those shitty websites having you on log isn't really something I would want. I don't see advantages, getting a host with a static IP is extremely cheap today.
That's nothing compared to my experience when I got allocated static IP (IPv4) at university. I didn't even request it, the university has /16 allocated, and doesn't do any NAT, instead a stateful firewall blocks all incoming connections by default.
Anyway, the RevDNS resolved to a host containing my full name. I suppose that would discourage any abusive behavior, but even if you didn't have intention of doing that it was still a weird experience.
Yeah, I agree with how IP works, and prefer static IP over dynamic, but having my name in the DNS name is a bit too much. The only step further from that would be including my SSN there as well.
Even when walking down the street I'm not required to wear a name tag.
I'm not an expert in this area really. I've heard the argument made that even if static IP's were commonplace you would still need other fingerprinting methods as there are entire houses/apartment complexes/businesses running multiple users through NAT behind their static IP.
Also, I'm not sure what your experience has been but my IP only changes very rarely. Seems to happen about once every 6 months. My understanding that this was somewhat common, at least in the land of cable/coax-ISPs. Is 6 months not long enough to glean anything useful?
Also mobile devices that connect to different networks would get different IPs. Your cell phone would get a different IP address at home, cell, work, friends house etc... Thus there would still need to be some tracking/fingerprint to follow across networks.
I think it's possible to have the best of both worlds. Assign your dynamic prefixes to your wifi devices etc, and receive also a static allocation for any servers.
> Sadly, depending on the ISP, the prefix is not necessarily static and may change on reconnect
I'm happy that my ISP does this, as I have my router reboot every night so that I can get a new IPv4 address every day to reduce tracking. I already surf with cookies disabled by default, and only enable them to log into web sites.
I like the fact that I get a new IPv6 prefix every night as it ties into the above tracking avoidance nicely.
I'm sure there are further browser-based fingerprinting techniques being done, but it's nice to take out some low-hanging fruit.
I've had my IPv4 address from my cable ISP for years. They give me a new IPv6 prefix every time my cable modem loses connection.
For privacy I think it would be nice if the IP/prefix isn't fixed per household for long periods of time, but there seems to be a lot of IPv6 software out there designed with the assumption that the prefix is static.
Mostly the same here. My cable modem IPv4 address would stay the same for about a year. It only changed when we had an extended power outage of more than 6 hours about once a year during a bad storm.
Hurricane Electric provides free static /64 and /48 tunnels: https://tunnelbroker.net/ I've been using one for years, it's great, albeit with the occasional hiccup connecting to picky CDNs.
There are a few ISPs that rpovide proper, static, end-to-end IPv6 networking, with decent documentation, but they are unfortunately few and far between and are usually relatively expensive (bargain-basement ISPs don't tend to support IPv6, at least for their customers, at all).
Here in the UK AAISP (Andrews & Arnold) are the usual example that springs to mind for doing dual-stack IPv4 & IPv6 right. There are others that support it to varying degrees.
There is also Zen Internet who are cheaper than AAISP. They provide a static /48 subnet allocation that you can divide up into 2^16 /64 subnets.
Unfortunately IPv6 is opt in so after getting your connection you will have to contact them, they will then assign you a /48 and enable IPv6 on your connection.
I chose my ISP for much the same reason (idnet), well the combination of IPv6, static IPv4, and not being one of the big four.
(And it's always entertaining to ask the folk trying to sell BT/Talktalk/Sky/Virgin broadband deals on the street about IPv6 for the utterly blank looks that you get).
The fixed IPv4 was a key matter when I signed up. Particularly that they offered /29s, though that is less important now that SNI is almost universally supported and due to physical line issues over the last year or few (and wanting >17Mbps upstream) I've moved most of the public bits I hosted (literally) in-house to external locations.
The question of IPv6 and fixed IPv4 is fun to raise when sales robots talk about matching other ISP's offerings. The irritating one is when they say "I'm sure we can..." and persist when I say "I know for a fact your consumer product range does not offer that".
I once asked a Virgin Media sales-droid about IPv6 on a leased line, and was told they could give us IPv6 if we handed back our IPv4 addressing... somewhat special.
If the prefix is dynamic there is a (undocumented?) feature[1] in iptables that allows to only match an EUI-64 or custom static suffix, which should be enough for home networks. I'm mentioning this here because I looked for hours for a solution the first time I had to deal with this.
Basically you specify the destination address as:
::[suffix]/::ffff:ffff:ffff:ffff
or, if you are lucky enough to get a /56 prefix and want to control a single /64 subnet at a time:
Same thing is happening with Jio in India. Is it possible that this is happening because Jio is mobile network. I think I read somewhere that mobile phones are not provided static IPs.
Would make sense for routing if the first n bits are common to the cell tower. Static IPs for phones would result in slower and more expensive routing, as we can't use prefixes for routing anymore.
As bad as our ISP situation is in Canada, there are a few smaller ones like teksavvy which will make your ipv6 assignment static of you call in and request it.
Which, by design, means that Rogers and Bell must support this capability. Yet, they likely won't offer it unless it's monetized (i.e. monthly service charge).
I’ve gotten pretty lucky with my past and current ISPs (Spectrum and AT&T fiber in the USA). The only times I’ve had my public IPv4 address or IPv6 prefix change was when the router’s MAC address or DUID (dhcpv6) changed.
For my use case, I kind of like this system since everything is (mostly) static and I can change it if I need to.
> The problem is how do you know how many subnets the ISP is willing to give you? Unfortunately there’s no way of finding this
This was by far the most frustrating part of configuring IPv6 on my home network. Every IPv6 guide out there assumes you already know the PD size for your ISP, and I couldn't find any tool that would let me test different sizes. Even if I had known
> you can run odhcp6c manually with the -P option if you have to probe your ISP to find out what size of prefix you can get
, I don't have an OpenWRT router so that wouldn't have helped me.
In the end I just had to guess and hope that if it didn't work it was in fact the wrong PD size and not some other misconfiguration on my part.
If I’m not wrong, can’t you just listen router advertisements to get correct subnet? I just configured similar setup using RA and DHCPv6 for my personal network.
You can listen to RAs on your router's WAN interface, which may tell you the WAN subnet, but they won't tell you anything about the routed prefix which is what you use for networks on the LAN side of the router. The only way to get any info about that is to do DHCPv6-PD requests (or ask the ISP).
Hmm, I thought these prefixes a subset of the CIDR provided through RA on WAN?
I am kind of in similar situation as parent poster. My ISP supposedly provides IPv6, but from the RA announcements it looks like it is /64. My assuption was that I supposed to split it myself into smaller pieces. It's also sucks since they are providing /64 which is the smallest CIDR that SLAAC requires.
When I called my ISP they said that I only have IPv4, so it's not like I can get much help with IPv6.
Although I know IPv6 works, because when I connected a box and told it to configure itself through RA it did and I was able to ping ipv6 hosts.
Nope, the WAN and LAN networks need to use different, non-overlapping network ranges. The only automated way to get the LAN prefix is to ask the ISP via DHCPv6-PD.
Routing in v6 is exactly the same as in v4. If your ISP gives you 203.0.113.42/24 on the WAN, you can't turn around and use other parts of 203.0.113.x on the LAN. The only difference is that in v6 you actually get a routed prefix, and that DHCPv6-PD exists to automate it.
I don't know, and I wouldn't know how to do that either. In the end I found out that if I monitored the dhcp6c.log file on my router and tried different PD sizes I could see whether it was working or not.
My hometown does not have wired Internet but fortunately 4G is available. So I decided to share my Android Internet using a WiFi router.
I had a Raspberry Pi lying around and decided to put it to use for this. All I had to do was tether USB to raspberry PI and connect PI to the router over Ethernet. I had working Internet connection in first attempt only to realize after some time that it was only IPv6 websites that worked. I had to touch router configuration to fix IPv4.
IPv6 seems to solve lot of networking issues. It's a pity that the giants[1] still haven't implemented it.
I don't think software is there yet for creating a home IPv6 network. Docker doesn't have good IPv6 support, for instance. It felt like going back to the stone ages of IPv4 and specifying all IP addresses manually vs doing some kind of DHCP-like automatic assignment like IPv4 does. Maybe it's possible, but I haven't been able to get it to work.
You're supposed to use DHCPv6 or Neighbor Discovery -- like everything else in IPv6-land, it's significantly more complicated than it is over IPv4.
I don't run the whole network IPv6 -- for hosts I care about having an IPv6 egress for, I use a Wireguard tunnel in IPv6 private address space to a bastion host. If I want to expose a port, I forward it from the other side. It's a sad state of affairs :-(
I'm not sure it's that much more complicated as such, beyond being different/unfamiliar.
Just setting up SLAAC is very straightforward, probably (ignoring any unfamiliarity issues) more simple than DHCP?
Pulling addresses from your service provider via prefix delegation can be a bit funny, and could do with being a lot more polished. Instructions/community support in particular can be problematic as ISPs tend to use different prefix lengths, rather than just standardising on /56. And also less relevant if you have a static allocation, which is potentially more likely with IPv6 than IPv4.
And DNS becomes more important, as does firewalling, no more relying on the somewhat dubious NAT safety net.
It's mainly so I can "road warrior" to my internal resources from my laptop transparently. IPv6 is a good choice for this since it won't conflict with any NAT address space you're likely to be on.
It didn't work for me on my IPv6 ISP, until I started assigning addresses manually. It felt like a big step back. I wasn't willing to waste more time on research, so I decided to go with IPv4.
For a home network/SME-scale, I don't see the value proposition of IPv6. It takes time to retrain staff, incurs hardware and software replacement costs in some cases (not to mention licensing changes from vendors) and ties up developer/IT time during the process of upgrading and troubleshooting IPv6 teething issues (as I've found in my case). The outcome is that the network can now handle more addresses and more advanced workloads, but becomes harder to maintain. Most home/SME-scale networks don't need even half of the 10.0.0.0/8 address space and don't take advantage of the new features, so it becomes pointless to upgrade unless you outgrow IPv4's capabilities or know you're on track to doing so.
This is a pretty decent overview of IPv6 on a home network. Here are some other things I learned when doing something similar recently on my home network (except the router is a FreeBSD box).
- You can run `dhclient` interactively to learn the size of the prefix your ISP delegates. The OP touches on this, but the solution is OpenWRT-specific. Most distributions include `dhclient` or have it packaged.
- It’s possible that the IP your ISP assigns your router is in a different prefix from the prefix it delegates to you. For example, my ISP for a while assigned an IP in 2607::/16 while delegating a /56 prefix in 2605::/16.
- Prefixes can also change. When I switched my router to FreeBSD, I started getting a /56 prefix in 2607::/16 instead of 2605::/16.
- Some systems (e.g., Windows 7) don’t support getting DNS via router advertisements. If you want to support them, you need to run a DHCPv6 server and advertise that other stateful configuration is available.
- Kea is the successor to the ISC DHCP server. I found it a bit nicer and more flexible to configure.
- On Linux, NetworkManager and systemd-networkd handles a lot of this stuff automatically, but your customization options are limited. I couldn’t find a way to do the above without having to do things manually myself.
- FreeBSD’s DHCP client in base does not yet support DHCPv6. To get an IP and a prefix, you need to install one from ports. I’m using dhcp6c, following this guide[1] to set it up.
- ICMPv6 is integral to IPv6, but if you want to filter it, follow the advice in RFC-4890. Filtering ICMPv6 incorrectly will mess up your network in weird ways (e.g., my MBP could get an IP but wouldn’t get a DNS server until I fixed the problem).
- IANA maintains a registry[2] of IPv6 multicast addresses. I found this helpful when writing firewall rules.
- When advertising LAN services over DNS, make sure you use the “secure” or “template” IP and not the temporary IP used for IPv6 privacy. Also, you can’t assign domain names to link-local addresses, but you can advertise a DNS server (via RA and DHCPv6) on one.
- mDNS is the exception to the above. Avahi and Bonjour advertise link-local address and are able to resolve them properly.
> FreeBSD’s DHCP client in base does not yet support DHCPv6. To get an IP and a prefix, you need to install one from ports. I’m using dhcp6c, following this guide[1] to set it up.
Colin Percival made it a bit easier (IMO)[1] it is meant for AWS EC2 but worked for me with my ISP as well. The guide you submitted probably will work everywhere.
Thanks for the suggestion. It turns out, I was wrong. dhcpcd is being imported into base for FreeBSD 13.
One big limitation with dual-dhclient is that dhclient doesn’t support setting the delegated prefix on the interface. You have to parse it out and generate a rtadvd.conf with the prefix.
I ended up switching from dhcp6 to dhcpcd since the latter is actually maintained and seems to work better with my ISP (hopefully …).
> One of the recent experiences of Linux Plumbers Conference convinced me that if you want to be part of a true open source WebRTC based peer to peer audio/video interaction, you need an internet address that’s not behind a NAT.
UPnP is completely useless for CGNAT, and PCP would work only IF the CGNAT gateway would support it, which most don't (or it's disabled).
I don't think great difficulty about NAT is concerning CPE NAT, i.e. your local network, as it's trivial to forward ports (or port ranges) manually. Most problems are with CGNAT, i.e. on mobile broadband or some cable and DSL providers.
Where I am the number of ISPs that support PCP is the same as the number of ISPs that support IPv6 - zero.
My point wasn't that IPv6 is currently the answer, my point was that it's impossible to host anything or be reachable by anyone for A LOT of people in the world.
It’s too bad that we are inheriting the static IP policies from IPv4, because ISPs want to upsell.