skip to content

IT Help and Support

University Information Services
 

Please note that some of the information in this document is in flux and subject to final changes. There will also be some information added to explain the migration from the old to the new UDN prefix. UIS will make a formal announcement when the updates are complete.

University Information Services (UIS) is gradually enabling its services with support for the Internet Protocol version (IPv6), the next generation of TCP/IP, the network communications protocol which is used to route traffic across the global internet. The version used predominantly on the internet, which most people are familiar with, is version 4.

Whilst there is no defined date for the ending of support IPv4 (and it is expected this will be many years in the future, probably decades), the general trend is toward IPv6 and, in the interim, support for both protocols should be included on any new service.  With an aim that IPv4 can gradually be deprecated, as this becomes feasible.

This document explains some of the key differences between the two protocols and how IPv6 will be implemented on the University Data Network (UDN).

Contents

Introduction to IPv6

This section is intended as a basic introduction to IPv6 for the purpose of understanding the decisions taken when designing the deployment of a new protocol on the UDN.  More comprehensive information on IPv6 in general is available elsewhere and should be consulted by IT staff, prior to deployment.

It is important to remember that IPv4 and IPv6 are technically completely separate protocols with no way to intercommunicate between them.  More details on this issue are given below.

Addressing and netmasks

The most visible difference between IPv6 and IPv4 is the larger addresses: IPv4 addresses are 32 bits long and written in 'dotted quad' format with four decimal numbers - e.g. 131.111.8.42.  IPv6 uses 128 bit addresses, written in 8 groups of 16 bit blocks (each written as 4 hexadecimal digits), separated by colons - e.g. 2a05:b400:000d:0000:0000:0000:0000:0001.

When writing addresses, within each block of 4 hex digits the leading zeroes may be omitted.  In addition, once per address (and no more) a contiguous run of one or more blocks which are all ':0000:' may be replaced by a double colon.  These shorthands are the usual way in which IPv6 addresses are presented for display in software and network equipment.  For example, the above address will most commonly be written as 2a05:b400:d::1.

Netmasks are written in the same 'mask length' format as CIDR (Classless Inter-Domain Routing) IPv4, with '/length' after the address.  For example, a /126 subnet has 126 bits of network address, leaving 2 bits for host/network address (bottom being the network anycast address, although this is not required; there is no top address for a directed broadcast).

The format for writing IPv6 addresses is defined in RFC 5952 — examples here will be written in this format except where emphasis is needed (for example, sometimes a leading '0' is used in blocks of 4 digits to illustrate the use of four bits of space).

Subnets

Edge subnets (which PCs, printers, etc. connect to, as opposed to subnets used to link routers together) are typically all /64 in size, for various reasons.  A /64 subnet leaves 64 bits for the host address which is large enough for any practical single layer 2 domain (e.g. a VLAN).

Because of this, an IPv6 subnet will usually never need enlarging due to an increased number of hosts being connected (unlike an IPv4 subnet where, on the UDN, multinetting is typically used to provide additional addresses).  As such, it is more important to think of the number of subnets required, rather than the number of addresses on any individual subnet.

Unicast Address configuration

IPv6 differs radically from IPv4 in how a host obtains an address to talk to the network. There are currently five main ways in which this can be done: new ways have been added over time and the recommended methods have changed.  Current best practice is described below.

EUI-64 addresses

The original mechanism is called EUI-64 and uses features built into ICMPv6 (Internet Control Message Protocol, which provides things such as PING in IPv4 and IPv6 but has been significantly extended in IPv6 for other purposes).  These allow a host to obtain information about the subnet (address and netmask) to which it's attached and construct a unique address for itself, based on its MAC address — this mechanism is called stateless address autoconfiguration (SLAAC, pronounced "slack").  SLAAC can (and usually does) also supply the router address to hosts.  As such, it is not necessary to run a DHCP server, nor statically configure an address, in order for it to talk to the network.

Privacy (RFC 4941) addresses

Since EUI-64 results in the final 64 bits of an IP address being consistent, even when a host is moved between subnets on the internet (not to mention the OUI portion of the MAC address being embedded, allowing the hardware type of the host to often be determined), concerns about privacy resulted in the development of privacy addresses (RFC 4941, September 2007).  These were introduced with Windows XP and Mac OS X 10.7 Lion) and result in the client selecting a random address for itself (albeit one valid for the subnet to which it is attached) and changing it every day or so, or when it's disconnected and reconnected to the network.  Privacy addresses are typically used for ephemeral outbound/client connections from a host, in addition to another mechanism.  This system does not require any particular support from the network, beyond that for EUI-64, above.

