Facilitating Data Usage Control Through IPv6 Extension Headers

Haydar Qarawlus

1 a

, Malte Hellmeier

1 b

and Falk Howar

1,2 c

Fraunhofer ISST, Dortmund, Germany

TU Dortmund University, Dortmund, Germany

Keywords:

Data Usage Control, Data Privacy, Data Sovereignty, IPv6, Extension Headers, Hop-by-Hop Options,

Destination Options.

Abstract:

Data ownership and privacy control are gaining increasing attention and relevance. More and more aspects of

enforcement methods for data ownership, data usage control, and data access control are being researched to

ﬁnd suitable solutions and practical applications. This includes technical methods, standards, and reference

architectures for controlling data after it has been shared, which are frequently discussed under the term data

sovereignty. However, enforcing data sovereignty is still challenging, and most solutions only work in trusted

environments or are focused on the application layer. In this paper, we focus on policy enforcement mecha-

nisms to facilitate data sovereignty on a lower network layer. We explore the use of steganography concepts

and IPv6 extension headers in data usage control as an additional usage control measure. We propose the use

of IPv6 Hop-by-Hop Options and Destination Options Extension Headers, including possible implementation

methods and a prototype setup. We tested our work in multiple scenarios to examine performance and appli-

cability. The results highlight the numerous beneﬁts of our proposal with minimal drawbacks.

1 INTRODUCTION

The value of data across various industries is contin-

uously increasing, with more industries depending on

data for their operations (Zrenner et al., 2019). How-

ever, this value increase raises the risks of data mis-

use (Jung and D

orr, 2022). The increased risks reduce

trust among the parties sharing data, leading to slow-

downs in data sharing to increase caution. To counter

this, much research is being done in this area, includ-

ing topics such as data ownership and usage (Otto

et al., 2022). Much of the research focuses on data

sovereignty and its effects on increasing trust. An in-

crease in trust can be achieved through, for example,

the design of speciﬁc high-level protocols and frame-

works for data sharing. Frameworks like the Inter-

national Data Spaces (IDS)

create environments for

data sharing under conditions controlled by the data

owners, enforced through technical applications such

as IDS Connectors operating in user-space at each

end. Although user-space applications, such as IDS

https://orcid.org/0000-0003-3248-1163

https://orcid.org/0000-0002-2095-662X

https://orcid.org/0000-0002-9524-4459

https://internationaldataspaces.org, last accessed:

March 2nd, 2025

Connectors, are essential to increase trust, a signiﬁ-

cant research question remains open with respect to

facilitating transparency, third-party veriﬁcation, and

possible enforcement. At the time of writing, the en-

forcement of the data usage policies deﬁned by the

owners occurs on the end systems and, in some cases,

within secure environments (Wagner et al., 2018). To

our knowledge, there is no current research that ex-

plores the embedding and enforcement of data usage

policies at different stages and locations other than the

end systems. We address this through the following

research questions (RQs):

1. Can data usage control concepts be applied at the

network protocol level?

2. What are possible implementation methods for

network-based data usage policy enforcement?

3. Which security, technical, and performance as-

pects must be considered?

In this work, we attempt to answer the research ques-

tions through the use of a known and well-deﬁned

medium, namely Internet Protocol Version 6 (IPv6)

Extension Headers. We focus on examining the com-

patibility of the IPv6 Hop-by-Hop Options and Des-

tination Options extension headers for carrying rele-

vant data usage policy data. We deﬁne a format for the

526

Qarawlus, H., Hellmeier, M., Howar and F.

Facilitating Data Usage Control Through IPv6 Extension Headers.

DOI: 10.5220/0013566200003967

In Proceedings of the 14th International Conference on Data Science, Technology and Applications (DATA 2025), pages 526-535

ISBN: 978-989-758-758-0; ISSN: 2184-285X

carried polices and examine how it can be enforced

during transport.

Our paper is organized as follows: In Section 2,

we provide background information and related work

to the topics addressed in this paper. Next, we high-

light our proposed approach for using extension head-

ers in Section 3. We provide a proof-of-concept pro-

totype setup and implementation possibilities in Sec-

tion 4. In Section 5, we evaluate our prototype across

multiple test environments. We identify the known

limitations and discuss our ﬁndings in Section 6 and

highlight possible future work in Section 6.2. Finally,

we conclude our work in Section 7.

2 BACKGROUND AND RELATED

WORK

In this section, we review related research and intro-

duce a brief background to the key concepts used in

this work.

2.1 Data Sovereignty and Control

Securing data while maintaining control in a

self-determined way characterizes the term data

sovereignty (Hellmeier and von Scherenberg, 2023;

Jarke et al., 2019). While a single deﬁnition would

not cover the term’s complexity, current conceptual-

ization describes it as the ability of a data provider

to negotiate speciﬁc contract agreements on how a

data asset is used by an external data consumer (von

Scherenberg et al., 2024). This allows data owners to

set speciﬁc conditions on how their data may be re-

quested and consumed.

Current solutions to address data sovereignty are

using connectors for each data sharing participant

in order to satisfy access control requirements (Otto

et al., 2022). Through the use of additional frame-

