One of the recent questions I am getting around IPv6 deployment has to do with connecting remote sites and making branch offices highly available without using BGP. Today, with IPv4 it is not uncommon for a typical branch office to have two ISP connections, each with unique IPv4 ISP address space (provider assigned). The branch site will have a router or firewall that will make use of both connections by leveraging NAT and some sort of tracking or performance algorithm to determine which connection to use. It is able to do this because the solutions utilized NAT to obscure the actual IPv4 addresses used by the hosts. It is cost effective and works for many scenarios where some sort of higher availability and/or failover is desired for these sites without the complication of BGP. All these configurations allow the remote site to have local Internet hop off without backhauling the traffic across WAN or VPN links back to the corporate office.
So the natural question that comes from this IPv4 topology solution is, how do I do this in IPv6?
The answer is not as clean and neat as many would like it to be but there are several options you can utilize. Let's cover each of them and go over their merits and shortcomings.
1. Use both IPv6 provider assigned address ranges in your remote branch location. Optionally use NPTv6 on the router(s) to handle failure scenarios of ISP's and to provider faster failover.
2. Use a single IPv6 provider assigned address range in your remote branch location. Use NPTv6 on the router(s) to handle failure scenarios of that primary ISP. Simplifies host address configuration.
3. Use VPN to extend your primary provider independent address space to the remote branch for routing. Optionally use NPTv6 on the router(s) to handle local Internet hop off. Simplifies host address configuration.
4. Use ULA in your branch location and use NPTv6 on the router(s) to direct traffic to the appropriate ISP. Simplifies host address configuration however complicates routing and global reachability.
5. Upgrade the site to use provider independent configuration and do BGP and run a single prefix that is routable. No NPTv6, no PA address space and highly available.
After describing these options I am often asked, which is the best? What configuration should be used? The first option almost everyone selects is 4 - it looks and feels like what they operate with IPv4 today. I can't blame anyone for picking that initially, especially given it familiarity. But I believe ULA should only be used in narrow situations with an eye on preferring global unicast address space at all times. After picking the option of global unicast address space the next sorting preference is provider independent address space. This is a tough one and for many is not a viable option due to a variety of reasons. Costs, operational skills to run BGP and slightly more complex routing configurations, hardware requirements, plus often it can be political. So, with a preference for global unicast, likely provider assigned address space where are we left? Options 1, 2 and 3 are all still possible. My next rule is to try and simplify host address configuration and try and make RFC 6724 as predictable as possible. This means preferring a single prefix from one service provider to address the site. Just like in IPv4 you will likely prefer a particular connection due to speed, cost or some other criteria that is dictated by business decisions. Use the address prefix that comes out of that decision and address the site. Use a VPN connection from the other ISP to connect the remote site back to your corporate via routing and set up NPTv6 if needed. This solution address almost all use cases and has the advantage of being predictable from a routing and topology basis.
If you have existing PI space from a regional registry like ARIN then consider extending the address space to the remote site via VPN. If you require local Internet hop off you can then enable NPTv6 and leverage that. Remember, NPTv6 brings all the penalties of potential protocol brokenness. There can be situations where certain applications and protocols will not function correctly so NPTv6 is an undesirable tool for that reason. This is one of the reasons that I avoid ULA and why making use of ULA is so far down my list. At least with a true global unicast address you can guarantee proper IPv6 functionality in all cases.
To make things even more challenging - there are very few NPTv6 (or older NAT66) implementations available. So those that think NAT and IPv6 is a happy future, think again.
I hope this helps clarify how I come to my design recommendations and why I think ULA is a poor option for many situations and how leveraging NPTv6 today will be a challenge.
- Ed
Howfunky...a place with useless technical content!
Showing posts with label ULA. Show all posts
Showing posts with label ULA. Show all posts
Wednesday, November 19, 2014
Sunday, December 08, 2013
Follow up to my IPv6 and ULA post plus some thoughts on design and IPv6 behavior
I've gotten some interesting comments and questions in regards to my IPv6 ULA (Unique Local Address) post and I wanted to outline the questions and then follow up with my thoughts and some high level design discussion.
The first question is around the situation of multiple ISP connections without using BGP and Provider Independent (PI) addresses or alternately switching from one ISP to another. The argument is pretty straightforward, you don't want to have to renumber your servers, network links and other infrastructure when changing ISP's because the IPv6 address space you have is allocated from that ISP. That IPv6 address space will no longer be yours when you change from ISP A to ISP B. So, alternately you can use ULA for your network, server and even client devices and only use that ISP IPv6 address space at the edge, similar to how you implement IPv4 today. This requires the use of some sort of NAT translation at the edge.
The second question is a bit of a refinement of the above that argues you should use ULA for all internal hosts and your LAN and WAN resources so you don't have to renumber if you change ISP's but also so you have a consistent address prefix preference for internal traffic to register with DNS.
I think those really are the main pro ULA arguments I have heard so far. Let's tackle the first part which is really all about flexibility in choosing and changing your ISP and reducing the IPv6 renumbering costs to a fractional degree. The second one I will cover in a different post.
The following diagrams shows the multiple ISP connection configuration which is no different than migrating from one ISP to another. We start with ISP A on the left and will be moving to ISP B on the right. Our initial network configuration will use ISP A's IPv6 Provider Assigned (PA) address block and our goal is the move to ISP B's IPv6 Provider Assigned (PA) address block. For a duration of time you will have both ISP A's and ISP B's IPv6 address blocks active on your network. The next diagrams (Figure 2 and 3) are what everyone thinks they want to deploy. It utilizes some sort of NAT technology at the Internet edge and assumes you will only use ULA for the "internal" network.
Figure 1. Dual connections while migrating service providers
Figure 2. ISP 1 with NAT66
Figure 3. ISP 2 with NAT66
The primary problem with the ULA solution people want is that there are no good production quality NPTv6 implementations out there to run on a firewall or edge Internet device today. This limits your ability to actually deploy that solution so you are left with NAT66 (not a good option in my opinion). Furthermore, NPTv6 still breaks many end to end features for applications relying on the underlying networking protocol not doing NAT. Application developers will still have to build NAT traversal mechanisms into their apps even though we were not supposed to need them with IPv6 at all. The only advantage you will gain is that with NPTv6 you have a stateless solution for NAT as only the prefix is actually changed. This reduces the amount of resources required on that Internet edge device greatly compared to the same solution with IPv4. An additional option is to go with NAT66 (which is available from some network manufactures) but which make IPv6 even more brittle and introduces every one of the NAT/PAT problems we have with IPv4 only on a much larger scale. I consider this solution a huge mistake and using it roles back all the progress and design work that the architects of IPv6 put into the protocol.
The slightly more difficult dual ISP PA migration (Figure 1) solution will actually work just fine without ULA. You will have to do some planning to do renumbering however depending on your design this could potentially be relatively easy. The most difficult resources to renumber would be your LAN and WAN infrastructure and your servers. Client devices should be dynamically obtaining their IP addresses (IPv4 or IPv6) and should not care greatly if their network address prefix changes over a weekend or even within the day. IPv6 has no issue with running both PA IPv6 prefixes at the same time nor does it require ULA to do this function. You might gain some time back on larger LAN and WAN networks on not having to renumber and this could be true for servers also however you will have to write additional firewall rules and you will still have to give them global unicast addresses if they need to talk to the public IPv6 Internet at all (remember, limited or no NPTv6 support today). This means you still have to touch the device to change it over from one IPv6 prefix to another. If it does not have the requirement for being able to get to the public Internet at all then there is a use case for using ULA. I see this as a secure network and I argued in the previous blog post that a secure network would be a legitimate use case for ULA.
ULA may buy you a small amount of stability in avoiding some address renumbering but I would argue that a proper DDI solution solves almost all the issues using DDNS and name to IP address resolution. What you gain from ULA to avoid renumbering you will likely have to pay back 10 fold in NAT traversal issues and pain.
A quick question, how often are people changing ISP's for small to medium sized businesses? I think some of the renumbering argument assumes this happens far more often than it does. For many medium to larger enterprise customers they will likely get Provider Independent IPv6 address space and utilize BGP to advertise to multiple ISP's at once (Figure 4). They do not require NPTv6 and even if they need local Internet hop off at a branch location they would simply deploy both PI and PA IPv6 prefixes at that site and let RFC 6724 solve the source/destination matching (Figure 5). They can gain more granular control of the routing behavior if they modify the prefix policy tables.
Figure 4. Dual homed IPv6 BGP peering
Figure 5. IPv6 PI and PA with local Internet hop off
As for those that are dual homing but not running BGP they do not require ULA or a NAT solution, simply run both IPv6 PA address space on the network (Figure 1) and let RFC 6724 solve the source/destination matching. If you want more control you can manage the prefix policy tables on your hosts or do some routing policy work within your network. Even so, if you are doing dual homed but no BGP you likely don't have a large enough network to care or bother with those efforts. Either way, I believe it is still simpler to use both service providers IPv6 PA space than to deal with ULA and NAT.
Thoughts? What other ways to you see ULA being an advantage over global unicast IPv6 addresses in your network?
- Ed
My book is available for pre-order on Amazon or you can order directly from the publisher Apress
The first question is around the situation of multiple ISP connections without using BGP and Provider Independent (PI) addresses or alternately switching from one ISP to another. The argument is pretty straightforward, you don't want to have to renumber your servers, network links and other infrastructure when changing ISP's because the IPv6 address space you have is allocated from that ISP. That IPv6 address space will no longer be yours when you change from ISP A to ISP B. So, alternately you can use ULA for your network, server and even client devices and only use that ISP IPv6 address space at the edge, similar to how you implement IPv4 today. This requires the use of some sort of NAT translation at the edge.
The second question is a bit of a refinement of the above that argues you should use ULA for all internal hosts and your LAN and WAN resources so you don't have to renumber if you change ISP's but also so you have a consistent address prefix preference for internal traffic to register with DNS.
I think those really are the main pro ULA arguments I have heard so far. Let's tackle the first part which is really all about flexibility in choosing and changing your ISP and reducing the IPv6 renumbering costs to a fractional degree. The second one I will cover in a different post.
The following diagrams shows the multiple ISP connection configuration which is no different than migrating from one ISP to another. We start with ISP A on the left and will be moving to ISP B on the right. Our initial network configuration will use ISP A's IPv6 Provider Assigned (PA) address block and our goal is the move to ISP B's IPv6 Provider Assigned (PA) address block. For a duration of time you will have both ISP A's and ISP B's IPv6 address blocks active on your network. The next diagrams (Figure 2 and 3) are what everyone thinks they want to deploy. It utilizes some sort of NAT technology at the Internet edge and assumes you will only use ULA for the "internal" network.
The primary problem with the ULA solution people want is that there are no good production quality NPTv6 implementations out there to run on a firewall or edge Internet device today. This limits your ability to actually deploy that solution so you are left with NAT66 (not a good option in my opinion). Furthermore, NPTv6 still breaks many end to end features for applications relying on the underlying networking protocol not doing NAT. Application developers will still have to build NAT traversal mechanisms into their apps even though we were not supposed to need them with IPv6 at all. The only advantage you will gain is that with NPTv6 you have a stateless solution for NAT as only the prefix is actually changed. This reduces the amount of resources required on that Internet edge device greatly compared to the same solution with IPv4. An additional option is to go with NAT66 (which is available from some network manufactures) but which make IPv6 even more brittle and introduces every one of the NAT/PAT problems we have with IPv4 only on a much larger scale. I consider this solution a huge mistake and using it roles back all the progress and design work that the architects of IPv6 put into the protocol.
The slightly more difficult dual ISP PA migration (Figure 1) solution will actually work just fine without ULA. You will have to do some planning to do renumbering however depending on your design this could potentially be relatively easy. The most difficult resources to renumber would be your LAN and WAN infrastructure and your servers. Client devices should be dynamically obtaining their IP addresses (IPv4 or IPv6) and should not care greatly if their network address prefix changes over a weekend or even within the day. IPv6 has no issue with running both PA IPv6 prefixes at the same time nor does it require ULA to do this function. You might gain some time back on larger LAN and WAN networks on not having to renumber and this could be true for servers also however you will have to write additional firewall rules and you will still have to give them global unicast addresses if they need to talk to the public IPv6 Internet at all (remember, limited or no NPTv6 support today). This means you still have to touch the device to change it over from one IPv6 prefix to another. If it does not have the requirement for being able to get to the public Internet at all then there is a use case for using ULA. I see this as a secure network and I argued in the previous blog post that a secure network would be a legitimate use case for ULA.
ULA may buy you a small amount of stability in avoiding some address renumbering but I would argue that a proper DDI solution solves almost all the issues using DDNS and name to IP address resolution. What you gain from ULA to avoid renumbering you will likely have to pay back 10 fold in NAT traversal issues and pain.
A quick question, how often are people changing ISP's for small to medium sized businesses? I think some of the renumbering argument assumes this happens far more often than it does. For many medium to larger enterprise customers they will likely get Provider Independent IPv6 address space and utilize BGP to advertise to multiple ISP's at once (Figure 4). They do not require NPTv6 and even if they need local Internet hop off at a branch location they would simply deploy both PI and PA IPv6 prefixes at that site and let RFC 6724 solve the source/destination matching (Figure 5). They can gain more granular control of the routing behavior if they modify the prefix policy tables.
Figure 5. IPv6 PI and PA with local Internet hop off
As for those that are dual homing but not running BGP they do not require ULA or a NAT solution, simply run both IPv6 PA address space on the network (Figure 1) and let RFC 6724 solve the source/destination matching. If you want more control you can manage the prefix policy tables on your hosts or do some routing policy work within your network. Even so, if you are doing dual homed but no BGP you likely don't have a large enough network to care or bother with those efforts. Either way, I believe it is still simpler to use both service providers IPv6 PA space than to deal with ULA and NAT.
Thoughts? What other ways to you see ULA being an advantage over global unicast IPv6 addresses in your network?
- Ed
My book is available for pre-order on Amazon or you can order directly from the publisher Apress
Subscribe to:
Posts (Atom)