Category: Computer Networks

VPN: Protocols

VPN: Protocols



Point-to-Point Protocol (PPP) is a layer 2 protocol used in point-to-point connections (dial-up, ISDN) to encapsulate any protocol at upper layers. It is an extension to HDLC.

A PPP packet has the following format:

where the most significant fields are:

  • leading and trailing flags: they are required for data framing;
  • Address and Control fields: they are inherited from HDLC but they are completely meaningless in point-to-point connections; they were kept to make it simple to upgrade the processing algorithms in HDLC devices;
  • Protocol field: it specifies the protocol at upper layer for the encapsulated packet.

‘01111110’ is the sequence delimiting the frame, but in order to send that sequence as data some stuffing rules are required. In PPP stuffing is at byte level: the escape sequence ‘01111101’ is inserted both when a byte equal to the delimiting byte appears in the data, and when a byte equal to the escape byte itself appears:

PPP byte stuffing.svg

Link Control Protocol (LCP) has the task of opening and closing PPP connections, negotiating some options (such as frame maximum length, authentication protocol).


An IP packet can not encapsulate directly a protocol at layer 3 or lower, because the ‘Protocol’ field in the IPv4 header can specify only protocols at upper layers (such as TCP, UDP, ICMP).

Generic Routing Encapsulation (GRE) is a protocol to encapsulate any protocol (including IP and other protocols at lower layers) into IP: the GRE header is inserted between the encapsulating IP header and the encapsulated packet, and the ‘Protocol’ field in the encapsulating IP header is set to 47.

The GRE header has the following format:

where the most significant fields are:

  • C, R, K, S flags (1 bit each one): they indicate the presence/absence of optional fields;
  • strict source routing (s) flag (1 bit): if set to 1, the packet is dropped if, when the source route list (‘Routing’ field) ends, the destination has not been reached yet (similar to TTL);
  • Recur field (3 bits): it specifies the allowed maximum number of additional encapsulations (currently not supported);
  • Version field (3 bits): it specifies the version of the GRE protocol (0 in this case);
  • Protocol type field (16 bits): it specifies the protocol of the encapsulated packet;

Enhanced GRE

The format of the Enhanced GRE header introduces the new ‘Acknowledgment number’ field:

5 8 13 16 32
C R K S s Recur A Flags Version (1) Protocol type
Key (payload length) Key (call ID)
Sequence number (optional)
Acknowledgment number (optional)

where the most significant fields are:

  • Key field (32 bits):
    • payload length (16 bits): it specifies the packet length excluding the GRE header (in bytes);
    • call ID (16 bits): it specifies the session ID for the packet;
  • Acknowledgment number field (32 bits): the sender puts in the packet the last packet sequence number it has received from the destination (cumulative ACK).
The new ‘Acknowledgment number’ field, in combination with the ‘Sequence number’ field, allows some additional mechanisms:

  • flow control: sliding windows avoid destination flooding, and they are moved when ACK packets are received;
  • out-of-order packet detection: Enhanced GRE was designed for PPP encapsulation, and PPP is a protocol for point-to-point connections where it is not expected packets arrive out-of-order → out-of-order packets are always discarded;
  • lost packet detection: when a timeout expires, that is no ACKs have been received, the packet is detected as lost, but the detected lost packets are not re-transmitted;
  • congestion control: when too many timeouts are detected, the packet transmission is slowed down not to congest the network.


L2TP original reference scenario: provider provisioned deployment mode.

Layer 2 Tunneling Protocol (L2TP) is a protocol to tunnel any layer 2 protocol (PPP in this discussion) into IP. L2TP was originally designed for provider provisioned access VPNs and it was standardized by IETF; later it was extended to customer provisioned access VPNs by simply implementing the LAC functionality into the user machine.

In the L2TP original reference scenario, a remote user wants to send a packet through a point-to-point (PPP) connection to an internal server inside the corporate network. An L2TP tunnel to the target L2TP Network Server (LNS) and an L2TP session inside the tunnel are required to emulate the PPP connection over the service provider network.

When the PPP frame arrives at the L2TP Access Concentrator (LAC), if an L2TP tunnel has not been established yet to the LNS, before opening an L2TP session the LAC has to establish a tunnel to the LNS: the LNS authenticates itself to the LAC by using a challenge-based mechanism similar to Challenge Handshake Authentication Protocol (CHAP), and a new control connection is created.

Each L2TP session uses two channels inside the tunnel:

  • data channel: to carry data messages, that is the PPP frames;
  • control channel: to exchange control messages, aimed to manage the communication (such as verifying that packets arrive, retransmitting lost packets, checking the right order of packets).
In contrast to data messages, control messages are exchanged in a reliable way: lost control messages are always retransmitted.

Multiple sessions may coexist within the same tunnel, sharing the same control connection, to distinguish multiple flows of PPP frames from multiple remote users: each tunnel is identified by a tunnel ID, each session is identified by a session ID.


Besides the authentication ensured during the tunnel establishing step, L2TP does not provide any security mechanism by itself: in fact it does not make sense to use mechanisms like encryption for L2TP packets travelling along the tunnel, because the service provider’s LAC still can look at the layer 2 frames → any security mechanism has to be implemented end-to-end, that is between the user and the final destination inside the corporate network.
Optionally it is possible to use IPsec through the tunnel: it provides a strong security, but it is complicated to be implemented.

A packet inside the L2TP tunnel includes several encapsulated headers:

