Network Development Team

We’ve a timeline of work for the IPv6 deployment for the next month which might be of interest to some and at the same time we’ve work updating the hardware and operating systems for certain core services. There’s other services that will also need to support IPv6 but I don’t want to plan at an operational level for much more than a month ahead since unexpected additional tasks tend to crop up and skew the dates.

In brief we’re enabling IPv6 to our server room and starting the first core service upgrades, in some cases mixing the migration in with a standard hardware/software refresh (where combining the tasks makes the migration simpler rather than harder). The dates reflect the weekly JANET at risk period for maintenance, Tuesday 7:00am-9:00am.

You might think that we could enable core services faster however the above is one persons work from a four man team – we will have normal duties and other projects underway during this period (the team manages 22 public services and about 13 internal services (physical network monitoring, telecoms integration etc).

The enabling of the first part of the OUCS server room this morning (and the background research/testing as well as the notes this section is based on) was done by another team member however the essential features are that we’re providing IPv6 to the server room with router advertisements disabled, meaning dual stacked servers run by other teams won’t suddenly obtain an IPv6 address automatically. We can get on and IPv6 enable our teams services with a statically configured address without disrupting others. The configuration on a cisco device looks like

ipv6 nd ra suppress
ipv6 nd prefix default 2592000 604800 no-autoconfig

The Cisco IPv6 command reference for nd is available online. In the example above ignore the numbers which are just defaults for valid-lifetime and preferred-lifetime in seconds (normally for a specific network prefix, which we do not need in this case) via router advertisement. The important part is the ‘suppress’ and ‘no-autoconfig’.

The first line tells the router that for ipv6 neighbour discovery it should suppress periodic router advertisements. The second line instructs the router that if asked it should tell the client not to use autoconfiguration for the network. In technical terms, when it gets a request from a client it will respond but in the Prefix Option (see RFC2461) the A-bit is cleared, meaning that the client must not use autoconfiguration for that prefix.

For further information see this c-nsp thread on RA/RS messages and also this other thread.