Semantically opaque interface identifiers "secured" (RFC 7217) addresses

Orthogonal to the use of privacy addresses for outbound connections, semantically opaque interface identifiers (RFC 7217, April 2014), sometimes known as "secured" addresses, are now recommended (in RFC 8064, February 2017) as a replacement to EUI-64 as the mechanism of choice to determine a stable address that remains available during the entire time that a host is connected to a particular network, for similar privacy reasons.  This system involves a host selecting a "cryptographically generated" (effectively random) address for itself where the final 64 bits will vary, as the host moves between different subnets, but be consistent when it is connected to a particular subnet (unless a clash or other problem is detected).  These addresses have replaced the use of EUI-64 in macOS 10.12 Sierra and recent versions of Windows 10 and Linux (with NetworkManager 1.2 and later, as used in Ubuntu 16.04).

DHCPv6 addresses

There is also a DHCPv6 protocol: the ICMPv6 protocol advertises to hosts whether they can pick their own address (using one of the above mechanisms) or specify they must use DHCPv6.  In addition, they can indicate the client should select its own address but use DHCPv6 to discover the addresses of DNS or other (such as PXE boot) servers.  If DHCPv6 is being used to issue addresses, the DHCP server must track which addresses it has allocated but, if only used to supply information such as the DNS server addresses, does not need to maintain any state.  Note that some operating systems (in particular, Android) ignore the ICMPv6 flag indicating that a host must use DHCPv6 and select their own address anyway.

Static addresses

In addition to these automatic mechanisms, hosts can still be statically configured with an address.  This is typically used when a particular host or service needs a known address so it can be registered in the DNS and located.  The IPv6 protocol mandates that hosts support multiple addresses on a single network interface, so it is common to register one address per service rather than per server; the service addresses can then be moved between physical boxes.  Note that EUI-64 addresses should not be moved between boxes as they technically belong to the Ethernet interface which owns a particular MAC address: when setting up a service, a fixed address should be chosen and avoid the need to update the DNS, if the physical/virtual host on which it runs changes.  Note that some operating systems disable router discovery when a static address is configured: in these situations, a default gateway must be configured manually.

Best practice

The end result of all these possibilities is that end hosts will typically decide which address they're going to use and can get onto the network without explicit configuration, as opposed to the network administrator allocating and configuring addresses, before a host can talk to the network.  This obviously raises issues of traceability and accounting.  These changes were introduced deliberately, to minimise the overhead of connecting to an IPv6 network.

At the time of writing (August 2018), current best practice is for clients to use a combination of semantically opaque interface identifiers (RFC 7217) and privacy addresses (RFC 4941): semantically opaque interface identifiers to pick a stable address for the duration of their connection to a particular network and privacy addresses for outbound (client) connections.  This arrangement makes it difficult for hosts outside the same layer 2 domain (e.g. VLAN), when only the IPv6 address (and not the MAC address) is available, to be able to infer information about the host making the connection, nor match up connections from the same host over time, or as it moves location, from the IPv6 address it is using.

Stateless DHCP should only be used to supply "other" information (DNS servers, boot servers, etc.), rather than issue addresses.  In particular, relying on DHCP as the authoritative source of address allocation and usage is strongly discouraged and likely to be incorrect.

Various configuration options can be set on networks to 'break' the autoconfiguring nature of IPv6 (in particular, suppressing router responses to requests for available subnet prefixes and router addresses).  However, this tends to go against the 'spirit' of IPv6 and is often a futile exercise which will present problems later.  The UIS recommends that IPv6 is embraced in full and the differences in behaviour are accepted, rather the attempts made to disable them and bend things into a manner to be more like IPv4.

Link-Local Addresses (LLAs)

Regardless of the routable address range in use on a particular subnet, a host will also  select a Link-Local Address (LLA).  These addresses are in fe80::/10 (fe8X-febX:...) although, in practice, the addresses always start fe80::....  These addresses are similar to their IPv4 equivalents in 169.254.0.0/16 addresses in IPv4 (RFC 3927).