MAC header IP header UDP header L2TP header PPP header PPP payload
PPP header

It identifies the point-to-point connection between the remote user and the internal server inside the corporate network.

L2TP header

It identifies the L2TP tunnel:

8 16 32
T L 0 S 0 O P 0 Version (2) Length
Tunnel ID Session ID
Ns Nr
Offset size Offset pad :::

where the most significant fields are:

  • T flag (1 bit): if set to 0 the packet is a data message, if set to 1 it is a control message;
  • Tunnel ID field (16 bits): it identifies the L2TP tunnel;
  • Session ID field (16 bits): it identifies the L2TP session, that is the data channel in the tunnel;
  • Ns field (16 bits): it contains the sequence number of the data/control message;
  • Nr field (16 bits): it contains the sequence number of the next control message to be received for a reliable control connection.
UDP header

Why is a layer 4 protocol such as UDP used to move layer 2 frames? This can be explained by considering firewalls over a general network: if a packet does not contain a layer 4 encapsulation, it is easier to get discarded by firewalls.
Another possible reason is that layer 4 can be accessed through sockets, while the operating system is in charge of layer 3. Since L2TP wants to be a solution against PPTP (proposed by operating system vendors), L2TP designers wanted to make it accessible to the applications and not to be tight to the will of the operating system vendors.
It is also possible to use a different layer 4 protocol (such as ATM, Frame Relay).

IP header

It contains the IP addresses of the tunnel endpoints.
In the original reference scenario, the IP addresses correspond to the LAC and the LNS.


PPTP original reference scenario: customer provisioned deployment mode.

Point-to-Point Tunneling Protocol (PPTP) is a protocol to tunnel the PPP protocol into IP. PPTP was originally designed for customer provisioned access VPNs and it was developed by major operating system vendors; later it was extended to provider provisioned access VPNs by introducing a PPTP Access Concentrator (PAC) with functionality similar to the LAC one.

The PPTP original reference scenario differentiates itself from the L2TP one for the fact that the PPTP tunnel is established between the remote user itself and the PPTP Network Server (PNS).

In contrast to L2TP, PPTP provides weak (optional) security mechanisms: the standard covers the usage of specific Microsoft-proprietary security protocols such as MPPE for encryption and MS CHAP for authentication, so there is not any negotiation of protocols.

Data channel

The encapsulated PPP frames go through the data channel:

IP header GRE header PPP header PPP payload

PPTP uses the Enhanced GRE protocol to encapsulate the PPP frames into IP. The PPP payload can be optionally encrypted by MPPE.

Control channel

The PPTP control messages go through the control channel:

IP header TCP header PPTP control message

Control messages are required for tunnel data session setup, management and tear-down, and they are sent to the well-known TCP port 1723 of the PNS.


The functionality of the Internet Protocol Security (IPsec) protocol suite in IPv4 is very similar to the one in IPv6.

The main difference is that in IPv6 IPsec is an extension header included in the standard, while in IPv4 it is a new additional protocol encapsulated into IP (for AH the ‘Protocol’ field is set to 51, for ESP it is set to 50):

Authentication Header (AH).
IPv4 header AH header TCP/UDP header payload
authenticated data
Encapsulating Security Payload (ESP).
IPv4 header ESP header
(for encryption)
TCP/UDP header payload ESP header
encrypted data
authenticated data


Secure Sockets Layer (SSL), today called Transport Layer Security (TLS), is a cryptographic protocol which is designed to provide communication security between a client and a server:

  1. the client opens a TCP connection on port 443 with the server, and sends a challenge for server authentication;
  2. the server sends to the client a Hello message containing its certificate and the response to the challenge encrypted by the server’s private key;
  3. the client verifies the certificate by looking into a list of certificates given by a trusty certification authority, then it decrypts the response to the challenge by using the server’s public key;
  4. the client decides a private key for the secure communication and sends it to the server by encrypting it through the server’s public key → from this point on all record messages will be encrypted by using that private key (which should be periodically renegotiated);
  5. often the server asks the user to type its username and password on a web page for client authentication (at application layer).


SSL can be used to create site-to-site and access VPNs, but it is mostly used in SSL (pseudo) VPNs to grant a secure access to services (such as web service, e-mail) through TCP/UDP-based tunneling. The main advantage for SSL (pseudo)VPNs is that they have a good chance of working on any network scenario, without any problems in traversing NATs, firewalls or routers, and SSL services can also be accessed by web browsers through HTTPS.

Comparison to alternative solutions

Comparison to IPsec

Advantages SSL is more convenient than IPsec in terms of:

usage: IPsec has too many options to be configured and administered, while SSL just requires to compile the application along a library implementing SSL;

security: it works at application layer ⇒ an attack to SSL just involves the application and not the whole operating system;

maturity: it has been used for a lot of years over a lot of versions ⇒ few bugs in code;

compatibility with NAT traversal:

– no authentication of IP header because SSL is on top of the transport layer;
– no encryption of ports as with IPsec ESP.


SSL is critical with DoS attacks: packets always need to be processed up to transport layer, while in IPsec they are dropped already at network layer.

Comparison to PPTP

SSL overcomes some PPTP issues:

  • poor interoperability with non-Microsoft platforms;
  • some network administrators may configure their routers to block GRE, on which PPTP is based, due to the fact that they do not like source routing feature.

SSL (pseudo)VPN flavors