works and mechanisms, connectors are able to en-

force usage limitations on data within their runtime

environments (Jung and D

orr, 2022).

Research was done to explore data usage control

enforcement in different contexts. For example, re-

lated work explored the use of both trusted platform

modules and secure execution environments, such as

Intel SGX, to create isolated environments ensuring

the application of certain restrictions on data usage

(Wagner et al., 2018). Moreover, work was done

to explore the basic use of certain transmission pro-

tocols, such as the Transmission Control Protocol

(TCP), to pre-exchange data usage policy informa-

tion and create enforcement conditions once the data

is transmitted (Kelbert and Pretschner, 2013).

In other contexts, work was done on the topic of

data usage control and data privacy at the operating

system level. For example, mechanisms were created

to bind policies deﬁned by data owners to datasets be-

ing exchanged as a complete bundle. (Wang et al.,

2013). This bundle was then analyzed by the oper-

ating system’s kernel, and the conditions set in the

bundle were enforced. More recent work summarized

a wide range of usage control mechanisms across var-

ious use cases (Akaichi and Kirrane, 2025).

In this work, we explore facilitating the enforce-

ment of certain data usage control aspects through the

use of network protocols and Internet Protocol (IP)

Version 6 packet headers.

2.2 Steganography

Under the umbrella of the research domain for infor-

mation hiding, the possibility of hiding secret infor-

mation inside a cover medium for secure communica-

tion is often referred to as steganography (Ahvanooey

et al., 2022; Kahn, 1996; Krishnan et al., 2017). The

hidden information and the cover medium can range

from pure text to images and videos to speciﬁc net-

work packets. Especially in digital communication,

network steganography has established itself as an in-

dependent term with increased research interest, with

various implementations (Seo et al., 2016).

Implementations that use internet protocols such

as IPv4 and IPv6 to covertly send information have

been researched for various use cases. Methods in-

clude the use of fragmentation bits within an IPv4

header to covertly transmit data (Kundur and Ah-

san, 2003). Further, speciﬁc ﬁelds within the IPv4

packet headers, such as the overﬂow ﬁeld of the

timestamp options were used to transmit covert infor-

mation across networks (Bedi and Dua, 2020b). In

IPv6, extension headers have been used to transmit

data (Mazurczyk et al., 2019; Bedi and Dua, 2020a).

We base our approach on similar principles to embed

data usage policies within IPv6 packets.

2.3 Networking Concepts

In this subsection, we introduce the network concepts

related to speciﬁc headers, which are essential for un-

derstanding our work.

2.3.1 IP Packet Headers

Data is transmitted through the internet mainly via the

IPv4 and IPv6 network-layer protocols, which contain

metadata such as the sender and receiver IP addresses.

The header structure varies based on the protocol ver-

sion being used, as shown in Figure 1a.

Facilitating Data Usage Control Through IPv6 Extension Headers

527

IPv4 Header Payload

(a) IPv4 packet structure.

IPv6 Header TCP Header Payload

(b) Example of an IPv6 packet structure.

Figure 1: Packet structure for IPv4 and IPv6 based on Deer-

ing and Hinden (1998).

Next Header Header Length Options

Figure 2: Structure of IPv6 Hop-by-Hop Options extension

header following Deering and Hinden (1998).

The IPv4 header contains the source and des-

tination addresses, total packet length in bytes, IP

header length, data protocol information, and check-

sum. The total length of the IPv4 header is limited

to 60 bytes (Postel, 1981). IPv6 was introduced to

address the shortcomings of IPv4, including address

space and extensibility. In contrast to the ﬁxed-header

size of IPv4, IPv6 offers a more modular structures.

This allows for variable size information to be trans-

mitted if needed, as illustrated in Figure 1b. Further-

more, the variable size enable Extension Headers, ad-

dressed in more detail in Section 2.3.2. Each IPv6

packet starts with the IPv6 header for routing, con-

taining the source and destination addresses and a next

header ﬁeld, specifying the type of the next header for

processing (Hagen, 2014).

2.3.2 IPv6 Extension Headers

Extension headers were introduced in order to make

IPv6 extensible, allowing the possibility to add

functionality in the future beyond the basic deﬁni-

tions (Hagen, 2014), but are purposefully vaguely de-

ﬁned. They require only three ﬁelds: Next header,

deﬁning the type of subsequent header, length, deﬁn-

ing the length of the extension header, and the actual

data ﬁeld. Typically, extension headers are not to be

processed by intermediary nodes, except the Hop-by-

Hop Options extension header (Deering and Hinden,

1998). Figure 2 illustrates the Hop-by-Hop Options

header structure, where the data ﬁeld in the header

was renamed to options to represent the contents of

the header.

The Hop-by-hop Options header contains infor-

mation to be processed by the nodes along the net-

work path. As shown in Figure 3, each option must

contain an identifying option type ﬁeld, deﬁning data

padding, processing behavior, and whether the con-

tent can be changed by the nodes. It also speciﬁes the

length of its data ﬁeld in bytes. Finally, the data ﬁeld

