This document provides advice and guidelines for IP addressing and related key protocols for organisations connected to the HSCN. Published 24 May 2017.
Download this guidance as a PDF.
This document provides advice and guidelines for Internet Protocol (IP) addressing and related key protocols for organisations connected to the Health and Social Care Network (HSCN). Related key protocols and methods include Network Address Translation (NAT), Domain Name System (DNS), and Dynamic Host Configuration Protocol (DHCP).
Those with Information Management and Technology (IM&T) managerial and technical roles within organisations connected to HSCN.
Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NHS Digital. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes.
Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment.
It is important to note that a risk assessment is a prerequisite for the design of effective security countermeasures. A correctly completed risk assessment enables an NHS organisation to demonstrate that a methodical process has been undertaken which can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes. This means that changes implemented following this guidance are done so at the implementers' risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer.
The HSCN IP addressing policy is designed to future proof connectivity for health and social care in the longer term. With the advent of cloud technologies and internet enabled applications the NHS will inevitably move towards an internet centric approach. The adoption of Réseaux IP Européens (RIPE) assigned addresses throughout the core of the network, and a move towards the same for all endpoints, will support the eventual move to a cloud/internet based solution.
The HSCN IP addressing policy provides the flexibility to connect either with or without Network Address Translation (NAT). However, HSCN mandates the use of a public (RIPE assigned) address at the point of connection for all new sites, whilst migrated sites may maintain a legacy addressing scheme where there is a technical or business requirement to do so. To meet with this requirement, NAT will be configured at the end-site HSCN customer-premises equipment (CPE). This section provides detail on how NAT works and the importance of taking a co-ordinated approach to its deployment.
NAT is a mechanism that translates IP addresses within private, internal networks to another range of IP addresses for transport over an external network (such as the internet or HSCN). Incoming traffic is translated back for delivery within the inside network by the NAT technology.
NAT is a widely used technology that permits the manipulation of IP traffic. Further details can be found in the Internet Enginieering Task Force (IETF) Request for Comments (RFC) 1631. In using NAT it may be necessary to consider the practicalities of logging, as well as source/destination access control policies, as NAT manipulates the headers of IP packets, and effectively breaks the end to end Transmission Control Protocol/Internet Protocol (TCP/IP) connection. If considering using NAT it is prudent to establish full logging and auditing policies beforehand, to ensure compliance with good practice guidelines for auditing the use of shared IP addresses.
NAT is a technology that is prevalent in Internet Protocol version 4 (IPv4) networks, where IPv4 public internet addresses are a limited resource. Because of the continuing expansion of the World Wide Web (WWW), and other internet based services demanding IPv4 addresses, it is no longer an option for organisations to obtain additional public IPv4 address space to interface public facing systems, and so NAT has become a necessity for many network designs.
NAT typically takes place at the boundary between an organisation's internal network and any external network gateway, and allows a multitude of private (RFC 1918) IP addresses to use a limited pool of public IP addresses, or a single address if necessary.
NHS organisations typically use NAT to interface between their local sites and the N3 network, whilst home workers may well use NAT within their local router to interface to their internet service provider (ISP).
There are many types of NAT offering many different benefits as well as limitations - the types of compatible applications or the levels of auditing that are applicable at the end service level, for example.
With NAT the border device, typically a router or firewall, uses stateful translation tables to map the private 'hidden' IP addresses to the single address (or pool) and then rewrites the outgoing IP packets on exit so that they appear to originate from the border device. In the reverse communications path responses are mapped back to the originating IP address using the rules (or 'state') stored in the translation tables. The translation table rules established in this fashion are flushed after a pre-determined period, unless new traffic refreshes their state.
The border device can contain two types of NAT table entries, dependent on the NAT method in use:
- Dynamic entries - where multiple internal (private) IP addresses are translated in to a single external IP address, or a pool of external IP addresses
- Static entries - where internal and external IP addresses are mapped one-to-one.
In large deployments the masking of unauthorised use of the network, using NAT, can be of serious concern. When faced with possible illegal activities external to the local source network, investigation and discovery of the originating machines within the network can be extremely difficult if detailed logs are not kept.
Port Address Translation (PAT), or Network Address Port Translation (NAPT) as it is also known, is a common form of IPv4 NAT. Also known as a 'hide NAT', PAT maps connections from many internal addresses to a single external IP address by using multiple ports that create and handle connections.
These connections are held in a state table to preserve and maintain this connectivity. Because of the design of the TCP/IP protocol, well known ports (0-1023) are not used, leaving ports 1024 to 65535 to be mapped against a single external IP address.
Whilst over 64000 connections could be mapped against a single IP address it is considered good practice not to exceed 40000. If this limit is regularly exceeded performance issues may be encountered, at which point the use of a second IP address, or pool of IP addresses, should be considered. It can sometimes be difficult to retrospectively build this into an existing solution; therefore it should be factored into the design from the outset.
As a result of this mapping process it is not possible for an external host to create a connection directly to an internal host because the end-to-end connection is effectively terminated at the border device.
Although in the first instance this can appear to be a limiting factor for the usefulness of PAT, this process also has its benefits. It provides a very simple yet effective method of protecting internal hosts from external attack at the network level.
PAT is often utilised in home environments or in large scale deployments.
From an administrative point of view PAT is the simplest to implement, only requiring the entry of a static rule to run effectively. Auditing, on the other hand, can generate large log files dependent on the level of information required and the amount of traffic passing through the border device.
Without these detailed logs it is very difficult to track individual connections made through PAT. In addition, restrictions at the destination service may be difficult to enforce.
Also known as 'One-to-One NAT' or 'Static NAT', full cone NAT creates a static entry on the NAT device. This maps a single internal IP address to a single external IP address. In a typical installation this process also directly maps all the ports on a one to one basis. As this form of translation is static the translating device maintains only basic connection information, because the translation is applied directly at the initiation of each connection, by matching the source and destination IP addresses.
Typically this form of NAT is utilised when connections are not only initiated from the private network, but also when connections need to be initiated into the private network - for example, for access to a specific system from an external network.
Fig. 1 provides an example of the translation undertaken by the border router when a user within a private network initiates a connection to a server on the internet.
In this scenario the ports are not illustrated as there is no port translation. Should the server initiate the connection to the user machine, the reverse of the connection process described above would be applicable.
This form of NAT can prove useful in cases when other forms of NAT may already be in use for the masking of multiple internal IP addresses, and where certain machines require external identification. This could be an audit requirement, or be part of an access enforcement policy by a service which restricts access by IP address.
If undertaking auditing at the service endpoint, this form of NAT provides a direct mapping of an external IP address to an internal IP address, which can be linked in case of investigation. The discovery of the internal address, together with its associated machine and user, is dependent on the source organisation's disclosure of this information.
Restricted cone NAT is very similar to full cone NAT in its operation but distinguishes itself by not allowing incoming connections, unless the private machine (internal to the network) has previously initiated a connection to the external destination address.
Enhancements to restricted cone NAT can create a port restricted cone NAT. This can also be utilised in enforcing policy by using the port to restrict access.
This form of NAT has similar issues as full cone NAT. However with the addition of port restricted cone NAT, further security measures at the service end can be utilised to restrict connections to individual ports.
Also known as 'bi-directional NAT', symmetric NAT uses a rule that directs each request from the same internal IP address and port to a specific destination IP address and port to be mapped to a unique external source IP address and port. If the internal IP and port is utilised to connect to a different destination IP and port, a different mapping is used.
Only an external host that receives a packet from an internal host can send a packet back.
With symmetric NAT, the NAT mapping refers specifically to the connection between the local host address and port number and the destination address and port number and a binding of the local address and port to a public-side address and port. Any attempt to change any one of these fields requires a different NAT binding. This is the most restrictive form of NAT behaviour under UDP, and it has been observed that this form of NAT behaviour is becoming quite rare, because it prevents the operation of all forms of applications that undertake referral and handover.
Fig. 2 gives an example of a request from an internal IP address and port to a specific destination IP address and port mapped to a unique external source IP address and port. Diagram sourced from Cisco.
Owing to the nature of the packet manipulation carried out by NAT, there are several issues with attempting to pass Internet Protocol Security (IPSec) virtual private network (VPN) traffic across devices that perform NAT functions. VPN tunnels gain protection through authentication headers, and use checksums to validate the encapsulated traffic. The NAT packet manipulation alters the checksum of the packet therefore rendering any protection invalid.
In these cases technologies such as NAT Traversal (NAT-T) can be utilised. This uses UDP traffic along with the VPN traffic, thus allowing the creation of a VPN across the NAT device.
IPSec VPN users can run into trouble when traversing a NAT-ing device, such as a firewall or router, because:
- The TCP/UDP header within an IPSec Encapsulated Security Payload (ESP) packet is encrypted, preventing the mapping of ports by the NAT-ing device.
- NAT changes the IP and TCP/UDP headers carried within IP packets, invalidating IPSec's integrity check.
VPN Pass-through, usually found in home routers that support PAT, addresses issue '1' (above) by NAT-ing encrypted packets without mapping ports inside the TCP/IP payload. However VPN Pass-through is not a standard, and behaviour varies between vendors' products.
NAT Traversal (NAT-T) refers to a series of Internet Engineering Task Force (IETF) drafts that fix issue '2' (above) by wrapping encrypted IPSec packets inside a clear text UDP wrapper. Any NAT-ing device can translate both the source IP address and source UDP port of the clear text wrapper without changing any part of the encrypted IPSec packet carried inside.
It is essential though that the devices at both ends of the IPSec tunnel support the same version of NAT-T, be able to detect when to use NAT-T, and keep the NAT mapping alive for the lifetime of the tunnel.
Fig. 3 below provides an example of IPSec NAT Traversal
NHS Digital appreciates that the use of NAT comes with advantages and disadvantages. This section outlines some of the recognised drawbacks that can accompany the deployment of NAT.
The use of NAT is sometimes seen to enhance, the level of security within a network. This is due to the NAT technology 'hiding' the internal addressing scheme of the organisation behind either a single or a series of separate IP addresses that differ to the internal scheme.
This can also be seen as a drawback where NAT may provide a false sense of security resulting in the overall level of security being lowered. There can be a danger of assuming all security threats are external, leading to practices that make internal breaches much easier. With a secured firewall at the network perimeter, the contribution of NAT to the overall security model is negligible.
IPSec is a set of protocols developed to support packet level authentication and encryption at the transport layer. The technology depends on end-to-end consistency of the IP addresses in the IP headers. NAT presents a significant obstacle to IPSec technology, as the IP address header is changed when traversing a NAT environment. Application layer security techniques, such as SSL, that do not depend on an IP address can function correctly in the presence of NAT.
An Application Level Gateway (also known as Application Layer Gateway) is usually employed between application peers when an intervening protocol or device (in this case NAT) prevents direct connectivity. The purpose of the ALG is to simulate direct connectivity. The IETF RFC2663 relating to NAT Terminology provides a definition of ALG in section 2.9.
The following lists a number of protocols that may require the aid of an ALG to traverse a NAT environment.
- FTP (File Transfer Protocol)
- DNS (Domain Name System/Service)
- RealAudio (de-facto standard for streaming data over the World Wide Web)
- H.323 (multimedia conferencing protocol, which includes voice, video, and data conferencing, for use over packet-switched networks)
- SMTP (Simple Mail Transfer Protocol)
- Telnet (terminal emulation)
- RSVP (Resource Reservation Set-up Protocol)
- SNMP (Simple Network Management Protocol)
ALG's are vendor specific, and are not normally developed to generically fit environments outside the particular vendor's product range. It is recommended that these issues should be discussed with the hardware vendor prior to any purchase or implementation involving NAT.
This section describes a technology that can assist in the deployment and management of IP addresses - Dynamic Host Configuration Protocol (DHCP).
DHCP is a standardised protocol that enables clients to be dynamically assigned with various configuration parameters, such as an IP address, sub-network mask, default gateway, and other critical network configuration information.
DHCP servers centrally manage such configuration data, and are configured by network administrators with settings that are appropriate for a given network environment. DHCP servers in turn communicate with DHCP clients through the use of DHCP messages.
DHCP supports three methods of IP address allocation:
- Dynamic DHCP allocation
- Static allocation
- Dynamic BOOTP allocation
A network can use one or more of these methods. The network administrator can select which of the methods to use.
DHCP provides for both static and dynamic configuration of IP clients. Static configuration enables you to assign a specific IP address and configuration to a client with a specific Media Access Control (MAC) address. When DHCP assigns IP addresses dynamically, IP clients are assigned an IP address that is chosen from a range of available addresses. Dynamic address assignment can be deployed when an individual client does not require a specific, static address.
DHCP is based on the Bootstrap Protocol (BOOTP) and maintains some backward compatibility with it.
There are two primary differences, between DHCP and BOOTP that should be noted. First, DHCP defines mechanisms through which clients can be assigned an IP address for a finite lease period, allowing for reassignment of the IP address to another client later. Secondly, DHCP provides the mechanism for a client to gather other IP configuration parameters it needs to operate in the TCP/IP network.
Though BOOTP is a predecessor of DHCP, it is still a viable from of address management. The backward compatibility of DHCP ensures that, within a DHCP environment, BOOTP specific devices can be allocated IP addresses.
The management overhead of introducing new clients to a network is simplified as the majority of addressing is administered centrally at the DHCP server.
The task of introducing new sub-networks, or re-addressing portions, or the whole, of the network is also simplified through centralisation.
The flexibility of DHCP ensures that devices that do require static address, whether for authentication purposes or other reasons, can be managed centrally. Most products will allocate static addresses by device MAC address, though some products can also assign by username or workgroup.
There are numerous software and hardware solutions that provide DHCP functionality, but inherently it is the network operating system (NOS) that is the most commonly used resource. Most standard NOS offerings include DHCP functionality as standard.
Classless Inter-Domain Routing (CIDR), also called "Supernetting", is a technique used to reduce the size of routing tables on large networks such as the internet.
A number of contiguous IP subnets can be represented by a single entry with some routing algorithms, allowing for faster routing decisions.
CIDR can also be useful in private class C networks to reduce routing times and generally improve performance. Secondary addressing and multi-site situations are other scenarios where CIDR can be used, or where large class A LAN segments with more than 254 hosts need to be re-addressed.
This section covers some of the key services that need to be considered when migrating from one IP address scheme to another, and the appropriate action required to ensure minimal disruption. Further guidance can be found in the HSCN technical guidance.
As part of the HSCN service provision, a centrally hosted Domain Name System (DNS) is provided in the core. However, LAN hosts may not always access these services directly, but may instead reference one or a thread of locally hosted DNS name servers, before eventually referencing the national DNS. An example may be when a host attempts to establish a connection to another IP host, it will first check its local HOSTS file (if there is one) for the name of the remote host. If the remote host is not in the HOSTS file, the host will send a query to its LAN hosted primary DNS name server. The primary name server may well not contain the information about the particular destination host; in that case, the query must be forwarded to another name server that is higher up in the domain name hierarchy. This is DNS forwarding. When re-addressing a LAN environment, though the national hosted DNS address does not change, it is essential to ensure locally hosted DNS are updated to reflect the new address scheme.
The HSCN core DNS may also cross reference locally hosted DNS servers at end user sites. This is DNS delegation. When re-addressing a LAN environment, it is essential to ensure changes to locally hosted DNS servers used for delegation are registered with DNS servers that sit higher up the DNS hierarchy.
Locally hosted web site domain names and their associated IP addresses are registered and updated using the DNS registration form on the NHS Digital website. When changing the external IP address scheme of a locally hosted service, it is essential this form is completed to ensure the correct DNS name entry and IP address appears within the national DNS table.
To ensure the changeover is co-ordinated in a controlled manner, the end user site can specify to NHS Digital when the change is to be activated.
Locally hosted SMTP servers and their associated domain names and IP addresses are registered and updated using the SMTP registration form on the NHS Digital website. A Mail Exchanger (MX) record is an entry in a DNS table which controls where mail for a particular domain name is sent. This information is also registered and updated via the SMTP registration form. When changing the external IP address scheme of a locally hosted SMTP mail server, it is essential this form is completed to ensure the correct domain name entry and IP address appears within the national DNS. To ensure the changeover is coordinated in a controlled manner, the end user site can specify to NHS Digital when the change is to be activated by contacting DNSTeam@nhs.net.
End sites that host or access services that authenticate using the IP address need to ensure changes to advertised IP addresses at either the client or host site, are co-ordinated at both end user sites.
Changes to GP firewall rule tables to allow new incoming sessions into the GP LAN should be requested through your network service provider.
Internet Protocol version 6 (IPv6) is designated as the successor to IPv4, with the main driving force for its design being the expected depletion of the IPv4 public address space. The standard is specified in RFC2460: Internet Protocol, Version 6 (IPv6) Specification.
Where IPv4 uses 32 bit addresses IPv6 uses 128 bits, resulting in an immensely larger address space than IPv4 (around 79 octillion times the IPv4 address space), with the IPv6 subnet size standardised at 64 bits.
This expanded address space eliminates the primary need for network address translation (NAT), from the network design point of view, as increased flexibility in IP address allocation and routing is provided by IPv6.
As well as increased IP address space IPv6 provides several key benefits over IPv4, including:
- simpler packet headers - IPv6 specifies a new packet format, designed to minimise packet-header processing
- IPv6 provides better capabilities to support auto-configuration, such as Dynamic Host Configuration Protocol (DHCP), multicasting, traffic engineering, and zero configuration networking
- mandatory Internet Protocol security (IPsec) support - IPsec was originally developed for IPv6
(All information in this section sourced from: RIPE NCC - IPv6 Transition Mechanisms)
IPv4 and IPv6 cannot communicate directly with each other. Network operators need to run IPv4 and IPv6 networks in parallel to ensure that all parts of the internet remain reachable for everyone. There are various transition mechanisms that make this possible.
Transition mechanisms allow:
- IPv6 devices to communicate with each other over an IPv4 network ("tunnelling")
- IPv6 devices to communicate with IPv4 devices ("translation")
Transition mechanisms discussed in this section include:
Tunnelling and encapsulation
- Nat64 and DNS64
When IPv6 was developed in the 1990s as the new internet protocol to replace IPv4, which was already running out at that time, it was assumed that the transition would happen relatively swiftly and there wouldn't be a long period when both protocols would be used extensively at the same time.
As we now know, this assumption was wrong - and for the foreseeable future, both protocols will have to be used side by side until IPv6 is more widely deployed.
However, this poses a challenge, because IPv6 was not developed to be backward compatible with IPv4. This means that an IPv4 device and an IPv6 device cannot communicate directly with each other without some mechanism or device in between. These mechanisms are called "transition mechanisms".
To connect IPv6 devices over an IPv4 network, an IPv6 tunnel over the IPv4 network is used. In the context of IPv4 to IPv6 transition, the IETF RFC4213 (Basic Transition Mechanisms for IPv6 Hosts and Routers) defines tunnelling as: "A technique for establishing point-to-point tunnels by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures."
The IPv6 packet originating from the sender's IPv6 device is encapsulated at the entry node of the tunnel, where it gets an additional IPv4 header and then travels through the IPv4 network as an IPv4 packet. At the tunnel exit node, the IPv4 header gets removed (decapsulated) and the package reaches the destination IPv6 device as an IPv6 packet.
6in4 uses tunnelling to encapsulate IPv6 traffic over explicitly, manually configured IPv4 links. The IPv4 tunnel endpoint address is determined by configuration information on the encapsulating node.
6in4 is the simplest tunnelling mechanism - a manually configured tunnel towards a fixed tunnel broker. It is reliable and stable, but not scalable - it's not suitable for a provider deploying IPv6 for a large customer base. However, this method is especially suitable for an individual home user to set up IPv6 connectivity via a tunnel broker, if the network provider doesn't provide IPv6 connectivity.
6to4 is generally not used anymore. It is a tunnelling technique that solved the disadvantage of the 6in4 tunnelling technique not being scalable. A provider could use it to roll out IPv6 deployment to a large customer base. However, 6to4 has a major drawback: it can cause unacceptably long latencies, resulting in negative user experiences.
6to4 uses only the 2002::/16 IPv6 prefix and the 22.214.171.124/24 IPv4 prefix for all the tunnel endpoints (tunnel entry and exit nodes) anywhere in the world.
When a source 6to4 IPv6 device (which is often the tunnel entry point as well) wants to communicate with a destination IPv6 device, the tunnel entry point can find a tunnel exit point automatically by anycasting the prefix - no tunnel configuration is necessary. However, the 6to4 end user device needs a public IPv4 address.
The IPv4 tunnel exit point is embedded in bit numbers 17-48 of the 6to4 IPv6 address. So, the tunnel entry point automatically takes the IPv4 address of the tunnel exit point from the IPv6 address of the destination.
A schematic representation of the different parts of a 6to4 IPv6 address:
Since the tunnel endpoints are anycasted, the user has no control over which tunnel endpoint will be used. The return traffic can also choose another tunnel entry point, which can create asymmetrical routing, long latencies, and unacceptably long waiting times for users.
The 6rd tunnelling technique was developed to fix the issues with long latencies that characterised 6to4, while maintaining scalability.
The principle behind 6rd tunnelling is similar to that of 6to4, with the main difference being that the internet service provider's (ISP's) IPv4 and IPv6 address space is used for the tunnel endpoints. This means anycast is no longer used, and traffic is symmetrical and controlled by the ISP.
Just like with 6to4, the IPv4 addresses of the tunnel endpoints have to be embedded in the IPv6 address of the end user device. Since the first 32 bits of the end user device's IPv6 address will be taken up by the ISP's prefix and the second 32 bits will be the embedded IPv4 address of the tunnel endpoints, only one /64 IPv6 range is available for each device.
Requesting a larger allocation of address space (a /29 instead of a /32) would mean three more bits, which equals eight IPv6 subnets that can be assigned to each end user device, instead of just one.
You can also choose to embed only the variable part of your IPv4 address in the 6rd IPv6 address. If you are using a /21 IPv4 allocation, that would mean embedding only the variable bits - the last 11 bits (32-21 = 11bits) - instead of embedding all 32 bits of the IPv4 address.
Combining both measures (requesting a /29 IPv6 allocation and only using the variable bits of the IPv4 address) gives us the following:
In contrast to all the other transitioning mechanisms discussed above, DS-lite encapsulates IPv4 packets in IPv6 packets, resulting in the tunnelling of IPv4 over IPv6. This is just the opposite of all the other transitioning techniques discussed.
DS-lite enables an IPv6 device to connect to IPv4 devices and the IPv4 internet.
The main purpose of DS-lite is for the ISP to avoid deploying a public IPv4 address to the customer's customer premises equipment (CPE). Instead, only global IPv6 addresses are assigned.
The CPE distributes private IPv4 addresses for the clients - the same as a NAT device. However, instead of performing the NAT itself, the CPE encapsulates the IPv4 packet inside an IPv6 packet. The CPE uses its global IPv6 connection to deliver the packet to the ISP's carrier-grade NAT (CGN), which has a public IPv4 address. The IPv6 packet is decapsulated, restoring the original IPv4 packet. NAT is performed on the IPv4 packet and it is routed to the public IPv4 internet.
In the case of translation, the IPv6 packet is not encapsulated in an IPv4 packet. Rather, the IPv6 header of the packet is replaced by an IPv4 header: so, the IPv6 packet is converted into an IPv4 packet.
NAT64/DNS64 is a technique that makes it possible for IPv6-only clients to talk to IPv4 devices.
In the provider's domain there is a translator box (Nat64 server) that strips the IPv6 headers off the packets and replaces them with IPv4 headers. The NAT64 server is the endpoint for at least one IPv4 address and an IPv6 network segment of 32-bits (for example, 64:ff9b::/96).
The central part of this mechanism is DNS64. In the case of DNS64, the DNS server converts IPv6 DNS queries into IPv4 DNS queries, and then converts the received answers (the IPv4 DNS records) into IPv6 records, which can be interpreted by the IPv6-only device.
NAT64/DNS64 is used by large mobile providers.
One issue is that some mobile phone apps are only supported over IPv4 and are not IPv6 capable.
To solve this issue, an additional transition mechanism called 464XLAT is used in combination with NAT64/DNS64. 464XLAT works by installing software (CLAT demon) on the IPv6 mobile device.
464XLAT gives the mobile device a dummy (private) IPv4, so the IPv4-only applications can now work with an IPv4 address, and the demon translates locally on the mobile to IPv6.
Any transitioning technique adds complexity and requires more network management and should be avoided if possible.
Dual stacking your entire network is the preferable solution if possible.
IPv6 Transition Mechanisms - videos (RIPE NCC)
A Comparison of IPv6 over IPv4 Tunnel Mechanisms (IETF Internet-Draft)
Case Study: T-Mobile US Goes IPv6-only Using 464XLAT (Internet Society)
ALG or Application Layer Gateway is a software component that manages specific application protocols such as SIP (Session Initiation Protocol) and FTP (File Transfer Protocol). An ALG acts an intermediary between the Internet and an application server that can understand the application protocol.
The IETF RFC4291 - 'IP Version 6 Addressing Architecture' defines an Anycast Address as: "An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance)".
Border Gateway Protocol is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the internet. The current version of BGP is version 4 (BGP4), which was published as RFC4271 in 2006 which updated the specification with common industry practices and includes support for Classless Inter-Domain Routing and use of route aggregation to decrease the size of routing tables.
The Bootstrap Protocol (BOOTP) is a computer networking protocol used in Internet Protocol networks to automatically assign an IP address to network devices from a configuration server.
Carrier Grade Network Address Translation (CGN) - a large-scale NAT that translates private IPv4 addresses into public IPv4 addresses. CGN employs Network Address and Port Translation methods to aggregate multiple private IPv4 addresses into fewer public IPv4 addresses. (Source: Cisco)
Classless Interdomain Routing - allows for the aggregation of different classes of IPv4 addresses. CIDR involves two portions of an IPv4 address, the network portion and the host portion. The network portion (the left-most bits) of a given IP address identifies a given network. The right-most bits are the host portion which identifies the host within a network. CIDR allows for the host portion of an IPv4 address to, in effect, borrow bits from the network portion, thus allowing for the conservation of address space, and allowing for more control within the local network.
CLAT handles the translation of IPv4 to IPv6 for applications that do not support DNS64. CLAT is needed when transitioning to IPv6 on Global System for Mobile Communications (GSM) networks using NAT64 as the IPv4 access method.
Customer premises equipment - associated equipment, generally a router (or modem, such as DSL), located at the customer or subscriber's premises and connected with a network provider or carrier's telecommunication channel at the demarcation point - that is, where the provider service connects to the customer network.
Dynamic Host Configuration Protocol (DHCP) is a network protocol that enables a server to automatically assign an IP address to a computer from a defined range of numbers (a scope) configured for a given network.
Domain Name System - The internet's system for converting alphabetic names into numeric IP addresses. For example, when a Web address (URL) is typed into a browser, DNS servers return the IP address of the Web server associated with that name.
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin authenticity, integrity and confidentiality protection of packets. Defined in RFC4303.
File Transfer Protocol - a standard Internet protocol for transmitting files between computers over TCP/IP connections.
H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols to provide audio-visual communication sessions on any packet network. H.323 is commonly used in VoIP, Internet Telephony, and IP-based videoconferencing.
Health and Social Care Network
Internet Engineering Task Force - a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and Internet standards. IETF deals particularly with TCP/IP standards and the IP suite.
Internet Protocol Security (IPsec) is a protocol suite for secure Internet Protocol (IP) communications that works by authenticating and encrypting each IP packet of a communication.
Internet Protocol version 4 is the fourth revision of the Internet Protocol (IP).
Internet Protocol version 6 is the most recent version of the Internet Protocol (IP).
Internet service provider - a company that provides individuals and other companies with access to the internet and other related services such as web site building and virtual hosting.
Media Access Control address - a hardware address that uniquely identifies each node of a network.
The IETF RFC4291 - 'IP Version 6 Addressing Architecture' defines a Multicast Address as: "An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address".
An MX record is an entry in a DNS table which controls where mail for a particular domain name is sent.
NHS National Network
Network address translation (NAT) is a method of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.
NAT Traversal - a computer networking technique of establishing and maintaining Internet protocol connections across gateways that implement network address translation (NAT).
An operating system designed for computer networking to allow shared file and printer access among multiple computers in a network, enable the sharing of data, users, groups, security, applications, and other networking functions, typically over a LAN or private network.
Open Shortest Path First - a routing protocol for IP networks which uses a link state routing (LSR) algorithm and falls into the group of interior gateway protocols (IGPs), operating within a single autonomous system (AS). It is defined as OSPF Version 2 in RFC2328 (1998) for IPv4. Updates for IPv6 are specified as OSPF Version 3 in RFC5340 (2008).
Port Address Translation, also referred to as Network Address Port Translation, is a method by which many network addresses and their TCP/UDP ports are translated into a single network address and its TCP/UDP ports. See RFC3022 section 2.2.
A Request for Comments (RFC) is a formal document from the Internet Engineering Task Force (IETF) that is the result of committee drafting and subsequent review by interested parties.
The Réseaux IP Européens Network Coordination Centre (RIPE NCC) is the Regional Internet Registry (RIR) for Europe, the Middle East and parts of Central Asia.
Resource Reservation Protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. See RFC2205.
Simple Mail Transfer Protocol (SMTP) is an internet standard for electronic mail (email) transmission. First defined by RFC 821 in 1982, it was last updated in 2008 with the Extended SMTP additions by RFC 5321, which is the protocol in widespread use today.
Simple Network Management Protocol - a set of protocols for network management and monitoring supported by many typical network devices such as routers, hubs, bridges, switches, servers, workstations, printers, and other network components and devices.
Secure Sockets Layer - a standard security technology for establishing an encrypted link between a server and a client, typically a web server (website) and a browser, or a mail server and a mail client.
Transmission Control Protocol/Internet Protocol is the basic communication language or protocol of the Internet. It can also be used as a communications protocol in a private network. TCP and IP are two distinct computer network protocols but so commonly used together that TCP/IP has become standard terminology for referring to either or both of the protocols.
Transition Network - a backbone network service providing core network functionality; Points of Presence (PoPs); external Gateways; Access PoPs supporting Legacy N3 Access Services, Head End services; Broadband; Video Conferencing (VC); Virtual Private Network (VPN); IP Address Management (IPAM); Domain Name System (DNS); Network Time Protocol (NTP); Enhanced Internet Gateway (EIG); Enhanced Monitoring Service (EMS); Advanced Behavioural Analysis Suite (ABAS); Security Management Services; connectivity to the HSCN Peering Exchange Network; and Transitional Assistance to migrate TN end users from the legacy environment to the new HSCN environment.
User Datagram Protocol - part of the Internet Protocol suite. An alternative communications protocol to Transmission Control Protocol (TCP) used primarily for establishing low-latency and loss tolerating connections between applications. UDP is officially defined in RFC768.
A Uniform Resource Locator is a reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it.
Virtual private network (VPN) - a private network that is built over a public infrastructure. Security mechanisms, such as encryption, allow VPN users to securely access a network from different locations via a public telecommunications network, most frequently the internet.