These addresses are used for protocols which operate only on the local subnet and cannot be routed (in particular, because there is no network portion) — for example Neighbor Discovery (ND), which is used in a manner similar to ARP in IPv4 and the protocols which make up SLAAC need them to discover the routers and routable prefix in use on the subnet.  As such, an LLA will appear on a host in advance of the routable address being added, as per one or more of the above .

LLAs are usually quoted with a "%interface" suffix, when entered on a host, as the address on its own does not determine the interface through which is reachable.

Unique Local Addresses (ULAs)

IPv6 has an equivalent of 'private addresses' - called Unique Local Addresses (ULAs) but their use is intended to be slightly different from private addresses in IPv4.  Because the address space in IPv6 is so much greater than IPv4, and any particular organisation should have sufficient globally-routable addresses for every device to have such as an address, there should be no need for Network Address Translation (NAT) and the array of associated protocols to allow it to support protocols with embedded IP addresses (e.g. protocol fix-up for FTP) or needing to open inbound connections (e.g. UPnP, NAT-PMP).

NAT is not recommended as a security feature, even under IPv4, but a regular firewall or access control lists used, if traffic is to be filtered.  Also, given the increasingly diverse range of locations from which users wish to access services, making them directly accessible from the internet, in a secure way, is strongly recommended, where possible.

ULAs should only be used where a device really has no need to be connected to or from the internet, or vice versa. Which devices/networks this applies to can be difficult to determine.  For example, the past few years of IPv4 has seen the introduction of printers obtaining firmware and accepting print jobs across the internet, network-enabled security cameras and other devices.  If unsure, and renumbering will be difficult later, putting devices on globally-routable addresses and using appropriate access controls on routers and firewalls (which can be relaxed later) is probably the best solution.

There are no plans to deploy ULAs on the UDN at present.  This policy can be reviewed if a need arises.

Interoperability with IPv4

IPv6 was designed as a completely new protocol from IPv4 and not as a backwards-compatible upgrade: no attempts were made to allow the two protocols to intercommunicate directly (i.e. you cannot use an IPv6-only device to connect to an IPv4-only device, or vice-versa).

However, a number of protocols (Toredo, 6to4, NAT64, etc.) have been developed which allow some degree of interoperability.  Some of these must be explicitly supported on each host, whilst some allow a special protocol-level proxy router to be placed somewhere on a network (often not even on the local network but somewhere else on the internet) and used to allow hosts to intercommunicate.  Most of these protocols have been designed as an interim measure, to get IPv6 where it would not normally be able to reach, because of legacy firewalls and routers, for example.

In some cases, support for these protocols comes already enabled on user devices and can spring into life, if a suitable proxy router is discovered on the internet.  This can result in them being used, even without a system or network administrator being aware of it, perhaps bypassing firewall policies or resulting in weird routes, via the internet, to reach even local UDN destinations.  Whilst the use of some of these protocols can be blocked, often the easiest way to prevent their use is to enable native support for IPv6 on the local network.

Because of this, and other reasons, experience has shown that many of these protocols generate more problems than they solve.  The long-term goal should be for native IPv6 support with a view to turning off IPv4 and so their use is generally discouraged, in favour of native IPv6.

Whilst many of these protocols will work fine on the UDN, it is not expected that explicit local support will be given for them (in terms of either resolving issues with getting them working, or providing the required proxy services themselves).

In the interim, it is expected that hosts run in a dual-stack environment, supporting both IPv4 and IPv6 natively.  When looking up the IP address of a host in the DNS (e.g. "www.cam.ac.uk"), if both IPv4 and IPv6 addresses are available, and the client host has IPv6 connectivity, it will typically try to connect to IPv6 first, before falling back on IPv4, if that fails.  It is expected this situation will exist for many years, while IPv4 is gradually deprecated.

Support for IPv6 on the UDN

Support for IPv6 for on the UDN is largely equivalent to that for IPv4:

  • Address ranges can be allocated and routed as normal
  • Hosts and routers can be registered in the IP Register database and are available in the DNS
  • Redundant first hop routing is provided and provides the same failover times 
  • BGP is supported for redundant connections
  • Multicast is available, including connectivity to the global internet
  • Tracking and logging of connections
  • MPLS VPNs can carry IPv6 unicast traffic

There are a number of areas where IPv6 support is currently NOT available, either due to technical limitations or services not yet being developed.  These include:

These limitations are expected to be addressed as resources and technical solutions allow.

University allocation