contains the data to be processed at the nodes (Car-

Opt Type Opt Length Opt Data

Figure 3: Structure of an IPv6 Hop-by-Hop Option as de-

ﬁned by Deering and Hinden (1998).

penter, B and Jiang, S, 2024). The Destination Option

header retains the same data structure but is only pro-

cessed at the destination (Deering and Hinden, 1998).

In this work, we use Hop-by-Hop Options and

Destination Options headers as the means to transmit

usage policies within network packets.

3 PROPOSED APPROACH

We propose the use of IPv6 extension headers to

enrich network packets with metadata, addressing

RQ 1 by facilitating control mechanisms that en-

able data usage control at the network protocol level.

Our proposal serves as an addition to the applica-

tion and transport-level enforcement mechanisms cur-

rently available through connectors applications, or

within secure environments as examined by Wagner

et al. (2018).

Based on data sovereignty concepts, our proposal

allows data owners to deﬁne a set of rules to be at-

tached to packets leaving their system. Unlike the

Dataspace Protocol (DSP)

, which uses the full Open

Digital Rights Language (ODRL) standard to deﬁne

the policies, we present a simpler, smaller policy for-

mat due to size considerations and processing over-

heads. To enable compatibility with the DSP, ODRL

can be mapped to our proposed format, enabling the

use within existing dataspaces. Code 1 shows a sam-

ple policy following our proposed format.

{

"t": "PLC",

"d": "2001:0db8:85a3::8a2e:0370:7334",

"r": "DE",

"o": "a1b2c3"

}

Code 1: Example of a network-speciﬁc policy with a geo-

fenced restriction.

To minimize space usage, each ﬁeld within the

policy uses a single letter to identify its purpose.

The policy deﬁnition contains metadata information

to identify the type of policy (”t”). Next, it deﬁnes

the packet’s destination (”d”). Its value is an IPv6 ad-

dress, deﬁning a single user or a complete network.

This provides data owners with the ability to deﬁne

https://docs.internationaldataspaces.org/ids-knowl

edgebase/v/dataspace-protocol, last accessed: March 2nd,

2025

DATA 2025 - 14th International Conference on Data Science, Technology and Applications

528

the parties that can gain access to the data and prevent

possible misuse through malicious requests.

Next, the policy sets the data’s regional constraints

through the ﬁeld (”r”). This restriction allows data

owners to deﬁne the region or country where the data

can be accessed. This gives data owners additional

assurance to protect their data and limit data trans-

port to locations where data privacy restrictions are

not strict. For example, the data owners may deﬁne

that their data may not leave Germany (deﬁned using

the ISO 3166 code ”DE” in Code 1), where strict Gen-

eral Data Protection Regulations (GDPR) are applied.

Finally, the policy deﬁnes a ﬂexible options ﬁeld

(”o”). The use of this ﬁeld is purposefully left open

to allow for different implementations. For example,

the option ﬁeld may be interpreted as the action that

can be taken by the node inspecting this policy, e.g.,

terminating the transmission and notifying the sender.

As each packet can have one Hop-by-Hop Op-

tions and one Destination Options extension header,

the policy is embedded as a single option within that

header. As detailed in Section 2.3.2, each option must

contain three ﬁelds: The option type, the length of

the data, and the data itself. The policy content is

embedded within the data ﬁeld, with its length di-

rectly calculated and set within the option length ﬁeld.

Within the option type ﬁeld, we deﬁne that the pro-

cessing node should ignore the option header if it is

not understood and that the remaining headers should

be processed typically. This allows nodes to continue

processing or forwarding the packet without dropping

it unnecessarily. This approach follows the standard

deﬁnition of the Hop-by-Hop Options and Destina-

tion Options extension header (Deering and Hinden,

1998).

Using a plain JSON string directly within the ex-

tension header facilitates easier identiﬁcation and pro-

cessing by responsible parties, but it also increases the

risk of malicious removal of policies. To mitigate this,

obfuscation methods can prevent the detection of the

policy. Simple algorithms, such as ROT47, based on

the Caesar Cipher (Wobst, 2007), can be applied with-

out severe overhead, as they shift the characters by a

speciﬁed value.

4 IMPLEMENTATION

POSSIBILITIES

To answer RQ 2, we examine various possible ways

to implement our proposed solution. The two most

realistic and implementable approaches, in-node pro-

cessing and the use of middle boxes, are introduced in

the following.

Region A Region B

Figure 4: An example implementation based on the usage

of routers for enforcement.

4.1 In-Node Processing

The ﬁrst approach involves processing the headers di-

rectly at the network nodes. It requires a correctly

conﬁgured network infrastructure (i.e., routers, layer-

3 switches, etc.) that supports IPv6 Extension Header

processing within each node. Figure 4 illustrates a

scenario implementing this approach. The scenario

involves two users located in different regions, inter-

connected through various network nodes.

In the example shown in Figure 4, a user U

directly connected to a regional network with net-

work provider S

in “Region A”. Through this con-

nection, U

sends data to U

, which is located in “Re-

gion B”. Upon sending data, U

appends all outgo-

ing IPv6 packets with a Hop-by-Hop Options Header

containing the policy as option data. Upon arrival at

