The UDN (University Data Network)'s connection to the internet is provided via Janet, the UK's Education and Research Network. Janet has specific rules about who can use it to access the internet, prohibiting commercial use (except as part of University business). In addition, it also places requirements on identifying who is using the connection so misuse can be traced, if required.
Often, institutions require a way to connect purely commercial entities to the network, or provide connectivity where the auditing requirements of Janet are undesirable or not possible. The UDN's Commercial Internet service allows some of the requirements to be relaxed.
This service is commonly referred to as the "Mythic Beasts service" due to the name of the company which provides the internet connectivity for it.
Contents
- Provider
- Who can be connected
- Upstream connection
- Routing on the UDN
- Speed
- Delivery to institutions
- Cost
- Requesting the service
Provider
The UIS has partnered with Mythic Beasts to provide internet connectivity fo this service.
Who can be connected
In principle, anybody who has a legitimate connection with the Collegiate University can be connected to the commercial network. This includes:
- Commercial entities who are occupying Collegiate University premises,
- Overnight visitors (so-called "bed and breakfast" guests),
- Visitors whom it is not possible to identify individually when they connect.
The connection cannot be offered as an open, public network to people or organisations with no connection to the Collegiate University (for example, it must not be presented on an open wireless SSID, accessible from a public area), or supplied to external parties with no legitimate relationship with the Collegiate University.
Because of the limited bandwidth, the service should typically not be used for users who could be connected to the UDN with appropriate care. This includes students and conference guests staying for more than a short period.
Users must comply with normal legal regulations and the spirit of the Janet Acceptable Use Policy, points 8-16.
If these terms are violated, the service may be withdrawn with immediate effect. If unsure, customers should contact UIS Networks, before connecting the customer.
Upstream connection
The commercial network upstream connection is provided via a VPN tunnel between the UDN and the provider's network across the University's regular Janet connection. Commercial network traffic from the University is sent through this tunnel and breaks out onto the public internet on the provider's network, using their IP addresses, so traffic will appear to originate from their network.
This is permissible over Janet because the traffic passing over it is encrypted and effectively originates from the provider's network.
Routing on the UDN
The routing for the commercial network is handled by the same physical hardware as the UDN (routers and switches), but the routing for it is kept separate from the UDN by carrying it inside an MPLS layer 3 VPN.
In the main, traffic between the UDN and the commercial network will need to be routed through the public internet and Janet, so traffic from a commercial network host will re-enter the UDN as if from outside.
However, there are some subnets which pass through a direct connection between the networks. These are typically to support the operation of the commercial network itself, e.g. for DNS and DHCP services.
More details of how this is supplied to institutions is provided below.
Speed
The VPN tunnel is nominally expected to run at 100Mbit/s, sharing this bandwidth with all the customers of the service.
The link is intended for normal client use, with intermittent/bursty demands from individual hosts. As such, institutions should receive rates around the advertised speed. If there is significant contention, the actual delivered rate will be lower. It is expected that, when this situation occurs on a regular basis, there will be enough customers to warrant an upgrade of the link.
The link is supplied on the understanding this is how it will be used by institutions: institutions should not set up (for example) constant streams of data across it using more than an insignificant amount of bandwidth.
It is not possible for institutions to reserve a proportion of the bandwidth across the commercial connection for their exclusive use.
Delivery to institutions
Institutions will be supplied with the commercial connection on a separate VLAN from their normal UDN connection. It cannot be fed via the same VLAN as a secondary range, nor fed over the same routed link as an existing UDN connection (either statically or using BGP).
IP addressing
The commercial connection uses IPv4 addresses in the range 10.224.0.0/16 and IPv6 addresses in 2A00:1098:5::/48. The IPv4 range is taken from the block allocated to UDN-wide private IP addresses.
Institutions will receive a block of addresses from the above ranges — for IPv4, it is necessary to allocate a range of the appropriate size, for the required number of clients; for IPv6, this will typically be a single /64.
The number of addresses allocated should correspond to the number of simultaneously-connected devices (with a bit of padding for DHCP redundancy and to accommodate reuse). A /24 (approximately 250 devices) is usually sufficient for most connections, although larger blocks are available without a problem (although a very large block — probably larger than a /22 — may suggest that too many hosts are being connected and institutions should note the bandwidth availability).
When IPv4 traffic exits the commercial network onto the provider's network connection, it will be SNATed behind public addresses used by the provider: these addresses must not be relied upon and can change without notice. The provider will handle the SNAT translation and keep logs to trace back access to a particular internal site. Institutions should not SNAT the traffic themselves to avoid problems with double-NAT and traceability.
The IPv6 traffic uses global addresses belonging to the provider and will be routed without translation.
The support of IPv6 is mandatory: institutions must provide this to clients and not take steps to block this or prevent its use. Clients must provided with an IPv6 address automatically, either via SLAAC or DHCPv6. This is to reduce the load on the SNAT and associated logging and administrative work in maintaining it. If an institution routes the traffic via an internal router, this must support IPv6 and provide it to the client network.
It is not possible to provide individual public IPv4 addresses or inbound DNAT to allow services to be reached, inbound across the commercial connection.
Routing
Typically the connection will be supplied as a simple edge VLAN, allowing the client hosts to be directly connected.
However, institutions may wish to route the traffic through an internal router, either because of their internal network design, or because they wish to receive a block of addresses they can split up to offer to different parties within the institution. In this situation, a link VLAN/subnet can be provided the client range routed across it.
Institutions may use an internal router to provide connectivity between the commercial range and their internal network, to provide access to local resources. However, they must not allow traffic from the commercial network at their site to reach other locations on the UDN in the UDN address space: traffic to other sites must be routed out through the commercial connection.
DNS
There is a connection between the commercial network and the UDN to allow access to the University recursive DNS servers at 131.111.8.42 / 2001:630:212:8::D:0 and 131.111.12.20 / 2001:630:212:8::D:1 without needing to go via the public internet, allowing prompt queries.
These addresses should typically be used by clients to do DNS resolution, although institutions can use other DNS servers, if they so wish.
DHCP
The VLAN can be set up to provide IPv4 DHCP services to client hosts, either from a pool of addresses, or via manual configuration of MAC-IP mappings.
There is no DHCPv6 service available at present although client hosts will be able to use SLAAC to determine the prefix and router address through the normal IPv6 RA (Router Advertisement) mechanisms.
Tracing clients
The UIS will log IPv4/IPv6-MAC usage to record the ethernet address of the client device using a particular IP address at a particular time.
Responsibility for traffic on the network is passed down to the institution to whom the connection is supplied. If there are repeated problems with access, it may be necessary for an institution to revisit its policy of who is allowed to access the service.
If an institution is offering the connection to separate internal parties, they can run a router and have a block of addresses routed to them, to subnet feed separately to the different internal groups.
Security and firewalling
No firewalling or other content filtering is performed on the connection although, given the nature of SNAT on the IPv4 traffic, hosts within the University will not typically be reachable over IPv4 from the public internet. However, no such filtering exists on the IPv6 connection so, traffic to hosts using their IPv6 addresses will not be blocked.
Within the commercial network at the University, no filtering between institutions exists, so a client host may be reached from another site without restriction.
Institutions should apply filtering on their connections as they deem appropriate. This can be provided using the Managed Firewall Service.
Cost
The commercial network is available is an additional service and incurs an annual charge. The price is listed on the Network Charges page.
Requesting the service
Institutions wishing the make use of the service should contact UIS Networks with the details of how they'd like it provided:
- The desired size of the IPv4 and IPv6 client address blocks. For most deployments, these will be a /24 and /64, respectively. Remember that, as you should not NAT traffic, these ranges will need to be large enough for all connected clients.
- How they'd like the routing for the subnet to be set up.
- Whether they'd like the UIS to set up DHCP on the client subnet.
They should also submit an order for the required amount.
Last modified: 2nd May 2019