Web proxying: The web server does not support HTTPS ⇒ a ‘VPN gateway’,2 at the edge of the corporate network, downloads web pages from the web server through HTTP, and ships them to the user, outside the corporate network, through HTTPS.

Port forwarding: The client runs an application supporting an application protocol (such as FTP, SMTP, POP3), hence a port forwarder installed on the client converts packets, sent to a specific port, from the application protocol into HTTPS packets sending them from another port, and vice versa.

Application translation: The web server is an application server (e.g. mail server) supporting an application protocol (such as FTP, SMTP, POP3), therefore the ‘VPN gateway’ converts HTTPS into the application protocol and vice versa through a port forwarding mechanism implemented inside the ‘VPN gateway’.

SSL’ed protocols: Some application protocols can natively integrate SSL into themselves (e.g. SMTP-over-SSL, POP-over-SSL) ⇒ client and web server can directly communicate in a secure way without the need for translation by a ‘VPN gateway’.

Application proxying: The client uses a SSL’ed protocol, but the web server does not support it ⇒ a ‘VPN gateway’ is still required with port forwarding mechanism.

Network extension: Both the client and the web server do not support SSL ⇒ two ‘VPN gateways’ are required, one at the user side and the other one at the web server side, so the SSL tunnel is created between the two ‘VPN gateways’.

Asynchronous Transfer Mode

Asynchronous Transfer Mode

Asynchronous Transfer Mode (ATM) is a connection-oriented standard to set up virtual circuits over B-ISDN networks. Each circuit is identified by a Virtual Path Identifier (VPI) and a Virtual Circuit Identifier (VCI), and it can be permanent or dynamically set up through signaling messages.

ATM cells are very small: each ATM cell is 53 bytes long, made up of a 5-bytes-long header, containing the connection identifiers, and a 48-bytes-long payload, hence low latency and low packetization delays.

ATM networks have a very complex model, derived from a telecom-operator mentality to have the full control of the network and guarantee a high fault tolerance.


When ATM was designed, it was thought to be implemented ubiquitously in the network, also at its edges in the network cards of the user PCs. Nowadays PCs at the edges are implementing only the IP protocol because its implementation is cheaper, and ATM can be found only as transport layer in the core of the network hidden from the user.

ATM Adaptation Layer (AAL) of type 5 is used for Segmentation and Reassembly (SAR):

  • Segmentation: IP packets are split into ATM cells;
  • Reassembly: ATM cells are combined into IP packets.

AAL makes interaction between IP and ATM complex, because IP addresses should be translated to ATM connection identifiers and vice versa, therefore nowadays the tendency is abandoning the ATM control plane and adopting the MPLS control plane.

Integrated Service Digital Network

Integrated Service Digital Network

Integrated Service Digital Network (ISDN) allows to carry data along with the voice: a variety of digital devices can be connected to a bus and can transmit over the available ISDN channels:

• Basic Rate Access (BRA) or Basic Rate Interface (BRI): it offers 2 data B-channels at 64 kbps and 1 signaling D-channel at 16 kbps ⇒ total: 144 kbps (good for single users or small offices);

• Primary Rate Access (PRA) or Primary Rate Interface (PRI): it offers 30 data B-channels at 64 kbps and 1 signaling D-channel at 16 kbps ⇒ total: 2 Mbps (good for companies).

The transmission is based on Time Division Multiplexing (TDM); all channels go to a Network Termination and enter the network over a digital wire called ‘local loop’. The channels inherit the logics from telecom operators: they keep being alive also when no data is exchanged.

IPv6: extension headers

IPv6: extension headers


There are six extension headers, added only when needed and processed in the following order:

1. Hop by hop option: it includes optional information to be processed by every hop;
2. Routing: it enables source routing, that is the source decides which route the packet needs to take;
3. Fragment: it manages fragmentation;
4. Authentication Header (AH): it allows to authenticate the sender;
5. Encapsulating Security Payload (ESP): it allows to encrypt the packet contents;
6. Destination option: it includes optional information to be processed just by the destination.

All the extension headers have the same generic format (the length must be a multiple of 64 bits):

where the fields are:

Next Header field: it specifies the following extension header in the chain, or the header at upper layer (e.g. TCP/UDP) if this is the last extension header;

Header Length field: it specifies the length of the current extension header. As new extension headers can be standardized over time, old devices may not be able to process recent extension headers ⇒ they can look at the ‘Length’ field to skip the unknown extension header. The ‘Header Length’ field may be not in some extension headers (such as the ‘Fragment’ extension header) which the IPv6 standard defines as having fixed length.

Hop by hop option and Destination option

The Hop by hop option and Destination option extension headers can include multiple additional options:

  • Hop by hop option: it includes options which every router the packet goes through has to process;
  • Destination option: it includes options which just the destination has to process.

For example, if there are two options with 8-bit-long values, the extension header will have the following format:

where each option always has the three following fields:

  • Length field (8 bits): it specifies the length of the current option, so that routers unable to recognize the option can just skip it;
  • Type field (8 bits): it identifies the current option.

The first two bits always specify the action to be executed in case the option is not recognized, while the third bit specifies whether the option can be changed on-the-fly:

-00 the current option can be ignored and it is possible to proceed to the next one;
-01 the packet must be discarded;
-10 the packet must be discarded and an ICMPv6 Parameter Problem must be generated;
-11 the packet must be discarded and an ICMPv6 Parameter Problem must be generated, unless the destination address is a multicast one;
-xx0 the option can not be changed;
-xx1 the option can be changed on-the-fly;

  • Value field (variable length): it contains the value of the option.