, the option contents are processed to ensure that the

constraints for forwarding of the data are met. Upon

arrival at S

, the last node in region A, along the se-

lected path, the option data are processed again to en-

sure that the route matches with the destination re-

gion. At S

in the destination’s region B, the policy

is processed further to ensure that the IPv6 address

matches the one set in the policy constraint. If any

node along this path decides not to forward the re-

quest, the transmission is interrupted. The node can

optionally notify the user through an Internet Control

Message Protocol Version 6 (ICMPv6) that the trans-

mission has failed.

The main beneﬁt of this approach is utilising exist-

ing infrastructure. As the processing is done in-node,

the delay overheads incurred are minimal. Further ad-

justments to the infrastructure are also minimal since

the method used is based on the standard IPv6 pro-

tocol, and it should be supported by network devices

adhering to it.

To allow the network infrastructure to process the

added extension headers within the packet, the net-

work operator must apply a new conﬁguration at var-

ious network locations, or at least along several pre-

selected paths designated for these packets. Depend-

ing on the size of the network and the infrastructure

setup, the difﬁculty level of this option can vary from

easily achievable to economically infeasible.

Facilitating Data Usage Control Through IPv6 Extension Headers

529

Region A Region B

Figure 5: An example implementation based on the usage

of transparent middle boxes for enforcement.

4.2 Use of Middle Boxes

To address possible implementation difﬁculties of the

ﬁrst approach, we propose a second method based on

the use of network middleboxes that reduces reali-

sation complexity. A middlebox is deﬁned formally

in RFC 3234 as “any intermediary device perform-

ing functions other than the normal, standard func-

tions of an IP router on the datagram path between

a source host and destination host” (Carpenter and

Brim, 2002, p. 3). This deﬁnition allows middleboxes

to cover a wide variety of use cases and applications,

such as ﬁrewalls, Intrusion Detection Systems, VPN

Gateways, etc. (Benhabbour and Dacier, 2025).

To implement our proposal, the network operator

must route the trafﬁc between two networks through

a suitable middlebox. Figure 5 illustrates this de-

ployment. As shown, trafﬁc ﬂowing from S

to S

is routed through a middlebox E

, either physically

by rewiring and re-routing connections, or virtually

through Software Deﬁned Networking (SDN) and

Network Function Virtualization (NFV) concepts.

The main advantage of using middleboxes is the

speed and ease of deployment. This allows our pro-

posal to be implemented for initial tests within a net-

work without signiﬁcant changes to the network in-

frastructure, as it’s attached to existing network com-

ponents. Furthermore, depending on the middlebox

performance and optimization level, this approach

can be used as a permanent implementation. The mid-

dlebox can be set up in a ”transparent” mode, in which

the transmission’s source and destination are unaware

of its existence. This could allow for further use cases

where the embedding of policies in headers does not

occur directly at the source of the transmission, for

example, with the use of a corporate Virtual Private

Network (VPN).

An additional advantage of this approach is the

ability to use different or custom Extension Header

formats. Since middleboxes examine each packet for

extension headers, operators are not restricted to Hop-

by-Hop Options extension headers; They can instead

choose to use the Destination Options extension head-

ers or create their own specialized header format per

the IPv6 standard to address speciﬁc use cases.

Generally, the use of middleboxes can incur addi-

tional delays due to the additional routing of a new

network component. Further delays can be incurred

during the processing at the middlebox itself. How-

ever, these delays depend on the middlebox’s speciﬁc

implementation and optimization level.

5 PROTOTYPICAL EVALUATION

To address the technical aspects of RQ 3, we build a

prototype of our proposal and evaluate its validity and

applicability with various parameters across different

deployment scenarios.

5.1 Evaluation Setup

We evaluate our proposal in varying conditions de-

signed to validate two main test cases. The ﬁrst case is

the implementability using middleboxes. The second

case is aimed to test the applicability of the proposed

solution outside of controlled environments.

5.1.1 Validation in Controlled Environments

For the ﬁrst test case, we use the GNS3

network

emulator to create a virtual environment closely rep-

resenting real network operating environments and

topologies. Similar to the topology illustrated in Fig-

ure 5, we created a topology that includes the two

geopolitical regions, EU and UK. Within the EU, we

set up two routers representing the top-level networks

of Germany and France, with the latter’s network con-

nected to the UK network. The link between these

networks is adapted to use a middlebox that functions

as the policy enforcer component. The task of the

middlebox is to scan each packet traversing the link

from the EU side to the UK side. The middlebox then

blocks any transmission containing a policy that re-

stricts the data transmitted to the region ”EU”. Fur-

ther, the links between all networks within the emula-

tor are conﬁgured without artiﬁcial delays.

To inject the policies at the server side in Ger-

many, we used a speciﬁc IP table conﬁguration and

created an application that uses the NetﬁlterQueue

and the Python Scapy

Libraries to intercept and add

the extension headers to outgoing IPv6 packets.

The enforcer (E

) component is implemented sim-

ilarly, using the Ubuntu distribution of the Linux op-

https://gns3.com/, Last accessed: February 17th, 2024

https://github.com/oremanj/python-netﬁlterqueue, last

