8

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.

Improve this question
1
  • 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 9, 2013 at 18:05

5 Answers 5

Reset to default
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.
Improve this answer
1
  • Why would someone have to run IPv6 internally, and if so, on what time frame do you have in mind for when they would have to do that?
    – user1809090
    Feb 13 at 21:17
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.

Improve this answer
6
  • IPv6 packets CANNOT be fragmented, IPv6 doesn't allow packet fragmentation.
    – Tomek
    Feb 25, 2019 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, 2019 at 1: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, 2019 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, 2019 at 7: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, 2019 at 8:36
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.

Improve this answer
2
  • 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, 2019 at 2: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, 2019 at 9: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/

Improve this answer
12
  • 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, 2015 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, 2015 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, 2015 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, 2015 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, 2015 at 19:54
-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.

Improve this answer
2
  • 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, 2015 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, 2016 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .