3

I'd like to set up an IPv6-in-IPv4 SIT tunnel server. I've combed through the Ubuntu IPv6 wiki page but everything is geared towards connecting to a tunnel as a client, rather than hosting one. I'd like to use 6in4 as it's quite simple/versatile and seems to negotiate most home routers/firewalls without issue.

This will be primarily used by our sysadmin staff to access IPv6 from home on DSL/Cable connections that don't natively support it. The reason I'd like to run this myself is twofold:

  1. I find the likes of Hurricane Electric tunnels to be quite slow and occasionally unreliable.
  2. I don't like the idea of our traffic going off through HE's network. We have our own core transit network and IPv6 allocation from RIPE so we may as well make use of it!

This would be used by 5-10 users simultaneously.

Equipment I have at my disposal that could be used as a host:

  • Cisco ISRs
  • Cisco ASAs
  • Juniper MXs
  • Linux/Windows servers (Ideally would be Ubuntu)

Thanks in advance.

SimonJGreen
  • 3,205
  • 5
  • 33
  • 55
  • Do you really want your employees' _home_ networks suddenly dropped smack in the middle of your _work_ network? Also, 6in4 has absolutely _no_ security and doesn't go through NAT quite as well as you think. – Michael Hampton Feb 04 '13 at 22:48
  • 2
    @MichaelHampton Don't think I said I'd put them in our office network? They'd be in a network the same as any of our customers (We're a small ISP) completely segregated off. It's not a concern. Our sysadmins currently can't easily test IPv6 connectivity when working from home, eg late night on call, so as I see it this solves the problem perfectly! – SimonJGreen Feb 04 '13 at 22:53

2 Answers2

8

If I'm not mistaken, SIT is symmetrical: the same thing is done on both sides.

Configuration should be pretty straightforward:

Cisco IOS: 

interface Tunnel0
 description 6in4 to <client>
 no ip address
 ipv6 enable
 ipv6 address 2001:db8:::1/64
 tunnel source <local ipv4>
 tunnel destination <client ipv4 addr>
 tunnel mode ipv6ip

Juniper JunOS

interfaces {
   ip-0/1/0 {
      unit 0 {
         tunnel {
            source <local ipv4>;
            destination <client ipv4 addr>;
         }
         family inet6 {
            address 2001:db8::1/64;
         }
      }
   }
}

Linux iproute2:

ip tunnel add tun-6in4 mode sit remote <client ipv4 addr> local <local ipv4> 
ip link set tun-6in4  up
ip addr add 2001:db8:::1/64 dev tun-6in4

I have no experience in ASA configuration, but it should be doable too.

However, there are several drawback with 6in4:

  • N tunnels on hub node for N peers

  • No easy way to update peer IP for dynamic-ip clients.

You might want to have a look at dynamic VPN technologies, such as OpenVPN (solves issue #2, although devices will be dynamically generated) or tinc (solves both), or any other capable of encapsulating ethernet (thus IPv6) with tap devices.

petrus
  • 5,297
  • 26
  • 42
  • Thanks, that's a great answer. So the end "client" device would have it's v6 gateway set to the "server" tunnel ipv6 device right? (2001:db8:::1 in your example). And then firewalling/routing is just like any other setup with the tunnel as the interface? – SimonJGreen Feb 04 '13 at 22:58
  • @SimonJGreen: Exactly. tunnel is the wan interface, to the default ipv6 gateway. Routing/firewalling like any other interface. – petrus Feb 04 '13 at 23:04
2

Giving employees of an ISP home connectivity to IPv6 is very important.

6in4 is symmetrical, so you set up the tunnel in the same way on both ends (forming a virtual 'cable' between them). Routing is then done as usual: the 'customer' end uses the tunnel as default gateway, and the 'server' routes the prefixes down the corresponding tunnel. That last bit might require some (manual or automatic) re-distribution of routes.

On Cisco IOS redistribute static in your routing protocol config is an easy way to do this, but you might want to filter the re-distribution. I usually redistribute 'customer' routes in BGP. It keeps the IGP (like ISIS or OSPF) cleaner, which will help convergence speed of your core after a link flap or failure. And BGP offers much better filtering options. For example by attaching communities to redistributed routes.

To expand a bit on the answer given by petrus. I'll give the Cisco notation, but this will work in other operating systems in about the same way.

You can have numbered and unnumbered links. Numbered links might make debugging easier, but it makes your addressing plan a bit more complex. In both cases you will have to delegate a bit of address space to the user. The addresses on the link are only used on the link, and the user probably needs to have addresses for networks behind the link as well. So route a /56 or a /48 down the link.

Let's start with an unnumbered link. Create the link with ipv6 enable to create link-local addresses on the link. Something like this on the 'server' side:

interface Tunnel1
 description 6in4 to <client-1>
 no ip address
 ipv6 enable
 tunnel source <local ipv4>
 tunnel destination <client-1 ipv4 addr>
 tunnel mode ipv6ip

interface Tunnel2
 description 6in4 to <client-2>
 no ip address
 ipv6 enable
 tunnel source <local ipv4>
 tunnel destination <client-2 ipv4 addr>
 tunnel mode ipv6ip

ipv6 route 2001:db8:a001::/48 Tunnel 1
ipv6 route 2001:db8:a002::/48 Tunnel 2

router bgp 65530
 address-family ipv6
  redistribute static

And on the 'client' side:

interface Tunnel1
 description 6in4 to <server>
 no ip address
 ipv6 enable
 tunnel source <client-1 ipv4>
 tunnel destination <server ipv4 addr>
 tunnel mode ipv6ip

interface FastEthernet0/0
 ipv6 address 2001:db8:a001:1::1/64

ipv6 route ::/0 Tunnel 1

And now exactly the same with numbered links. The benefit is that you can more easily ping the other endpoint of the tunnel. Something like this on the 'server' side:

interface Tunnel1
 description 6in4 to <client-1>
 no ip address
 ipv6 address 2001:db8:0:a001::1/64
 tunnel source <local ipv4>
 tunnel destination <client-1 ipv4 addr>
 tunnel mode ipv6ip

interface Tunnel2
 description 6in4 to <client-2>
 no ip address
 ipv6 address 2001:db8:0:a002::1/64
 tunnel source <local ipv4>
 tunnel destination <client-2 ipv4 addr>
 tunnel mode ipv6ip

ipv6 route 2001:db8:a001::/48 2001:db8:0:a001::2
ipv6 route 2001:db8:a002::/48 2001:db8:0:a002::2

router bgp 65530
 address-family ipv6
  redistribute static
  redistribute connected

And on the 'client' side:

interface Tunnel1
 description 6in4 to <server>
 no ip address
 ipv6 address 2001:db8:0:a001::2/64
 tunnel source <client-1 ipv4>
 tunnel destination <server ipv4 addr>
 tunnel mode ipv6ip

interface FastEthernet0/0
 ipv6 address 2001:db8:a001:1::1/64

ipv6 route ::/0 2001:db8:0:a001::1

I choose 2001:db8:0:a001::/64 for the point-to-point link related to delegation 2001:db8:a001::/48 for convenience. You can choose any prefix you like, but keeping things recognisable with an address space as large as IPv6 can help...

Sander Steffann
  • 7,712
  • 19
  • 29