accessed: March 2nd, 2025

https://scapy.net/, last accessed: March 2nd, 2025

DATA 2025 - 14th International Conference on Data Science, Technology and Applications

530

erating system and a speciﬁc IP tables ruleset. The

enforcer application was written in Python using the

aforementioned libraries. The client in the UK used

the simple wget

command-line interface (CLI) to re-

quest the main webpage from the server in Germany.

The experiments were run in batches. We use the

policy format shown in Code 1 in every batch. To

measure the possible effects of the total size of the

policy contents on the performance, we systemati-

cally adjust the size of the options ﬁeld ”o”. The ﬁeld

is initially populated with ﬁve characters, with sys-

tematic increments in character length in steps of two

characters for each experiment batch. The increments

continue until 55 characters are reached. Each experi-

ment batch consists of 10 requests sent from the client

in the UK to the server in Germany. Each request in-

cludes the policy within an extension header in each

packet header. To evaluate the cases, we collect the

mean roundtrip time and success rate metrics.

Additionally, two experiment batches are used to

evaluate the baseline roundtrip metrics without ex-

tension headers. One experiment evaluates the mean

roundtrip time without a middle box, and the other

evaluates the mean roundtrip time with a middlebox

added that only forwards the packets without addi-

tional processing. These experiments help to identify

the basic delays incurred by a packet when traversing

the emulated network setup.

5.1.2 Applicability Outside Controlled

Environments

In addition to the experiments in a controlled labora-

tory setup, we test the applicability and limits of our

proposed solution in other environments. For this, we

test the survivability of our proposed approach across

the Internet. The main driving factor behind this case

is the work done by L

eas et al. (2022). They deter-

mine that packets embedded with large Hop-by-Hop

Options extension headers are mostly blocked by In-

ternet Service Providers (ISPs). As such, we present

this test case to additionally test the content limits of

our proposed solution.

For this case, we designed various experiments

that are similar to the previous case. The experiments

include using the cloud provider Amazon Web Ser-

vices (AWS) to deploy IPv6 capable services across

multiple continents. For each test scenario, batches of

multiple HTTP requests are made to each deployed

service. Table 1 summarizes the tested AWS loca-

tions.

Similar to the experiment setup deﬁned in 5.1.1,

https://www.gnu.org/software/wget/, last accessed:

March 2nd, 2025

Table 1: AWS locations used to test this work.

Location Code City, Country

ap-south-1 Mumbai, India

ap-northeast-3 Osaka, Japan

ap-northeast-2 Seoul, South Korea

ap-southeast-1 Singapore, Singapore

ap-southeast-2 Sydney, Australia

ap-northeast-1 Tokyo, Japan

ca-central-1 Montreal, Canada

eu-central-1 Frankfurt, Germany

eu-west-1 Ireland, Ireland

eu-west-2 London, United Kingdom

eu-west-3 Paris, France

eu-north-1 Stockholm, Sweden

the requests were run in batches of 10 experiments

for each extension header size conﬁguration. Simi-

larly, each request is modiﬁed to include an extension

header with varying options ”o” ﬁeld.

Unlike the ﬁrst experiment case, this experiment

used a different technical basis for the execution. In-

stead of virtual machines running within a GNS3

emulator environment, these requests were run on a

dedicated Linux machine connected to the Internet

through a Coaxial connection with 1000 mbps down-

load speed and a 50 mbps upload speed. An HTTP

request is sent per experiment to the AWS service,

which in turn only returns an empty response, indi-

cating the request was successfully received.

To generate a baseline for each experiment batch

with an embedded policy, a baseline experiment batch

was run for each AWS location. The baseline con-

sisted of a pure IPv6 HTTP request and did not in-

clude any extension headers. These experiments en-

able us to collect baseline metrics to evaluate the

effects of extension header insertion and processing

along various routes.

In our initial experiments, we used the Hop-by-

Hop Options extension header to embed the policy

information. However, the requests were mostly re-

jected, validating the conclusions made by L

eas et al.

(2022). As such, we adjusted the packet insertion

method to use the similarly structured Destination

Options extensions header to embed the policy infor-

mation, still allowing for the use of middleboxes for

enforcement.

5.2 Results

We examine experiment results in order to answer the

performance aspect of RQ 3, structuring the presenta-

tion into two parts based on the environment used.

Facilitating Data Usage Control Through IPv6 Extension Headers

531

Figure 6: Mean roundtrip times in controlled environments.

5.2.1 Controlled Environments

In the ﬁrst result set, we present the roundtrip times

of the packets obtained from the emulated test envi-

ronment. The results from the experiments are shown

in Figure 6.

The results show that a baseline mean roundtrip

time for a request without any extension headers

traversing a middle-box-free link from the client to

the server is 10ms. The addition of the middlebox

to the setup incurs an additional 1ms delay. This ad-

ditional delay is negligible in non-real-time applica-

tions.

The ﬁrst main added delay starts when inserting

the extension headers without a middlebox instance

along the link, as seen when observing the green line

in Figure 6. Once an extension header is inserted, the

mean roundtrip time is shifted to a range between 18-