The Routing extension header allows the source to decide decides which route the packet needs to take (source routing), and it has the following format:

where the fields are:

  • Routing Type field (8 bits): it specifies the type of routing (currently ‘0’ for classical source routing);
  • Segment Left field (8 bits): it specifies the number of remaining hops to the destination;
  • Router Address fields (128 bits each one): they are the list of the IPv6 addresses of the routers which the packet should go through.

In the example in figure, source S sends the packet towards destination D, adding a ‘Routing’ extension header which forces the packet to go through intermediate routers R1 and R2. So at first the packet apparently has router R1 as destination, while real destination D is specified as last step in the router list specified by the ‘Routing’ extension header.

When the packet arrives at router R1, this recognizes it as apparently addressed to it; in fact, its address appears in the ‘Destination Address’ field in the IPv6 header. Router R1 checks the next headers and it discovers the packet contains a ‘Routing’ extension header, realizing that the final destination for the packet is another host (in particular the ‘Segment Left’ field says that two hops should be traversed before arriving at the final destination).

Router R1 finds the IPv6 address of the next hop to which it should send the packet and replaces it with its IPv6 address, then it sends the packet with destination set to R2. The process will continue hop by hop, until destination D will receive an IPv6 packet whose ‘Routing’ extension header contains the ‘Segment Left’ field set to 0, which means that the packet has reached the final destination.

Destination D is able to know all the hops the packet passed through because they are all written in the ‘Routing’ extension header, so it can forward the reply to source S by specifying the same (reversed) list of hops.


The Fragment extension header allows to send a packet in smaller parts called ‘fragments’, and it has the following format:

where the fields are:

  • Fragment Offset field (13 bits): it specifies the byte number at which the fragment starts within the fragmented section in the original packet;
  • More Fragments (M) flag (1 bit): if it is set to 0 the current packet is the last fragment;
  • Identification field (32 bits): all the fragments of a specific packet have the same identifier.

Each packet includes two sections:

  • a section that can not be fragmented, so it is repeated in all fragments: it includes the IPv6 header and all the extension headers preceding the ‘Fragment’ extension header;
  • a section that can be fragmented: it includes all the extension headers following the ‘Fragment’ extension header and the packet payload.

In contrast to IPv4, only the sender node is allowed to fragment the datagrams, while IPv6 routers do not support fragmentation. Moreover, the IPv6 standard strongly suggests to use Path MTU Discovery instead of fragmentation for performance reasons.


The solutions developed for IPv6 have been ported from IPv4-IPsec protocol suite. In IPv6 IPSec is an integrated protocol suite that defines two headers:

  • Authentication Header (AH): it authenticates the whole packet, but the fields which are changed on passing from one hop to another (e.g. ‘Hop limit’ field), by guaranteeing that no one has tempered the contents of the packet;
  • Encapsulating Security Payload (ESP): it authenticates and encrypts the packet payload for data privacy.


IPsec does not define which algorithms are to be used for encryption and authentication, but the two parties have to agree on which ones to use for exchanging IPsec-protected information ⇒ flexibility: algorithms are chosen according to the current needs.

A Security Association (SA) can be defined as the set of agreements between two parties A and B on the private keys and algorithms to be used for ESP authentication and encryption and AH authentication. Each SA is identified by an identification tag called Security Parameter Index (SPI), included in the AH and ESP headers, and it is a one-way logical channel: A and B have to open a SA to agree on keys and algorithms for messages going from A to B, and they have to open another SA to agree on them for messages going from B to A. Often a SA is opened for each TCP port.


How can A and B agree on secrete keys avoiding that extraneous people know them? There are three main strategies:

static configuration: the keys are configured manually in A and B ⇒ key negotiation is not required at all;

Diffie-Hellman method: it allows to agree on a key without exchanging it, hence nobody can discover the secret keys by sniffing the traffic between A and B;

• Internet Key Exchange (IKE) protocol: it uses digital certificates and asymmetrical cryptography to send secret keys in a secure way.

The IKE protocol specifies that an IKE SA has to be established from A to B to agree on the secret keys for the child SA from A to B, and vice versa another one for the child SA from B to A. The IKE SA from A to B consists of the following operations based on asymmetrical cryptography:

1. B asks A for a secret key to be used for the child SA from A to B;
2. A asks a trusty certification authority for B’s digital certificate, in order to know if B is really who he is telling to be;
3. the certification authority provides A with B’s digital certificate, encrypted by using the certification authority’s private key, containing B’s signature, that is the association between B and a public key;
4. A decrypts the digital certificate by using the certification authority’s public key and learns the public key associated to B;
5. A sends the secret key for the child SA to B, encrypting the message by using the public key associated to B so that it can be decrypted only by knowing B’s private key;
6. B receives the message from A, decrypts it by using its private key and learns the secret key decided by A for the child SA;
7. the child SA using the agreed secret key can be opened from A to B.

Some extraneous people may look at the traffic exchanged between A and B and guess the secret keys after a while, by performing brute-force attacks or analyzing some deduced statistical information. Internet Security Association Key Management Protocol (ISAKMP) is a sub-protocol of IKE to periodically renegotiate the secret keys in a secure way, so that extraneous people do not have time to guess them.


The Authentication Header (AH) guarantees connectionless integrity and data origin authentication for IP packets: it authenticates the whole packet, but the fields which are changed on passing from one hop to another (e.g. ‘Hop limit’ field), by guaranteeing that no one has tempered the contents of the packet. AH has problems dealing with NATs, because it also authenticates the addresses and the ports. The key concept is: no one can change the packet, everyone can read it.

