7

As an organisation we've just requested our first IPv6 allocation. At present we are a wholly IPv4 organisation with a global IPv4 address allocation configured on our edge router and used (predominately) to NAT via an edge firewall to internally hosted web servers with private IPv4 addresses.

I appreciate that one way to make our external facing services available to the IPv6 internet would be to implement IPv6 dual-stack across the internal network and directly assign globally accessible IPv6 addresses (in addition to their existing IPv4 addresses) to those servers.

However, even after reading lots of posts and articles on IPv6 transition technologies and the pro's and con's of NAT in an IPv6 world I'm still not entirely sure whether we could essentially replicate our existing set-up but with IPv6 addresses, i.e. could we configure a globally routable IPv6 interface on our edge router with an associated IPv6 'external' interface on our firewall and simply 1:1 NAT globally facing IPv6 addresses to an IPv4 address?

This is obviously based on the principle that we have an IPv6 BGP peering arrangement with our ISP and that our internal addressing needs are met by RFC1918 but we'd like to make selected external services IPv6 accessible.

Matthew
  • 71
  • 1
  • 1
  • 2
  • 5
    You will eventually have to make your entire network IPv6, so you may as well plan for it now, instead of trying to do this Franken-network. – Michael Hampton Jan 09 '13 at 18:05

5 Answers5

5

As said in the first comment, I also strongly suggest moving to dual-stack, since, in the long run, it is cheaper than implementing NAT solutions. (You will have to do it anyway, so why not now?)

But still, for your problem, there are two possible solutions/workarounds:

  • a router with NAT64 support;
  • a load balancer with native IPv6 support, balancing servers behind it via IPv4.
TRiG
  • 1,181
  • 3
  • 13
  • 30
mulaz
  • 10,682
  • 1
  • 31
  • 37
2

That way of making IPv4 services available over IPv6 is quite common. You need a firewall that can do static NAT64 mappings. I have done it using Juniper SSG boxes myself.

I did see some issues with fragmentation though. Because an IPv6 header is bigger than an IPv4 header the conversion will make the packet slightly bigger. That might cause the IPv6 packet to be fragmented, and I have seen devices that ignore all fragmented traffic. To avoid problems with users that have such a broken device it is better to reduce the MTU on the IPv4 side a bit (1480 or 1400 are common values) so that even after the conversion the packet is smaller than 1500 bytes.

