Personal tools
\\\\\\\\\
Toolbox /////////
KAREN wiki
KIWI ADVANCED RESEARCH AND EDUCATION NETWORK
IPv6 Migration
From KAREN wiki
Contents |
What this page is for
This page is intended to be a description of what needs to be done to migrate an existing IP network to using IP version 6. It is intended to be read by engineers and support staff who already understand how an IP version 4 network works.
This page is to include all the material listed in the box at right, and doubtless other things as we come to them.
This page does not include
- An introduction to IPv6. You can find one of those here.
- Discussion of whether IPv6 is a good idea. For an estimate of the date on which current IPv4 address allocation will cease see The CIDR Report
- Configuration of computer operating systems for IPv6, which is covered here
And for the time being this page will not include
- Wireless components, because we haven't started working with IPv6 on those yet.
- Discussion of Application-Level Gateways or anything else needed to operate a network solely on IPv6.
This page is discussing a network which has at least most of the components mentioned in Figure 1:
Figure 1: Example Network
All KAREN members are required to maintain a connection to the public Internet, which matters in parts of what follows.
Acknowledgement
This page is largely written by Donald Neal. Thanks to Perry Lorier of The University of Waikato's WAND research group for his help with the DNS.
Obtaining Address Space
There are ways of getting IPv6 connectivity without your own allocated IPv6 addresses. One way is to use "local" addresses from the range fc00::/7 (i.e. with the first two bytes in the range fc00-fdff). These are intended to work in the same way as IPv4 private addresses. For a full explanation of how this is supposed to work, see RFC4913.
But if your aim is to migrate parts of your network over time to operate on IPv6 and to have IPv6 connectivity to the outside world, you will need IPv6 addresses which can be used in the IPv6 Internet. You're likely to get those from wherever you currently get your IPv4 addresses.
Addresses, both IPv4 and IPv6, are chiefly allocated to service providers by Regional Internet Registries, which in this part of the world means APNIC. Service providers then allocate addresses to their customers. However, many larger organisations such as universities are members of APNIC and receive their address allocations directly from APNIC. To get started in dealing with APNIC, take a look at their "Quick start guide" here.
APNIC's current policies call for a basic allocation to users of a /32 address block (that's 2^96 or about 80 000 000 000 000 000 000 000 000 000 addresses). If you don't have plans for a large-scale move to IPv6, but have more than one connection to the outside world - as any KAREN member will - you can probably get by with a /48 (which is only 2^80 or about 1 000 000 000 000 000 000 000 000 addresses).
If you aren't an APNIC member, you can get started with IPv6 by asking REANNZ for a /48 taken from address space allocated for use by KAREN. No, this service is not provided for IPv4 addresses.
If you use KAREN addresses, you will need later to get different address space from your other provider in order to get access to IPv6 sites not reachable over KAREN. This is because KAREN doesn't carry just any Internet traffic, so only sites attached to research and education networks will know how to send traffic to addresses issued for KAREN. And yes, that does mean that in assigning IPv6 addresses for use inside your organisation, you will need to consider whether you want an address to be available for use by parties outside research and education networks.
This has advantages if you wish to make some material - perhaps especially large data sets - available only over KAREN. And stateless autoconfiguration (see below) means renumbering an IPv6 network may not be as hard as renumbering an IPv4 network.
(See also Connecting to the Outside World.)
Checking Switch and Router Software
In the past, vendor implementations of IPv6 have omitted some features found in implementations of IPv4. Nowadays you are likely to be able to implement IPv4 both within your network and to the outside world without requiring big changes to router or switch software. That said, there are a certain number of components out there running fairly old software. The real issue is to understand what software versions your existing equipment is running. And your existing inventory processes tell you that, right?
You may well discover that your equipment does not support management (via SSH and SNMP) over IPv6. But that's not a problem preventing use of IPv6 by end users.
See the Cisco IPv6 roadmap for levels of IPv6 support in various IOS versions.
In years past, one approach taken was to implement separate infrastructure using routers dedicated to IPv6 (some of which were PC's running the Quagga routing software). In most situations that won't be necessary today.
Firewalls
A firewall in a New Zealand institution will generally be of one of two types.
One is a computer running free software, either a BSD variant with PF or Linux with iptables. The other type is a commercial firewall appliance.
The free software options are likely to support IPv6 just fine, with two provisos. The first is that iptables does not support NAT for IPv6. This may well not be a problem, since one of the aims of IPv6 was to remove the need for NAT.
The second point to note is that you will still need to reproduce for IPv6 at least some of the firewall rules you're using with IPv4. There is a cost in administration time to maintaining extra rules. If you're using software to help you administer IPv4 rules, that's likely to need to be changed to cope with IPv6.
In 2007 support for IPv6 in commercial firewall products was generally weak, though less so in products intended for larger customers. If you're using a recent version of products like Checkpoint, Cisco ASA or Juniper ScreenOS, you may well already have all the IPv6 functionality you need. Older products are likely to give you trouble.
The same issue may also arise with other related products in your network, such as web proxying appliances.
Check your firewall software version's support for IPv6. Look in detail at what functions it implements for both IPv4 and IPv6, not just whether it will carry IPv6 packets. If you're not able cost-effectively to upgrade your appliance to provide IPv6 support, you may have a problem.
One answer to that problem is to use a PC running free software to provide an IPv6-only firewall in parallel with an existing IPv4-only firewall.
Figure 2: Parallel Firewalls
To prevent this from forming an IPv4 path around existing firewalls, make sure that the only interface on the IPv6 firewall which has an IPv4 address is the one used for administration. Then run routing software, probably Quagga, on the IPv6 firewall to announce a default IPv6 route to internal routers or layer three switches in your network, and to have the firewall learn our network's internal routes.
Assuming you're using OSPFv3 as your interior routing protocol, the Quagga configuration to have a firewall advertise a default route is not complex:
In the daemons file set
ospf6d=yes
In the file zebra.conf define a default route to the interface on the border router facing the firewall
! Default route to border router interface ipv6 route ::/0 2001:dead:beef:123:4567:89ff:feab:cdef
In the file ospf6d.conf
interface eth1 ipv6 ospf6 instance-id 0
This is the interface facing your network. This interface and the one facing the border router will both need IPv6 addresses assigned.
router ospf6 router-id 10.255.1.1 redistribute static route-map static-ospf6 interface eth1 area 0.0.0.0
Select a sensible router ID for the firewall. The IPv4 address you're using to administer it?
ipv6 prefix-list v6-default seq 10 permit ::/0
route-map static-ospf6 permit 10 match ipv6 address prefix-list v6-default
No routes to your own network are configured, since they'll be learned by OSPFv3 from the internal router(s).
If you're going to use OSPFv3 on the border router, the firewall's routing configuration will be simpler. Two interfaces will need to be assigned to OSPFv3 area zero, but no static routes need to be defined. The border router will then advertise the default route.
On the other hand, if you have only one internal router or switch running IPv6, you may prefer statically to configure routes on it and on the firewall.
IPv6 routing and IPv4 routing operate entirely independently of each other, so any approach to IPv6 routing will not affect existing IPv4 services.
Setting up OSPFv3
This section yet to be written.
In short: OSPF version 2 is specific to IP version 4. If you're using it at the moment, you will almost certainly need to set up OSPF version 3, which is specific to IP version 6. This will give you two instances of OSPF running independent of each other. The good news is that if your routers support IPv6 this is easy to set up and looks very much like OSPFv2 in use.
Connecting to the Outside World
There are essentially three ways to connect to the outside world using IPv6: "Native" IPv6, statically-configured tunnels which carry IPv6 packets inside IPv4 packets, and automatically-configured tunnels. A good explanation of this stuff can be found here.
In theory you're able to start off with IPv6 connectivity only over KAREN. In practise there's a problem with this.
When a computer using IPv6 asks for a DNS name to be resolved, it may receive both IPv6 and IPv4 addresses in response. A computer with IPv6 enabled will prefer IPv6 addresses. But where the research and education networks with which KAREN communicates don't have a route to the IPv6 addresses in the response, your computer should use the IPv4 address anyway. That means fact that KAREN does not carry all routes for commercial IPv6 users shouldn't be a problem. But in practise cases do arise where KAREN advertises a route to a company using IPv6, but that company does not receive routes advertised out by KAREN. In that case, turning on IPv6 will mean a loss of connectivity unless you configure the computer in question to prefer IPv4 addresses.
What this means is that your users will see better results if you have IPv6 both over KAREN and over a commercial provider. Which is the same approach KAREN members use for IPv4.
Note: It is technically feasible for a department within an organisation to set up its own IPv6 connectivity by tunnelling IPv6 through a centrally-administered IPv4 network. But your organisation's firewall may not be able to inspect IPv6 packets inside IPv4 packets. In that case you may find there is an organisational policy in place preventing the use of tunnels from inside the firewall, or restricting connectivity between your end of the tunnel and other parts of your organisation's network. And if there isn't, there should be.
Native IPv6
This section is not yet complete.
In short: KAREN supports IPv6, but officially noone else in New Zealand will sell you an IPv6 service yet. To connect to KAREN using IPv6 you will need an address from KAREN's space which you configure on your border router's interface facing KAREN, and an IPv6 address which you configure on each interface on your border router facing your internal network. Then your border router needs to exchange IPv6 routes over BGP with KAREN. This is not hard.
You also need to ensure that your border router has IPv6 connectivity to your internal network. One way to do this is to run OSPFv3 on your border router. It then advertises a default route into your network. If for some reason you don't want to run OSPFv3 on your border router, you could simply configure static routes to your internal address ranges on your border router. Another element, probably your IPv6 firewall, would then advertise a default route to the border router as described in the section on Firewalls.
Statically-Configured Tunnels
This section is not yet complete.
A statically-configured tunnel encapsulates IPv6 packets inside IPv4 packets, allowing them to pass over an IPv4-only network.
(A range of types of tunnelling for IPv6 exist, including GRE, IPSec and even MPLS. This section assumes the aim is to provide a connection to the public IPv6 Internet over an IPv4 network, and sticks to IPv6-in-IPv4 as the simplest way of doing that.)
If you're using a native connection to KAREN but want IPv6 connectivity to sites not reachable over KAREN, you're likely to want to run a tunnel to another provider. The idea is that packets going to destinations for which you can't route traffic through KAREN will be forwarded to the other provider. They will then route traffic between your tunnel, other tunnels to them and ultimately the public IPv6 Internet.
Figure 3: Using KAREN and an IPv6 over IPv4 tunnel
It is possible in practise to experiment with IPv6 by setting up a tunnel from a single computer rather than a router. But apart from the security issue this may raise (see note above) this page is about migrating a network, which is a larger-scale activity than that. So for access to sites outside KAREN you will eventually want to set up a static tunnel on a router.
To do that you'll need from your carrier the IPv4 and IPv6 addresses of the carrier's end of the tunnel and the IPv6 address to be used at your end of the tunnel. You'll assign your own IPv4 address to your end, which you'll need to tell your carrier.
For a Cisco configuration for this, see here. Do note that that description assumes your routing protocol is RIP, which it won't be.
A Juniper configuration is not complex:
interfaces {
ip-0/0/0 {
unit 0 {
tunnel {
source <local IPv4 address>;
destination <far end IPv4 address>;
}
family inet6 {
address <local IPv6 address/netmask>;
}
}
}
}
On a Juniper M-series router you may need a tunnel PIC for this, but this is not needed on the J-series.
If your carrier will not provide IPv6 even by tunnelling, you have the option of establishing a tunnel to an IPv6 tunnel broker such as SixXS, who will provide connectivity to the IPv6 Internet and other tunnel users. But less direct routes for traffic inside New Zealand mean this is a third-best option.
Automatically-Configured Tunnels
This section yet to be written.
In short: For sites just getting started with IPv6, or who face hurdles in running native IPv6 infrastructure, the Tui Project is worth a look.
Assignment of Addresses to Machines
If your network is large enough to have a plan for allocation of IPv4 addresses, you'll need one for IPv6 addresses too. You will also need to think about any organisational policies or practices - especially for control of access - which rely on IPv4 addresses. For example, the use of fixed addresses by administrators to get access to particular services.
An IPv6 interface will normally have more than one address, starting with an automatically-generated address valid only on the local link (usually beginning fe80). This section discusses addresses which can be used to move packets outside the local link.
As in IPv4, addresses can be configured statically on devices, or they can be assigned using DCHP. An option not available with IPv4 is stateless autoconfiguration, in which devices automatically generate their own unique addresses.
In practise for IPv6 addresses you're likely to be using static assignment where you need to and stateless autoconfiguration in other cases.
Static Address Assignment
This page describes the process of statically configuring IPv6 addresses for a number of operating systems. You might assign addresses in this way where a given interface must always use the same address, because
- The address is to be advertised in the DNS, e.g. a DNS server address
- The address is used in access control, e.g. a machine used by a network administrator
- The address is itself configured into applications, e.g. a database back end
And router interfaces will use static addresses.
Stateless Autoconfiguration
An IPv6 interface will select for itself a unique local address. On an ethernet interface, this will be based on the interface's hardware "MAC" address. It will then use this address to verify that the same address is not being used by any other node it can reach.
It will also send out a router solicitation request. If a router on the local link is configured to use IPv6, that router will respond with a router advertisement. That advertisement includes a prefix describing the address block in use on that link. Using that address block and a number derived from its MAC address, the interface will construct a unique address for itself.
This means that stateless autoconfiguration won't do anything until a router has been enabled to return router advertisements. This in turn means that an operating system, even if it has IPv6 enabled on an interface, won't try to use IPv6 for most tasks until a router is enabled. So they key time in migrating a particular network (or VLAN) would be when router advertisements are enabled rather than when any configuration change is made on a computer.
Stateless autoconfiguration is a sensible choice in a network which does not use DHCP, or one where DHCP over IP version 4 is to remain in use for all attributes except the IPv6 address. While in theory name server addresses can be passed to computers by stateless autoconfiguration, in practise this is not implemented.
DHCPv6
This section yet to be written.
In short: If you wish to use IPv6 to dynamically assign other attributes as well as addresses to computers, such as name server addresses, you could in theory use DHCPv6, which is analogous to DHCP under IPv4. DHCPv6 is not widely used.
Application Issues
The departments at Victoria and Waikato universities which use IPv6 have not seen any problems caused by application software incompatible with IPv6. That doesn't mean it can't happen. Particular care needs to be taken with older software (e.g old enough to still be using the gethostbyaddr() function) and with software which handles IP addresses. Also be aware of configurations (e.g. web server .htaccess files) which use IP addresses.
The Domain Name System
If your only aim is to provide IPv6 connectivity from your network, you don't need to do anything about DNS. But if you want to make your services, like web or file servers, available by DNS name over IPv6, you'll need to reproduce for IPv6 the same sort of configuration you already have for IPv4.
This can involve three sets of tasks, which can be carried out independently of each other:
- Forward DNS - Advertise IPv6 addresses for services
- Reverse DNS - Carry out reverse DNS resolution of IPv6 addresses
- Make your DNS server(s) available to be queried over IPv6
If you're using BIND as your DNS software, you probably want to upgrade to version 9.x if you haven't already.
Forward DNS
Forward DNS records allow a name to be looked up, returning an address. For IPv6 this works in the same way as for IPv4, except that an address is held in a "AAAA" (pronounced "quad A") record rather than an "A" record. So to add an IPv6 address to the DNS for an existing name which already has an IPv4 A record is just a matter of adding a single line to your existing file. Like this:
orc.cs.hillcrest.ac.nz. IN A 130.217.42.42 orc.cs.hillcrest.ac.nz. IN AAAA 2001:db8:beef:123::42:42
On doing this, you can expect desktop computers which have access over IPv6 to prefer the AAAA address over the A address. So it is at this point that any application or IPv6-specific network problems may show up. Try this with the address of a service less used by desktop machines before your main web server.
Reverse DNS
Reverse DNS records allow an address to be looked up, returning a name. For IPv6 this works in the same way as for IPv4, but the syntax used is a bit different, and IPv6 reverse DNS works independently of IPv4 reverse DNS, meaning your reverse IPv6 configuration will go into a separate zone file.
In the case of BIND, that means you'll need an entry in your main configuration file, usually named.conf, pointing to a new IPv6 reverse zone file. The example below is for the address block 2001:db8::/32 .
//2001:dead
zone "8.b.d.0.1.0.0.2.ip6.arpa" {
type master;
file "reverse.2001:0db8"
};
The reverse zone file (here "reverse.2001:0db8") works in much the same way as its IPv4 equivalent, except that it uses PTR records to record individual addresses, and describes the addresses it applies to using nibbles:
$TTL 86400 @ IN SOA elf.hillcrest.ac.nz ent.hillcrest.ac.nz ( 2000808290001 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Negative cache TTL ) ; IN NS elf.hillcrest.ac.nz. IN NS eagle.hillcrest.ac.nz.
; Department for IPv6 Studies $ORIGIN 2.4.0.0.0.0.0.0.0.0.0.0.3.2.1.0.f.e.e.b.8.b.d.0.1.0.0.2.ip6.arpa.
2.4.0.0 IN PTR orc.cs.hillcrest.ac.nz.
As with IPv4, you can delegate reverse zones within your address allocation to departments which operate their own DNS servers. Also as with IPv4 you will need to have the provider of your addresses, possibly APNIC, set up a delegation to your name servers for the addresses you have been allocated.
DNS Servers with IPv6 Addresses
This section is not yet complete.
IPv6 DNS records can be looked up by queries carried over IPv4, or vice versa.
To allow your DNS servers to be queried over IPv6 from the outside world requires that you add IPv6 addresses to your own name servers and add AAAA records for them to the DNS records held by the DNS servers which hold delegations for you. For example, if your name servers serve the name hillcrest.ac.nz, the servers for the .ac.nz domain (which are the .nz servers operated by the Domain Name Commission) will hold records which allow them to respond to queries for hillcrest.ac.nz with your servers' addresses.
You will need to add IPv6 addresses to your existing IPv4 addresses. This is not a complex change:
ent.hillcrest.ac.nz. IN A 130.217.254.250 orc.cs.hillcrest.ac.nz. IN AAAA 2001:db8:beef:feed::42:42
The .nz name servers are already reachable over IPv6.
Setting up an internal recursive DNS server to handle your outgoing DNS queries, most of which will still pass over IPv4 outside your network, is not a major task either.
Known IPv6 Use in New Zealand
A number of carriers and ISP's have worked with IPv6, though the author doesn't know of one which offers an official IPv6 product.
Since 2005 the Computer Science department at Victoria University of Wellington has provided IPv6 access to the outside world using a tunnel provided by TelstraClear.
Massey University has worked in the other direction. While Massey has had a native IPv6 connection to KAREN since 2007 and receives email over IPv6, it doesn't yet provide native IPv6 to the desktop. Massey allows IPv6 access to machines whose users want it using ISATAP.
Since August 2008 a number of departments in The University of Waikato have had IPv6 access to the outside world using native IPv6 over KAREN. A single web site within the university is available to the outside world over IPv6.
The Tui Project is working to provide a simple way into IPv6 for organisations which do not have an IPv6 provider.
If you do your own peering at a APE or WIX, you should be able to use V6IX to do the same things with IPv6 as you do with IPv4. Depending on your peers, of course.