The Authentication Header has the following format:

where the fields are:

  • Next Header field (8 bits): it specifies the next encapsulated protocol;
  • Payload Length field (8 bits): it specifies the Authentication Header length in 32-bit words -2 (it may be cleared to zero);
  •  Security Parameters Index (SPI) field (32 bits): it identifies the Security Association for this datagram (if cleared to zero, a Security Association does not exist; values in the range 1 to 255 are reserved);
  • Sequence Number field (32 bits): it contains a monotonically increasing counter value;
  • Message Digest field (variable length): it summarizes the contents of the packet by using a secret key: everyone who wants to change the contents of the packet has to know the key in order to recompute the message digest (similar to the error detection field).


The Encapsulating Security Payload (ESP) header provides origin authenticity, integrity and confidentiality protection for IP packets: it authenticates and encrypts the packet payload for data privacy. Though ESP can authenticate, it does not perform the same functionality of AH: ESP does not authenticate the whole IPv6 packet. The key concept is: no one can read the packet, therefore no one can change it.

where the fields are:

  • Security Parameters Index (SPI) field (32 bits): it identifies the Security Association for this datagram;
  • Sequence Number field (unsigned 32 bits): it contains a monotonically increasing counter value. The ‘Sequence Number’ field is mandatory for the sender and it is always present even if the receiver does not select to enable the anti-replay service for a specific SA, but processing of this field is at the discretion of the receiver;
  • Payload Data field (variable length): it contains the data described by the ‘Next header’ field;
  • Padding field (variable length 0 to 255 bits): padding may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary;
  • Padding Length field (8 bits): it specifies the size of the ‘Padding’ field (in bytes);
  • Next Header field (8 bits): an IPv4/IPv6 protocol number describing the format of the ‘Payload Data’ field;
  • Authentication Data field (variable length): it contains an Integrity Check Value (ICV) computed over the ESP packet minus the ‘Authentication Data’ field. The ‘Authentication Data’ field length is specified by the selected authentication function. The ‘Authentication Data’ field is optional: it is included only if the authentication service has been selected for the SA at issue. The authentication algorithm specification must specify the ICV length and the comparison rules and processing steps for validation. Note that the ‘Authentication Data’ field is not encrypted.


Two usage modes are possible for ESP (optionally in combination with AH):

  • transport mode: ESP does not encrypt the IPv6 header, hence anybody in the middle is able to see the source and destination IP addresses in the IPv6 header:

  • tunnel mode: the IPv6 packet is encapsulated into another IPv6 packet having ESP, hence the IPv6 header of the original packet, containing the source and destination IP addresses, is encrypted and nobody can see it:

IPv6: header

IPv6: header

The standard IPv6 header has the following fixed-size (40 bytes) format:

where the most significant fields are:

  • Version field (4 bits): it is not really used, because the packet discrimination is made by the layer 2 ⇒ this enables the dual-stack approach;
  • Priority field (8 bits): equivalent to the IPv4 ‘Type of Service’ field, it allows to distinguish different kinds of services for quality of service;
  • Flow label field (20 bits): it allows to distinguish different flows for quality of service;
  • Next header field (8 bits): it refers to the packet payload, that is a header at upper layer (e.g. TCP/UDP) or the first extension header in the chain;
  • Hop limit field (8 bits): it is equivalent to the IPv4 ‘Time To Live’ field;
  • Source address field (128 bits): it contains the sender’s IPv6 source address for the packet;
  • Destination address field (128 bits): it contains the addressee’s IPv6 destination address for the packet.

Some IPv4 fields have been removed:

  • Checksum field: error protection is delegated to layer 2 (frame check sequence);
  • Fragmentation field: fragmentation is delegated to the ‘Fragment’ extension header;
  • Header length field: IPv6 header is fixed-size, as additional features are optionally offered by extension headers.
IPv6: Addressing

IPv6: Addressing


Address format

Each IPv6 address is 128-bit-long, and the prefix replaces the netmask:


The concept of link in IPv6 is the same as the concept of subnetwork in IPv4: in IPv4 a subnetwork is a set of hosts with the same prefix; in IPv6 a link is the actual physical network.

All the hosts in the same subnetwork belong to the same link and vice versa:

  • on-link hosts have the same prefix, so they can communicate directly;
  • off-link hosts have different prefixes, so they can communicate through a router.

Addressing space organization

In this section we will see the global unicast addresses, the local unicast addresses and the multicast addresses.

Global unicast addresses

They are equivalent to the IPv4 public addresses, and they begin with the three bits ‘001’:

  • Prefix: it must be the same as the one assigned to the link which the host is connected to. Assignment criterion for prefixes is topology-based: they are assigned according to the service provider hierarchy:

– Top Level Authority (TLA): a large service provider;
– Next Level Authority (NLA): an intermediate service provider;
– Subnet Level Authority (SLA): the organization.

  • Interface identifier: it identifies the host interface. Optionally it can be in EUI-64 format: the 64-bit IPv6 interface identifier derives from the host’s 48-bit MAC address:

where the ‘universal’ bit is the seventh bit in the OUI and it is changed from 0 to 1.

Addresses for IPv4 interoperability

