I get a lot of concern expressed by people who run multi-homed enterprises in IPv4 land and think that they don’t have the same ability in IPv6. In many cases, the second sentence uttered is “and don’t tell me to use BGP, we don’t have a network guru on staff.” If any of this sounds familiar, keep reading. While I am going to tell you that BGP might be part of your solution, I’m also going to show you some other alternatives and talk about practical approaches to deploying very simple BGP solutions that don’t really require a “network guru on staff” to operate.
It is not only possible, but, relatively simple to multi-home an enterprise network in IPv6. There are some differences from IPv4 in some situations, but, nothing that can’t be easily solved once you understand a few basics.
Reviewing the techniques used in IPv4 will set the stage for how to do it in IPv6. We’ll start with the most effective technique and work down to the less effective, but often simpler, solutions employed in many enterprises today.
Multihoming With BGP
…do the exact same thing in IPv6 that you are doing in IPv4.
The most effective technique for multihoming in IPv4 is what is known as “Provider Independent” (PI) address space combined with the Border Gateway Protocol (BGP) in which the enterprise receives a complete routing table from each upstream and advertises its own routes to its upstreams.
This solution offers the greatest flexibility and reliability possible. It is also the most expensive, requiring relatively high-end border routers, space directly from your RIR (or in the RIPE region from a cooperating LIR) and an Autonomous System Number (AS Number or ASN for short). These things can be expensive to obtain (address space + an ASN is at least $1,750 initially), but, the annual fees are just $100 for an enterprise user in the ARIN region, so, the cost is not prohibitive. If your enterprise is using this technique for multi-homing, there’s really good news for you in IPv6. All you need to do is get an IPv6 block from your RIR (ARIN will issue you a 48 for $1,250, for example) and do the exact same thing in IPv6 that you are doing in IPv4.
The second most effective technique is very similar to the first technique, but, uses less expensive routers. Instead of taking a full feed from your upstreams, you take some subset of routes or even just a default route alone from each provider. You advertise your prefix(es) to each provider and life is mostly as good as in the first solution. This solution is also available in IPv6, as above.
Another common multi-homing technique is very similar to the first two, but, uses Provider Assigned addresses from one of your two providers. You can do this in IPv6 as well, but, there are tradeoffs and this may be a good time to consider switching to PI space instead.
Multihoming Without BGP
A common variation on these techniques is not to run BGP locally, but, to have both providers statically route a given address space to you. However, without BGP from your site, there are failure modes where the provider may continue advertising your addresses and black-holing some of your traffic during outages to just one provider. Once you’ve gone to the trouble of setting up this much infrastructure, it’s rarely worth while to avoid using BGP to do the routing.
IPv6 applications are being developed with the belief that IPv6 addressing is end-to-end…
The most common technique for multihoming in IPv4 without BGP is to get PA prefixes from each provider and use them on the outside of a NAT which translates between your interior IPv4 addresses and the “public” PA addresses. The problems with this solution are many, but, in spite of the problems, quite a few enterprises are successfully using this solution with relatively good results. The really bad news is that this solution absolutely doesn’t port to IPv6. In IPv6, there is no NAT of the type that would be required here (at least not supported by RFC). IPv6 applications are being developed with the belief that IPv6 addressing is end-to-end and applications do not need to concern themselves with workarounds for modified addressing information in headers.
The good news, however, is that you can actually deploy an IPv6 stateful inspection firewall in parallel to (possibly on the same hardware) your NAT enabled IPv4 firewall, use globally routable IPv6 addresses, and still have all the same policy protection on IPv6 that you have with IPv4 on your NAT firewall. However, not all IPv6 firewalls are created equal. You want to make sure you use one that has a default deny any any behavior in the absence of or after loss of configuration information. Firewalls with this behavior are just as secure as NAT. (Lots of self-proclaimed security experts may tell you otherwise. This is what the industry calls “security theater” rather than actual security. Many will point to the Payment Card Industry Data Security Standard (PCI-DSS) claiming NAT is required. PCI has recently updated their standards and removed the language that appeared to require NAT).
A New IPv6 Multihoming Option
It is not only possible, but, relatively simple to multi-home an enterprise network in IPv6.
If you still don’t want to get PI space or deal with BGP, there’s yet another solution to multi-homing without NAT and without BGP that you can use on your enterprise network. You can obtain an IPv6 PA prefix from each service provider. Use some form of signaling (routing protocol or other) on that link to make sure the provider is alive. So long as it is, include that provider’s prefix in your router advertisements throughout your enterprise. When it goes down, withdraw that prefix. You can set host policy for which providers addresses to prefer if you feel the need. Maintaining this for an enterprise with significant infrastructure is probably harder than BGP multihoming, but, it can be done. I also expect we will see tools for doing this more easily in the near future.
Your internal network can still include routes to the specific addresses inside your network from all three providers independent of the RAs, so, you don’t have to run around renumbering servers or anything else all the time. You do need to make numbers available and remove numbers over time as you switch providers, but, it’s not nearly the chore it was in IPv4 and it can be done with a relatively orderly transition process without significant user impact in most cases. If you are in an environment where that would pose a challenge, it’s probably best to just get a PI prefix and an ASN and do BGP based multihoming instead.
{ 14 comments… read them below or add one }
There is a simple way of doing multihoming with IPv6 wihout BGP, without NAT, called “LISP”.
LISP is the Locator ID/Separator Protocol. More information can be found on http://www.lisp4.net/
I use it at home to multihome my IPv6 PI prefix over my residential IPv4-only fiber and IPv6-only DSL connection.
Thanks Job! Perhaps you would be interested in doing a guest post here on LISP and your experience with it?
Yes, Job, you can use LISP as an alternate solution to the problem as well. In my opinion, referring to LISP as simple is like referring to the mechanics of an electronically fuel injected internal combustion engine as “as simple as suck-squeeze-blow-go”. While it’s an accurate description of the macro-level process, it’s a gross oversimplification of the complete mechanical picture.
@Chris, yes! I would be honored. Hit me with an email explaining what kind of post you are looking for.
@Owen, From a user-perspective, all that is required is about 6 lines of CLI. That seems pretty simple to me… Also from a financial point of view: the low price point at which you can do multihoming with LISP compared to leased lines, bgp feeds, etc etc makes it a very simple decision :-)
- Job
Owen, a packet comes to a CPE router, it looks that destination address up in a mapping database, it obtains locator addresses. It uses those locator addresses to encapsulate to a remote site. What is complicated about that? It certainly is a lot simpler conceptually to understand (and to configure and operate as Job states) than BGP.
So tell me what is complicated about LISP.
Dino
Dino,
There’s a lot more to configuring a useful and workable LISP environment and you know it.
Taking real advantage of LISP requires configuration elements on every end host and most routers. It’s not significantly easier than MPLS, which has the advantage of holding its complexity at the core and not being generally deployed to end-nodes.
You are right… It’s probably slightly easier to configure an end-node for LISP than to configure it for BGP (though not a whole lot).
However, with BGP, I don’t generally have to deploy it to every end node.
Owen,
ISPs are applying filter to control IPv6 routing table, so in PI multihoming scenario, what will be the case for enterprise having /48 or /56? is there any restriction on prefix size?
@Adil
First, let me say that I generally think that /56s are a bad idea from the word go. They will reduce the probability of some really cool development that could occur with DHCP-PD providing better security and compartmentalization options to home users in a fully automated and plug-and-play way. I strongly support /48s as the minimum end-site assignment unit.
Second, many providers will not accept anything longer than a /48, so, I doubt /56s will make it very far in the global routing table.
At this point, I don’t know of any providers that are still filtering out /48s or shorter from the PI blocks. Some are still filtering /33s and longer from PA block ranges, but, it is not clear how long that will last.
All of the RIRs currently support assigning /48s to every end site without any penalty whatsoever. Some of them have confusing language around /56s which makes it sound like you have to justify every /56, but, in reality, if you assign a /48 to an end site, that is considered full justification for 256 /56s without regard to how many networks are actually used at that end-site.
Owen
Hallo Owen,
thank you very much for your article.
I have a problem, we plan to migrate to Dual-Stack inside our network. there is everything fine, but now the question is about PI- address space. We have in our several branches (different providers in diferent countrys) IPv4-PA. Branches are connected over leased lines (VPN).
I really try to find some imformation in the internet about PI address apce, also on RIPE website, but I have still no idea how to use an i.e. /48 block of IPv6-addresses together with BGP. I know a lot about the knowledge about IPv6 and BGP, but have I to order PI-IPv6-/48 blocks for every branch in every country? When I only use one /48 block for all branches, I have to subset it and then I only can advertise maybe /52 and higher..
I hope you know where my knowledge gap is located. It is really difficult to find good answers in PI addressing and routing. Till now I cannot decide what will be the best technique for the company.
kind regards,
Henry
Hello Henry,
I am in the same boat as you. I will be very curious to hear a solution from Owen or other folks
PR
Henry,
Sorry for the delay in reply. Yes, I believe you need a /48 for each end site to make them independently routable. If you attempt to advertise the /52, it will likely not make it beyond the service provider you are directly paying.
One possibility might be if you have a common provider or providers at all sights, you might be able to use the /52s and ask the provider(s) to proxy-aggregate the routes for you. However, I think your best bet is to go with /48s everywhere and advertise them as needed.
The difference between v4 and v6 in BGP is negligible at the protocol level. What you are really asking about is the cultural and behavioral probabilities of various ISPs around the world.
To the best of my knowledge, everyone is now accepting PI /48s from PI space. Many (most) are accepting /48s anyway. Some are filtering PA prefixes to be /32 or shorter. Some have filters allowing PA prefixes to be deaggregated down to /36.
Hope that helps.
Owen
So, i have a question building on Henry’s, never working with my own PI block and my lack of BGP knowledge
Lets say I have 3 sites/branch offices. If I get a /32 could I then break this down and give a /48 to each geographically separated site and multihome each site. Where a local, onsite, router advertises solicits that site’s local /48
Then if possible, (and for phase 2) could I announce Sites A and B as a last resort route for site C]
Thanks,
Adam
@adam
The better solution than using a /32 would be to get a block of /48s (perhaps a /44) from ARIN as a PI end-user. If you get a /32, it’s possible that some ISPs filtration policy will block the more specifics.
However, absent filtration issues, yes, advertising a separate multihomed /48 from each of 3 sites within your organization would be no different than 3 organizations advertising 3 separate /48s from their multihomed end sites.
To do it cleanly, each site will need its own autonomous system number, but, there are hacks that can be used to reuse the same autonomous system number, though I don’t recommend that approach.
If you have a backbone between the sites, it would probably be better to announce the /32 from all sites and announce the more specific from each site. I was assuming from the first part of your description that these were discreet end sites not connected other than over the internet.
@owen
Wow, that was a quick response. I apologize for my ignorance. I grew up on ISP allocation and NAT so this is a new beast for me. I want to start a proper multistack IPv6 implementation but IPv6 scares my boss because its different. So I need a complete and well thought out plan to even have a chance of doing this right. Lets just say he wants to run v4 internally and translate to v6 when necessary so he can wash his hands of v6.
Our organization has 4 sites, 1 primary and 3 branch offices. The Primary is a collocation facility that has at least 4 ISPs while the branches have at least 2 (one has 3). All sites are also connected by an IPv4 MPLS. (if you cant tell we move boat loads of data). I was hoping the MPLS provider would one day provide v6 support or one day I would configure v6-v6 tunnels over the MPLS but that would be phase 2 of the project. The MPLS pipe is far narrower than the ISP pipes so, if I break up a larger block between sites I need traffic to route to the native site before it routes to the larger block via a secondary site.
Anyways, I was under the impression, a /32 was the smallest recommended allocation by ARIN probably to keep routing tables from exploding. Then, thanks to your article I learned everything down to a /48 was usable by a multi-homed PI.
I think the disconnect I am running into is even if i get a /32 as a PI end user, it may still be filtered because it was not specified by ARIN as being broken up into smaller chunks. As such, some ISPs will filter the smaller chunks if i break it up. Though, if I request a chunk smaller than /32 ARIN says its going to be broken up so smaller ISPs are more likely to respect the small solicitation.
In any case, the ultimate question is what size address block should I propose to my boss given our use case.
Sorry, I have never worked with AIRN or BGP so this is a new adventure for me.
Adam