• Home
• News
• About FireBrick
• Products

• FireBrick FB2900
• FireBrick FB6000

• Legacy Products
• Buy FireBrick
• Contact Us
• Support
• Reseller Area
• Press Information

FireBrick FB6000

IPv4, IPv6 and NAT

This page explains some of the issues of IPv4, IPv6 and NAT, and how you can use the FireBrick

IPv4 (legacy internet protocol)

The first widely deployed internet protocol is Internet Protocol version 4 (IPv4). It has been in use for decades, but long ago it was realised that the address space was not big enough. IPv4 has 3.5 billion addresses available for devices. There are more mobile phones than that!

IPv4 addresses are 4 decimal numbers with dots, e.g. 193.17.12.1

IPv6 (current internet protocol)

IPv6 is the current internet protocol version. It was developed in the last millennium and the main practical difference from IPv4 is that it has more addresses. IPv6 has over 300 trillion trillion trillion addresses.

IPv6 has been available from some internet providers for a long time, but until recently has suffered from chicken and egg problems. People are not deploying IPv6 services (like web sites) as so few users have IPv6. Users are not asking for IPv6 as no few IPv6 services are available. However, 2011 is the year of IPv6 because IPv4 addresses have finally run out. This means IPv4 addresses will become harder to get, and expensive, over the coming years. In the face of this people are finally making IPv6 happen on a larger scale.

IPv6 addresses are up to 8 blocks of hexadecimal separated by colons. A double colon can be used where there are less than 8 blocks shown and the missing blocks are zero. e.g. 2001:DB8::1

Dual stack

It is important to realise that you do not have to decide IPv4 or IPv6. The practical way to address the change to IPv6 is to have both IPv4 and IPv6 at once. All common operating systems can do this. ISPs providing IPv6 also provide IPv4. This allows you to continue to access the legacy IPv4 internet and the newer IPv6 internet at the same time. If you have your machine and network set up with dual stack then this is just sorted automatically by applications (such as web browsers) without you having to care about it.

NAT (Network Address Translation)

One of the reasons IPv4 has lasted so long is the use of NAT. Whilst there are many ways to map IP addresses and ports, NAT is typically deployed on end user routers. The router gets one real IP address and allows private IP addresses on a LAN to share that one address. This works, but there are problems. As IPv4 addresses become rarer we will see multiple levels of NAT and internet providers running NAT within their networks as well.

In order to allow this sharing, the router doing NAT has to track sessions (just like the FireBrick firewall does), and allocate temporary port numbers when it changes the IP address between the private IP and real IP. Of course, new incoming connections have nowhere to go (i.e. to which private address should they be mapped). This has the side effect of providing a level of firewall for NAT connected networks. It is not a very flexible firewall, and there are various tricks to bypass the firewall effects of NAT from the inside. It is important not to confuse NAT with a firewall. Any firewalling effect of NAT is a byproduct.

NAT works well where there are services using specific protocols such as TCP using a single outgoing connection. This applies to services like web page access, and collecting and sending emails and indeed many of the things typical internet users want.

NAT does not work well with anything else. Some routers are really clever at providing application level gateways (ALGs) to translate protocols to work well using NAT. Different routers have different levels of ALG support, and each new protocol could need a new ALG in the router. Some newer protocols are designed to work over NAT.

NAT is evil

NAT may seem like a good idea but it is really not. Internet protocol is designed around the idea that every endpoint on the global network has a unique routeable IP address. Yes, you may have firewalls, but the routing and addressing principles are part of the basic design of IP. NAT breaks those rules. So what? Well, it creates problems. Any new protocol developed has to work around NAT, but exactly what devices will do or not do when they NAT is not defined and varies - so they have to work on the lowest common denominator. NAT seriously stifles innovation and development of new protocols. Yes, the internet could have been designed around NAT like principles in the first place, but it was not.

But you do not have to take our word for it - even people like RIPE (The EU regional internet registry) speak out against NAT. This is in spite of the fact that they are the people that have the job of allocating the dwindling number of IPv4 addresses that remain to the ISPs. They recognise that NAT does not help. All it has done is delay IPv6 deployment.

Fortunately IPv6 does not need NAT. There are plenty of IP addresses. There are perfectly good firewalls. NAT should never be used on IPv6. The FireBrick provides a platform to help deployment of IPv6 within your network, whether you are an ISP or a home user, even if your IPv4 ends up using NAT.

NAT-PMP / PCP