They are to be used during the transition phase, and they begin with 80 bits set to zero:

  • IPv4-mapped addresses: the first 80 bits are zeros and the next 16 bits are set to one:
  • IPv4-compatible addresses: the first 80 bits are zeros and the next 16 bits are set to zero (e.g. the IPv6 address ‘::’ maps the IPv4 address ‘’):
    The compatible format is used to represent an IPv6 node. This format enables you to configure an IPv6 node to use IPv6 without having a real IPv6 address.

    Local Unicast Addresses

Link local addresses

In IPv6, link-local addresses always begin with 1111111010 (FE80). Unlike site-local addresses, link-local addresses are never forwarded by routers and therefore can only be reached on the link. This is the reason why the next 54 bits are set to 0. The last 64 bits are set randomly by the operating system. The prefix is FE80::/64.

Site local addresses

In IPv6, the first 10 bits of a site-local address are set to 1111111011, which is why these addresses always begin with FEC0. The following 54 bits are the subnet ID, which you can use in your organization for hierarchical routing, and the last 64 bits are the interface ID, which is the part that has to be unique on a link (local network on which hosts communicate without intervening routers). Thus, the prefix of a site-local address is FEC0::/10. They are equivalent to the IPv4 private addresses. They are deprecated

Unique Local Unicast

The address block FC00::/7 is divided into two /8 groups:

  • The block FC00::/8 has not been defined yet. It has been proposed to be managed by an allocation authority, but this has not gained acceptance in the IETF. This block is also used by the cjdns mesh network.
  • The block FD00::/8 is defined for /48 prefixes, formed by setting the 40 least-significant bits of the prefix to a randomly generated bit string. This results in the format fdxx:xxxx:xxxx:: for a prefix in this range. RFC 4193 offers a suggestion for generating the random identifier to obtain a minimum-quality result if the user does not have access to a good source of random numbers.

Multicast addresses

A multicast address identifies a group of stations and it has the following format:

where the fields are:

  • Flag field (4 bits): it is used to mark a multicast group:

– T = 1: the multicast group is temporary (e.g. user-defined conference call);
– T = 0: the multicast group is permanent (e.g. address of all the hosts in the network, it can not be overwritten);

  • Scope field (4 bits): it is used to limit the diffusion of the multicast (better than IPv4 TTL):

1 – node local: the packet can not go outside the host;
2 – link local: the packet can not go outside the layer 2 network;
5 – site local: the packet can not go outside e.g. the campus network;
8 – organization local: the packet can not go outside the organization network;
E – global: the packet can go everywhere;

  • Group ID field (112 bits): it identifies the multicast group, and the packet is forwarded to all the nodes in the group.

If a host wants to belong to a multicast group, it needs to ask for it by using the ICMP protocol; once it is added to the multicast group, it will receive all the packets sent to that particular multicast address. It is very important to notice that the hosts that will receive a multicast packet are not defined by the source, but they are ‘decided’ by the destinations.

Solicited node multicast addresses

Every operating node by default belongs to a solicited node multicast group whose address derives from its IPv6 address:

There may be more than one host in the same multicast group, but generally there are not since the multicast address is generated from the IPv6 address.

Mapping IPv6 over Ethernet

Each multicast packet is delivered through an Ethernet frame with a specific MAC address derived from the IPv6 multicast address, so that the packet is processed just by the interested hosts:


As the prefixes for global addresses are assigned according to the service provider hierarchy, if a company wants to change from a service provider to another one, all the links in the company network will have to change their prefixes. IPv6 is meant to support easy renumbering for both hosts and routers:

  • hosts: routers gradually stop advertising the old prefix (deprecated) and start advertising the new one (preferred) ⇒ each host will have during the migration phase two addresses with different prefixes for the same interface;
  • routers: Router Renumbering is a standard which allows the border router to notify the other internal routers of the new prefix.

However renumbering still has some unsolved problems, related to how to automatically update e.g. the DNS entries, firewall filters, address-based corporate policies, etc.


A big company may decide to buy Internet connectivity from two different service providers because it wants to keep being connected to the Internet even if one of the service providers has some problems.

As the prefixes for global addresses are assigned according to the service provider hierarchy,

each host inside the company network will have two global addresses with different prefixes for the same interface, hence the host will have to select which address to use for every outcoming packet. This may cause some non-trivial configuration problems:

  • routing based on destination address: the host should be able to select the right prefix for outcoming packets, otherwise let us suppose the host selects the provider A’s prefix but the destination is in the provider B’s networ, therefore the border router thanks to its routing mechanisms will forward the packet directly into the provider B’s networ. Then the provider B will block that packet because the source address has a different prefix;
  • double registration in DNSes: the host should be registered in DNSes by two different addresses for the same alias;
  • automatic renumbering: renumbering mechanisms should dynamically support a change from a provider B to a provider C.

Scoped addresses

A host can have two interfaces (e.g. an Ethernet interface and a wi-fi one) which can be connected to two different links at the same time. When the host wants to send a packet to a link local target address, it does not know whether to make the packet exit the interface A or the interface B, because both the links have the same prefix; moreover, as each link local address is unique within its link, a host in the link A may have the same link local address as another host in the link B.

In IPv6 the host needs to specify in the target IPv6 address an identifier called scope which is used to identify the physical interface (e.g. FE80::0237:00FF:FE02:A7FD%19). The values for the scopes are selected by the operating system according to its internal criteria.

IPv6: security issues

IPv6: security issues