The UDN has a single public IPv6 /32 block — 2a05:b400::/32, giving the addresses 2a05:b400:..., with 32 bits for the subnet number, i.e. around 4.2 billion subnets of /64 in size.  The UDN obtained this block in June 2018 after joining RIPE as an LIR (Local Internet Registry).  The block is Provider Independent (PI), separate from Janet, and so can be routed via other providers, if necessary, and is anticipated to suitable for the UDN's foreseeable needs.

(The UDN also has the block 2001:630:210::/44, giving the addresses 2001:630:21P:QRST:....  The block is part of the Janet allocation [2001:630::/32]: academic, research and other institutions connected solely to Janet typically all have addresses in this block.  It is intended that the UDN and connected institutions migrate from this block to the new block over the coming months and it is released.  This status and usage of this legacy block will not be covered further in this document.)

The space is divided up into a series of /48 blocks as follows:

/32 (UDN)   /48 Use

2a05:b400

: 0000 Loopbacks and backbone links
0001 UDN-institution links
0002-000f Core services where addresses may need to be entered (e.g. DNS servers)
0010-00ff University-wide services
0100-... /48s for institutional networks start here

All other parts of this block are reserved for future use.

The UDN block was allocated by RIPE on behalf of the university and associated institutions, including colleges and research units connected solely to the UDN.  It is NOT expected additional space will need to be required: institutions will be assumed to get their IPv6 allocated from the UDN block and not receive separate allocations outside of this range, regardless of whether they had those in IPv4.  If an institution feels this to be inappropriate, they should discuss this with UIS Networks.

Institution allocation

Upon requesting its first block of IPv6 address space (by contacting IP Register, as with IPv4), a single /48 prefix from the above /32 will be reserved, giving 65,536 subnets for internal use.  Institutions may decide how this address space is to be organised, typically into a series of /64s.

In the case of the simplest institutions, only requiring a single subnet, this is likely to just be the first subnet within the /48 block, i.e.:

UDN   Institution   Subnet Purpose
/32 /36 /40 /44 /48 /52 /56 /60 /64
2a05:b400 : P Q R S : 0 0 0 0 One and only subnet for Department of Small Studies

If and when an institution with a single subnet requires additional subnets, these will be allocated from the /48 block reserved for the institution.

Note that, if an institution uses a routed connection (either static or BGP), then the link subnets with the UDN will NOT come out of the institutional block, but instead be allocated from the 2a05:b400:1::/48 block.  Addresses in the link subnet MUST NOT be considered as part of the institution but, instead, as part of the UDN backbone and can change as the network is reorganised.

More complex sites may have multiple internal subnets and wish to structure their organisation of this space.  For example, colleges may wish to separate student residential subnets from administrative and servers connections - they can adopt a more complex strategy that takes advantage of boundaries that are maskable for routing and access control reasons.  For example - St Botolph's College, receiving the allocation 2a05:b400:130::/48, may decide to subnet as follows:

UDN   Institution   Subnet Purpose
/32 /48 /52 /56 /60 /64
2a05:b400 : 0130 : 0 0 0 0 Backbone network
1 0 Central servers
2 0 0 Administrative staff - city centre site
1 Administrative staff - west Cambridge site
8 0 0 Student bedrooms - first court
1 Student bedrooms - second court
2 Student bedrooms - third court
N ... etc.
e 0 0 eduroam network - city centre site
1 eduroam network - west Cambridge site
f 0 0 Building management - city centre site
1 Building management - west Cambridge site
4 0 CCTV - city centre site
1 CCTV - West Cambridge site

Typically, in this situation, the UIS would route all of the /48 to the institution, rather than adding routes to the individual subnets in use.  This simplifies the network configuration but institutions must ensure that they blackhole (null route) any unused addresses in their /48.

Note that, despite having the entire /48 routed to them, institutions must ensure that any address blocks they're actively using are suitably registered with IP Register.  Due to current limitations with the database, these subnets must be /64s (or part thereof) and cannot be larger allocations, so each individual /64 must be separately registered.

It should be noted that allocations are made to institutions and not sites - an institution with multiple sites will typically not be allocated a separate block for each site, but will have portions of the /48 allocated to the institution routed to each site, as requested by the institution.

Multi-part institutions

