I've written previous posts on NPTv6 but it seems I didn't do a particularly good job explaining the different between NPTv6 and NAT66 and there is still a lot of confusion understanding what the actual difference is between the two. While both are doing network translation they are doing it differently.
The difference is pretty simple. NAT66 performs the same function we have with NAT44. It is a stateful network address translation on a router or firewall. It will take an IPv6 address on one network interface and translate it to a new IPv6 address on the other network interface and forward the packet. It may perform some sort of application fix up to keep certain protocols and applications from having problems. It requires resources (CPU and memory) on the router or firewall to do this and the returning traffic will have to come through the same device because it is keeping a state table of all the translations it is performing.
NPTv6 is different then NAT66 in that only the leftmost prefix portions of the address are translated. This means that the device doing this translation do not need to keep state at all. So NPTv6 is stateless and therefore in theory can scale better and also be distributed across many devices doing the same function (regardless of forwarding changes and asymmetrical routing). The internal prefix and the external prefix sizes must match so if you want to use NPTv6 you need to do some work to make sure things match up. In other words, your internal network may have a /64 ULA prefix that you want to use NPTv6 to give it access to the IPv6 Internet. You will need a /64 of global unicast address space to allow the router or firewall to do the NPTv6 function with. If you have a /48 internally that you want to use NPTv6 with then you will require a /48 for that externally.
There are some minor variations of these two. NAT66 can, in theory also provide PAT functions allowing the overload of a single IPv6 address by multiple IPv6 addresses behind it. This really is not needed with IPv6 at all as there are more than enough IPv6 addresses to go around. In theory SLB64 looks like NAT66 because it is providing a shared VIP to access a resource and translating traffic appropriately.
As a general rule of thumb, those in the IPv6 community see NPTv6 as a potential tool to solve some corner case issues and they see NAT66 as not desirable. There really is no reason to run NAT66 and if you do require any sort of NAT function then you should be using NPTv6. Unless we want to repeat all the mistakes we have made with NAT44 over the years (and now NAT444 with CGN solutions) then adopting NAT66 is a poor choice.
Obviously this debate is ongoing and it could end up that NAT66 ends up winning but I am hopeful that won't be the case.
- Ed
Howfunky...a place with useless technical content!
Showing posts with label NAT66. Show all posts
Showing posts with label NAT66. Show all posts
Tuesday, December 10, 2013
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
Tuesday, February 14, 2012
IPv6 to IPv6 Network Prefix Translation or NPTv6
I was reading through some comments on reddit about NAT66 or RFC 6296 which is really NPTv6 and I realized that universally there seems to be a misunderstanding of why NPTv6 is needed, when you would use it and that it was intended to only address the needs of those use cases and not to emulate what is happening in IPv4 today.
Credit should be given to far smarter folks than I on this topic, specifically Dan Wing with Cisco who first explained NAT66 to a lot of folks (notice he is presenting on how to avoid having to do NAT66) and who also authored the Happy Eyeballs draft RFC which should pop out of draft here shortly. Dan is soft spoken but I'll call out that he is the co-chair of the IETF Behave (Behavior Engineering for Hindrance Avoidance) working group along with Dave Thaler from Microsoft. Obviously Fred Baker and Margaret Wasserman for authoring the RFC though I haven't been lucky enough to chat with either of them about it, though I hope to do so, opportunity permitting.
Okay, on to NPTv6.
So what is NPTv6? NPTv6 is simply rewriting IPv6 prefixes. If your current IPv6 prefix is 2001:db8:cafe::/48 then using NPTv6 it would allow you to change it to 2001:db8:fea7::/48 - that is it. It is a one for one prefix rewrite - you can't overload it, have mismatching prefix allocations sizes, re-write ports or anything else. Importantly, it doesn't touch anything other than the prefix. Your network/host portion remains intact with no changes.
So what is NPTv6 not? It is not for sharing IPv6 addresses, it is not for port overloading and it is not stateful.
Now that we have the ground rules set lets talk about the use cases that NPTv6 was brought about to address. Fundamentally NPTv6 addresses deficiencies in current host behavior and the lack of support for source address selection, next-hop route selection and split-zone DNS. The most common use case condition will be to fix source address selection issues for home and SMB's that have two providers (for whatever reason, redundancy, walled garden services like VOIP or IPTV, etc.) For almost all Enterprises this is not an issue as they will obtain Provider Independent (PI) IPv6 space and dual home properly. They might have to deal with split-zone DNS but I will address that in another post.
What happens when you have two Global Unicast Addresses (GUA) on the same interface? To clarify, not two interfaces each with a GUA. The host has to make a decision about which interface to use yet it knows nothing about how routing works within the network and therefore likely uses RFC 3484 to determine what to do. There are already many issues with host behavior outlined in RFC 5220 so go read that to get a good idea of some of the challenges.
Lets go over a sample practical use case to show where NPTv6 might help your home dual provider situation. This is an example - the prefixes are unnaturally large for an SMB or home user and I will update the diagrams later to properly reflect potential prefixes you would get in a real world situation. Regardless, it is sufficient to show the issue.
Source Address Selection Diagram - the problem:
The solution for the home user or SMB is to remove the multiple IPv6 GUA configuration and use a single IPv6 GUA address on the interface. Once this is done then you end up with proper traffic flow.
Source Address Selection Diagram - the fix case 1:
In the above diagram the host only has a single GUA to source traffic from and therefore selects it to send a request to a server, in this case 2001:db8:f000::1. Notice that the host forwards the traffic to RTR A which is it's default gateway. RTR A then forwards the traffic outbound and everything works as expected.
Source Address Selection Diagram - the fix case 2:
In the above diagram the host only has a single GUA to source traffic
from and therefore selects it to send a request to a server, in this
case 2001:db8:ff00::b. Notice that the host forwards the traffic to RTR A
which is it's default gateway. RTR A then forwards the traffic to RTR B because a static route assignment has been entered for a longer specific prefix in this case. RTR B receives the traffic and because it has NPTv6 set up it realizes it has a prefix match and must do a prefix replacement prior to forwarding the traffic upstream. RTR B then forwards the traffic outbound and everything works as expected.
So realistically, how do we avoid all this in the first place? The only way is for the host to gain more intelligence in making decisions about what source interface address to select. Some sort of policy control would have to happen on the host OS. Alternatively, all hosts could participate in some sort of routing to determine proper paths and hold a route forwarding table. I don't really see that as a viable alternative in many environments today.
In other words, there is little a network engineers can do to fix this problem. It really is an OS host issue and if network engineers really want NAT to go away fully in IPv6 then we have to beg and plead to get a fix done in all the major OS platforms. It also brings to light one of the biggest changes between IPv4 and IPv6, a host can have multiple IPv6 addresses per interface. Somehow we need to get routing information onto the host.
So, is NPTv6 desirable from an IPv6 perspective? I would argue no, I would prefer that my host selected the correct source address and everything just worked. The problem is that it doesn't work that way today and for the foreseeable future it doesn't look promising. So NPTv6 is a necessary evil to address some of these corner case condition of getting IPv6 deployed widely on the Internet today.
- Ed
Credit should be given to far smarter folks than I on this topic, specifically Dan Wing with Cisco who first explained NAT66 to a lot of folks (notice he is presenting on how to avoid having to do NAT66) and who also authored the Happy Eyeballs draft RFC which should pop out of draft here shortly. Dan is soft spoken but I'll call out that he is the co-chair of the IETF Behave (Behavior Engineering for Hindrance Avoidance) working group along with Dave Thaler from Microsoft. Obviously Fred Baker and Margaret Wasserman for authoring the RFC though I haven't been lucky enough to chat with either of them about it, though I hope to do so, opportunity permitting.
Okay, on to NPTv6.
So what is NPTv6? NPTv6 is simply rewriting IPv6 prefixes. If your current IPv6 prefix is 2001:db8:cafe::/48 then using NPTv6 it would allow you to change it to 2001:db8:fea7::/48 - that is it. It is a one for one prefix rewrite - you can't overload it, have mismatching prefix allocations sizes, re-write ports or anything else. Importantly, it doesn't touch anything other than the prefix. Your network/host portion remains intact with no changes.
So what is NPTv6 not? It is not for sharing IPv6 addresses, it is not for port overloading and it is not stateful.
Now that we have the ground rules set lets talk about the use cases that NPTv6 was brought about to address. Fundamentally NPTv6 addresses deficiencies in current host behavior and the lack of support for source address selection, next-hop route selection and split-zone DNS. The most common use case condition will be to fix source address selection issues for home and SMB's that have two providers (for whatever reason, redundancy, walled garden services like VOIP or IPTV, etc.) For almost all Enterprises this is not an issue as they will obtain Provider Independent (PI) IPv6 space and dual home properly. They might have to deal with split-zone DNS but I will address that in another post.
What happens when you have two Global Unicast Addresses (GUA) on the same interface? To clarify, not two interfaces each with a GUA. The host has to make a decision about which interface to use yet it knows nothing about how routing works within the network and therefore likely uses RFC 3484 to determine what to do. There are already many issues with host behavior outlined in RFC 5220 so go read that to get a good idea of some of the challenges.
Lets go over a sample practical use case to show where NPTv6 might help your home dual provider situation. This is an example - the prefixes are unnaturally large for an SMB or home user and I will update the diagrams later to properly reflect potential prefixes you would get in a real world situation. Regardless, it is sufficient to show the issue.
Source Address Selection Diagram - the problem:
The solution for the home user or SMB is to remove the multiple IPv6 GUA configuration and use a single IPv6 GUA address on the interface. Once this is done then you end up with proper traffic flow.
Source Address Selection Diagram - the fix case 1:
Source Address Selection Diagram - the fix case 2:
So realistically, how do we avoid all this in the first place? The only way is for the host to gain more intelligence in making decisions about what source interface address to select. Some sort of policy control would have to happen on the host OS. Alternatively, all hosts could participate in some sort of routing to determine proper paths and hold a route forwarding table. I don't really see that as a viable alternative in many environments today.
In other words, there is little a network engineers can do to fix this problem. It really is an OS host issue and if network engineers really want NAT to go away fully in IPv6 then we have to beg and plead to get a fix done in all the major OS platforms. It also brings to light one of the biggest changes between IPv4 and IPv6, a host can have multiple IPv6 addresses per interface. Somehow we need to get routing information onto the host.
So, is NPTv6 desirable from an IPv6 perspective? I would argue no, I would prefer that my host selected the correct source address and everything just worked. The problem is that it doesn't work that way today and for the foreseeable future it doesn't look promising. So NPTv6 is a necessary evil to address some of these corner case condition of getting IPv6 deployed widely on the Internet today.
- Ed
Subscribe to:
Posts (Atom)