People have little experience with security problems because IPv6 is not used much yet, hence IPv6 could still have undiscovered security holes which may be exploited by attackers. Moreover, during the migration phase hosts need to open two ports in parallel, one for IPv4 and another one for IPv6, hence two ports have to be protected against attacks from outside.

DDoS attacks with SYN flooding

A host interface can have multiple IPv6 addresses, therefore it can generate multiple TCP SYN requests, each one with a different source address, to a server in order to saturate its memory by making it open several unclosed TCP connections.

Fake Router Advertisement messages

A host may start sending ‘Router Advertisement’ messages advertising fake prefixes therefore the other hosts in the link will start to send packets with wrong prefixes in their source addresses.

IPv6: core network

IPv6: core network

In the IPv6 core networks the main goal is to have IPv6 traffic without upsetting the network existing for more than 20 years which at present is working well. It would not be possible to sustain the human and technological costs for worldwide migration to radically change the existing IPv4 network to make it IPv6.


The goal for 6 Provider Edge (6PE) solution is to connect IPv6 clouds one with each other through a MPLS backbone. 6PE requires that the operator’s network works by MPLS. In this scenario the provider’s edge is represented by the first routers which users’ CPEs meet.

Our goals are to:

  • Keeping the network core unchanged (without excluding the possibility for future changes).
  • Adding the IPv6 support to the edge of the provider’s network.
  • Delivering IPv6 routing information via MPLS/BGP, like in VPNs.

To obtain this the primary requirement is to have a MPLS core network.

In the picture:

  • the MPLS core network is the one made up of PE-1, P-1, P-2, PE-2;
  • the two side devices, PE-1 and PE-2, are partially ‘immersed’ in the MPLS network;
  • links between CE and PE can be thought as links providing an ADSL connection to the home user.

6PE is thought to take a fully-working core network, able to transport IPv4 packets via MPLS, and add the IPv6 support just to the provider’s edge routers (PE). In fact, once a packet is encapsulated into an MPLS packet, the intermediate devices will not be interested anymore in the type of contained packet, but they will be interested just in the label which allows them to distinguish the LSP to which to route it.

In fact, on PEs a further update is required in order to add the MG-BGP support, protocol which allows to transport and communicate both IPv4 and IPv6 routes. Then the big advantage for this solution consists in requiring to update just PEs and not all intermediate routers: after all, an operation that the provider can manage without high costs.

How IPv6 networks are advertized

  1. CE-3 advertizes that it is able to reach the IPv6 network ‘2001:3::/64’.
  2. This information is received also by PE-2.
  3. PE-2 sends this information to all the PEs in the network, saying that it is able to reach ‘2001:3::/64’ through the next hop ‘FFFF:’, nevertheless its interface is IPv4 (this is because if an IPv6 route is given an IPv6 next hop needs to be given).
  4. PE-1 receives this information.
  5. PE-1 sends the received information to all the routers connected to it, so also to the home CEs, saying that it is able to reach the network ‘2001:3::/64’.
  6. If an MPLS path between PE-1 and the address ‘’ does not exist yet, the classical  MPLS mechanisms (so the LDPv4 signaling protocol) are used to set up this path.

How IPv6 traffic is routed

To route an IPv6 packet two labels are used:

  • MP-BGP label (internal): it identifies the destination CE to which the destination PE needs to send the packet;
  • LDP/IGPv4 label (external): it identifies the LSP between the two PEs over the MPLS network.


Let us suppose that a host in the network ‘2001:1::/64’ wants to send a packet to a host in network ‘2001:3::/64’:

1. the packet arrives at CE-1;

2. CE-1 knows that the network ‘2001:3::1/64’ exists and it sends the packet towards PE-1;

3. PE-1 puts two labels in front of the packet: the internal label and the external label;

4. PE-1 sends the packet to P-1, which sends it to P-2;

5. P-2, that is the penultimate hop, removes the external label from the packet (penultimate label popping) and sends it to PE-2;

6. PE-2 removes the internal label and sends the packet to CE-3;

7. CE-3 forwards the packet to the destination in the network ‘2001:3::/64’.


  • PE routers have to be dual stack and to support MP-BGP, while intermediate routers do not need any change.
  • This solution provides customers with a native IPv6 service without changing the IPv4 MPLS core network (it requires minimal operational costs and risks).
  • This solution scales as long as there are few IPv6 clouds to be deployed.


Internet Control Message Protocol version 6 (ICMPv6) is an integral part of the IPv6 standard, and it in turn integrates the functionalities of ARP and IGMP protocols expanding them.

All the ICMPv6 messages are put just after the extension headers in the packet, and they have the same generic format:

where the ‘Type’ field identifies the type of ICMPv6 message:

  •  diagnostics messages: like in ICMPv4, they allow to report errors or problems in the network:

1 = Destination Unreachable
2 = Packet Too Big
3 = Time Exceeded
4 = Parameter Problem

  •  messages used by the ping command:

128 = Echo Request
129 = Echo Reply

  •  Multicast Listener Discovery messages: they expand the IGMP functionality:

130 = Multicast Listener Query
131 = Multicast Listener Report
132 = Multicast Listener Done

  •  Neighbor Discovery messages: they expand the ARP functionality:

133 = Router Solicitation
134 = Router Advertisement
135 = Neighbor Solicitation
136 = Neighbor Advertisement
137 = Redirect

Packet Too Big