Protocols exists to allow devices on a LAN, behind NAT or a firewall, to request holes in the firewall and forward port mapping. Older protocols like uPnP are not supported but the Firebrick supports NAT-PMP and PCP protocols.

To use these you enable them on a per interface basis. Once enabled they allow mapping of IP addresses. However, these mapped sessions are still subject to firewall rules, so default incoming firewalling prevents any traffic passing unless exceptions are made. These exceptions can test against the mapped target (i.e. private) IP address, and also test if NAT-PMP/PCP was applied or not when deciding to allow or deny the session.

Using FireBricks with IPv6

Most other equipment has required IPv6 to be bolted on, but the current FireBrick operating system was re-designed from scratch to support IPv6. There are some aspects that are IPv4 or IPv6 specific because of the way the protocols work, but in general you can simply use IPv4 or IPv6 addresses wherever you need. You do not need separate commands for each.

Native IPv6 on Ethernet

The <subnet.../> definition can take any mix of IPv4 and/or IPv6 addresses in the ip="..." attribute. E.g. <subnet ip="10.0.0.1/24 2001:DB8:1:2::1/64"/> defines an IPv4 and IPv6 subnet. Note that IPv6 subnets are normally /64 (64 bit network address and 64 bit host address).

You can also define a gateway as an IPv6 address in the subnet or route objects.

The <interface.../> also allows you to set ra="true" which means that on that interface any route announcements that are seen cause the FireBrick to pick an address and gateway automatically.

The <subnet.../> also allows you to set ra="true" which means the FireBrick will send out route announcements to tell other machines on your network the IPv6 address to use and to use the FireBrick as a gateway. You can also set IPv6 DNS server parameters.

Native IPv6 over PPP

L2TP (ISP end) can allow routing of blocks of IPv6 addresses down the link in the same way as IPv4 address blocks, using RADIUS. This allows the ISP to provide IPv6 natively over PPP.

PPPoE (customer end) can negotiate IPv6 support on the PPP link and will set the default route for IPv6, or allow specific IP6 routes to be defined.

There is no PPP prefix delegation, so you will need to set up your IPv6 LAN when using PPPoE to match the block being routed by the ISP.

Tunneled IPv6

L2TP can also support IPv6 routing via a tunnel to an IPv4 address down the PPP link, and this can be set using RADIUS. This allows an ISP to provide IPv6 where the end user equipment cannot handle IPv6 natively over PPP.

To manually route an IPv6 block tunnelled via an IPv4 endpoint, just use a route for IPv6 with an IPv4 gateway. E.g. <route ip="::/0" gateway="192.88.99.1"/> will make a default route for IPv6 (::/0) via an IPv4 endpoint (192.88.99.1).

IPv6 when your ISP does not support it

IPv6 allows an automatic tunnelling of blocks of IPv6 space to an IPv4 endpoint. The system works by using addresses starting 2002: with the next 4 bytes being the IPv4 address.

This means there is a huge block of IPv6 address space routed to every IPv4 address. To make use of it you just need (a) to set up the prefix on your LAN matching the WAN IPv4 address you have and (b) set up a default route to send outgoing IPv6 traffic to a public IP6/4 gateway. This will not work if your WAN link is via an IPv4 NAT, but will work using PPPoE and an external (fixed) public address.

E.g. if your IPv4 address on the WAN address is 193.17.12.123 then you simply create the IPv6 subnet for this on your LAN, e.g. <subnet ip="2002:C111:C7B::1/64" ra="true"/> where C1 is hex for 193, 11 is hex for 17, C is hex for 12, and 7B is hex for 123. This makes your LAN have a block of IPv6 addresses, and advertises it to other machines on the LAN.

You then just need a route to the internet, e.g. <route ip="::/0" gateway="192.88.99.1"/> which sends to the gateway 192.88.99.1 which is a public anycast IPv6/4 gateway.

NAT and ALGs

The FireBrick has a comprehensive support for IP and port mapping. It even allows mapping of IPv6 to IPv4 addresses. You can set up NAT using a <rule-set.../> that has set-nat="true".

The FireBrick provides simple mapping for TCP and UDP and ICMP protocols, with configurable session timeouts. It does not provide any application level gateway (ALGs) to assist NAT. There are no plans to add ALGs to FireBrick as IPv6 removes the need for NAT or ALGs. As such, if you find you need ALGs, you should consider how you can deploy IPv6 and avoid NAT in the first place.