Build your own IPv6 lab on the cheap, part 2

Note: This is part two of two; the first part was posted last week.

Last week, we took a look at how to make the transition from IPv4 to IPv6 using nothing but standard equipment you probably already own. This week, you can wrap up your project with the details below.

Building an IPv6 tunnel

Since your ISP almost definitely doesn’t deliver IPv6 yet, you’ll need to build a tunnel across the IPv4 Internet to someone who can gateway you onto the IPv6 Internet. In this case, I used Hurricane Electric’s free IPv6 tunnel broker service. You’ll need to sign up for an account (a fairly painless process) before you can create a new tunnel.

To do that, you’ll need to know the outside interface IP of the router. If you create the tunnel from behind the firewall, the Create Tunnel dialog will tell you the originating IP. If not, you can run show interfaces ethernet to see what IP your ISP has doled out.

If you want, you can choose a specific POP to which to route your tunnel, but Hurricane Electric’s service does a pretty good job of telling you where you’re coming from and which of its POP options might be the fastest for you. Once you hit submit, Hurricane Electric will ping your IPv4 tunnel endpoint to ensure it’s available (which is why you allowed ICMP echo requests in the “out-local” rule earlier), then it will dump out all of the information you’ll need to configure your end of the tunnel.

The Tunnel Details dialog even goes so far as to provide you with a personalized example configuration. Choose Vyatta from the drop-down box and hit Show Config. You should get a ready-made chunk of configuration that looks like this:

configure

edit interfaces tunnel tun0

set encapsulation sit

set local-ip X.X.X.X

set remote-ip 209.51.161.14

set address 2001:470: XXXX:XXXX::2/64

set description "HE.NET IPv6 Tunnel"

exit

set protocols static interface-route6 ::/0 next-hop-interface tun0

commit

That block uses slightly different modal notation from what I’ve shown in my examples so far. It is effectively a version that’s easier to hand-type (along with the necessary configure and commit statements):

set interfaces tunnel tun0 encapsulation 'sit'

set interfaces tunnel tun0 local-ip 'X.X.X.X'

set interfaces tunnel tun0 remote-ip '209.51.161.14'

set interfaces tunnel tun0 address '2001:470: XXXX:XXXX::2/64'

set interfaces tunnel tun0 description 'HE.NET IPv6 Tunnel'

set protocols static interface-route6 ::/0 next-hop-interface 'tun0'

Essentially what that does is creates a new IPv6 tunnel interface (tun0), configures its local and remote endpoints, sets the local IPv6 address of your end of that tunnel, and issues an IPv6 default route that points to the other end of the tunnel.

One critical note: This block of configuration does not filter any traffic passing over that tunnel. If you hit Commit at the end of the given block, you’ve opened the outside interface of your router to any and all IPv6 traffic from anywhere.

For a very long time, everyone has been very accustomed to using NAT to hide their internally addressed networks (courtesy of RFC1918 address blocks such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, for example). The real reason for this: It’d be impractical to use external addressing for every network — we would have been out of address space years ago. However, as a side effect, you can’t directly reach internal hosts from the outside unless you specifically poke a hole in your firewall by implementing an external-to-internal NAT translation.

That’s one of the first basic lessons to learn about IPv6. There is no NAT in the IPv6 standard because there’s no need for it — the address space consumption issues present in IPv4 simply don’t exist in IPv6. As a consequence, any internal IPv6 hosts you have are directly accessible by their “real” addresses unless you put in rules to block the traffic.

That’s the next job. First, a rule to control access to the tun0 interface on the router itself (again, allowing ICMP so that we can ping it from the outside):

set firewall ipv6-name tun-local default-action 'drop'

set firewall ipv6-name tun-local description 'IPv6 Traffic To Router'

set firewall ipv6-name tun-local rule 10 action 'accept'

set firewall ipv6-name tun-local rule 10 description 'Accept Established-Related'

set firewall ipv6-name tun-local rule 10 state established 'enable'

set firewall ipv6-name tun-local rule 10 state related 'enable'

set firewall ipv6-name tun-local rule 15 action 'accept'