Some large institutions may have internal or affiliated units or groups hosted on their network which have a high level of complexity or autonomy.  It may be desirable that separate /48 blocks are allocated for use by those groups, distinct from the institution hosting them.  These may include:

  • A hosted service which sits outside (or above) the hosting institution, and may move elsewhere in future or should be distinct from the institution itself.  An example might be school-level services (e.g. website, fileservers, Active Directory infrastructure, etc.) that are hosted in one or more of the constituent departments making up the school.
  • A group which is expected to be broken off from the hosting institution at some point in the near future.  A separate block will allow a clean split and avoid fragmentation of the institutional blocks.
  • A group with sufficient size, complexity or autonomy where a separate block is required to give them sufficient scope for organising the address space.
  • An institution providing connectivity or support to another (e.g. contracted-out IT provision) - a separate block should be allocated to the hosted institution (or the routing transferred to the hosting institution).
  • Temporary usage (which may extend to several weeks or months) and it would be beneficial to the hosting institution that the address space was distinct from their own.

In all cases, the hosted group or unit should have sufficient complexity that renumbering will present a problem - for example, a single school web server on an IP address in one of its departments would not present much problem, if it had to change its address to be hosted in another department in the same school.  In general, renumbering in IPv6 is a much simpler process than in IPv4 due to mechanisms built in to the protocol to support it (often without needing to reconfigure client machines at all).

These situations are dealt with on a case-by-case basis and institutions should contact IP Register, if they have a query.

Host allocation

The basic rules for users and network administrators on machines and users using the UDN are the same for IPv6 as IPv4. Principally:

  1. They must be allowed to do so.
  2. Any particular access must be traceable back to the machine and user which made it.

On the UDN, it is a requirement that hosts and their IP addresses are registered in the IP Register database for three main reasons.  Some of these reasons are no longer applicable in IPv6:

  • To mark an address as "used" (and avoid it being allocated to something else).
    The large amount of IPv6 address space available on a single subnet, and the mechanisms a client has to select a unique address for itself without assistance, means that individual addresses do not typically need marking in this way.
  • To record the end user, system administrator, equipment details and location of the device.
    While the need to do this for a particular device remain, it is difficult to register a static address due to the uncontrollable and dynamic way in which some of the host address configuration mechanisms in IPv6 operate.
  • To register the hostname and IP address in the DNS.
    DNS entries are primarily registered to allow clients to locate the address of a server. Whilst reverse DNS is sometimes used to identify a client, perhaps as a form of authentication/authorisation, this is not especially secure and advised against. Registration of IP addresses and hostnames is considered 'good form' in IPv4 but is probably impractical in IPv6, for the dynamic address reasons.

Given the above three reasons, in IPv6, the policy on the UDN has changed with respect to both IPv6 and retrospectively to IPv4:

  • Hosts with manually-selected static addresses must still be registered.
    Typically these will be machines providing services (e.g. a web site, IMAP mailserver, desktop workstation contactable by SSH) and a DNS name needs to be registered to provide a way to locate the host.  In addition, if a static address is chosen for other purposes (e.g. to have a fixed address for outbound connection sources), it is a good idea to register it in the database to mark that address as used.
  • It is not necessary to register every host in IP Register, unless a DNS entry is required.
    Pure client machines typically do not need registering in the database.  When making outbound connections on to the UDN and public internet, the address will be seen as unregistered and have no reverse DNS; likewise, the host will have no forward lookup.  Hosts using the EUI-64 or semantically opaque interface identifier (RFC 7217) mechanism could be registered (in particular, if inbound access is required), if the local network administrators desire, but it would not be mandatory.

It is very important to note that, even though it is not necessary to register pure client devices, Janet rules still require us to know which device (and user) was using which address(es) at which time (and vice versa).  This may be accomplished by performing network level logging and/or authentication.  However, if no such logging is in place, it may be necessary to force every client machine to disable privacy extensions and force a static EUI-64 address, then register those addresses in IP Register.