Sander Steffann
  • 7,712
  • 19
  • 29
  • IPv6 packets CANNOT be fragmented, IPv6 doesn't allow packet fragmentation. – Tomek Feb 25 '19 at 22:12
  • There is a mechanism for fragmenting ipv6 packets. It's only normally supposed to be done by the sending host, but NAT64 is kindof an exception. – Peter Green Feb 26 '19 at 01:41
  • @Tomek IPv6 packets can be fragmented, just not by a router on the path. The end nodes can fragment, and a NAT64 gateway can "simulate" an end node. – Sander Steffann Feb 26 '19 at 23:42
  • I believe the fragmentation on the sending node is involving PMTU and is done on higher OSI model levels (like in TCP or UDP), not in the IPv6 itself (please note that IPv4 has this capability built in, you can see fragments which do not carry TCP or UDP headers). And of course PMTU breaks when router operators disable/filter certain ICMP/ICMPv6 messages. As for NAT64 I guess it can be done but still I would question at what level. And of course it can happen below IPv6 itself but at this time it would also be transparent. – Tomek Feb 27 '19 at 07:27
  • @Tomek Fragmentation happens in IPv6 at layer 3, just like IPv4. The difference is that in IPv4 it is part of the IPv4 header while in IPv6 it is an extension header. But that is still layer 3. – Sander Steffann Feb 28 '19 at 08:36
  • Ok, I take that. I was short-circuiting "fragmentation" for "router/intermediate node fragmentation". Both are allowed in IPv4 (the latter - if not disabled by Don't Fragment bit), and only the first in IPv6. – Tomek Feb 28 '19 at 10:23
2

Can it be done?

Yes.

You will need a stateful NAT64 implementation. Normally these are used to provide local IPv6 clients with access to resources on the public IPv4 internet but there is nothing stopping you using one to allow IPv6 clients on the public internet to access local IPv4 resources. Firewalls can be used to limit what hosts can be accessed through the NAT64 gateway.

Should it be done?

In general I would say no.

The key problem with this approach is that you will lose information on the source IP address of the traffic. There is simply no way to cram a 128 bit source IP into a 32-bit field. So it will be hard to track down and report abuse.

What are the alternatives?

There are serveral. I will present them in what I consider to be decreasing order of preference.

The first option is to deploy dual stack on those segements of your network between the servers and the network edge. This is good practice for when you start deploying IPv6 throughout your network.

The second option is to deploy tunnels leading from your network edge to the servers in question. The tunnels can bring the ipv6 traffic over the IPv4 network to the servers which can then process it natively.

The third option is a reverse proxy. Since it works at the application level it can encode the external IP address information into an application level header. Application side changes may be needed to take advantage of this information but many applications will already support it as reverse proxy setups are quite common in large deployments for other reasons.

Peter Green
  • 4,211
  • 12
  • 30
  • Why would you lose information? The internet traffic would go to router over ipv6, with all the data, and the router's NAT, using ipv4, would do the translation to the correct LAN device. Or am I missing something? – IMTheNachoMan Feb 16 '19 at 02:31
  • 1
    The nat will have to replace the original source IPv6 address (and possibly port) with an IPv4 address (and possibly port) , since there are a lot less IPv4 addresses than IPv6 addresses the information about the original source IP cannot be preserved in this process. Knowing where incoming traffic came from is often important for abuse control (rate limiting and banning). – Peter Green Feb 16 '19 at 09:40
-3

Yup, Mem is totally right. Dual Stack and only on the public side of the network is a mandatory first step...that is the real holdup. That is to say nothing of ALSO being ready to just abandon IPv4.

NAT devices will do what they have always done. IPv6 provides private address space but there is no way to guarantee that it is globally unique...so we still need to NAT to guarantee that. Most people are still using NAT and will perpetually regardless of the impetus behind NAT decades ago. No critical need to foist IPv6 on anything inside your network that is under a NAT/SNAT using NAT444/CGNAT

This is a 2013 study done on IPv6 at the Government level. Echoes the timeline and guidance of just how far away the world is from IPv6 dominance and IPv4 abandonment, plus the whole intermediary dual -stack requirement that will have to last the entire duration of transition.

http://www.govtech.com/wireless/What-Happened-to-IPv6.html

When looking for devices to do this NAT look for support for NAT444/CG-NAT...This is not the same as NAT64,NAT44,etc

IPv4 will be here until the year 2148. Article below http://venturebeat.com/2013/06/07/at-our-current-rate-of-progress-ipv6-will-be-fully-implemented-on-may-10-2048/

Matt B
  • 1
  • 1
  • 1
    If you generated your ULA properly the chance of a collision is about 1 in 2^40, or vanishingly small. Compared to private addresses in IPv4, where collision is virtually guaranteed, it's a completely different scenario. I'm not terribly worried about a one in a trillion chance... – Michael Hampton Jan 13 '15 at 19:25
  • Depends on if you have abandoned NAT with IPv6. Not everyone is, just read up on CGNAT. With NAT collision is not possible by definition, regardless of the version of IP. Without NAT it is possible with IPv6 (or IPv4 for that matter). Small odds mean nothing to high end operators and service providers who have to handle 5, 6 and 7 9's of availability. It's pass/fail for "must be up services". Trusting the odds just doesn't cut it – Matt B Jan 13 '15 at 19:41
  • 1
    Yes, but that's _thirteen nines_. It's not a serious consideration at all (and would arise well before production anyway). And I sure as hell hope you've abandoned NAT with IPv6; the benefits are just too extensive to ignore. – Michael Hampton Jan 13 '15 at 19:43
  • What are the odds if someone maliciously tries to exploit this against a high profile network that is "trustfully" not using NAT with private IPv6. It just takes an ounce of social engineering, and inside contact with inside info, to overturn all that. That is why security through obscurity is no security at all – Matt B Jan 13 '15 at 19:48
  • 1
    In such a case NAT only obscures the origin of the attack, making analysis and response more difficult. The same as it does now. – Michael Hampton Jan 13 '15 at 19:54
  • @MattB NAT44 may be a possible workaround for some security problems, but the NAT also introduce some security problems. NAT66 can be slightly more secure than NAT44, but a properly configured firewall without NAT is more secure than NAT66. – kasperd Jan 13 '15 at 20:03
  • @kasperd. NAT is not the enemy or intrinsically flawed. Sure people can blame their network problems on NAT, but really the root cause is not NAT by definition, but poorly designed networks. Again, there will always be NAT. Just take a loadbalancer that is publishing an IPv6 address to the internet with dozens of servers behind it. Guess what...it is going to NAT to those internal servers...even if its IPv6 to IPv6. It is like saying IPv6 makes MPLS obsolete...just doesn't make sense – Matt B Jan 13 '15 at 20:43
  • @MattB I have seen too many problems caused by NAT to believe what you are saying. Load balancing is different. It doesn't even have to involve NAT. DSR load balancing is more efficient, eliminates the need for injecting client IP in headers, and doesn't need any NAT. – kasperd Jan 13 '15 at 21:00
  • @kasperd Ok, I dont know what problems with NAT you have seen. I just don't believe that the true root cause wasn't an ill-conceived network design. Regarding DSR load balancing...no way. You can't even do cookie insertion,application acceleration, or even port address translation. Those are all show stoppers for DSR. So back to NAT/PAT for the win regardless of what IP version you are using if you need serious high-end load balancing without giving up basic application functionality https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return – Matt B Jan 13 '15 at 21:37
  • The last link in your answer is assuming that growth is linear. That is a flawed assumption. I took the percentage of IPv6 usage as published by Google from the 1. of January from 2009 to 2015 and tried fitting it to a linear growth and to a logistic growth. As expected the logistic growth is a much better match. And according to that fitting we'll see IPv6 deployment reach 50% of the users by mid 2018. – kasperd Jan 13 '15 at 22:25
  • Kasperd-please realize, those stats are not counting whats happening on the internet as a whole . Its only tracking whats on the external network of *google users* only. Not really a useful comparison. If you do further research you'll find less than 1% of organisations have IPv6 deployed end to end. And you will find that most of that "google IPv6" traffic is mobile phone traffic...meaning the Carriers (Verizon/ATT) are using CG-NAT while having literally hundreds of millions of IPv4 phones behind them. You should know 2018 is not realistic. Feel free to keep the rosy shades on though... – Matt B Jan 14 '15 at 00:14
  • @MattB I consider the statistics provided by Google to be more trustworthy than any of the information you have provided so far. Moreover multiple of your claims directly contradict my personal experience. I hope you understand why this makes it very hard for me to take your claims serious. You should know that logistic growth is more realistic than linear growth. There is nothing unrealistic about the growth rate predicted by the logistic model. Some countries have exceeded that growth rate already. I'll leave this discussion now and be back in 2018. – kasperd Jan 14 '15 at 01:03
-5

Yes, of course you can. In fact that is the wisest thing to do.

Don't believe people who say "Oh....you will HAVE to change your entire network to Ipv6 eventually, so dont delay"

Utter nonsense.

I have been through this at the carrier-grade level.

IPv4 is here to stay. It works just fine for the vast majority of organizations, because of RFC1918.

If you are an organization with less than 17 millions devices requiring IP addresses under your direct legal control. Then IPv6 will be little more than a speedbump and it certainly won't affect your servers/desktops. Here is how you do it:
Assuming you understand classical network design.

Your Edge routers go MPLS/IPv6/IPv4
Your Core rouers go MPLS/IPv6/IPv4
Your Distro routers go MPLS/IPv6/IPv4
Your Loadbalancer/Firewalls external interfaces are IPv6/IPv4 and plug upstream into the Distro. F5 supports this quite honestly effortlessly and the LTM as an ingress firewall (way faster than juni/cisco firewalls) so we dont have to use ACLS on the Distro routers The internal interfaces of the Loadbalancer/Firewall are all pure IPv4 and plug into your spine/leaf or your layer 2 service/access routers and switches which also all stay IPv4 if they are even layer 3.

So you keep NAT. You maintain a hard publicIP/privateIP NAT border with the devices like F5 BIGIP's and Firewalls that effortlessly handle IPv6 to IPv4 NAT. They bridge your public distro layer with your private service/access layer.

Now everything you choose to keep NAT'd (which probably already is) stays IPv4 and all that crap IPv6 host software can be deleted with impunity because only your high end network gear running on the public edge of yoru network has to worry about IPv6

Seriously, be wise. IPv6 is not overtaking IPv4 in our lifetimes in any way that means something. At this current rate of adoption it wont ready parity with the IPv4 BGP tables in terms of size for 200 more years.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Mem
  • 27
  • 2
    NAT is a kludge that broke end-to-end connectivity. Because of it we have to use further kludges like ssh jump boxes, Nagios proxies, SIP proxies, STUN, and many other things, just to get basic connectivity, and all of those have their drawbacks, such as being a royal pain to manage and work with. But this is supposed to be a good thing?! – Michael Hampton Jan 13 '15 at 19:35
  • 1
    That was all there was to it in the 90s, when end-to-end connectivity for every device was a wet dream. This day and age NAT is pretty much the only reason such a relatively small percentage of consumer devices are zombies. IPv6 does way more than just solve the problem at hand - I find its complexity unnecessary, but that's opinion. I imagine it being very convenient at the carrier level, and probably just a minor headache for larger organizations who employ IT professionals. Below that, large scale NAT retirement will reduce DDoS prices to pennies. Wait for it. – Mantriur Mar 15 '16 at 21:44