set firewall ipv6-name tun-local rule 15 description 'Accept ICMP Echo'

set firewall ipv6-name tun-local rule 15 icmpv6 type 'echo-request'

set firewall ipv6-name tun-local rule 15 protocol 'ipv6-icmp'

And another to allow answers to flow back to the inside from the outside:

set firewall ipv6-name tun-in description 'IPv6 Traffic To Internal'

 

set firewall ipv6-name tun-in rule 10 action 'accept'

set firewall ipv6-name tun-in rule 10 description 'Accept Established-Related'

set firewall ipv6-name tun-in rule 10 state established 'enable'

set firewall ipv6-name tun-in rule 10 state related 'enable'

Then apply both of these rules to the tun0 interface:

set interfaces tunnel tun0 firewall in ipv6-name 'tun-in'

set interfaces tunnel tun0 firewall local ipv6-name 'tun-local'

set firewall ipv6-name tun-in default-action 'drop'

At this point, you should be able to ping from the router out to the other end of the IPv6 tunnel (this IPv6 IP will be listed in the Hurricane Electric Tunnel Details dialog next to Server IPv6 Address):

ping6 2001:470:XXXX:XXXX::1

If you get replies, you’ve done well up to this point.

Configuring the internal network for IPv6

The next task is to get IPv6 running on the inside interface. As I mentioned earlier, there is no NAT in IPv6; if you want to route traffic into a separate IPv6 subnet behind your router, you’ll need a block of publicly routable IPs.

Fortunately, there are literally trillions upon trillions of them, so there’ s no problem getting them allocated. In the Hurricane Electric Tunnel Details dialog, you’ll see that the provider has already routed a /64 network across your pipe in addition to the /64 it gave you for the tunnel itself. There’s also a link in the lower half of the screen that reads “Allocate /48,” which allows you to cut a larger network for yourself (a /48 is 65,536 /64s).

In general, most IPv6 host networks will consist of 64 bits of network space (exactly half of the total 128-bit address). That’s a huge amount of space — enough for about 18 quintillion hosts. Obviously, you’d never have that many hosts on one network together, but it leaves enough space for hosts to be able to freely auto-generate their own addresses and never risk overlapping with another host.

If you want to be able to field more than one /64 network (say, to support a DMZ on a third Ethernet interface), you’ll need a larger allocation. If you’re just looking to provide address space for the inside (eth1) network on your router, the /64 is perfect and you won’t need to allocate a /48.

Using the pre-allocated /64 you’ll find in the Tunnel Details dialog next to “Routed /64,” you can address the eth1 interface of your router:

set interfaces ethernet eth1 address '2001:470:XXXX:XXXX::1/64'

Next, you’ll want to configure your router to advertise itself so that IPv6 hosts on your network can autoconfigure themselves to match the configuration of your router:

set interfaces ethernet eth1 ipv6 router-advert prefix '2001:470:XXXX:XXXX::/64'

set interfaces ethernet eth1 ipv6 router-advert send-advert 'true'

After you commit those two sections to the configuration, any IPv6-enabled host on your network will automatically address themselves within that network block and be ready to access the internet via IPv6. If you’re using Microsoft Windows Vista or Windows 7 and haven’t disabled IPv6, you’ll almost immediately see the “new network” dialog pop up. Testing should be as simple as hitting a known IPv6-only site. If you can get there, you’re good to go. You’re now running a basic, dual-stack IPv4/IPv6 network.

Other projects

After you’re all set up, you can keep busy with a number of other projects. For example, if you have a few NICs you can toss into your router or a switch that’s capable of VLAN tagging, you can allocate a /48 for your tunnel and carve out extra networks and configure routing and firewalling between them. Hurricane Electric has a great set of “certifications” that you can register for and attempt to complete — many of which will require you to set up various servers (mail, DNS, and so on) on your IPv6 space and make them accessible to the IPv6 Internet.

If you get the time to do it, running through this process will bring you up to speed and give you the basic tools you’ll need to survive in a post-IPv4 world. Instead of lagging behind the curve when the IPv6 hammer falls, you’ll be ready.

This article, “Build your own IPv6 lab on the cheap, part 2,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.