Trying to get a static IPv6 prefix is not possible. So there is actually LESS availability of static IPv6 for some reason - even through the address space is so massive, the rules around using it are so restrictive you can't get something static.
This ripples into absolutely everything - now doing firewall rules is a total pain. Additionally the machines and devices are constantly changing IP addresses (on IPv6). So the old small business setup model where a DHCP server is setup, some static IPs configured then reservations in DHCP made, then everything works great no matter what happens in DNS or other servers etc is gone, which feeds mgmt dashboards so you can easily do a alerts or period end report - so and so used 5TB, is something wrong with their machine type stuff - get's harder.
I am curious what recommended IPv6 solution is for this classic small biz situations.
Dual WAN, primary ATT, secondary comcast (for failover). Local DHCP server for addressing. Monitoring / reporting by User/IP. VPN terminating at a sonicwall or similar.
1) Without a static IP - what do I give my VPN users? 2) With all the IP address changes, how do I assign IP's to users to get my monitoring tools to play well with everything. 3) With PD, how do I get my failover working well?
A dynamic prefix sucks for a number of reasons, but at least for firewall rules you can just match the last 64 bits using a mask. At least, ip6tables can do this.
> Additionally the machines and devices are constantly changing IP addresses
You probably mean the privacy extensions addresses (AKA temporary). Those are complementary to the persistent ones (EUI-64) and shouldn't concern your firewall because they aren't normally used for receiving connections, unless you intend to block outbound traffic.
> I am curious what recommended IPv6 solution is for this classic small biz situations.
For a small business, the recommendation is: get a (static) /48 from your ISP, split it into several /64 subnets, advertise a prefix for each subnet, a DNS server (RDNSS) and let the clients assign their own addresses via SLAAC. There's no need for a DHCPv6 server (in fact some clients don't support it, see Android) or reservations because the addresses are unique and static.
If your ISP is evil and doesn't give you a static prefix, you can advertise a ULA prefix (basically the IPv6 version of RFC 1918) and use that in place of the dynamic one. Clients will use the dynamic prefix for Internet connections and the ULA for local services (printers, NASs, etc.).
Another related issue is the ULA design - they're meant to be randomly generated but it's not enforced, so you just know there'll be a bunch of internal networks with custom duplicate ULAs that will only show up when some businesses merge, so we'll be back to re-ipaddressing subnets.
IPv6 has changed a bit since the first RFCs (privacy extensions etc) so I imagine at some point someone will look at this and make some changes to suit. I wonder if it'll be relaxing ULA recommendations or adding something else entirely.
I'm insanely excited for never having to worry about subnet size again but it just doesn't seem like there's a clear best-practice one-true-way everyone-agrees way forward right now for a whole bunch of popular use-cases.
pfSense only got support for PD-aware firewall rules a few months ago[1], and it seems rather limited as such.
It's obviously more complex, but could this not be solved by running an internal DNS resolver, assigning every machine a hostname, and having those machines use e.g. ddclient or similar to ensure their IPv6 address is current in the internal DNS table?
I mean I know it's easier to remember that e.g. 192.168.1.4 is your printer, and .5 is the CNC router, etc. but I feel like that's not how IPv4 was intended to be used.
How does this work on my networked PDU, UPS, speaker, light hub, or even printer for that matter since you mention it [0]? There is vast universe of "machines" that aren't full fat PCs (or if they are under the hood grant zero native flexibility to the operator over any of that). But they all can take a static IP fine and then get managed from there, shoved into VLANs which are also straightforward with IPv4, etc.
I agree with GP that this is a really, really common scenario in SMB. And it means a lot of stuff can stay up and active with quite minimal network infrastructure.
>but I feel like that's not how IPv4 was intended to be used.
First, why not, and what source? People have been using static IPv4 for this sort of thing for as long as I can remember ethernet (mid 90s) at least and probably before I ever did my first networking at all. But second, so what? It's useful, makes sense and has tons of usage. It allows basic networks to get bootstrapped in a super lightweight fashion and its dependable when there are issues at higher stacks. It certainly doesn't scale, but conversely at scale handling more moving parts reliably also is much more feasible so that's ok.
It definitely seems like one of those things that should have been a gimme in a new standard. With the opportunity to have close enough to limitless addresses why did they have to make it more restrictive then the old very limited system?
----
0: Ignoring granted that many of them don't support IPv6 at all, because some already do and that number may eventually be 100% or sufficiently close. And that would probably happen sooner if there was more demand due to IPv6 meeting existing needs.
A couple of years ago I tryed to make my homenetworks complete IPv6, but then I realised, IPv6 is a such pain for me at home with a couple of VLANs and so. Of course just NAT is bad, but it had also it's good points.
It's not pretty 8(
I wish we could have had (static) PD, then locally define a netmask, and then DHCP or straight static for local devices.
Internally, you'd ignore PD for routing within netmask - so regardless of where WAN link went you'd still be ok locally. But because address space is so big, and PD is so big, these local addresses were also (with PD attached) globally routable.
I'd also love if IPv6 only devices had an EASY way to hit IPv4 (ie, xxx:ipv4 in IPv6 address space, with the border device which could be dual stack translating over to IPv4) as a default transition config. One problem is that IPv6 put so many new concepts in it doesn't map as cleanly as maybe IPv5 might have (just an extension in size of space).
Doesn't NAT64 do exactly that? It translates `64:ff9b::<32 bit IPv4 address>` -> `IPv4`. I get there's stateful/stateless issues and "default" configs (i.e. DNS64), but sounds like the technology is there.
My big issue remains multi-homing for smaller setups like my homelab and SMB's. When doing NAT (and I could do NPT with my v6 network) all my policy is at the gateway - what traffic goes over what link, etc. I lose all that with IPv6, and I'm still trying to figure out how to deal with it - what used to be simple policies like "my home office uses CenturyLink and only fails over to Sparklight if that's down while everything else does the opposite" now require some way to push down the client or more sophisticated IFTT style setups on the router (if this gateway goes down depreciate the prefix and advertise this one instead).
In theory, you could actually disable router advertisements on the routers themselves, and run a small daemon that just announces the right information.
I actually investigated the feasibility of something like this - but the way IPv6 RA's work requires they be sent from the link-local address of the router itself, so I'd have to run said daemon on the router itself - at which point I can just write some scripts to modify configuration on event triggers.
I have three seperate VLANs (Untrusted Devices, Servers, Normal) which is easy with IPv4/NAT/HAProxy.
IPv6 was unpredictable in how I could get more than a /64 subnet (so no VLANs allowed). After guessing at how to get it for a few hours, I was able to get a /56 subnet, and set it up. I even disabled IPv4 (dual stack caused it's own set of issues). IPv6 was much, much slower. I was unable to track down why it was so much slower, so I ended up just doing back to IPv4.
https://www.ripe.net/publications/docs/ripe-690#5-2--why-non...
You want portable /56s?
You realise that's incredibly expensive for everybody else right? Today's portable /24s are a considerable burden, and you'd like to have far smaller routes assigned for basically your personal convenience. I don't know for sure what it would cost, but certainly thousands of dollars per year each seems like a very modest estimate.
But consider: (1) that for ages the route table growth has been slow due to v4 shortage, and router memory has kept getting cheaper on the normal memory cost curve for this plateau phase in history, and (2) Consumer ISPs have been abusing this and making prefixes jump around even on CPE reboots, instead of having them stable for months and years like is the design, and (3) mechanisms to smooth out renumbering haven't been deployed because ISPs have gotten away with doing [2] without any mitigations.
The 'net infra could probably afford to start giving many more people portable blocks, and it would be only fair that ISPs would have to pay a bit for their sins regarding [2], and to this would add incentives to do [3].
And also, in absolute terms it's currently tiny, ~ 2 M routes that can be represented in a couple of addrs worth of space each in line card memory when deciding just which interface to forward, and keeping in mind that only core routers that don't outsource transit to other upstream telcos have a need to keep this in memory.
Is it simply that you don't understand why it's incredibly expensive? It means everybody who does network routing has to buy extra hardware to track all this useless noise you've decided ought to be "free", that hardware costs money.
Your ISP choosing to charge you for stuff that doesn't cost them anything is completely separate. I would say "Choose an ISP which isn't shit" but you're probably American and have no such choice. Too bad?
But in the general case, for a customer who is just using the Internet from the same place as last time, there's no benefit to changing their IP addresses and clearly there's no reason static addressing shouldn't be free, it's just like one database entry for them to do it.
I could imagine them explaining OK, you get static BUT it might change if you move home or something, and that feels pretty acceptable to me.
For what it's worth I get static IPv6 and IPv4 (although of course the IPv4 is a tiny block, only a /27 IIRC whereas I have a /48 of IPv6) but I'm in the UK and with a specialist ISP that cares a lot about this stuff.
Even some of the large ISPs can get it right. I used to have fiber optic service from a large telephone company (starts with "C" ends in "EnturyLink") and could use their account management portal to go and get anything up to a /26, complete with setting up reverse DNS, just by clicking a button and agreeing to a relative pittance of money. I think the /26 was $40 per month and the /28 I had was $10 a couple of years ago. They would give me a static IPv6 /48 for nothing, just a click, and delegate the reverse DNS zone to me. A /56 that was supposedly dynamic but never actually changed was given by default.
The problem seems to be which ISPs want to do what. ISPs run by phone companies seem to think of their networks, and the customer networks attached to them, as actual internetworked networks. ISPs run by video companies seem to think of their networks as extensions of distribution systems for linear television channels.
The more ASes that exist, the more routes need to be propagated. If every household were theoretically assigned a network that they could take with them anywhere, and advertise, a well-connected router would have millions and millions of routes to track and forward.
One of the goals of IPv6 was to make the Internet more hierarchical to avoid this.
I agree with your point. I should be able to get a static PD from my ISP (a /56 or /60 easily) and that should stay the same for all time, given a MAC address. In other words, PD should be stateful.
I have thought about setting up my LAN with "Unique Local Addresses" and doing NAT66 if I can ever manage to get a public IPV6 address from my ISP.
I'm not really sure how much each of these types of memory cost, but I did find [1] which says "The cost of TCAM is also about 30 times more per bit of storage than SRAM". That suggests a CPU with something more like 0.5-1 GB of L3 cache would be a closer comparison.
[1] https://research.ijcaonline.org/volume115/number7/pxc3902299...
I would much rather have a local network naming system that works and use human readable names in all situations where I want to specify firewall rules. It's a shame that this still really isn't an option, the technology is there, it just needs some polish to not require so much tweaking.
Plus blackholing temporarily due to a stale cache is better than blackholing permanently due to a stale rule pointing to an old IP.
the don't know the router lost its connection
This is a technical argument for IPv6, because there is no reason to worry about exhaustion and scarcity with it. The issue here is on the business side of things.
As others have mentioned: as a kludge you can assign ULA on your network and then use NPTv6 for when the prefix you're delegated changes in the non-static scenario.
This system would need to support MTU >= 1500, and enforce geographical locality so it doesn't get banned by Netflix.
Alternatively, I could setup a v6 tunnel for my home network and each of my remote nodes that doesn't have native v6, "beyondcorp" style. But I want to have an "internal" network where everything is definitely running over wireguard. But wireguard over v6 just means more bytes on the wire and suboptimal routing, and v6 over wireguard falls under the first point.
Now it's true that if one of my VPS's was v6 only, then I'd start to care about v6 reachability to keep my wireguard mesh a full mesh. But at this time I just don't see the use, and without a use anything I setup for kicks will eventually fall apart like my previous few tests of IPv6 did.
I wish IANA and friends would let home users and other smaller entities request global /56 address blocks and force ISPs to peer/announce (nothing crazy, just a default route).
EDIT: end users should be able to request static blocks from their ISPs for free, not IANA.