22ms. The process of header insertion at the server is

therefore incurring an additional 7-11ms delay.

Once a middlebox is added to the topology, the de-

lays are further increased, as seen from the blue line.

In this case, a middlebox operates on the link between

EU and the UK. The middlebox software intercepts

packets; However, no application logic is applied. As

such, all packets are automatically accepted for for-

warding. This interception process of the middlebox

incurs an additional 4-10ms, resulting in a total mean

roundtrip time of 23-29ms. During this time, the mid-

dlebox intercepts the packet at its inbound interface,

transfers it from the kernel level of the operating sys-

tem to the user-level, and then forwards it to the mid-

dlebox software for a ﬁnal forwarding decision.

The ﬁnal delay increase occurs when the middle-

box software is operating in ”Enforcement” mode. In

this mode, the middlebox actively parses the packet

headers and extracts the extension header content.

The extracted content is scanned for a policy accord-

ing to the format deﬁned in Section 3. After parsing

the policy contents, the middlebox compares the pol-

icy elements with the metadata of the packet headers.

If the packet is allowed to leave the EU, the decision

is to forward it towards its destination. In total, this

process incurs an additional 5-10ms, resulting in a to-

tal mean roundtrip time of 27-33ms.

Throughout the experiment batches with various

extension header sizes, the mean delays across all

cases remain stable without major ﬂuctuations. As

such, the added delay costs are easily determined at

each stage of the experiments, allowing for speciﬁc

optimizations to be conducted.

5.2.2 Outside Controlled Environments

In the second result set, we present our experiments’

mean roundtrip times and success rates against the

various AWS instances deployed worldwide. As ex-

plained in Section 5.1.2, we replace the use of the

Hop-by-Hop Options extension header with the Des-

tination Options extension header. This change does

not affect the functionality of the middlebox, as it pro-

cesses all packets and extracts header information as

conﬁgured.

The ﬁrst result subset covers the mean roundtrip

time and is shown in Figure 7. The ﬁgure includes the

baseline value for each experiment without any ex-

tension header. The baseline is distinguished with the

extension header size 0 for each plotted data series.

Further, the subset results are grouped based on their

geographic location to maintain a similar result scale

for each group.

Generally, the roundtrip times remain stable for

each region compared to its baseline until reaching

a total extension header size of 108 bytes. After-

wards, the mean roundtrip time starts to vary signif-

icantly based on the region. In the case of the Asia-

Paciﬁc region, the roundtrip times increase from be-

low 1000ms to over 12000ms in the worst case if the

total size of the extension header is larger than 108

bytes. In the case of Europe, the roundtrip times re-

mained stable throughout the various sizes, except for

the region ”eu-west-2 (London, UK)”. In this particu-

lar location, the roundtrip time increased from below

400ms to over 6000ms after the extension header size

increased to more than 108 bytes.

The ﬁnal result subset covers the mean request

success rate and is shown in Figure 8. Similar to the

previous subset, the baseline values are included at

the data point 0 for each experiment.

Similar to the behavior observed in the roundtrip

time results, the mean success rate of the packet is

measured at 100% for the majority of the extension

header sizes. Moreover, the decrease in request suc-

DATA 2025 - 14th International Conference on Data Science, Technology and Applications

532

(a) Asia-Paciﬁc (b) Europe

Figure 7: Average roundtrip times for packets tested against the various AWS regions.

(a) Asia-Paciﬁc (b) Europe

Figure 8: Average success rate for packets tested against the various AWS regions.

cess rate begins to occur after reaching 108 bytes

of total extension header size. The most detrimen-

tal results are observed in the Asia-Paciﬁc region.

Here, the request success rate starts to decrease after

108 bytes and continues to remain unstable afterward.

This continues until reaching 126 bytes, after which

all requests begin to have a 0% success rate.

Comparably, the results observed in Europe do not

experience a similar drop for the vast majority of ex-

tension header sizes. A rate drop from 100% to 0% is

only observed upon reaching an extension header size

of 126 bytes. We attribute this drop in success rate to

various factors, such as active ﬁrewalls blocking the

packets with unusually large headers, or to limitation

to packet sizes enforced by multiple network opera-

tors along the routes.

We further examined the observed varying

roundtrip times. We repeated the experiments for

those cases and closely studied the captured and trans-

ferred packets. We deduced that the requests were

experiencing drops along certain high-bandwidth or

high-speed routes to their destination. As such, the

packets were retransmitted and rerouted through other

and often longer routes.

6 DISCUSSION

Our proposal provides an answer to our main research

question RQ 1 by enabling aspects of usage control

at the network protocol level. Its main beneﬁt is the

addition of a protection layer without exposing the

payload. Owners can add policies to their data that

can be veriﬁed and enforced by authorized third par-

ties, such as network providers, without affecting any

encryption and without accessing the contents of the

data. Our proposed implementation methods and per-

formance evaluation provide answers to RQ 2 and

RQ 3.

Our proposal can be a signiﬁcant factor in increas-

ing trust among parties sharing data, as a data owner

will not need to solely trust the services running at

the data recipient’s side to enforce or uphold any

possible data usage policies. The enforcement takes

