Towards the end of the second term registrations on the student wireless network were suspended. As of the beginning of the third term, this remains the case - students who are trying to register a wireless device on the eduroam wireless network for the first time will be unable to do so; students who are updating an existing registration should be able to. We do not know when this problem might be resolved.
Affected students will see an error message saying "This network has no more addresses available. Please make a note of this error and report it technical support (see below)."
Simplistically, the problem is that there are no further IP addresses available on the student wireless network. However, at this stage it seems appropriate to give a more detailed explanation.
Shortly before exams last year, the student wireless network ran out of IP addresses. In November 2013, we doubled the number of the addresses available to the network (from 2048 to 4096). At that stage, our predictions suggested that this would be sufficient to get us to the end of 2014/beginning of 2015. Unfortunately that prediction proved incorrect; in a mere four months after term started we ran out again (representing a slightly larger than 100% growth). Whilst the rate of growth has taken us by surprise, it is an understandable consequence of the wireless renewal project and the deployment of wireless into residences.
A technical limitation of IP networks is that the size can only be expanded by a factor of two (i.e size must always double). As it stands, the University does not have a contiguous block of IP addresses large enough to accommodate a grown student wireless network. As a result, we cannot repeat the exercise of the end of 2013 without an enormous amount of work and changes to every computer on the University's network. Because of the impending IPv4 address exhaustion, and because of our current allocation policy (see below), it is not possible for the University to successfully apply for additional address space.
Although it happened much sooner than we anticipated, it is not an unexpected problem. Over the year or two, we have given significant thought to how we would address this (and address similar problems elsewhere on our network). The gist is that the solution involves a fundamental change in the way we allocate IP addresses, from static assignment (i.e. you get the same IP address every time you connect) to dynamic assignment (i.e. your IP address will change each time you connect). Whilst the former has many advantages, it is uncommon on the Internet today. The main reason for this is that latter allows us to "oversell" the available address, as we only have to worry about the number of concurrent connections (rather than the number of possible connections).
Unfortunately we've been using the static assignments for about 20 years, and this way of doing things is an inherent assumption in a large number of systems. Thus, in order to make this change, we need to unravel the dependencies and ensure that alternatives exist to handle the change. Whilst it is not necessary for us to consider every possibility in order to implement a change, there is a core subset that must be addressed before we can do so. These include the network registration system, network access control, and accounting and logging systems. The risks of not resolving these are worse, and more far reaching, than the status quo.
It has been our intent to make this change for some time (cf Multiple Devices), but staffing constraints have meant that we have not been able to devote sufficient time to the problem. This remains the case: whilst this issue is currently receiving more attention that it previously was, the same staff who have to deal with this problem are simultaneously dealing with a number of other equally or more critical (but not as visible) problems.
We were initially hopeful that we'd have a workable solutions by the end of the July vacation. However, a number of unexpected complexities have arisen, with the result that this didn't happen.
At this stage we're unable to predict when we might be able to resolve this. It is primarily depends on our being able to find uninterrupted blocks of time to work through the complex issues that underlie this problem.