Isn't "Track Interface" Dangerous on a Managed Network?
-
Hi everyone,
For the last few days I've been trying to wrap my mind around the thinking of using "track interface" for IPv6 WAN connections, and I can't figure out how to resolve a whole host of problems that this creates. I like to think of what it would be like to deploy IPv6 under the assumption that IPv4 didn't exist; in the sense that the IPv6 network should be able to work 100% without loss of functionality in the absence of IPv4.
Some of the issues that I can see with a LAN interface configured this way are as follows:
-
How do I get a static IPv6 address on the router so I can add it to a local DNS server and not have to remember the IP and easily access it by hostname/fqdn?
-
Same question stands for local servers - is it still OK to manually define or create a static lease for their IPv6 addresses with this configuration?
-
What default gateway do you set if the router no longer has a static address is this now the ISPs gateway address?
-
Does this type of configuration not place you 100% at the mercy of your ISP not changing your delegated IP range in such a way that if they change it then your whole LAN stops working?
-
If you do specify the ISPs gateway as the gateway address on all your systems, doesn't this mean that you will need to now change the gateway setting manually on every server if you change to a new ISP?
These are problems that start to occur in the absence of IPv4 only of course and fundamentally all relate back to the LAN becoming very dependent on your ISP. Isn't it smarter to hand out addresses on the LAN via DHCPv6 yourself. That way, if the ISP screws something up then at least your LAN continues to work OK until internet is restored.
I think fundamentally, I never considered the implications of deploying an IPv6 network in the sense that each device has an internet address. I guess IPv6 in general makes it harder to change ISPs without having "IP address portability" in the same way that we have phone number portability when we change carriers.
What are your thoughts on these points and how can you mitigate some of these issues?
-
-
Yeah - Handing out IPs dynamically is something I'd hope to have seen die with IPV4.
A static IPV6 block per customer is so much more useful and I really can't see a reason not to do that other than to extort money from customers.
-
In an environment that needs to be stable and statically addressed, you really need a static IPv6 assignment. Dynamic PD would be problematic if it changes, just like it would be with IPv4. There are a variety of possible solutions to this issue. Possibly the best if your only option is dynamic PD is using static ULA space as your static server IPs, and letting them obtain their public v6 IPs dynamically. That has potential complications with source IP selection, depending on specifics. But it avoids NATing Internet traffic, which should be considered evil with v6.
Strictly using ULA internally and doing NPT to your PD subnet is a possibility, though we currently don't have a means of doing auto-NPT based on PD. That likely is something we'll implement in the future. You'd have to manually update your NPT when PD changes for now.
-
- How do I get a static IPv6 address on the router so I can add it to a local DNS server and not have to remember the IP and easily access it by hostname/fqdn?
You don't; instead, you use DDNS, DNSupdate or mDNS.
- Same question stands for local servers - is it still OK to manually define or create a static lease for their IPv6 addresses with this configuration?
In principle, you can map a static suffix to each host and have the router combine that with the delegated prefix and assign it to the hosts via DHCP6, and also update the DNS forwarder as appropriate; this is not currently supported by pfSense, though.
- What default gateway do you set if the router no longer has a static address is this now the ISPs gateway address?
Recommended practice for IPv6 – prefix delegation or not -- is to announce the router's link-local address (which has the benefit of always being resolvable).
- Does this type of configuration not place you 100% at the mercy of your ISP not changing your delegated IP range in such a way that if they change it then your whole LAN stops working?
It doesn't have to; see above.
- If you do specify the ISPs gateway as the gateway address on all your systems, doesn't this mean that you will need to now change the gateway setting manually on every server if you change to a new ISP?
You don't; see above.
These are problems that start to occur in the absence of IPv4 only of course and fundamentally all relate back to the LAN becoming very dependent on your ISP. Isn't it smarter to hand out addresses on the LAN via DHCPv6 yourself. That way, if the ISP screws something up then at least your LAN continues to work OK until internet is restored.
For strictly LAN-internal communication, you could always just use link-local addresses to begin with.
I think fundamentally, I never considered the implications of deploying an IPv6 network in the sense that each device has an internet address. I guess IPv6 in general makes it harder to change ISPs without having "IP address portability" in the same way that we have phone number portability when we change carriers.
Only if you insist on hard-coding stuff on the clients. DNS (and, if you like mDNS) exist; why not use them?
-
Also, pretty much anyone can get an IPv6 block from the RIR. You just have to find an ISP that is willing to announce your IP range on their AS number. We do this for some of our customers with IPv4. I don't see why ISPs couldn't do it with IPv6.
-
I think fundamentally, I never considered the implications of deploying an IPv6 network in the sense that each device has an internet address. I guess IPv6 in general makes it harder to change ISPs without having "IP address portability" in the same way that we have phone number portability when we change carriers.
IP address portability has existed from day one of the Internet, just getting a PI IP assignment from your RIR. Granted for IPv4 you have to have at least a /24 to announce it in Internet BGP (and have it actually work), and have to document why you need that many IPs. Most SMBs can't justify a /24 assignment. But, for IPv6, no justification is necessary so that's an option where your ISP(s) are willing to advertise IPv6 space that's directly assigned to you. Therein lies the problem in most cases, as unless you're spending a decent chunk of change with your ISP(s) they're not going to advertise your IP space.
Also, pretty much anyone can get an IPv6 block from the RIR. You just have to find an ISP that is willing to announce your IP range on their AS number. We do this for some of our customers with IPv4. I don't why ISPs couldn't do it with IPv6.
Depends on the ISP and the type of service. Good that you make it an option, and you could just as easily do the same with v6. Generally ISPs won't do that for even business class cable or DSL connections (and forget about it for residential), and that's also where you'll end up with dynamic PD. Many SMBs aren't going to spend significantly more on fiber connectivity where ISPs make BGP announcements an option.
-
Very true. We are actually a hosting provider and not an ISP. I imagine most ISPs wont do this unless you are a large account that spends lots of money. We don't charge for the service of announcing an IP range on one of our AS numbers and we don't have any account size or spend requirements for it but our services are already expensive to begin with. I suppose you could set up one server with us, have us announce your IP range and route it to your server, and then setup a VPN from the server to wherever. But that would be sub optimal compared to just finding an ISP willing to announce your IP range directly.
-
I imagine most ISPs wont do this unless you are a large account that spends lots of money.
Depends on how you define "lots." Generally in the US if you have fiber connectivity, they're willing to do it, even if it's just a single connection you're buying with them. Looking at ~$1000 USD/month at the low end for that type of connection, though that can vary widely depending on location.