place by preventing data transfer at the network level.

Furthermore, our proposal acts to strengthen existing

data privacy regulations, like the GDPR in the Eu-

ropean Union, by providing an enforcement mecha-

nism to identify and prevent data from leaving certain

geographical regions, ensuring data privacy and data

Facilitating Data Usage Control Through IPv6 Extension Headers

533

sovereignty is preserved.

The approach has implications for data ownership

and data sovereignty, namely regarding the scope of

explored technologies. To our knowledge, no recent

work has been done on implementing aspects of data

sovereignty at the network protocol level. As ex-

plored in Section 2.1, the available research focuses

on the two main parties (sender and receiver) and not

the medium or protocols through which the data is be-

ing transferred.

6.1 Limitations

As with any new research area, we are aware of vari-

ous limitations discussed in the following.

Delay Increase. Regular IP packets are usually pro-

cessed and forwarded by nodes at the hardware level,

scanning for speciﬁc data ﬁelds, which minimizes

any possible delays. However, processing extension

headers involves increased resource requirements, as

shown in our prototypical evaluation. This can cause

signiﬁcant delays in comparison to standard packets.

To address this point, future work can examine the

possibilities of performance optimization and design-

ing frameworks to enable hardware acceleration to

process the policy header. Furthermore, methods to

efﬁciently embed the extension headers on the kernel

level, such as the work by Iurman et al. (2023), can

be applied to signiﬁcantly reduce initial delays seen

in Figure 6.

Survivability of Packets with Hop-by-Hop Options

Extension Headers. In addition to their beneﬁts,

using IPv6 Extension Header in networks adds some

security concerns. Gamilla et al. (Gamilla and Naa-

gas, 2022) concluded that extension headers can be

used to evade Intrusion Detection Systems, allowing

for various other attacks. These security implications

and increased resource use cause internet providers to

drop packets with extension headers. As discussed in

Section 5.1.2, we observed the drop of packets with

the Hop-by-Hop Options extension header. However,

packets including the Destination Options extension

header are not as strictly blocked until certain size

limits are reached. To address this point, awareness

could be raised among network providers about data

usage control and the use of extension headers for this

purpose so that network operators can handle it as a

known option.

Security Considerations. To answer the security

aspect of RQ 3, malicious actors can use man-in-the-

middle attacks to manipulate IP packets along their

route to their destination (Bhushan et al., 2017). In

this case, the extension header can be modiﬁed to alter

the intended behavior of nodes processing the policy

extension header. Using obfuscation methods such as

ROT47 can provide an additional deterrent. To ad-

dress further considerations, future work can exam-

ine the use of veriﬁcation methods to detect unautho-

rized modiﬁcations and drop the packets where such

instances have been found. Another possibility would

be to use encryption mechanisms, where authorized

nodes encrypt/decrypt the content of the policy header

and perform the required actions.

6.2 Future Work

There are various points pertaining to possible future

work in this ﬁeld, both theoretically and practically.

More work can be done on the theoretical aspect, ex-

amining new use cases and potential policies. From

the practical angle, further work can be done to ad-

dress the points deﬁned in Section 6.1 so that the

known limitations can be well addressed.

In terms of the total size of the policies being em-

bedded within an IPv6 extension header, a problem

may arise if the policy used is extensive. Large exten-

sion headers might cause problems due to fragmen-

tation applied at the intermediary nodes. To address

this possible issue, research can be done on the use

of compression algorithms and encoding mechanisms

on the content of the policy options. Here, research

can be done to examine both, the applicability of such

algorithms in this context, and the implication of their

use on the total performance.

7 CONCLUSION

In this work, we presented a novel approach to data

usage control that functions at the network protocol

level based on the use of IPv6 extension headers. We

offered multiple implementation possibilities for our

proposed approach and how it can help facilitate new

mechanisms for usage control. Overall, the evalua-

tion results demonstrate the viability of utilizing net-

work protocols and IPv6 extension headers as addi-

tional mechanisms to enforce certain usage control

conditions. Moreover, using our approach enhances

data sovereignty by having additional parties act as

enforcers of the policies without gaining access to the

data being exchanged. Our work can be further exam-

ined and expanded to explore its implementation and

adjustment requirements across various use cases.

DATA 2025 - 14th International Conference on Data Science, Technology and Applications

534

ACKNOWLEDGEMENTS

This research was supported by the Cluster of Excel-

lence Cognitive Internet Technologies CCIT and the

Center of Excellence Logistics and IT, funded by the

Fraunhofer-Gesellschaft.

REFERENCES

Ahvanooey, M. T., Zhu, M. X., Mazurczyk, W., and Ben-

dechache, M. (2022). Information hiding in digital

textual contents: Techniques and current challenges.

Computer, 55(6):56–65.

Akaichi, I. and Kirrane, S. (2025). A comprehensive re-

view of usage control frameworks. Computer Science

Review, 56:100698.

Bedi, P. and Dua, A. (2020a). Network steganography using

extension headers in ipv6. In International Confer-

ence on Information, Communication and Computing

Technology, pages 98–110. Springer, Singapore.