Obviously, if host names are not registered in the IP Register database, care should be taken to avoid a duplicate of any particular name being used (if this matters - there won't be a clash in the DNS, but might be in local subnet service location, for example).  As such, a local registry of hostnames may need to be maintained or, alternatively, boxes in IP Register could be registered with no addresses.

Service addresses

When allocating a fixed address for a service (or server) for registration in the DNS, largely any scheme can be selected by the institution (the only important thing is NOT to set the 7th bit in the first byte of the host portion, i.e. <network>:0200:~ should be clear, as this bit means the address is 'universally unique' which a manually selected address will not be).  However, as a suggestion, the UIS's own scheme is presented here.

The UIS splits elements (separated by colons) of the host portion of an address to give a service identifier and instance:

Network portion   Host portion
/64   /80   /96   /112   /128
2a05:b400:PQRS:TUVW : 0000 : 0000 : <service-identifier> : <instance>

The service identifiers are largely unimportant but serve to reserve a /112 (i.e. ~65,000 addresses) for a particular service or area.  They can just be allocated sequentially, or chosen to represent something memorable - perhaps referring to the common TCP or UDP port number (probably in BCD) used by a particular service: for example '80' for websites, '25' for email.  Alternatively, something making a word or acronym could be used: 'd' for DNS servers, 'aaa' for RADIUS ("Authentication / Authorisation / Accounting"), '109' (hexadecimal representation of "log") for logging servers, etc. 

The instance numbers are then typically allocated sequentially, sometimes with test servers receiving a high number (e.g. 'fffX').

The colon separators between each block of 16 bits / 4 digits allow leading zeros to be omitted in each case.

Some examples for St Botolph's College, using this scheme, are shown below:

Address Use Meaning
2a05:b400:130:10::d:0 First recursive DNS server Service identifier = 'd' = DNS; instance = '0' = first server
2a05:b400:130:10::d:1 Second recursive DNS server ...; instance = '1' = second server
2a05:b400:130:10::d:a0 First authoritative DNS server ...; instance = 'a0' = first authoritative server
2a05:b400:130:10::e:0 First email server Service identifier = 'e' = email
2a05:b400:130:10::80:0 First web server Service identifier = '80' = TCP port 80 (for HTTP)
2a05:b400:130:10::aaa:0 First RADIUS server

Service identifier = 'aaa' = Authentication/Authorisation/Accounting

Default gateway / router addresses

As stated above, hosts can use SLAAC to discover the router address and this does not usually need to configured.  However, routers will generally need an address in the same subnet for operational purposes.

On the UDN, an edge subnet is typically connected to two routers. These routers will have physical addresses in the lowest 65,536 addresses (i.e. ...::0 to ::ffff), as well as ...::1 as a First Hop Redundancy Protocol-protected address.  This is effectively the network having a service identifier of '0'.  For example, if a host on the 2a05:b400:130:10::/64 subnet requires the default router address to be manually configured (perhaps because entering a static address for a service disables router discovery via ICMPv6), it should use 2a05:b400:130:10::1.

What happens inside institutional networks with their own routers is a matter for the institution.

Mixing public IPv6 and private IPv4

As stated above, there are no current plans to use ULAs (Unique Local Addresses - the equivalent of "private addresses" in IPv4) on the the UDN. However, the majority of hosts on the UDN are using private addresses merely as a method to avoid using a public IPv4 address for a host which does not need to be directly contacted from the internet.

As such, client machines using UDN-wide private IPv4 addresses will gain public IPv6 addresses, when IPv6 is enabled for them. This gives rise to a situation where a host has an address with a '.inst.private.cam.ac.uk' name for its IPv4 address and a '.inst.cam.ac.uk' name for its public IPv6 address.

In this situation, it is recommended that the host is given a name in the public space (e.g. 'inst.cam.ac.uk', rather than 'inst.private.cam.ac.uk'). It may be that the public IPv6 name is not registered in the DNS, if the machine is a pure client; if the name is registered, a vbox object may be more appropriate to indicate one of the addresses is hosted on the same box as the other.

The IP Register database does not consider two registrations with the same name, one in the public and one the private namespace, as being a clash. Care must be taken if this has happened and they refer to different boxes (this situation is probably undesirable, anyway).

Registering host addresses in IP Register

Much of the IP Register interface is now enabled for IPv6. IPv6 addresses for hosts can be added using the box_ops page; services (as secondary addresses on a host) are perhaps better represented using vbox_ops.

  • On /64 host subnets where the UDN routers provide the default gateway, the bottom /112 addresses (...:0:0000 to ...:0:ffff) are reserved for the UDN router addresses.  The remainder (i.e. ...:0000:0000:0001:0000 to ...:ffff:ffff:ffff:ffff) is available to the institution to allocate to hosts/services.
  • Point-to-point link subnets with the UDN are typically /126s with the UDN end at ...:1 and the institutional end at ...:2.
  • Subnets routed internally by an institution will typically be set up the same as the above, except that the gateway / upstream end will be available to the institution to register the router address(es) themselves.

Enabling IPv6 in an institution

In principle, enabling IPv6 on an institutional network is simply a matter of adding an IPv6 subnet prefix to the router interface.  Most hosts will already be IPv6-ready, pick up an address within a few seconds and begin talking IPv6, when the service they're trying to reach is available on IPv6.

However, care must be taken before switching this on as many of the pitfalls outlined above may occur.  These include:

  • Hosts may begin using unpredictable addresses.
    Some of the mechanisms clients may use to select an IPv6 address result in unknown and dynamically changing addresses, leaving an inability to trace a device or user.
  • IPv6 may bypass firewalls and other access control mechanisms.
    IPv6 is a different protocol at the ethernet level - some firewalls may block all unknown types of ethernet traffic; others may allow it to flow through unimpeded.  As such, care must be taken to ensure hosts are appropriately secured over IPv6.
  • A different-looking address will be seen in logs, etc.
    Similar to the previous item, requests will start to be seen from IPv6 addresses - these may break log processing scripts or be allowed/denied access to services secured by IP address.

The UDN logs IPv6 traffic for auditing in the same way as it does with IPv4.  However, this often just narrows a particular address down to a specific institutional network - if privacy extensions are in use, it may not be possible to track an individual host; this is the responsibility of the institution itself.

The UIS encourages institutions to begin preparing for IPv6. Depending on how an institutional network is connected to the UDN, various options are available to allow testing of IPv6 in a controlled fashion.  It is strongly recommended that IPv6 functionality is included as a mandatory item on all future equipment specifications.

Migration of prefixes from 2001:630:210::/44 to 2a05:b400::/32

As stated above, the UDN is migrating to a new PI prefix of 2a05:b400::/32 from a Janet PA prefix 2001:630:210::/44.  This will take place over several months, starting in Autumn 2018, giving institutions time to handle the issues specific to their usage of IPv6 (which may involve liaison with external parties).

The procedure which will be used is as follows:

  1. UIS Networks allocate a new /48 prefix for an institution (to replace the old /56).  In the case that the institution uses a single (or very simple) subnet, the replacement /64 subnet(s) will be allocated directly.  If an institution has a more complex setup, the institution will be left to organise this themselves.
  2. The institution is advised of the new prefix and asked if there is any reason why this should not immediately be added to their existing VLAN, in parallel with the old prefix.  The most obvious problem to be raised here is some sort of access control based on the IP address: if this is in use, the new prefix needs to be permitted access to the resource, before it is used.
  3. UIS Networks add the new prefix to the institutional VLAN, in parallel with the old prefix.  Regular end-user hosts using SLAAC will typically pick up the new prefix and begin to use it, without needing to be reconfigured.
  4. Institutions carry out any migrations of static addresses or other registrations in the DNS over to the new prefix.  Institutions should note the introduction of RFC7217 (Semantically Opaque Interface Identifiers) in many operating systems may have caused existing EUI-64 registrations to become invalid, anyway.  It is strongly recommended that pure client hosts are NOT registered in the DNS as their addresses can be ephemeral (perhaps changing after a reinstallation of the system software); any registrations can be left to be rescinded when the old prefix is removed in step 9.
  5. The institution notifies UIS Networks the migration of registrations over to the new prefix is complete and the old prefix is ready to be decommissioned.
  6. UIS Networks set an expiry of the old prefix to take place in 28 days (unless an institution has a reason to pick a different timeframe).  Hosts will cease to use the old prefix for outbound connections and begin using the new prefix exclusively.  Established connections using the old prefix will continue to work until the final expiry time.
  7. After the closedown period has completed, the old prefix will be removed from the VLAN.
  8. Any use of the old prefix for address-based access should removed (both for internal and external resources).
  9. The old prefix will be deallocated from the institution.

Institutions with internal routers will need to carry out migration steps 3-8 themselves and, in the case of institutions with large, complex internal subnetting structures, may take some time.  UIS Networks will also speak to the institution to switch over the subnets used on their uplinks with the UDN.

Once this process is complete, the 2001:630:210::/44 prefix will be returned to Janet and may be used by another institution.  As such, step 8 is important to avoid them being seen as part of the UDN for the purpose of access control.

Last updated: 12th December 2022