6 ms·
The irony for me is that I pretty easily get a static IPv4 block from my ISP (they do it for free for me, but should be $5/month or something). Trying to get a
by whoknowswhat11 5y ago
The irony for me is that I pretty easily get a static IPv4 block from my ISP (they do it for free for me, but should be $5/month or something).
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?
- gerdesj 5y agoNPt - eg: https://docs.netgate.com/pfsense/en/latest/nat/npt.html https://docs.netgate.com/pfsense/en/latest/nat/npt.html or NAT66 and friends for outbound. DNS for inbound. Sadly most VPNs don't support SRV or similar. Wireguard perhaps. It's not pretty 8(
- slownews45 5y agoThis is the issue. 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).
- andrewjf 5y ago> 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. 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.
- slownews45 5y agoI think 464XLAT is probably the better solution currently as you can interop with things like websockets etc / SIP? One problem is none of this was default, 464XLAT came out because folks were trying to solve this. That's much different than every router that supports IPv6 auto supports a NAT64 type solution. Other issues are created because of overall protocol differences etc.
- _ofdw 5y ago>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. 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.
- paxswill 5y agoDepending on your DHCP and DNS servers, they might already have this built in. dnsmasq will maintain DNS entries for the DHCP leases it hands out, and can also add AAAA records if it sees a SLAAC message for a MAC address it gave a DHCP lease to. BIND’s servers (dhcpd, named, kea) can be set up so that for each DHCP lease assigned, a DDNS update is sent.
- xoa 5y ago>and having those machines use e.g. ddclient or similar 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.
- rnhmjoj 5y ago> 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). 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.).
- GSGBen 5y agoThat works for one ISP, the issue is with two (a common design for SMB network reliability). Earlier recommendations I read were "get your own public /48 assigned and peer with both, NAT including NPT is not good". But it turns out some (all?) authorities won't do that for SMBs, so we're back to some form of translation, probably on top of ULAs running internally. 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.
- 5y ago