Just like previously, please read the disclaimerbefore proceeding; I ain’t no CCIE! Several points before diving off into the configuration :-
- Somewhat surprisingly, the most difficult part of getting IPv6 up and running was not the configuration nor the process of switching ISP to one that supported native IPv6. The most difficult part was acquiring a version of IOS that was not riddled with bugs related to (I think) running IPv6 over PPP. If you are undertaking this task, I would suggest making sure you have a very recent version of IOS – the one I am now running was released in July 2012.
- If you need a UK ISP that supports IPv6 for customers, I would suggest AAISP.
- Throughout this document, I am using the IPv6 documentation network 2001:db8/32, or more specifically 2001:db8:face/48. That doesn’t guarantee that I know what I’m talking about, but at least it doesn’t guarantee that I know nothing … as would be the case if I were using some random real IPv6 address.
- None of the following should interfere with anything you might be doing with IPv4. With the exception of times when I reloaded the router out of frustration, and occasionally to load a new firmware, my IPv4 connectivity was up and running continuously.
Before starting you need an IPv6 address to configure; unless you have a large internal network it doesn’t make sense to start playing with a ULA address. So get an allocation from your ISP. If you have a half-reasonable ISP, they will allocate you something like 2001:db8:face/48 which will give you 65536 different subnets to play with – perhaps slightlyover the top for a home network! To start with, you need to configure the router itself to enable IPv6 :-
ipv6 source-route ipv6 general-prefix MYISP 2001:db8:face::/48 ipv6 unicast-routing ipv6 cef
This basically enables IPv6 routing (with no routing protocols – only static and learnt routes) and configures a “general prefix” with the network details of what your ISP has provided you with. This can be used later to configure addresses in a way that means that changing ISP isn’t quite so painful, and in a way that is less error prone – typing in IPv6 addresses is a lot more prone to typos than IPv4 addresses. Once that is done, it is time to look at IPv6 security … normally people suggest getting everything working first, but as I am more of a security geek than a networking geek, I would suggest security comes first. This is not a great deal different to IPv4 security except that forgetting about NAT makes things simpler :-
ipv6 inspect routing-header ipv6 inspect name ipv6-allowed-out icmp ipv6 inspect name ipv6-allowed-out tcp ipv6 inspect name ipv6-allowed-out udp ipv6 inspect name ipv6-allowed-out ftp
This basically defines what traffic is allowed out (assuming it’s applied appropriately to an interface). Nothing really odd here … basically everything is allowed out, and I ask the router to inspect for routing information that might be available. The next bit is the incoming ACL :-
ipv6 access-list access-to-servers permit icmp any any permit tcp any host 2001:db8:face:f00d::c0:ffee eq 22 deny ipv6 any any log
Several key points about this ACL :-
- All IPv6 ACLs are “extended”.
- All IPv6 ACLs are named rather than numbered.
- The ICMP bit looks a little permissive, but ICMP is very much more required for a functioning IPv6 network than an IPv4 network. It can be tuned down somewhat, but you need ICMP for your network to work.
- The rule that allows access to my server on port 22 does not allow the use of the previously defined general-prefix. Come on Cisco, do the right thing here!
And another ACL for access to the router’s SSH port :-
ipv6 access-list authorised-v6 permit ipv6 2001:db8:face::/48 any deny ipv6 any any
And we might as well apply that last ACL right away :-
line vty 0 4 ipv6 access-class authorised-v6 in
Now we have the basics ready, we can start to configure interfaces. Before you start, it is worth figuring out what network addresses to use. IPv6 does of course allow the possibility of using wildly inappropriate hexspell words as network address, or you could be very sensible and come up with an appropriate allocation scheme. For larger networks, it is well worth reserving a large swathe of networks (such as 0000-7ffff) for someone to come along later to create a “better” scheme … as somebody who has dealt with a large IPv4 network where the original allocation scheme was somewhat suboptimal, I firmly believe that later network administrators should have the freedom to change the scheme in the light of more experience. You will often encounter the assumption that the host part of a network is always 64 bits (or the network mask is always /64). Whilst this is not a requirement at all, there are popular features of IPv6 that only work on a network that size such as address auto-configuration (SLAAC). In practice this means that you should always create networks with a /64 netmask, unless you have a very good reason not to (for instance when configuring statically configured links between routers). Even if you have no intention of allowing address auto-configuration. As a minimum, you will need two networks – one for the external interface, and one for the internal interface(s). As you may have guessed, we have already specified what the internal network is: 2001:db8:face:f00d/64, and I will use 2001:db8:face:1ced/64as the external interface. The first interface to configure is the internal network :-
interface Vlan101 ipv6 address MYISP 0:0:0:F00D::1/64 ipv6 enable ipv6 nd prefix 2001:db8:face:f00d::1/61 ipv6 nd router-preference High
The command to give the network and the interface an address requires a little explanation. First of all, we’re lucky enough to be able to use the “general-prefix” that we defined earlier. This “general-prefix” is merged with the unusual looking address that follows it :-
| MYISP general-prefix | 2001 | db8 | face | |
| Address to merge | 0 | 0 | 0 | F00D::1/64 |
| Result | 2001 | db8 | face | F00D::1/64 |
This provides the interface with an address. The next command simply enables IPv6 on the interface. The ipv6 nd prefix command tells the router what “prefix” to advertise to clients wishing to autoconfigure (using SLAAC).
As an aside, the whole topic of managing IPv6 addresses on clients is worth an article on its own – auto-configuration sounds like a good option (and indeed may be a good choice), but there are situations where you would prefer to not allow auto-configuration. And not all clients work equally well with all options.
The next command (ipv6 nd router-preference High) is a weak attempt to guard against false Router Advertisement messages – advertising this router as a High preference one may prioritise it’s use over any other mysterious routers that appear on this network. In practice, it is necessary to block RA messages from non-router ports using a switch feature such as ipv6 nd raguard. Once this interface is configured, you may well start to see IPv6 hosts with the command show ipv6 neighbours. And onto the configuration of the outside interface :-
interface Dialer0 ipv6 address MYISP ::1ced:0:0:0:1/64 ipv6 enable no ipv6 nd ra suppress ipv6 inspect ipv6-allowed-out out ipv6 traffic-filter access-to-servers in ipv6 virtual-reassembly in
This starts off in much the same way as the previous interface configuration, but in this case I also :-
- Explicitly enable RA messages on the interface with no ipv6 nd ra suppress. This is to ensure that the RA messages get out to the ISP’s router on the “other end”.
- Uses ipv6 inspect ipv6-allowed-out out so that IPv6 traffic is allowed out (and any associated packets are allowed back in again!).
- Uses ipv6 traffic-filter access-to-servers in to allow any unsolicited IPv6 traffic necessary in.
- Uses ipv6 virtual-reassembly in to use Cisco’s VFR feature to protect against fragmentation attacks.
Note that I have statically configured the address on this interface. Some ISPs require this, and some require that the interface is set to auto-configuration (ipv6 address autoconfig or ipv6 address dhcp). The last step is to configure a default route :-
ipv6 route ::/0 Dialer0
Some misconceptions I’ve come across through googling for tips and assistance :-
- There are plenty of examples which show internal interfaces configured with ipv6 nd prefix XXX in addition to the interface address. As far as I can see (and as demonstrated by my home network actually networking), there is no need to specify this prefix unless you are advertising multiple prefixes on an interface, or doing something even stranger.
- Examples often include ipv6 nd ra interval ${some-value}, which as far as I can see is somewhat unnecessary except that the default value of 200s means that connected hosts may take a while to spot the router.
- There are plenty of examples for setting up IPv6 with a tunnel within IPv4 where the IPv6 MTU is set to some value lower than the default such as ipv6 mtu 1280. Tuning the MTU for native IPv6 should not be necessary, and even if it is, the right value would be somewhat higher.
And of course, if anyone believes I’ve done something wrong, please let me know!