Bedi, P. and Dua, A. (2020b). Network steganography us-

ing the overﬂow ﬁeld of timestamp option in an ipv4

packet. Procedia Computer Science, 171:1810–1818.

Benhabbour, I. and Dacier, M. (2025). Endemic: End-to-

end network disruptions - examining middleboxes, is-

sues, and countermeasures - a survey. ACM Comput-

ing Surveys.

Bhushan, B., Sahoo, G., and Rai, A. K. (2017). Man-in-the-

middle attack in wireless and computer networking —

a review. In 2017 3rd International Conference on Ad-

vances in Computing, Communication & Automation

(ICACCA) (Fall), pages 1–6, Piscataway, NJ. IEEE.

Carpenter, B. and Brim, S. (2002). RFC 3234 - middle-

boxes: Taxonomy and issues.

Carpenter, B and Jiang, S (2024). RFC 7045: Transmission

and processing of ipv6 extension headers.

Deering, S. and Hinden, R. (1998). RFC 2460 - internet

protocol, version 6 (IPv6) speciﬁcation.

Gamilla, A. P. and Naagas, M. A. (2022). Header of death:

security implications of IPv6 extension headers to the

open-source ﬁrewall. Bulletin of Electrical Engineer-

ing and Informatics, 11(1):319–326.

Hagen, S. (2014). IPv6 essentials: Integrating IPv6 into

Your IPv4 Network. O’Reilly, Beijing, 3rd ed. edition.

Hellmeier, M. and von Scherenberg, F. (2023). A delimita-

tion of data sovereignty from digital and technological

sovereignty. ECIS 2023 Research Papers, 306.

Iurman, J., Vyncke, E., and Donnet, B. (2023). Using eBPF

to inject IPv6 extension headers. In Netdev 0x17. Net-

dev.

Jarke, M., Otto, B., and Ram, S. (2019). Data sovereignty

and data space ecosystems. Business & Information

Systems Engineering, 61(5):549–550.

Jung, C. and D

orr, J. (2022). Data usage control. In Otto, B.,

ten Hompel, M., and Wrobel, S., editors, Designing

Data Spaces, pages 129–146. Springer Cham.

Kahn, D. (1996). The history of steganography. Interna-

tional Workshop on Information Hiding.

Kelbert, F. and Pretschner, A. (2013). Data usage control

enforcement in distributed systems. In Bertino, E.,

editor, Proceedings of the third ACM conference on

Data and application security and privacy, ACM Dig-

ital Library, pages 71–82, New York, NY. ACM.

Krishnan, R. B., Thandra, P. K., and Baba, M. S. (2017). An

overview of text steganography. In 2017 Fourth Inter-

national Conference on Signal Processing, Communi-

cation and Networking (ICSCN), pages 1–6. IEEE.

Kundur, D. and Ahsan, K. (2003). Practical internet

steganography: Data hiding in IP. Proc. Texas wksp.

security of information systems.

eas, R., Iurman, J., Vyncke,

E., and Donnet, B. (2022).

Measuring IPv6 extension headers survivability with

james. In Proceedings of the 22nd ACM Internet Mea-

surement Conference, New York, NY, USA. ACM.

Mazurczyk, W., Pow

ojski, K., and Caviglione, L. (2019).

IPv6 covert channels in the wild. In Proceed-

ings of the Third Central European Cybersecurity

Conference, ACM Digital Library, pages 1–6, New

York,NY,United States. Association for Computing

Machinery.

Otto, B., ten Hompel, M., and Wrobel, S., editors (2022).

Designing Data Spaces. Springer Cham, 1 edition.

Postel, J. (1981). RFC 791: Internet protocol.

Seo, J. O., Manoharan, S., and Mahanti, A. (2016). Net-

work steganography and steganalysis - a concise re-

view. In 2016 2nd International Conference on Ap-

plied and Theoretical Computing and Communication

Technology (iCATccT), pages 368–371. IEEE.

von Scherenberg, F., Hellmeier, M., and Otto, B. (2024).

Data sovereignty in information systems. Electronic

Markets, 34(1).

Wagner, P. G., Birnstill, P., and Beyerer, J. (2018). Dis-

tributed usage control enforcement through trusted

platform modules and sgx enclaves. In Bertino, E.,

Lin, D., and Lobo, J., editors, Proceedings of the 23nd

ACM on Symposium on Access Control Models and

Technologies, pages 85–91. ACM.

Wang, X., Yong, Q., Dai, Y., Ren, J., and Hang, Z. (2013).

Protecting outsourced data privacy with lifelong pol-

icy carrying. In HPCC and EUC 2013, pages 896–

905, Los Alamitos, California and Washington and

Tokyo. Conference Publishing Services, IEEE Com-

puter Society.

Wobst, R. (2007). Cryptology unlocked. John Wiley &

Sons, Chichester and Hoboken, NJ.

Zrenner, J., M

oller, F. O., Jung, C., Eitel, A., and Otto, B.

(2019). Usage control architecture options for data

sovereignty in business ecosystems. Journal of Enter-

prise Information Management, 32(3):477–495.

Facilitating Data Usage Control Through IPv6 Extension Headers

535