Configuring a Cisco 877 for IPv6 on Snap/2Degrees

Recently while staying with the folks in New Zealand, I read that (their) consumer focused ISP – 2Degrees (Formerly Snap Internet) is actually offering IPv6 connectivity to customers, no strings attached!

Although not news, this is a pretty significant development for the New Zealand Internet Service Provider market, with almost every other provider very much heads in the sand on the matter.

IPv6 Adoption in New Zealand (Courtesy Google): Not impressive
IPv6 Adoption in New Zealand (Courtesy Google): Not impressive

Being a nation with a small population and in possession of a fairly reasonable stock of IPv4 addresses, it’s not surprising the countries services providers have been procrastinating.

But anyway, the important question: Does it actually work?

A Cisco 877 I left here a number of years ago ought to be up to the task.

First, let’s get IPv6 turned on:

Router(config)#ipv6 unicast-routing
Router(config)#interface Dialer0
Router(config-if)#ipv6 enable

And now the important bit – lease an IPv6 prefix from Snap using DHCP and prefix delegation, and name it ‘snap-provided-prefix’ (As an example):

Router(config-if)#ipv6 dhcp client pd snap-provided-prefix

We should pretty much get it straight away:

Router(config-if)#do show ipv6 dhcp interface
BVI1 is in server mode
 Using pool: default
 Preference value: 0
 Hint from client: ignored
 Rapid-Commit: disabled
Dialer0 is in client mode
 Prefix State is OPEN
 Renew will be sent in 10:44:15
 Address State is IDLE
 List of known servers:
 Reachable via address: FE80::200:F:FC00:0
 Preference: 0
 Configuration parameters:
 IA PD: IA ID 0x000B0001, T1 43200, T2 69120
 Prefix: 2406:E001:XXXX::/48
 preferred lifetime 86400, valid lifetime 86400
 expires at Jul 02 2013 10:33 AM (81855 seconds)
 Information refresh time: 0
 Prefix name: snap-provided-prefix
 Prefix Rapid-Commit: disabled
 Address Rapid-Commit: disabled

If not, it may be necessary to up/down the Dialer0 interface.

So now we’ve got a prefix, but we can’t do anything with it yet. Let’s add some more stuff, in particular the default route for IPv6:

Router(config)#ipv6 route ::/0 Dialer0

Now, let’s go into the configuration for the LAN side interface, and setup an address with that prefix we got from Snap:

Router(config)#interface BVI1
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 address snap-provided-prefix ::1000:0:0:0:1/64

The last one is a bit of an odd command. The expression “::1000:0:0:0:1/64″ sets the last 80 bits of the interface’s address, with the first 48 bits provided by the ISP. If you wanted to allocate another subnet in your network, you could change the “1000” to “1001” for example.

The subnet is /64 as always because this configuration will end up using EUI-64 for address assignment.

It should pretty much stick straight away:

Router(config)#do show ipv6 int br


BVI1                       [up/up]
Dialer0                    [up/up]



We’re almost online now, just one more thing: DNS.

I prefer to use stateless DHCPv6 for the configuration of IPv6 DNS servers (a fat lot of good for Android devices) but with RDNSS support almost non existent across mainstream platforms, we’ll have to live with it.

Here we’ll create a DHCPv6 pool just for handing out Snap’s two IPv6 DNS servers:

Router(config)#ipv6 dhcp pool default
Router(config-dhcpv6)#dns-server 2406:E000::100
Router(config-dhcpv6)#dns-server 2406:E000::200

And attach it to the BVI1 interface:

Router(config)#interface BVI1
Router(config-if)#ipv6 nd other-config-flag
Router(config-if)#ipv6 dhcp server default

Address configuration is done by ICMP in this configuration, so we’ve got to set the other-config-flag to let clients know to get the DNS servers via DHCP.

At this stage, anything connected to the network should now be online with IPv6. Windows 7+ clients do not need any additional configuration, the same should be true for most Linux distributions.

Running the “ipconfig /all” command on a Windows 7 machine confirms it’s all working nicely:


Here we can see a full IPv6 address on this client which is:

Snap’s prefix (2406:e001) plus our customer prefix (censored) plus the prefix of the local subnet I configured earler (0x1000) and finally this machine’s EUI-64, all together, making a rather long string of digits.

Now the ultimate test: Ask Mr Google that question we’ve all asked at some point:


And there it is. Pretty impressive to be seeing that from New Zealand!

Hang on, we’re not done yet

I shouldn’t have to explain, that there’s no such thing as private IP addresses in IPv6. Everything is public.

So we should put some firewall rules in place to keep those script kiddies out of the home network. I’ve implemented this using reflexive ACLs

ipv6 access-list outbound
 permit tcp any any reflect tcptraffic-out-ipv6 timeout 30
 permit icmp any any reflect icmptraffic-out-ipv6 timeout 30
 permit udp any any reflect udptraffic-out-ipv6 timeout 30
ipv6 access-list inbound
 permit icmp any FE80::/64
 permit udp any FE80::/64 eq 546
 evaluate tcptraffic-out-ipv6
 evaluate udptraffic-out-ipv6
 evaluate icmptraffic-out-ipv6

I’ve left ICMP open on the Link Local interface, in case it’s needed by the ISP for any reason, also I’ve left UDP port 546 open because that’s what’s used by the prefix delegation process.

Now apply that to the Dialer0 interface:

Router(config)#interface Dialer0
Router(config-if)#ipv6 traffic-filter inbound in
Router(config-if)#ipv6 traffic-filter outbound out

The above gives us back more or less the level of security we took for granted with NAT IPv4 address sharing.

Getting it working on Android devices

Because Google still have their head up their arses when it comes to the matter of DHCPv6 support, and Cisco not having implemented RDNSS in IOS until v15.4 (the last version for Cisco 877 was 15.1) – the easiest option to make this work is to configure IPv4 DNS servers (configured by DHCPv4) which will give out AAAA records in DNS responses.

Many ISPs (Including Snap’s) don’t. So you’ll have to find some others.