When a router receives a packet having a too large size, it performs a technique called Path MTU Discovery: it discards the packet and sends back an ICMPv6 message of type Packet Too Big in order to notify the sender of the allowed Maximum Transmission Unit (MTU) size and force it to send again the packet itself (and the next packets) with a size not exceeding the MTU specified by the router. This technique has the goal to avoid fragmentation as much as possible.

Multicast Listener Discovery

Multicast Listener Discovery is the component in ICMPv6 which expands the functionality of the IPv4 IGMP protocol to manage multicast group  memberships:

  • Multicast Listener Query:

– General Query: the router asks hosts if they are interested in joining some of multicast groups;

– Multicast Address Specific Query: the router asks hosts if they are interested in joining a particular multicast group;

  • Multicast Listener Report: the host notifies the router it wants to join a particular multicast group to receive all the multicast packets addressed to the multicast address corresponding to the specified multicast group;
  •  Multicast Listener Done: the host notifies the router it wants to stop receiving the multicast packets for a particular multicast group.

Neighbor Discovery

Neighbor Discovery is the component in ICMPv6 which expands the functionality of the IPv4 ARP protocol:

  • Neighbor Solicitation: the host sends a multicast packet having, as the target IPv6 address, the solicited node multicast address corresponding to the IPv6 address of which it wants to learn the MAC address;
  •  Neighbor Advertisement: the host having the specified IPv6 address sends back its MAC address;
  •  Router Solicitation: the host sends a multicast packet to solicit the router sending back a ‘Router Advertisement’ message containing the interface identifier associated to the link;
  •  Router Advertisement: the router advertises its presence within the link reporting the interface identifier associated to the link.

‘Neighbor Discovery’ ICMPv6 messages are used to autoconfigure the IPv6 addresses for a host connecting to a link: firstly the host has to get a link local address in order to be able to contact the other hosts within the link, then it has to get a global address in order to be able to exit the link and access the Internet by a globally unique address.

Link local address autoconfiguration process

The link local address is autoconfigured by using ‘Neighbor Solicitation’ and ‘Neighbor Advertisement’ ICMPv6 messages:

1. the host generates by itself an IPv6 address candidate to be its link local address:
– prefix: it is always ‘FE80::’;
– interface identifier: it can be generated either based on MAC address (EUI-64 format) or randomly for privacy reasons (traceability);

2. the host sends via multicast a ‘Neighbor Solicitation’ message to all the hosts within the link, specifying as target IPv6 address its self-generated address and asking if a host whose link local address is the same as the specified IPv6 address exists in the link (Duplicated Address Detection);

3. if a host having the sender’s link local address already exists in the link, it sends back a ‘Neighbor Advertisement’ message to the sender, which will have to generate randomly another candidate address and send via multicast another ‘Neighbor Solicitation’ message;

4. if no one replies, the address is unique within the link and the host is able to contact every other host within the same link by using its link local address, but it is not able to access the Internet yet because it needs a global address.

Global address autoconfiguration process

The global address is autoconfigured by using ‘Router Solicitation’, ‘Router Advertisement’, ‘Neighbor Solicitation’ and ‘Neighbor Advertisement’ ICMPv6 messages:

1. the host sends via multicast a ‘Router Solicitation’ message to solicit the router sending back a ‘Router Advertisement’ message containing the interface identifier associated to the link;

2. the router sends back a ‘Router Advertisement’ message containing the two flags ‘Managed Address Configuration’ (M) and ‘Other configuration’ (O):

  •  M = 1: the host has to contact the DHCP server for the prefix of the link and the other network configuration parameters (such as the DNS address), without caring of ‘Router Advertisement’ messages from the router (stateful configuration);
  •  M = 0: the host has to look at the ‘O’ flag:

– O = 1: the host can take the prefix of the link from the ‘Router Advertisement’ message, but it still has to contact the DHCP server for the other network configuration parameters (such as the DNS address);

– O = 0: the host can take the prefix of the link from the ‘Router Advertisement’ message, and no other configuration information is available from the DHCP server (stateless configuration), hence either the other network configuration parameters (such as the DNS address) will have to be configured by hand on the host, or the host can get the DNS address via IPv4;

3. the host generates by itself an IPv6 address candidate to be its global address:
– prefix: it is equal to the prefix of the link, taken either from the ‘Router Advertisement’ message or by contacting the DHCP server;
– interface identifier: it can be generated either based on MAC address (EUI-64 format) or randomly for privacy reasons (traceability);

4. the host sends via multicast a ‘Neighbor Solicitation’ message to all the hosts within the link, specifying as target IPv6 address its self-generated address and asking if a host whose global address is the same as the specified IPv6 address exists in the link (Duplicated Address Detection);

5. if a host having the sender’s global address already exists in the link, it sends back a ‘Neighbor Advertisement’ message to the sender, which will have to generate randomly another candidate address and send via multicast another ‘Neighbor Solicitation’ message;

6. if no one replies, the address is globally unique and the host is able to access the Internet by using its global address.

Another implementation proposed by Microsoft consists in the possibility for the host to contact the DNS server without knowing its address: the host sends packets to a fixed anycast address, and the network takes care of delivering the packet to the DNS server. However this implementation is not really used:

• implementations for anycast address management are rare;

• this solution is not supported by GNU/Linux operating system.

Autoconfiguration is based on the MAC address, so if the network card breaks and needs to be replaced the host will have to change its address, but the caches (e.g. the DNS cache) can not update immediately ⇒ static configuration is still possible, especially for fixed machines (e.g. servers for public websites) which need to avoid changing their addresses in order to keep being reachable as much continuously as possible.