IP Addressing Considerations
draft-iannone-ip-addressing-considerations-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Luigi Iannone | ||
| Last updated | 2023-08-21 (Latest revision 2023-06-26) | ||
| Replaces | draft-iannone-internet-addressing-considerations, draft-iannone-scenarios-problems-addressing | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists::Revised I-D Needed | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-iannone-ip-addressing-considerations-01
Network Working Group L. Iannone, Ed.
Internet-Draft Huawei
Intended status: Informational 26 June 2023
Expires: 28 December 2023
IP Addressing Considerations
draft-iannone-ip-addressing-considerations-01
Abstract
The Internet Protocol (IP) has been the major technological success
in information technology of the last half century. As the Internet
becomes pervasive, IP has been replacing communication technology for
many domain-specific solutions, but it also has been extended to
better fit the specificities of the different use cases. For
Internet addressing in particular, as it is defined in RFC 791 for
IPv4 and RFC 8200 for IPv6, respectively, there exist many
extensions. Those extensions have been developed to evolve the
addressing capabilities beyond the basic properties of Internet
addressing. This discusses the properties the IP addressing model,
showcasing the continuing need to extend it and the methods used for
doing so.
The most important aspect of the analysis and discussion in this
document is that it represents a snapshot of the discussion that took
place in the IETF (on various mailing lists and several meetings) in
the early 2020s. While the community did not converge on specific
actions to be taken, the content of this document may nonetheless be
of use at some point in the future should the community decide so.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 December 2023.
Iannone Expires 28 December 2023 [Page 1]
Internet-Draft IP Addressing Considerations June 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Current Properties of Internet Protocol Addressing . . . . . 5
3.1. Property 1: Fixed Address Length . . . . . . . . . . . . 5
3.2. Property 2: Ambiguous Address Semantic . . . . . . . . . 6
3.3. Property 3: Limited Address Semantic Support . . . . . . 6
4. Perceived IP Addressing Shortcomings . . . . . . . . . . . . 6
5. Existing IP Addressing Extensions . . . . . . . . . . . . . . 9
5.1. Length Extensions . . . . . . . . . . . . . . . . . . . . 9
5.2. Identity Extensions . . . . . . . . . . . . . . . . . . . 13
5.3. Semantic Extensions . . . . . . . . . . . . . . . . . . . 17
5.4. IP Addressing Extensions Overall Summary . . . . . . . . 21
6. Concerns Raised by IP Addressing Extensions . . . . . . . . . 23
6.1. Limiting Address Semantics . . . . . . . . . . . . . . . 23
6.2. Complexity and Efficiency . . . . . . . . . . . . . . . . 23
6.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Fragility . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. Summary of Concerns . . . . . . . . . . . . . . . . . . . 27
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Looking Forward . . . . . . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Informative References . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Desirable Networking Features . . . . . . . . . . . 50
Appendix B. IP Addressing Extensions driven by Use-Cases . . . . 53
B.1. Communication in Constrained Environments . . . . . . . . 53
B.2. Communication within Dynamically Changing Topologies . . 55
B.3. Communication among Moving Endpoints . . . . . . . . . . 58
B.4. Communication Across Services . . . . . . . . . . . . . . 63
B.5. Communication Traffic Steering . . . . . . . . . . . . . 64
B.6. Communication with built-in security . . . . . . . . . . 65
Iannone Expires 28 December 2023 [Page 2]
Internet-Draft IP Addressing Considerations June 2023
B.7. Communication protecting user privacy . . . . . . . . . . 66
B.8. Communication in Alternative Forwarding Architectures . . 66
Appendix C. Examples of Internet Addressing Properties
Extensions . . . . . . . . . . . . . . . . . . . . . . . 68
C.1. Length Extensions . . . . . . . . . . . . . . . . . . . . 68
C.2. Identity Extensions . . . . . . . . . . . . . . . . . . . 70
C.3. Semantic Extensions . . . . . . . . . . . . . . . . . . . 72
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 78
1. Rationale
The Internet Protocol (IP), positioned as the unified protocol at the
(Internet) network layer, is seen by many as key to the innovation
stemming from Internet-based applications and services. Even more
so, with the success of the TCP/IP protocol stack, IP has been
gradually replacing existing domain-specific protocols, evolving into
the core protocol of the ever-growing communication eco-system.
At its inception, roughly 40 years ago [RFC0791], the Internet
addressing system, represented in the form of the IP address and its
locator-base (topological) semantics, has brought about the notion of
a 'common namespace for all communications'. Compared to proprietary
technology-specific solutions, such 'common namespace for all
communications' ensures end-to-end communication from any device
connected to the Internet to another.
However, use cases, associated services, node behaviors, and
requirements on packet delivery have since been significantly
extended, with suitable Internet technology being developed to
accommodate them in the framework of addressing that stood at the
aforementioned beginning of the Internet's development. This
continuing evolution includes addressing and, therefore, the address
structure, as well as the semantic that is being used for packet
forwarding (e.g., service identification, content location, device
type). In this, the topological location centrality of IP is
fundamental when reconciling the often-differing semantics for
'addressing' that can be found new use cases. Due to this
centrality, use cases often have to adopt specific solutions, e.g.,
translating/mapping/converting concepts, semantics, and ultimately,
solution-specific addressing, and integrate them into the common IP
addressing model.
The IETF community has, at various times, discussed the IP addressing
model and its possible evolution, while keeping its structure
unchanged, so to accommodate future use cases and existing
deployments. This document does (or at least tries to) capture the
discussion that the IETF community held about IP addressing model in
Iannone Expires 28 December 2023 [Page 3]
Internet-Draft IP Addressing Considerations June 2023
the early 2020s. The discussion originated from two memos proposing
an analysis of the extensions developed to better adapt the IP
addressing model to specific use cases
[I-D.iannone-internet-addressing-considerations] and a (shorter)
companion memo trying to formalize a related problem statement
[I-D.iannone-scenarios-problems-addressing]. Further, an informal
side meeting was organized during IETF 112 [SIDE112] with a panel of
experts, which had a lively discussion. That discussion continued,
with a very large volume of messages, on the INTArea mailing list and
other mailing lists, like architectural discuss, honing into the
related question on what desired features a network should provide in
the first place (see Appendix A for a summary of the feature listed
in that discussion). The IAB also touched briefly the topic in one
of their retreats. The momentum and the amplitude of the discussion
did raise the question whether or not to go for a formal Working
Group, although the community failed to converge on a specific
direction that could eventually lead to an evolution of the IP
addressing model and at the same time the steam diminished.
The latest revision of the aforementioned individual submissions
captured the discussion of the wider community, summarizing mail
exchange and including contributions from a large set of co-authors.
This separate memo includes a large portion of those documents, in
addition to follow-up discussions since, with the purpose to document
the inputs, thoughts, and opinions of a part of the IETF community.
2. Introduction
As the Internet Protocol adoption has grown towards the global
communication system we know today, its characteristics have evolved
subtly, with [RFC6250] documenting various aspects of the IP service
model and its frequent misconceptions, including Internet addressing.
The very origin of the discussion resulting in this document was the
observation that in various use-cases, addressing has evolved and is
somehow adapted or extended.
Iannone Expires 28 December 2023 [Page 4]
Internet-Draft IP Addressing Considerations June 2023
These desired features have implications that go beyond addressing
and need to be tackled from a larger architectural point of view.
Nevertheless, the discussion that took place only focused on the
addressing viewpoint, identifying shortcomings perceived from this
perspective, in particular with respect to IP addressing properties.
The key properties of Internet addressing, outlined in Section 3, are
(i) the fixed length of the IP addresses, (ii) the ambiguity of IP
addresses semantic, while still (iii) providing limited IP address
semantic support. Those properties are derived directly as a
consequence of the respective standards that provide the basis for
Internet addressing, most notably [RFC0791] for IPv4 and [RFC8200]
for IPv6, respectively. The limitations of the IP addressing
properties are discussed in Section 4, including the various use
cases and scenarios where such limitations actually show up.
What is interesting to note is that different use-cases may actually
been handled with the same type of extension. This shows that, based
on an architectural approach, evolving the properties discussed in
Section 3 is possible and even desirable since it has the advantage
to be designed in a coherent fashion, avoiding point-solutions which
may create contention when deployed. To this end, Section 5
discusses Internet addressing properties extensions, associating the
different use-cases that take advantage of the property's extensions.
While the various extensions proposed through the years certainly did
a fine job in solving the problem at hand, this "patching" approach
raises also concerns. Section 6 outlines considerations and concerns
that arise with such extension-driven approach, arguing that any
requirements for solutions that would revise the basic Internet
addressing would require to address those concerns.
3. Current Properties of Internet Protocol Addressing
In this section, the three most acknowledged properties related to
_Internet addressing_ are detailed. Those are (i) fixed IP address
length, (ii) ambiguous IP address semantic, and (iii) limited IP
address semantic support.
3.1. Property 1: Fixed Address Length
The fixed IP address length is specified as a key property of the
design of Internet addressing, with 32 bits for IPv4 ([RFC0791]), and
128 bits for IPv6 ([RFC8200]), respectively. Given the capability of
the hardware at the time of IPv4 design, a fixed length address was
considered as a more appropriate choice for efficient packet
forwarding. Although the address length was once considered to be
variable during the design of Internet Protocol Next Generation
("IPng", cf., [RFC1752]) in the 1990s, it finally inherited the
Iannone Expires 28 December 2023 [Page 5]
Internet-Draft IP Addressing Considerations June 2023
design of IPv4 and adopted a fixed length address towards the current
IPv6. As a consequence, the 128-bit fixed address length of IPv6 is
regarded as a balance between fast forwarding (i.e., fixed length)
and practically boundless cyberspace (i.e., enabled by using 128-bit
addresses).
3.2. Property 2: Ambiguous Address Semantic
Initially, the meaning of an IP address has been to identify an
interface on a network device, although, when [RFC0791] was written,
there were no explicit definitions of the IP address semantic.
With the global expansion of the Internet protocol, the semantic of
the IP address is commonly believed to contain at least two notions,
i.e., the explicit 'locator', and the implicit 'identifier'. Because
of the increasing use of IP addresses to both identify a node and to
indicate the physical (or virtual) location of the node, the
intertwined address semantics of identifier and locator was then
gradually observed and first documented in [RFC2101] as 'locator/
identifier overload' property. With this, the IP address is used as
an identification for host and server, very often directly used,
e.g., for remote access or maintenance.
3.3. Property 3: Limited Address Semantic Support
Although IPv4 [RFC0791] did not add any semantic to IP addresses
beyond interface identification (and location), time has proven that
additional semantics are desirable (c.f., the history of 127/8
[HISTORY127] or the introduction of private addresses [RFC1918]).
Later on, IPv6 [RFC4291] introduced some form of additional semantics
based on specific prefix values, for instance link-local addresses or
a more structured multicast addressing. Nevertheless, systematic
support for rich address semantics remains limited and basically
prefix-based.
4. Perceived IP Addressing Shortcomings
What follows is the list identified during the various exchange,
which is however not to be considered exhaustive.
1. Limiting Alternative Address Semantics: Several communication
scenarios pursue the use of alternative semantics (e.g., for
privacy, for service identification, or for content
identification) preserving what constitute an 'address' of a
packet traversing the Internet, which may fall foul of the
defined network interface semantic of IP addresses.
Iannone Expires 28 December 2023 [Page 6]
Internet-Draft IP Addressing Considerations June 2023
2. Hampering Security: Aligning with the semantic and length
limitations of IP addressing may hamper the security objectives
of any new semantic, possibly leading to detrimental effects and
possible other workarounds (at the risk of introducing fragility
rather than security).
3. Hampering Privacy: The simple use of IP addresses as global
stable interface identifiers raises clear privacy concerns. It
goes beyond profiling the traffic of end users, since it can even
be easily used to obtain the real identity of individuals.
4. Complicating Traffic Engineering: Utilizing a plethora of non-
address inputs (e.g., port numbers, segments ID, payload) into
the traffic steering decision in real networks may complicate
traffic engineering in that it makes the development of suitable
policies more complex, while also leading to possible contention
between methods being used.
5. Hampering Efficiency: Extending IP addressing through point-wise
solutions also hampers efficiency, e.g., through needed re-
encapsulation (therefore increasing the header processing
overhead as well as header-to-payload ratio), through introducing
path stretch, or through requiring compression techniques to
reduce the header proportion of large addresses when operating in
constrained environments.
6. Fragility: The introduction of point solutions, each of which
comes with possibly own usages of address or packet fields,
together with extension-specific operations, increases the
overall fragility of the resulting system, caused, for instance,
through contention between feature extensions that were neither
foreseen in the design nor tested during the implementation
phase.
7. Extensibility: Accommodating new requirements through ever new
extensions as an extensibility approach to addressing compounds
aspects discussed before, i.e., fragility, efficiency etc. It
complicates engineering due to the clearly missing boundaries
against which contentions with other extensions could be managed.
It complicates standardization since extension-based
extensibility requires independent, and often lengthy,
standardization processes. And ultimately, deployments are
complicated due to backward compatibility testing required for
any new extension being integrated into the deployed system.
The above shortcomings are not apparent in every possible use case,
rather they appear, in a more or less severe form, in specific use
cases. Hereafter, a set of such kind of use cases, for which
Iannone Expires 28 December 2023 [Page 7]
Internet-Draft IP Addressing Considerations June 2023
extensions to the IP addressing model have been already proposed on a
case-by-case basis, is listed. An extensive discussion about these
use cases and related extensions can be found in Appendix B. Here,
for each use case, a very short description is provided, while
Table 1 shows how the previously identified issues do arise somehow
in these use cases.
* Communication in Constrained Environments: Resource constrained
networks like Internet of Things (IoT), Industrial IoT, avionics.
* Communication within Dynamically Changing Topologies: Networks
that exhibit dynamically changing, e.g. satellite networks,
vehicular networks, Flying Ad-hoc NETworks (FANETs).
* Communication among Moving Endpoints: The huge progress in
wireless communications (WiFi, 3G/4G/5G, etc) have enable
ubiquitous endpoint mobility.
* Communication Across Services: Communication among services and
resources from various aspects such as remote collaboration,
shopping, content production, delivery, education, etc.
* Communication Traffic Steering: The ability to control where the
traffic goes through (beyond the simple best-effort shortest-
path).
* Communication with built-in security: AAA (Authentication,
Authorization, Accountability), end-to-end encryption.
* Communication protecting user privacy: Private communication and
fingerprinting avoidance.
* Communication in Alternative Forwarding Architectures: Non-
Internet Protocol based networks.
Iannone Expires 28 December 2023 [Page 8]
Internet-Draft IP Addressing Considerations June 2023
+===============+=======+=======+=======+=======+=======+=======+
| | Issue | Issue | Issue | Issue | Issue | Issue |
| | 1 | 2 | 3 | 4 | 5 | 6 |
+===============+=======+=======+=======+=======+=======+=======+
| Constrained | | | | x | x | x |
| Environments | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
| Dynamically | x | | x | x | x | x |
| Changing | | | | | | |
| Topologies | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
| Moving | x | | x | x | x | x |
| Endpoints | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
| Across | x | | x | x | x | x |
| Services | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
| Traffic | x | | x | x | x | x |
| Steering | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
| Built-in | x | x | | x | x | x |
| Security | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
| Alternative | x | | | x | | x |
| Forwarding | | | | | | |
| Architectures | | | | | | |
+---------------+-------+-------+-------+-------+-------+-------+
Table 1: Issues Involved in Challenging Scenarios.
5. Existing IP Addressing Extensions
As already stated, during the years various technologies have been
developed that circumvent some IP addressing shortcomings, basically
extending the properties defined in Section 3. Hereafter, an
overview of such existing extensions is provided, grouped by
property. For each group, a general description and the methodology
used by the various extensions is provided. Details about the cited
technologies relates to properties extension can be found in
Appendix C.
5.1. Length Extensions
Extensions in this subsection aim at extending the property described
in Section 3.1, i.e., the fixed IP address length.
Iannone Expires 28 December 2023 [Page 9]
Internet-Draft IP Addressing Considerations June 2023
When IPv6 was designed, the main objective was to create an address
space that would not lead to the same situation as IPv4, namely to
address exhaustion. To this end, while keeping the same addressing
model like IPv4, IPv6 adopted a 128-bit address length with the aim
of providing a sufficient and future-proof address space. The choice
was also founded on the assumption that advances in hardware and
Moore's law would still allow to make routing and forwarding faster,
and the IPv6 routing table manageable.
We observe, however, that the rise of new use cases but also the
number of new devices, e.g., industrial/home or small footprint
devices, was possibly unforeseen. Sensor networks and more generally
the Internet of Things (IoT) emerged after the core body of work on
IPv6, thus different from IPv6 assumptions, 128-bit addresses were
costly in certain scenarios. On the other hand, given the huge
investments that IPv6 deployment involved, certain solutions are
expected to increase the addressing space of IPv4 in a compatible
way, and thus extend the lifespan of the sunk investment on IPv4.
At the same time, it may also be possible to use variable and longer
address lengths to address current networking demands. For example,
in content delivery networks, longer addresses such as URLs are
required to fetch content, an approach that Information-Centric
Networking (ICN) applied for any data packet sent in the network,
using information-based addressing at the network layer.
Furthermore, as an approach to address the routing challenges faced
in the Internet, structured addresses may be used in order to avoid
the need for routing protocols. Using variable length addresses
allow as well to have shorter addresses. So, for requirements for
smaller network layer headers, shorter addresses could be used, maybe
alleviating the need to compress other fields of the header.
Furthermore, transport layer port numbers can be considered short
addresses, where the high order bits of the extended address are the
public IP of a NAT. Hence, in IoT deployments, the addresses of the
devices can be really small and based on the port number, but they
all share the global address of the gateway to make each one having a
globally unique address.
5.1.1. Shorter Address Length
5.1.1.1. Description
In the context of IoT [RFC7228], where bandwidth and energy are very
scarce resources, the static length of 128-bit for an IP address is
more a hindrance than a benefit since 128-bit for an IP address may
occupy a lot of space, even to the point of being the dominant part
of a packet. In order to use bandwidth more efficiently and use less
energy in end-to-end communication, solutions have been proposed that
Iannone Expires 28 December 2023 [Page 10]
Internet-Draft IP Addressing Considerations June 2023
allow for very small network layer headers instead.
5.1.1.2. Methodology
Header Compression/Translation: One of the main approaches to reduce
header size in the IoT context is by compressing it. Such
technique is based on a stateful approach, utilizing what is
usually called a 'context' on the IoT sensor and the gateway for
communications between an IoT device and a server placed somewhere
in the Internet - from the edge to the cloud.
The role of the 'context' is to provide a way to 'compress' the
original IP header into a smaller one, using shorter address
information and/or dropping some field(s); the context here serves
as a kind of dictionary.
Separate device from locator identifier: Approaches that can offer
customized address length that is adequate for use in such
constrained domains are preferred. Using different namespaces for
the 'device identifier' and the 'routing' or 'locator identifier'
is one such approach.
5.1.2. Longer Address Length
5.1.2.1. Description
Historically, obtaining adequate address space is considered as the
primary and raw motivation to invent IPv6. Longer address (more than
32-bit of IPv4 address), which can accommodate almost inexhaustible
devices, used to be considered as the surest direction in 1990s.
Nevertheless, to protect the sunk cost of IPv4 deployment, certain
efforts focus on IPv4 address space depletion question but engineer
IPv4 address length in a more practical way. Such effort, i.e., NAT
(Network Address Translation), unexpectedly and significantly slows
IPv6 deployment because of its high cost-effectiveness in practice.
Another crucial need for longer address lengths comes from "semantic
extensions" to IP addresses, where the extensions themselves do not
fit within the length limitation of the IP address. This sub-section
focuses on address length extensions that aim at reducing the IPv4
addresses depletion, while Section 5.3, i.e., address sematic
extensions, may still refer to extensions when longer address length
are suitable to accommodate different address semantic.
5.1.2.2. Methodology
Split address zone by network realm: This methodology first split
Iannone Expires 28 December 2023 [Page 11]
Internet-Draft IP Addressing Considerations June 2023
the network realm into two types: one public realm (i.e., the
Internet), and innumerable private realms (i.e., local networks,
which may be embedded and/or having different scope). Then, it
splits the IP address space into two type of zones: global address
zone (i.e., public address) and local address zone (e.g., private
address, reserved address). Based on this, it is assumed that in
public realm, all devices attached to it should be assigned an
address that belongs to the global address zone. While for
devices attached to private realms, only addresses belonging to
the local address zone will be assigned. Local realms may have
different scope or even be embedded one in another, like for
instance, light switches local network being part of the building
local network, which in turn connects to the Internet. In the
local realms, addresses may have a pure identification purpose.
For instance, in the last example, addresses of the light switches
identify the switches themselves, while the building local network
is used to locate them.
Given that the local address zone is not globally unique, certain
mechanisms are designed to express the relationship between the
global address zone (in public realm) and the local address zone
(in any private realm). In this case, global addresses are used
for forwarding when a packet is in the public realm, and local
addresses are used for forwarding when a packet is in a private
realm.
5.1.3. Examples
Table 2 summarizes methodologies and lists examples of IP address
length extensions.
+========================+======================+=============+
| | Methodology | Examples |
+========================+======================+=============+
| Shorter Address Length | Header compression/ | 6LoWPAN, |
| | translation | ROHC, SCHC |
+------------------------+----------------------+-------------+
| | Separate device from | EIBP, LISP, |
| | locator identifier | ILNP, HIP |
+------------------------+----------------------+-------------+
| Longer Address Length | Split address zone | NAT, EzIP |
| | by network realm | |
+------------------------+----------------------+-------------+
Table 2: Summary Length Extensions
Iannone Expires 28 December 2023 [Page 12]
Internet-Draft IP Addressing Considerations June 2023
5.2. Identity Extensions
Extensions in this subsection attempt extending the property
described in Section 3.2, i.e., 'locator/identifier overload' of the
ambiguous address semantic.
From the perspective of Internet users, on the one hand, the implicit
identifier semantic results in a privacy concern due to network
behavior tracking and association. Despite that IP address
assignments may be dynamic, they are nowadays considered as 'personal
data' and as such undergoes privacy protection regulations like
General Data Protection Regulation ("GDPR" [VOIGT17]). Hence,
additional mechanisms are necessary in order to protect end user
privacy.
For network regulation of sensitive information, on the other hand,
dynamically allocated IP addresses are not sufficient to guarantee
device or user identification. As such, different address allocation
systems, with stronger identification properties are necessary where
security and authentication are at highest priority. Hence, in order
to protect information security within a network, additional
mechanisms are necessary to identify the users or the devices
attached to the network.
5.2.1. Anonymous Address Identity
5.2.1.1. Description
As discussed in Section 3.2, IP addresses reveal both 'network
locations' as well as implicit 'identifier' information to both
traversed network elements and destination nodes alike. This enables
recording, correlation, and profiling of user behaviors and
historical network traces, possibly down to individual real user
identity. The IETF, e.g., in [RFC7258], has taken a clear stand on
preventing any such pervasive monitoring means by classifying them as
an attack on end users' right to be left alone (i.e., privacy).
Regulations such as the EU's General Data Protection Regulation
(GDPR) classifies, for instance, the 'online identifier' as personal
data which must be carefully protected; this includes end users' IP
addresses [VOIGT17].
Even before pervasive monitoring [RFC7258], IP addresses have been
seen as something that some organizational owners of networked system
may not want to reveal at the individual level towards any non-member
of the same organization. Beyond that, if forwarding is based on
semantic extensions, like other fields of the header, extension
headers, or any other possible extension, if not adequately protected
it may introduce privacy leakage and/or new attack vectors.
Iannone Expires 28 December 2023 [Page 13]
Internet-Draft IP Addressing Considerations June 2023
5.2.1.2. Methodology
Traffic Proxy: Detouring the traffic to a trusted proxy is a
heuristic solution. Since nodes between trusted proxy and
destination (including the destination per se) can only observe
the source address of the proxy, the 'identification' of the
origin source can thereby be hidden. To obfuscate the nodes
between origin and the proxy, the traffic on such route would be
encrypted via a key negotiated either in-band or off-band.
Considering that all applications' traffic in such route can be
seen as a unique flow directed to the same 'unknown' node, i.e.,
the trusted proxy, eavesdroppers in such route have to make more
efforts to correlate user behavior through statistical analysis
even if they are capable of identifying the users via their source
addresses. The protection lays in the inability to isolate single
application specific flows. According to the methodology, such
approach is IP version independent and works for both IPv4 and
IPv6.
Source Address Rollover: Privacy concerns related to address
'identifier' semantic can be mitigated through regular change
(beyond the typical 24 hours lease of DHCP). Due to the semantics
of 'identifier' that an IP address carries, such approach promotes
to change the source IP address at a certain frequency. Under
such methodology, the refresh cycling window may reach to a
balance between privacy protection and address update cost. Due
to the limited space that IPv4 contains, such approach usually
works for IPv6 only.
Private Address Spaces: Their introduction in [RFC1918] foresaw
private addresses (assigned to specific address spaces by the
IANA) as a means to communicate purely locally, e.g., within an
enterprise, by separating private from public IP addresses.
Considering that private addresses are never directly reachable
from the Internet, hosts adopting private addresses are invisible
and thus 'anonymous' for the Internet. Besides, hosts for purely
local communication used the latter while hosts requiring public
Internet service access would still use public IP addresses.
Address Translation: The aforementioned original intention for using
private IP addresses, namely for purely local communication,
resulted in a lack of flexibility in changing from local to public
Internet access on the basis of what application would require
which type of service.
If eventually every end-system in an organization would require
some form of public Internet access in addition to local one, an
adequate number of public Internet addresses would be required for
Iannone Expires 28 December 2023 [Page 14]
Internet-Draft IP Addressing Considerations June 2023
providing to all end systems. Instead, address translation
enables to utilize many private IP addresses within an
organization, while only relying on one (or few) public IP
addresses for the overall organization.
In principle, address translation can be applied recursively.
This can be seen in modern broadband access where Internet
providers may rely on carrier-grade address translation for all
their broadband customers, who in turn employ address translation
of their internal home or office addresses to those (private
again) IP addresses assigned to them by their network provider.
Two benefits arise from the use of (private to public IP) address
translation, namely (i) the hiding of local end systems at the
level of the (address) assigned organization, and (ii) the
reduction of public IP addresses necessary for communication
across the Internet. While the latter has been seen for long as a
driver for address translation, in this section, we focus on the
first one, also since we see such privacy benefit as well as
objective as still being valid in addressing systems like IPv6
where address scarcity is all but gone [GNATCATCHER].
Separate device from locator identifier: Solutions that make a clear
separation between the routing locator and the identifier, can
allow for a device ID of any size, which in turn can be encrypted
by a network element deployed at the border of routing domain
(e.g., access/edge router). Both source and end-domain addresses
can be encrypted and transported, as in the routing domain, only
the routing locator is used.
5.2.2. Authenticated Address Identity
5.2.2.1. Description
In some scenarios (e.g., corporate networks) it is desirable to being
able authenticate IP addresses in order to prevent malicious
attackers spoofing IP addresses. This is usually achieved by using a
mechanism that allows to prove ownership of the IP address. Another
growing use case where identity verification is necessary for
security and safety reasons is in the aeronautical context, for both
manned and unmanned aerial vehicles ([RFC9153],
[I-D.haindl-lisp-gb-atn]).
5.2.2.2. Methodology
Self-certified addresses: This method is usually based on the use of
Iannone Expires 28 December 2023 [Page 15]
Internet-Draft IP Addressing Considerations June 2023
nodes' public/private keys. A node creates its own interface ID
(IID) by using a cryptographic hash of its public key (with some
additional parameters). Messages are then signed using the nodes'
private key. The destination of the message will verify the
signature through the information in the IP address. Self-
certification has the advantage that no third party or additional
security infrastructure is needed. Any node can generate its own
address locally and then only the address and the public key are
needed to verify the binding between the public key and the
address.
Collision-resistant addresses: When self-certification cannot be
used, an alternative approach is to generate addresses in a way
that is statistically unique (collision-resistant).
Authentication of the address then occurs in an out-of-band
protocol, where the unique identifier is resolved to
authenticating information.
Third party granted addresses: DHCP (Dynamic Host Configuration
Protocol) is widely used to provide IP addresses, however, in its
basic form, it does not perform any check and even an unauthorized
user without the right to use the network can obtain an IP
address. To solve this problem, a trusted third party has to
grant access to the network before generating an address (via DHCP
or other) that identifies the user. User authentication done
securely either based on physical parameters like MAC addresses or
based on an explicit login/password mechanism.
5.2.3. Examples
Table 3, summarize the methodologies and lists examples of identity
extensions.
Iannone Expires 28 December 2023 [Page 16]
Internet-Draft IP Addressing Considerations June 2023
+============================+======================+=============+
| | Methodology | Examples |
+============================+======================+=============+
| Anonymous Address Identity | Traffic Proxy | VPN, TOR, |
| | | ODoH |
+----------------------------+----------------------+-------------+
| | Source Address | SLAAC |
| | Rollover | |
+----------------------------+----------------------+-------------+
| | Private Address | ULA |
| | Spaces | |
+----------------------------+----------------------+-------------+
| | Address Translation | NAT |
+----------------------------+----------------------+-------------+
| | Separate device from | EIBP, LISP |
| | locator identifier | |
+----------------------------+----------------------+-------------+
| Authenticated Address | Self-certified | CGA |
| Identity | Addresses | |
+----------------------------+----------------------+-------------+
| | Third party granted | DHCP-Option |
| | addresses | |
+----------------------------+----------------------+-------------+
Table 3: Summary Identity Extensions
5.3. Semantic Extensions
Extensions in this subsection try extending the property described in
Section 3.3, i.e., limited address semantic support.
As explained in Section 3.2, IP addresses carry both locator and
identification semantic. Some efforts exist that try to separate
these semantics either in different address spaces or through
different address formats. Beyond just identification, location, and
the fixed address size, other efforts extended the semantic through
existing or additional header fields (or header options) outside the
Internet address.
How much unique and globally routable an address should be? With the
effect of centralization, edges communicate with (rather) local DCs,
hence a unique address globally routable is not a requirement
anymore. There is no need to use globally unique addresses all the
time for communication, however, there is the need of having a unique
address as a general way to communicate to any connected entity
without caring what transmission networks the packets traverse.
Iannone Expires 28 December 2023 [Page 17]
Internet-Draft IP Addressing Considerations June 2023
5.3.1. Extended Address Semantics
5.3.1.1. Description
Several extensions have been developed to extend beyond the limited
IPv6 semantics. Those approaches may include to apply structure to
the address, utilize specific prefixes, or entirely utilize the IPv6
address for different semantics, while re-encapsulating the original
packet to restore the semantics in another part of the network. For
instance, structured addresses have the capability to introduce
delimiters to identify semantic information in the header, therefore
not constraining any semantic by size limitations of the address
fields.
We note here that extensions often start out as being proposed as an
extended header semantic, while standardization may drive the
solution to adopt an approach to accommodate their semantic within
the limitations of an IP address. This section does include examples
of this kind.
5.3.1.2. Methodology
Semantic prefixes: Semantic prefixes are used to separate the IPv6
address space. Through this, new address families, such as for
information-centric networking [CAROFIGLIO19], service routing or
other semantically rich addressing, can be defined, albeit limited
by the prefix length and structure as well as the overall length
limitation of the IPv6 address.
Separate device/resource from locator identifier: The option to use
separate namespaces for the device address would offer more
freedom for the use of different semantics. For instance, the
static binding of IP addresses to servers creates a strong binding
between IP addresses and service/resources, which may be a
limitation for large Content Distribution networks (CDNs)
[FAYED21].
As an extreme form of separating resource from locator identifier,
recent engineering approaches, described in [FAYED21], decouple
web service (semantics) from the routing address assignments by
using virtual hosting capabilities, thereby effectively mapping
possibly millions of services onto a single IP address.
Structured addressing: One approach to address the routing
challenges faced in the Internet is the use of structured
addresses, e.g., to void the need for routing protocols. Benefits
of this approach can be significant, with the structured addresses
capturing the relative physical or virtual position of routers in
Iannone Expires 28 December 2023 [Page 18]
Internet-Draft IP Addressing Considerations June 2023
the network as well as being variable in length. Key to the
approach, however, is that the structured addresses capturing the
relative physical or virtual position of routers in the network,
or networks in an internetwork may not fit within the fixed and
limited IP address length (cf., Section 5.1.2). Other structured
approaches may be the use of application-specific structured
binary components for identification, generalizing URL schema used
for HTTP-level communication but utilized at the network level for
traffic steering decisions.
Localized forwarding semantics: Layer 2 hardware, such as SDN
switches, are limited to the use of specific header fields for
forwarding decisions. Hence, devising new localized forwarding
mechanisms may be based on re-using differently existing header
fields, such as the IPv6 source/destination fields, to achieve the
desired forwarding behavior, while encapsulating the original
packets in order to be restored at the local forwarding network
boundary. Networks in those solutions are limited by the size of
the utilized address field, e.g., 256 bits for IPv6, thereby
limiting the way such techniques could be used.
5.3.2. Existing or Extended Header Semantics
5.3.2.1. Description
While the former sub-section explored extended address semantic,
thereby limiting any such extended semantic with that of the existing
IPv6 semantic and length, additional semantics may also be placed
into the header of the packet or the packet itself, utilized for the
forwarding decision to the appropriate endpoint according to the
extended semantic.
Reasons for embedding such new semantics may be related to traffic
engineering since it has long been shown that the IP address itself
is not enough to steer traffic properly since the IP address itself
is not semantically rich enough to adequately describe the forwarding
decision to be taken in the network, not only impacting _where_ the
packet will need to go, but also _how_ it will need to be sent.
5.3.2.2. Methodology
In-Header extensions: One way to add additional semantics besides
the address fields is to use other fields already present in the
header.
Headers option extensions: Another mechanism to add additional
semantics is to actually add additional fields, e.g., through
Header Options in IPv4 or through Extension Headers in IPv6.
Iannone Expires 28 December 2023 [Page 19]
Internet-Draft IP Addressing Considerations June 2023
Re-encapsulation extension: A more radical approach for additional
semantics is the use of a completely new header that is designed
so to carry the desired semantics in an efficient manner (often as
a shim header).
Structured addressing: Similar to the methodology that structures
addresses within the limitations of the IPv6 address length,
outlined in the previous sub-sections, structured addressing can
also be applied within existing or extended header semantics,
e.g., utilizing a dedicated (extension) header to carry the
structured address information.
Localized forwarding semantics: This set of solutions applies
capabilities of newer (programmable) forwarding technology, such
as [BOSSHART14], to utilize any header information for a localized
forwarding decision. This removes any limitation to use existing
header or address information for embedding a new address semantic
into the transferred packet.
5.3.3. Examples
Table 4, summarize the methodologies and lists examples of semantic
extensions.
Iannone Expires 28 December 2023 [Page 20]
Internet-Draft IP Addressing Considerations June 2023
+===========================+======================+=============+
| | Methodology | Examples |
+===========================+======================+=============+
| Utilizing Extended | Semantic prefixes | HICN |
| Address Semantics | | |
+---------------------------+----------------------+-------------+
| | Separate device from | EIBP, ILNP, |
| | locator identifier | LISP, HIP |
+---------------------------+----------------------+-------------+
| | Structured | EIBP, ILNP |
| | addressing | |
+---------------------------+----------------------+-------------+
| | Localized forwarding | REED |
| | semantics | |
+---------------------------+----------------------+-------------+
| Utilizing Existing or | In-Header extensions | DetNet |
| Extended Header Semantics | | |
+---------------------------+----------------------+-------------+
| | Headers option | SHIM6, |
| | extensions | SRv6, HIP |
+---------------------------+----------------------+-------------+
| | Re-encapsulation | VxLAN, |
| | extension | ICNIP |
+---------------------------+----------------------+-------------+
| | Structured | EIBP |
| | addressing | |
+---------------------------+----------------------+-------------+
| | Localized forwarding | REED |
| | semantics | |
+---------------------------+----------------------+-------------+
Table 4: Summary Semantic Extensions
5.4. IP Addressing Extensions Overall Summary
The following Table 5 describes the objectives of the extensions
discussed in this memo with respect to the properties of Internet
addressing (Section 3). As summarized, extensions may aim to extend
one property of the Internet addressing, or extend other properties
at the same time.
+==========================+===============+===========+===========+
| | Length | Identity | Semantic |
| | Extension | Extension | Extension |
+==========================+===============+===========+===========+
| 6LoWPAN ([RFC6282], | x | | |
| [RFC7400], [BADENHOP15], | | | |
| [RFC8376], [RFC8724]) | | | |
Iannone Expires 28 December 2023 [Page 21]
Internet-Draft IP Addressing Considerations June 2023
+--------------------------+---------------+-----------+-----------+
| ROHC [RFC5795] | x | | |
+--------------------------+---------------+-----------+-----------+
| EzIP [EZIP] | x | | |
+--------------------------+---------------+-----------+-----------+
| TOR [TOR] | | x | |
+--------------------------+---------------+-----------+-----------+
| ODoH [RFC9230] | | x | |
+--------------------------+---------------+-----------+-----------+
| SLAAC [RFC8981] | | x | |
+--------------------------+---------------+-----------+-----------+
| CGA [RFC3972] | | x | x |
+--------------------------+---------------+-----------+-----------+
| NAT [RFC3083] | x | x | |
+--------------------------+---------------+-----------+-----------+
| HICN [CAROFIGLIO19] | | x | x |
+--------------------------+---------------+-----------+-----------+
| ICNIP [ICNIP] | x | x | x |
+--------------------------+---------------+-----------+-----------+
| CCNx names | x | x | x |
+--------------------------+---------------+-----------+-----------+
| EIBP [SHENOY21] | x | x | x |
+--------------------------+---------------+-----------+-----------+
| Geo addressing | x | | x |
+--------------------------+---------------+-----------+-----------+
| REED [REED16] | x (with P4 | | x |
| | [BOSSHART14]) | | |
+--------------------------+---------------+-----------+-----------+
| DetNet [DETNETWG] | | x | |
+--------------------------+---------------+-----------+-----------+
| Mobile IP [RFC6275] | | | x |
+--------------------------+---------------+-----------+-----------+
| SHIM6 [RFC5533] | | | x |
+--------------------------+---------------+-----------+-----------+
| SRv6 [RFC8402] | | | x |
+--------------------------+---------------+-----------+-----------+
| HIP [RFC7401] | | x | x |
+--------------------------+---------------+-----------+-----------+
| VxLAN [RFC7348] | | x | x |
+--------------------------+---------------+-----------+-----------+
| LISP ([RFC9300], | | x | x |
| [RFC8060]) | | | |
+--------------------------+---------------+-----------+-----------+
| SFC [RFC7665] | | x | x |
+--------------------------+---------------+-----------+-----------+
Table 5: Relationship between Extensions and Internet Addressing
Iannone Expires 28 December 2023 [Page 22]
Internet-Draft IP Addressing Considerations June 2023
6. Concerns Raised by IP Addressing Extensions
While the extensions to the original Internet properties, discussed
in Section 5, demonstrate the need of more flexibility in addressing,
they also raise a number of concerns, which are discussed in the
following sub-sections. To this end, the problems hereafter outlined
link to the approaches to extensions summarized in Section 5.4.
These considerations may not be present all the time and everywhere,
since extensions are developed and deployed in different part of the
Internet, which may worsen things.
6.1. Limiting Address Semantics
Many approaches changing the semantics of communication, e.g.,
through separating host identification from network node
identification [RFC7401], separating the device identifier from the
routing locator ([SHENOY21], [RFC9299]), or through identifying
content and services directly [CAROFIGLIO19], are limited by the
existing packet size and semantic constraints of IPv6, e.g., in the
form of its source and destination network addresses.
While approaches such as ICNIP [I-D.trossen-icnrg-internet-icn-5glan]
may override the addressing semantics, e.g., by replacing IPv6 source
and destination information with path identification, a possible
unawareness of endpoints still requires the carrying of other address
information as part of the payload.
Also, the expressible service or content semantic may be limited, as
in [CAROFIGLIO19] or the size of supported networks [REED16] due to
relying on the limited bit positions usable in IPv6 addresses.
6.2. Complexity and Efficiency
Realizing the additional addressing semantics may introduce
additional complexity. This is particularly a concern since those
additional semantics can be observed particularly at the edge of the
Internet, utilizing the existing addressing semantic of the Internet
to interconnect the domains that require those additional semantics.
Furthermore, any additional complexity often comes with an efficiency
and cost penalty, particularly at the edge of the network, where
resource constraints may play a significant role. Compression
processes, taking [FITZEK05] as an example, require additional
resources both for the sender generating the compressed header but
also the gateway linking to the general Internet by re-establishing
the full IP header.
Iannone Expires 28 December 2023 [Page 23]
Internet-Draft IP Addressing Considerations June 2023
Conversely, the performance requirements of core networks, in terms
of packet processing speed, makes the accommodation of extensions to
addressing often prohibitive. This is not only due to the necessary
extra processing that is specific to the extension, but also due to
the complexity that will need to be managed in doing so at
significantly higher speeds than at the edge of the network. The
observations on the dropping of packets with IPv6 extension headers
in the real world is (partially) due to such an implementation
complexity [RFC7872].
Another example for lowering the efficiency of packet forwarding is
the routing in systems like Tor [TOR]. As detailed before, traffic
in Tor, for anonymity purposes, should be handed over by at least
three intermediates before reaching the destination. Frequent
relaying enhances the privacy, however, because such kind of
solutions are implemented at application level, they come at the cost
of lower communication efficiency. May be a different privacy
enhanced address semantic would enable efficient implementation of
Tor-like solutions at network layer.
Repetitive Encapsulation: Repetitive encapsulation is a concern
since it bloats the packets size due to additional encapsulation
headers. Addressing proposals such as those in
[I-D.trossen-icnrg-internet-icn-5glan] utilize path identification
within an alternative forwarding architecture that acts upon the
provided path identification. However, due to the limitation of
existing flow-based architectures with respect to the supported
header structures (in the form of IPv4 or IPv6 headers), the new
routing semantics are being inserted into the existing header
structure, while repeating the original, sender-generated header
structure, in the payload of the packet as it traverses the local
domain, effectively doubling the per-packet header overhead.
The problem is also present in a number of solutions tackling
different use-cases, e.g., mobility [I-D.ietf-lisp-mn], data
center networking ([RFC8926], [RFC7348], [I-D.ietf-intarea-gue]),
traffic engineering [RFC8986], and privacy ([TOR], [DANEZIS09]).
Certainly, these solutions are able to avoid issues like path
lengthening or privacy concerns, as described before, but they
come at the price of multiple encapsulations that reduce the
effective payload. This, not only hampers efficiency in terms of
header-to-payload ratio, but also introduces 'encapsulation
points', which in turn add complexity to the (often edge) network
as well as fragility due to the addition of possible failure
points; this aspect is discussed in further details in
Section 6.4.
Compounding Concerns with Header Compression: IP header overhead
Iannone Expires 28 December 2023 [Page 24]
Internet-Draft IP Addressing Considerations June 2023
requires header compression in constrained environments, such as
wireless sensor networks and IoT in general. Together with
fragmentation, both tasks constitute significant energy
consumption, as shown in [MESRINEJAD11], negatively impacting
resource limited devices that often rely on battery for operation.
Further, the reliance on the compression/decompression points
creates a dependence on such gateways, which may be a problem for
intermittent scenarios.
According to the implementation of _contiki-ng_ [CONTIKI], an
example of operating system for IoT devices, the source codes for
6LowPan requires at least 600Kb to include a header compression
process. In certain use cases, such requirement can be an
obstacle for extremely constrained devices, especially for the RAM
and energy consumption.
Introducing Path Stretch: Mobile IP [RFC6275], which was designed
for connection continuity in the face of moving endpoints, is a
typical case for path stretch. Since traffic must follow a
triangular route before arriving at the destination, such detour
routing inevitably impacts transmission efficiency as well as
latency.
Complicating Traffic Engineering: While many extensions to the
original IP address semantic target to enrich the decisions that
can be taken to steer traffic, according to requirements like QoS,
mobility, chaining, compute/network metrics, flow treatment, path
usage, etc., the realization of the mechanisms as individual
solutions likely complicates the original goal of traffic
engineering when individual solutions are being used in
combination. Ultimately, this may even prevent the combined use
of more than one mechanism and/or policy with a need to identify
and prevent incompatibilities of mechanisms. Key here is not the
concerns arising from using conflicting traffic engineering
policies, rather conflicting realizations of policies that may
well generally work well alongside ([CANINI15], [CURIC18]).
This not only increases fragility, as discussed separately in
Section 6.4, but also requires careful planning of which
mechanisms to use and in which combination, likely needing human-
in-the-loop approaches alongside possible automation approaches
for the individual solutions.
6.3. Security
The properties described in Section 5 have, obviously, also
consequences in terms of security and privacy related concerns, as
already mentioned in other parts of this document.
Iannone Expires 28 December 2023 [Page 25]
Internet-Draft IP Addressing Considerations June 2023
For instance, in the effort of being somehow backward compatible, HIP
[RFC7401] uses a 128-bit Host Identity, which may be not sufficiently
cryptographically strong in the future, because of the limited size
(future computational power may erode 128-bit security). Similarly,
CGA [RFC3972] also aligns to the 128-bit limit, but may use only 59
bits of them, hence, the packet signature may not be sufficiently
robust to attacks [I-D.rafiee-6man-cga-attack].
IP addresses, even temporary ones meant to protect privacy, have been
long recognized as a 'Personal Identification Information' that
allows even to geolocate the communicating endpoints [RFC8280]. The
use of temporary addresses provides sufficient privacy protection
only if the renewal rate is high
[I-D.gont-v6ops-ipv6-addressing-considerations]. However, this may
raise some issues, like the large overhead due to the Duplicate
Address Detection, the impact on the Neighbor Discovery mechanism, in
particular the cache, which can even lead to communication
disruption. With such drawbacks, the extensions may even lead to
defeat the target, actually lowering security rather than increasing
it.
The introduction of alternative addressing semantics has also been
used to help in (D)DoS attacks mitigation. This leverages on
changing the service identification model so to avoid topological
information exposure, making the potential disruptions likely remain
limited [HAO21]. However, this increased robustness to DDoS comes at
the price of important communication setup latency and fragility, as
discussed next.
6.4. Fragility
From the extensions discussed in Section 5, it is evident that having
alternative or additional address semantic and formats available for
making routing as well as forwarding decisions dependent on these, is
common place in the Internet. This, however, adds many extension-
specific translation/adaptation points, mapping the semantic and
format in one context into what is meaningful in another context, but
also, more importantly, creating a dependency towards an additional
component, often without explicit exposure to the endpoints that
originally intended to communicate.
Iannone Expires 28 December 2023 [Page 26]
Internet-Draft IP Addressing Considerations June 2023
For instance, the re-writing of IP addresses to facilitate the use of
private address spaces throughout the public Internet, realized
through network address translators (NATs), conflicts with the end-
to-end nature of communication between two endpoints. Additional
(flow) state is required at the NAT middle-box to smoothly allow
communication, which in turn creates a dependency between the NAT and
the end-to-end communication between those endpoints, thus increasing
the fragility of the communication relation.
A similar situation arises when supporting constrained environments
through a header compression mechanism, adding the need for, e.g., a
ROHC [RFC5795] element in the communication path, with communication-
related compression state being held outside the communicating
endpoints. Failure will introduce some inefficiencies due to context
regeneration, which may affect the communicating endpoints,
increasing fragility of the system overall.
Such translation/adaptation between semantic extensions to the
original 'semantic' of an IP address is generally not avoidable when
accommodating more than a single universal semantic. However, the
solution-specific nature of every single extension is likely to
noticeably increase the fragility of the overall system, since
individual extensions will need to interact with other extensions
that may be deployed in parallel, but were not designed taking into
account such deployment scenario (cf., [I-D.ietf-intarea-tunnels]).
Considering that extensions to traditional per-hop-behavior (based on
IP addresses) can essentially be realized over almost 'any' packet
field, the possible number of conflicting behaviors or diverging
interpretation of the semantic and/or content of such fields, among
different extensions, may soon become an issue, requiring careful
testing and delineation at the boundaries of the network within which
the specific extension has been realized.
6.5. Summary of Concerns
Table 6, derived from the previous sections, summarizes the concerns
discussed in this section related to each extension listed in
Section 5.4. While each extension involves at least one concern,
some others, like ICNIP [I-D.trossen-icnrg-internet-icn-5glan], may
create several at the same time.
+============+==================+============+==========+===========+
| | Limiting | Complexity | Security | Fragility |
| | Address | and | | |
| | Semantics | Efficiency | | |
+============+==================+============+==========+===========+
| 6LoWPAN | | x | | x |
+------------+------------------+------------+----------+-----------+
Iannone Expires 28 December 2023 [Page 27]
Internet-Draft IP Addressing Considerations June 2023
| ROHC | | x | | x |
+------------+------------------+------------+----------+-----------+
| EzIP | | x | | |
+------------+------------------+------------+----------+-----------+
| TOR | | x | | x |
+------------+------------------+------------+----------+-----------+
| ODoH | | x | | |
+------------+------------------+------------+----------+-----------+
| SLAAC | | x | | |
+------------+------------------+------------+----------+-----------+
| CGA | x | | x | |
+------------+------------------+------------+----------+-----------+
| NAT | | x | | x |
+------------+------------------+------------+----------+-----------+
| HICN | x | | | |
+------------+------------------+------------+----------+-----------+
| ICNIP | x | x | | |
+------------+------------------+------------+----------+-----------+
| CCNx name | x | | | |
+------------+------------------+------------+----------+-----------+
| EIBP | | | | x |
+------------+------------------+------------+----------+-----------+
| Geo | x | | | x |
| addressing | | | | |
+------------+------------------+------------+----------+-----------+
| REED | x | | | |
+------------+------------------+------------+----------+-----------+
| DetNet | | x | | |
+------------+------------------+------------+----------+-----------+
| Mobile IP | | x | | x |
+------------+------------------+------------+----------+-----------+
| SHIM6 | | | | x |
+------------+------------------+------------+----------+-----------+
| SRv6 | | | | x |
+------------+------------------+------------+----------+-----------+
| HIP | | | x | x |
+------------+------------------+------------+----------+-----------+
| VxLAN | | x | | |
+------------+------------------+------------+----------+-----------+
| LISP | | x | | x |
+------------+------------------+------------+----------+-----------+
| SFC | | x | | x |
+------------+------------------+------------+----------+-----------+
Table 6: Concerns in Extensions to Internet Addressing
Iannone Expires 28 December 2023 [Page 28]
Internet-Draft IP Addressing Considerations June 2023
7. Discussion
The examples of extensions discussed in Section 5 to the original
Internet addressing scheme show that extensibility beyond the
original model (and its underlying per-hop behavior) is a desired
capability for networking technologies and has been so for a long
time. Generally, we can observe that those extensions are driven by
the requirements of stakeholders, derived from the aforementioned
problems and communication scenarios, thus, expecting a desirable
extended functionality from the introduction of the specific
extension. If interoperability is required, those extensions require
standardization of possibly new fields, new semantics as well as
(network and/or end system) operations alike.
This points to the conclusion that the existence of the many
extensions to the original Internet addressing is clear evidence for
wanting to develop evolution paths over time by the wider Internet
community, each of which come with a raft of issues that we need to
deal with daily. This makes it desirable to develop an architectural
and, more importantly, a sustainable approach to make Internet
addressing extensible in order to capture the many new use cases that
will still be identified for the Internet to come.
This is not to 'second guess' the market and its possible evolution,
but to outline clear features from which to derive clear principles
for a design. Any such design must not skew the technical
capabilities of addressing to the current economic situation of the
Internet and its technical realization, e.g., being a mere ephemeral
token for accessing PoP-based services (as indicated in related
arch-d mailing list discussions), since this bears the danger of
locking down innovation capabilities as an outcome of those technical
limitations introduced. Instead, addressing must be aligned with
enabling the model of permissionless innovation that the IETF has
been promoting, ultimately enabling the serendipity of new
applications that has led to many of those applications we can see in
the Internet today.
Having a more systematic approach, rather than point extensions,
would allow the Internet community to identify an overall
evolutionary path able to accommodate existing and future use cases,
without disruptive solutions breaking existing deployments, rather
with a well-thought out set of incremental steps.
An architectural evolution of the IP addressing model may bring clear
benefits in various scenarios. Examples of such benefits are
provided hereafter, for a short sample of use cases. An extensive
discussion about these use cases can be found in Appendix B.
Iannone Expires 28 December 2023 [Page 29]
Internet-Draft IP Addressing Considerations June 2023
* Communication in Constrained Environments Potential Benefits:
Avoid complex and energy hungry operations, like header
compression and fragmentation, necessary to translate protocol
headers from one limited domain to another, while enabling
semantics different from locator-based addressing may better
support the communication that occurs in those environments.
* Communication within Dynamically Changing Topologies Potential
Benefits: Allow for accommodating such geographic address
semantics into the overall Internet addressing, while also
enabling name/content-based addressing, utilizing the redundancy
of many network locations providing the possible data.
* Communication among Moving Endpoints Potential Benefits: Enable
better mobility, e.g., through an augmented semantic that may
fulfil the mobility requirements [RFC7429] in a more efficient way
or through moving from a locator- to a content or service-centric
semantic for addressing.
* Communication Across Services Potential Benefits: Allow for
incorporating different information, e.g., service as well as
chaining semantics, into the overall Internet addressing.
* Communication Traffic Steering Potential Benefits: More semantic
rich encoding schemes may help in steering traffic at hardware
level and speed, without complex mechanisms usually resulting in
handling packets in the slow path of routers.
* Communication with built-in security Potential Benefits: Security-
related key, certificate, or identifier could be included in a
suitable address structure without any information loss, which may
weaken security and trust.
* Communication protecting user privacy Potential Benefits: Enable
easy mechanism to obfuscate IP addresses to entities not involved
in the communication.
* Communication in Alternative Forwarding Architectures Potential
Benefits: Reduce the wastage by accommodating Internet addressing
in the light of alternative forwarding architectures, instead
enabling the direct use of the alternative forwarding information.
Finally, it is important to remark that any change in the addressing,
hence at the data plane level, leads to changes and challenges at the
control plane level, i.e., routing. The latter is an even harder
problem than just addressing and might need more research efforts
that are beyond what is discussed in this document, which focuses
solely on the data plane.
Iannone Expires 28 December 2023 [Page 30]
Internet-Draft IP Addressing Considerations June 2023
8. Looking Forward
At this stage, this document does not provide a definite answer nor
does it propose or promote specific solutions to the issues it
portrays. Instead, this document captures the discussion on the
perceived needs for addressing, with the possibility to fundamentally
re-think the addressing in the Internet beyond the objectives of
IPv6, in order to provide the flexibility to suitably support the
many new forms of communication that will emerge.
It has been observed during the interactions of this wider exercise
within the IETF that the considerations documented in this memo, with
the various extension-specific solutions, have the merit to capture
the views and opinions of a large part of the IETF community at the
time of writing this document.
Although some of the discussions hinted at "something should be
done", those same discussions never converged to answer the "what
should be done" aspect. However, we assert from experiences in the
past that the community may at some point in the future re-open
discussions surrounding the IP addressing model and its possible
evolution.
For the reason to possibly provide a useful starting point, thus to
help jump start any initial future discussion, this document provides
an archive of those specific discussions in the early 2020s as a
recollection of discussions held at that point in time.
We hope that any such future discussions and the possible input from
the recollections in this document, may bring the IETF community to
converge on concrete actions to be done.
9. Security Considerations
The present memo does not introduce any new technology and/or
mechanism and as such does not introduce any new security threat to
the TCP/IP protocol suite.
As an additional note, and as discussed in this document, security
and privacy aspects were not considered as part of the key properties
for Internet addressing, which led to the introduction of a number of
extensions intending to fix those gaps. The analysis presented in
this memo (non-exhaustively) shows those concerns are either solved
in an ad-hoc manner at application level, or at transport layer,
while at network level only few extensions tackling specific aspects
exist, albeit often with limitations due to the adherence to the
Internet addressing model and its properties.
Iannone Expires 28 December 2023 [Page 31]
Internet-Draft IP Addressing Considerations June 2023
10. IANA Considerations
This document does not include any IANA request.
Acknowledgments
Thanks to all the people that shared insightful comments both
privately to the authors as well as on various mailing list,
especially on the INTArea Mailing List. Thanks as well, for the
interesting discussions, to Carsten Borman, Brian E. Carpenter, and
Eric Vyncke.
Informative References
[ABDALLAH16]
Abdallah, A., Abdallah, E., Bsoul, M., and A. Otoom,
"Randomized geographic-based routing with nearly
guaranteed delivery for three-dimensional ad hoc network",
International Journal of Distributed Sensor Networks vol.
12, no. 10, pp. 155014771667125,
DOI 10.1177/1550147716671255, October 2016,
<https://doi.org/10.1177/1550147716671255>.
[ADACORSA] "Airborne data collection on resilient system
architectures", n.d.,
<https://www.kdt-ju.europa.eu/projects/adacorsa>.
[ALMADANI20]
AL-Madani, B., Elkhider, S., and S. El-Ferik, "DDS-Based
Containment Control of Multiple UAV Systems", Applied
Sciences vol. 10, no. 13, pp. 4572,
DOI 10.3390/app10134572, July 2020,
<https://doi.org/10.3390/app10134572>.
[BACnet] "BACnet-A Data Communication Protocol for Building
Automation and Control Networks", ANSI/ASHRAE Standard
135-2016, January 2016,
<https://www.techstreet.com/ashrae/standards/ashrae-
135-2016?product_id=1918140>.
[BADENHOP15]
Badenhop, C., Fuller, J., Hall, J., Ramsey, B., and M.
Rice, "Evaluating ITU-T G.9959 Based Wireless Systems Used
in Critical Infrastructure Assets", IFIP Advances in
Information and Communication Technology pp. 209-227,
DOI 10.1007/978-3-319-26567-4_13, 2015,
<https://doi.org/10.1007/978-3-319-26567-4_13>.
Iannone Expires 28 December 2023 [Page 32]
Internet-Draft IP Addressing Considerations June 2023
[BLE] "Bluetooth Specification", Bluetooth SIG Working Groups,
n.d., <https://www.bluetooth.com/specifications>.
[BOSSHART14]
Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N.,
Rexford, J., Schlesinger, C., Talayco, D., Vahdat, A.,
Varghese, G., and D. Walker, "P4: programming protocol-
independent packet processors", ACM SIGCOMM Computer
Communication Review vol. 44, no. 3, pp. 87-95,
DOI 10.1145/2656877.2656890, July 2014,
<https://doi.org/10.1145/2656877.2656890>.
[BUJLOW17] Bujlow, T., Carela-Espanol, V., Lee, B., and P. Barlet-
Ros, "A Survey on Web Tracking: Mechanisms, Implications,
and Defenses", Proceedings of the IEEE vol. 105, no. 8,
pp. 1476-1510, DOI 10.1109/jproc.2016.2637878, August
2017, <https://doi.org/10.1109/jproc.2016.2637878>.
[CANINI15] Canini, M., Kuznetsov, P., Levin, D., and S. Schmid, "A
distributed and robust SDN control plane for transactional
network updates", 2015 IEEE Conference on Computer
Communications (INFOCOM),
DOI 10.1109/infocom.2015.7218382, April 2015,
<https://doi.org/10.1109/infocom.2015.7218382>.
[CAROFIGLIO19]
Carofiglio, G., Muscariello, L., Augé, J., Papalini, M.,
Sardara, M., and A. Compagno, "Enabling ICN in the
Internet Protocol: Analysis and Evaluation of the Hybrid-
ICN Architecture", Proceedings of the 6th ACM Conference
on Information-Centric Networking,
DOI 10.1145/3357150.3357394, September 2019,
<https://doi.org/10.1145/3357150.3357394>.
[CCSDS-702.1-B-1]
CCSDS - Consultative Committee for Space Data Systems, "IP
over CCSDS Space Links", SIS Space Internetworking
Services Area, n.d.,
<https://public.ccsds.org/Pubs/702x1b1c1.pdf>.
[CHEN21] Chen, Y., Li, H., Liu, J., Wu, Q., and Z. Lai, "GAMS: An
IP Address Management Mechanism in Satellite Mega-
constellation Networks", 2021 International Wireless
Communications and Mobile Computing (IWCMC),
DOI 10.1109/iwcmc51323.2021.9498722, June 2021,
<https://doi.org/10.1109/iwcmc51323.2021.9498722>.
Iannone Expires 28 December 2023 [Page 33]
Internet-Draft IP Addressing Considerations June 2023
[CHRIKI19] Chriki, A., Touati, H., Snoussi, H., and F. Kamoun,
"FANET: Communication, mobility models and security
issues", Computer Networks vol. 163, pp. 106877,
DOI 10.1016/j.comnet.2019.106877, November 2019,
<https://doi.org/10.1016/j.comnet.2019.106877>.
[COMP4DRONES]
"COMP4DRONES", n.d.,
<https://www.kdt-ju.europa.eu/projects/comp4drones>.
[CONTIKI] "Contiki-NG: The OS for Next Generation IoT Devices",
n.d., <https://github.com/contiki-ng/contiki-ng>.
[CURIC18] Curic, M., Despotovic, Z., Hecker, A., and G. Carle,
"Transactional Network Updates in SDN", 2018 European
Conference on Networks and Communications (EuCNC),
DOI 10.1109/eucnc.2018.8442793, June 2018,
<https://doi.org/10.1109/eucnc.2018.8442793>.
[DANEZIS09]
Danezis, G. and I. Goldberg, "Sphinx: A Compact and
Provably Secure Mix Format", 2009 30th IEEE Symposium on
Security and Privacy, DOI 10.1109/sp.2009.15, May 2009,
<https://doi.org/10.1109/sp.2009.15>.
[DECT-ULE] "Digital Enhanced Cordless Telecommunications (DECT);
Common Interface (CI); Part 1: Overview", ETSI European
Standard, EN 300 175-1, V2.6.1, May 2009,
<https://www.etsi.org/deliver/
etsi_en/300100_300199/30017501/02.06.01_60/
en_30017501v020601p.pdf>.
[DETNETWG] "Deterministic Networking (DetNet) Working Group", n.d.,
<https://datatracker.ietf.org/wg/detnet/about/>.
[DINRG] "Decentralized Internet Infrastructure - DINRG", n.d.,
<https://datatracker.ietf.org/rg/dinrg/about/>.
[DONENFELD17]
Donenfeld, J., "WireGuard: Next Generation Kernel Network
Tunnel", Proceedings 2017 Network and Distributed System
Security Symposium, DOI 10.14722/ndss.2017.23160, 2017,
<https://doi.org/10.14722/ndss.2017.23160>.
[ECMA-340] EECMA-340, "Near Field Communication - Interface and
Protocol (NFCIP-1) 3rd Ed.", June 2013.
Iannone Expires 28 December 2023 [Page 34]
Internet-Draft IP Addressing Considerations June 2023
[ETSI-NIN] ETSI - European Telecommunication Standards Institute,
"Non-IP Networking - NIN", n.d.,
<https://www.etsi.org/technologies/non-ip-networking>.
[EZIP] Chen, A., Ati, R. R., Karandikar, A., and D. Crowe,
"Adaptive IPv4 Address Space", Work in Progress, Internet-
Draft, draft-chen-ati-adaptive-ipv4-address-space-13, 13
June 2023, <https://datatracker.ietf.org/doc/html/draft-
chen-ati-adaptive-ipv4-address-space-13>.
[FAYED21] Fayed, M., Bauer, L., Giotsas, V., Kerola, S., Majkowski,
M., Odintsov, P., Sitnicki, J., Chung, T., Levin, D.,
Mislove, A., Wood, C., and N. Sullivan, "The ties that un-
bind: decoupling IP from web services and sockets for
robust addressing agility at CDN-scale", Proceedings of
the 2021 ACM SIGCOMM 2021 Conference,
DOI 10.1145/3452296.3472922, August 2021,
<https://doi.org/10.1145/3452296.3472922>.
[FINKHAUSER21]
Finkhäuser, J. and M. Larsen, "Reliable Command, Control
and Communication Links for Unmanned Aircraft Systems:
Towards compliance of commercial drones", Proceedings of
the 2021 Drone Systems Engineering and Rapid Simulation
and Performance Evaluation: Methods and Tools Proceedings,
DOI 10.1145/3444950.3444954, January 2021,
<https://doi.org/10.1145/3444950.3444954>.
[FITZEK05] Fitzek, F., Rein, S., Seeling, P., and M. Reisslein,
"RObust Header Compression (ROHC) Performance for
Multimedia Transmission over 3G/4G Wireless Networks",
Wireless Personal Communications vol. 32, no. 1, pp.
23-41, DOI 10.1007/s11277-005-7733-2, January 2005,
<https://doi.org/10.1007/s11277-005-7733-2>.
[GNATCATCHER]
"Global Network Address Translation Combined with Audited
and Trusted CDN or HTTP-Proxy Eliminating
Reidentification", n.d.,
<https://github.com/bslassey/ip-blindness>.
[GOLDSCHLAG99]
Goldschlag, D., Reed, M., and P. Syverson, "Onion
routing", Communications of the ACM vol. 42, no. 2, pp.
39-41, DOI 10.1145/293411.293443, February 1999,
<https://doi.org/10.1145/293411.293443>.
Iannone Expires 28 December 2023 [Page 35]
Internet-Draft IP Addressing Considerations June 2023
[HANDLEY18]
Handley, M., "Delay is Not an Option: Low Latency Routing
in Space", Proceedings of the 17th ACM Workshop on Hot
Topics in Networks, DOI 10.1145/3286062.3286075, November
2018, <https://doi.org/10.1145/3286062.3286075>.
[HAO21] Hao, S., Liu, R., Weng, Z., Chang, D., Bao, C., and X. Li,
"Addressless: A new internet server model to prevent
network scanning", PLOS ONE vol. 16, no. 2, pp. e0246293,
DOI 10.1371/journal.pone.0246293, February 2021,
<https://doi.org/10.1371/journal.pone.0246293>.
[HISTORY127]
"History of 127/8 as localhost/loopback addresses", n.d.,
<https://elists.isoc.org/pipermail/internet-
history/2021-January/006920.html>.
[HUGHES03] Hughes, L., Shumon, K., and Y. Zhang, "Cartesian Ad Hoc
Routing Protocols", Ad-Hoc, Mobile, and Wireless
Networks pp. 287-292, DOI 10.1007/978-3-540-39611-6_27,
2003, <https://doi.org/10.1007/978-3-540-39611-6_27>.
[I-D.chen-ati-adaptive-ipv4-address-space]
Chen, A., Ati, R. R., Karandikar, A., and D. Crowe,
"Adaptive IPv4 Address Space", Work in Progress, Internet-
Draft, draft-chen-ati-adaptive-ipv4-address-space-13, 13
June 2023, <https://datatracker.ietf.org/doc/html/draft-
chen-ati-adaptive-ipv4-address-space-13>.
[I-D.gont-v6ops-ipv6-addressing-considerations]
Gont, F. and G. Gont, "IPv6 Addressing Considerations",
Work in Progress, Internet-Draft, draft-gont-v6ops-ipv6-
addressing-considerations-02, 1 June 2022,
<https://datatracker.ietf.org/doc/html/draft-gont-v6ops-
ipv6-addressing-considerations-02>.
[I-D.haindl-lisp-gb-atn]
Haindl, B., Lindner, M., Moreno, V., Portoles-Comeras, M.,
Maino, F., and B. Venkatachalapathy, "Ground-Based LISP
for the Aeronautical Telecommunications Network", Work in
Progress, Internet-Draft, draft-haindl-lisp-gb-atn-09, 27
March 2023, <https://datatracker.ietf.org/doc/html/draft-
haindl-lisp-gb-atn-09>.
[I-D.iannone-internet-addressing-considerations]
Iannone, L., Trossen, D., Mendes, P., Shenoy, N., Toutain,
L., Chen, A., Farinacci, D., Finkhäuser, J., and Y. Jia,
"Internet Addressing Considerations", Work in Progress,
Iannone Expires 28 December 2023 [Page 36]
Internet-Draft IP Addressing Considerations June 2023
Internet-Draft, draft-iannone-internet-addressing-
considerations-01, 5 September 2022,
<https://datatracker.ietf.org/doc/html/draft-iannone-
internet-addressing-considerations-01>.
[I-D.iannone-scenarios-problems-addressing]
Iannone, L., Trossen, D., Shenoy, N., Mendes, P.,
Eastlake, D. E., Liu, P., Farinacci, D., Finkhäuser, J.,
and Y. Jia, "Challenging Scenarios and Problems in
Internet Addressing", Work in Progress, Internet-Draft,
draft-iannone-scenarios-problems-addressing-00, 5
September 2022, <https://datatracker.ietf.org/doc/html/
draft-iannone-scenarios-problems-addressing-00>.
[I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., and J. Youn, "Transmission of IPv6
Packets over Near Field Communication", Work in Progress,
Internet-Draft, draft-ietf-6lo-nfc-22, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-nfc-
22>.
[I-D.ietf-bier-multicast-http-response]
Trossen, D., Rahman, A., Wang, C., and T. T. Eckert,
"Applicability of BIER Multicast Overlay for Adaptive
Streaming Services", Work in Progress, Internet-Draft,
draft-ietf-bier-multicast-http-response-06, 10 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
multicast-http-response-06>.
[I-D.ietf-drip-arch]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-31, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
arch-31>.
[I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-intarea-gue-09, 26 October 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
gue-09>.
Iannone Expires 28 December 2023 [Page 37]
Internet-Draft IP Addressing Considerations June 2023
[I-D.ietf-intarea-tunnels]
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-13, 26 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-13>.
[I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", Work in Progress, Internet-Draft, draft-
ietf-lisp-mn-13, 16 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-
13>.
[I-D.ietf-lisp-nexagon]
Barkai, S., Fernandez-Ruiz, B., Tamir, R., Rodriguez-
Natal, A., Maino, F., Cabellos-Aparicio, A., Paillisse,
J., and D. Farinacci, "Network-Hexagons:Geolocation
Mobility Network Based On H3 and LISP", Work in Progress,
Internet-Draft, draft-ietf-lisp-nexagon-50, 9 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
nexagon-50>.
[I-D.irtf-icnrg-5gc-icn]
Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
White, "Enabling ICN in 3GPP's 5G NextGen Core
Architecture", Work in Progress, Internet-Draft, draft-
irtf-icnrg-5gc-icn-04, 10 January 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
5gc-icn-04>.
[I-D.irtf-pearg-numeric-ids-history]
Gont, F. and I. Arce, "Unfortunate History of Transient
Numeric Identifiers", Work in Progress, Internet-Draft,
draft-irtf-pearg-numeric-ids-history-11, 11 December 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
numeric-ids-history-11>.
[I-D.rafiee-6man-cga-attack]
Rafiee and C. Meinel, "Possible Attack on
Cryptographically Generated Addresses (CGA)", Work in
Progress, Internet-Draft, draft-rafiee-6man-cga-attack-03,
8 May 2015, <https://datatracker.ietf.org/doc/html/draft-
rafiee-6man-cga-attack-03>.
[I-D.templin-6man-aero]
Templin, F., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
Iannone Expires 28 December 2023 [Page 38]
Internet-Draft IP Addressing Considerations June 2023
6man-aero-63, 12 October 2022,
<https://datatracker.ietf.org/doc/html/draft-templin-6man-
aero-63>.
[I-D.thomson-http-oblivious]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-thomson-http-oblivious-02,
24 August 2021, <https://datatracker.ietf.org/doc/html/
draft-thomson-http-oblivious-02>.
[I-D.trossen-icnrg-internet-icn-5glan]
Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and
J. Riihijarvi, "Internet Services over ICN in 5G LAN
Environments", Work in Progress, Internet-Draft, draft-
trossen-icnrg-internet-icn-5glan-04, 1 October 2020,
<https://datatracker.ietf.org/doc/html/draft-trossen-
icnrg-internet-icn-5glan-04>.
[I-D.trossen-rtgwg-impact-of-dlts]
Trossen, D., Guzman, D., McBride, M., and X. Fan, "Impact
of DLTs on Provider Networks", Work in Progress, Internet-
Draft, draft-trossen-rtgwg-impact-of-dlts-02, 30 August
2022, <https://datatracker.ietf.org/doc/html/draft-
trossen-rtgwg-impact-of-dlts-02>.
[ICNIP] Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and
J. Riihijarvi, "Internet Services over ICN in 5G LAN
Environments", Work in Progress, Internet-Draft, draft-
trossen-icnrg-internet-icn-5glan-04, 1 October 2020,
<https://datatracker.ietf.org/doc/html/draft-trossen-
icnrg-internet-icn-5glan-04>.
[IEEE-1901.1]
"IEEE Standard Test Procedures for IEEE Std 1901.1(TM) for
Medium Frequency (less than 15 MHz) Power Line
Communications for Smart Grid Applications",
IEEE standard, DOI 10.1109/ieeestd.2021.9381775, March
2021, <https://doi.org/10.1109/ieeestd.2021.9381775>.
[IEEE-802.15.4-LR]
"IEEE Standard for Low-Rate Wireless Networks",
IEEE standard, DOI 10.1109/ieeestd.2020.9144691, July
2020, <https://doi.org/10.1109/ieeestd.2020.9144691>.
[IPv4pool] "IANA IPv4 Address Space Registry", n.d.,
<https://www.iana.org/assignments/ipv4-address-space/ipv4-
address-space.xhtml>.
Iannone Expires 28 December 2023 [Page 39]
Internet-Draft IP Addressing Considerations June 2023
[JACOBSON09]
Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Briggs, N., and R. Braynard, "Networking named content",
Proceedings of the 5th international conference on
Emerging networking experiments and technologies,
DOI 10.1145/1658939.1658941, December 2009,
<https://doi.org/10.1145/1658939.1658941>.
[KHANVILKAR04]
Khanvilkar, S. and A. Khokhar, "Virtual private networks:
an overview with performance evaluation", IEEE
Communications Magazine vol. 42, no. 10, pp. 146-154,
DOI 10.1109/mcom.2004.1341273, October 2004,
<https://doi.org/10.1109/mcom.2004.1341273>.
[KOMORI02] Komori, T. and T. Saito, "The secure DHCP system with user
authentication", 27th Annual IEEE Conference on Local
Computer Networks, 2002. Proceedings. LCN 2002.,
DOI 10.1109/lcn.2002.1181774, August 2003,
<https://doi.org/10.1109/lcn.2002.1181774>.
[KRAHENBUHL21]
Krahenbuhl, C., Legner, M., Bitterli, S., and A. Perrig,
"Pervasive Internet-Wide Low-Latency Authentication", 2021
International Conference on Computer Communications and
Networks (ICCCN), DOI 10.1109/icccn52240.2021.9522235,
July 2021,
<https://doi.org/10.1109/icccn52240.2021.9522235>.
[KUO95] Kuo, F., "The ALOHA System", ACM SIGCOMM Computer
Communication Review vol. 25, no. 1, pp. 41-44,
DOI 10.1145/205447.205451, January 1995,
<https://doi.org/10.1145/205447.205451>.
[MAROJEVIC20]
Marojevic, V., Guvenc, I., Dutta, R., Sichitiu, M., and B.
Floyd, "Advanced Wireless for Unmanned Aerial Systems: 5G
Standardization, Research Challenges, and AERPAW
Architecture", IEEE Vehicular Technology Magazine vol. 15,
no. 2, pp. 22-30, DOI 10.1109/mvt.2020.2979494, June 2020,
<https://doi.org/10.1109/mvt.2020.2979494>.
Iannone Expires 28 December 2023 [Page 40]
Internet-Draft IP Addressing Considerations June 2023
[MESRINEJAD11]
Mesrinejad, F., Hashim, F., Noordin, N., Rasid, M., and R.
Abdullah, "The effect of fragmentation and header
compression on IP-based sensor networks (6LoWPAN)", The
17th Asia Pacific Conference on Communications,
DOI 10.1109/apcc.2011.6152926, October 2011,
<https://doi.org/10.1109/apcc.2011.6152926>.
[MISHRA20] Mishra, V., Laperdrix, P., Vastel, A., Rudametkin, W.,
Rouvoy, R., and M. Lopatka, "Don’t Count Me Out: On the
Relevance of IP Address in the Tracking Ecosystem",
Proceedings of The Web Conference 2020,
DOI 10.1145/3366423.3380161, April 2020,
<https://doi.org/10.1145/3366423.3380161>.
[OCADO] "Ocado Technology's robot warehouse a Hive of IoT
innovation", n.d., <https://techmonitor.ai/tech-leaders/
ocado-technology-robot-hive-innovation>.
[PANRG] "Path Aware Networking Research Group - PANRG", n.d.,
<https://datatracker.ietf.org/rg/panrg/about/>.
[PEARG] "Privacy Enhancements and Assessments Research Group -
PEARG", n.d., <https://irtf.org/pearg>.
[REED16] Reed, M., Al-Naday, M., Thomos, N., Trossen, D.,
Petropoulos, G., and S. Spirou, "Stateless multicast
switching in software defined networks", 2016 IEEE
International Conference on Communications (ICC),
DOI 10.1109/icc.2016.7511036, May 2016,
<https://doi.org/10.1109/icc.2016.7511036>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>.
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP
Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752,
January 1995, <https://www.rfc-editor.org/rfc/rfc1752>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2009] Imielinski, T. and J. Navas, "GPS-Based Addressing and
Routing", RFC 2009, DOI 10.17487/RFC2009, November 1996,
<https://www.rfc-editor.org/rfc/rfc2009>.
Iannone Expires 28 December 2023 [Page 41]
Internet-Draft IP Addressing Considerations June 2023
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101,
February 1997, <https://www.rfc-editor.org/rfc/rfc2101>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/rfc/rfc2474>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/rfc/rfc2663>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000,
<https://www.rfc-editor.org/rfc/rfc2775>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3083] Woundy, R., "Baseline Privacy Interface Management
Information Base for DOCSIS Compliant Cable Modems and
Cable Modem Termination Systems", RFC 3083,
DOI 10.17487/RFC3083, March 2001,
<https://www.rfc-editor.org/rfc/rfc3083>.
[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
<https://www.rfc-editor.org/rfc/rfc3118>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/rfc/rfc3972>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
Iannone Expires 28 December 2023 [Page 42]
Internet-Draft IP Addressing Considerations June 2023
[RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication Dial-
In User Service (RADIUS) Attributes Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent
Information Option", RFC 4014, DOI 10.17487/RFC4014,
February 2005, <https://www.rfc-editor.org/rfc/rfc4014>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/rfc/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/rfc/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.
[RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated
Addresses (CGA) Extension Field Format", RFC 4581,
DOI 10.17487/RFC4581, October 2006,
<https://www.rfc-editor.org/rfc/rfc4581>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/rfc/rfc4919>.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,
<https://www.rfc-editor.org/rfc/rfc4982>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/rfc/rfc5061>.
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
"Network Mobility (NEMO) Extensions for Mobile IPv4",
RFC 5177, DOI 10.17487/RFC5177, April 2008,
<https://www.rfc-editor.org/rfc/rfc5177>.
[RFC5275] Turner, S., "CMS Symmetric Key Management and
Distribution", RFC 5275, DOI 10.17487/RFC5275, June 2008,
<https://www.rfc-editor.org/rfc/rfc5275>.
Iannone Expires 28 December 2023 [Page 43]
Internet-Draft IP Addressing Considerations June 2023
[RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
VLANs: Scalable Security in a Multi-Client Environment",
RFC 5517, DOI 10.17487/RFC5517, February 2010,
<https://www.rfc-editor.org/rfc/rfc5517>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/rfc/rfc5533>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010,
<https://www.rfc-editor.org/rfc/rfc5795>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/rfc/rfc5944>.
[RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,
<https://www.rfc-editor.org/rfc/rfc6158>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<https://www.rfc-editor.org/rfc/rfc6182>.
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250,
DOI 10.17487/RFC6250, May 2011,
<https://www.rfc-editor.org/rfc/rfc6250>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/rfc/rfc6275>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/rfc/rfc6282>.
[RFC6626] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung,
"Dynamic Prefix Allocation for Network Mobility for Mobile
IPv4 (NEMOv4)", RFC 6626, DOI 10.17487/RFC6626, May 2012,
<https://www.rfc-editor.org/rfc/rfc6626>.
Iannone Expires 28 December 2023 [Page 44]
Internet-Draft IP Addressing Considerations June 2023
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<https://www.rfc-editor.org/rfc/rfc6740>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/rfc/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <https://www.rfc-editor.org/rfc/rfc7343>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/rfc/rfc7348>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/rfc/rfc7400>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/rfc/rfc7401>.
Iannone Expires 28 December 2023 [Page 45]
Internet-Draft IP Addressing Considerations June 2023
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/rfc/rfc7426>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015,
<https://www.rfc-editor.org/rfc/rfc7429>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/rfc/rfc7476>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/rfc/rfc7665>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/rfc/rfc7872>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/rfc/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/rfc/rfc8061>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <https://www.rfc-editor.org/rfc/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <https://www.rfc-editor.org/rfc/rfc8163>.
Iannone Expires 28 December 2023 [Page 46]
Internet-Draft IP Addressing Considerations June 2023
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
October 2017, <https://www.rfc-editor.org/rfc/rfc8280>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/rfc/rfc8376>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", RFC 8595,
DOI 10.17487/RFC8595, June 2019,
<https://www.rfc-editor.org/rfc/rfc8595>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/rfc/rfc8609>.
[RFC8677] Trossen, D., Purkayastha, D., and A. Rahman, "Name-Based
Service Function Forwarder (nSFF) Component within a
Service Function Chaining (SFC) Framework", RFC 8677,
DOI 10.17487/RFC8677, November 2019,
<https://www.rfc-editor.org/rfc/rfc8677>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/rfc/rfc8724>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
Iannone Expires 28 December 2023 [Page 47]
Internet-Draft IP Addressing Considerations June 2023
[RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April
2020, <https://www.rfc-editor.org/rfc/rfc8763>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/rfc/rfc8926>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
<https://www.rfc-editor.org/rfc/rfc8939>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/rfc/rfc8981>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/rfc/rfc9153>.
[RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/rfc/rfc9230>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/rfc/rfc9268>.
Iannone Expires 28 December 2023 [Page 48]
Internet-Draft IP Addressing Considerations June 2023
[RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural
Introduction to the Locator/ID Separation Protocol
(LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
<https://www.rfc-editor.org/rfc/rfc9299>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/rfc/rfc9300>.
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
Ed., "Locator/ID Separation Protocol (LISP) Control
Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
<https://www.rfc-editor.org/rfc/rfc9301>.
[RFC9354] Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins,
"Transmission of IPv6 Packets over Power Line
Communication (PLC) Networks", RFC 9354,
DOI 10.17487/RFC9354, January 2023,
<https://www.rfc-editor.org/rfc/rfc9354>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/rfc/rfc9374>.
[SHENOY21] Shenoy, N., Chandraiah, S., and P. Willis, "A Structured
Approach to Routing in the Internet", 2021 IEEE 22nd
International Conference on High Performance Switching and
Routing (HPSR), DOI 10.1109/hpsr52026.2021.9481818, June
2021, <https://doi.org/10.1109/hpsr52026.2021.9481818>.
[SIDE112] IETF 112 Side Meetings, "Internet Addressing: problems and
gap analysis", 2021,
<https://trac.ietf.org/trac/ietf/meeting/
wiki/112sidemeetings>.
[TERASTREAM]
"Deutsche Telekom tests TeraStream, the network of the
future, in Croatia", n.d.,
<https://www.telekom.com/en/media/media-
information/archive/deutsche-telekom-tests-terastream-the-
network-of-the-future-in-croatia-358444>.
[TOR] "The Tor Project", n.d., <https://www.torproject.org/>.
Iannone Expires 28 December 2023 [Page 49]
Internet-Draft IP Addressing Considerations June 2023
[TROSSEN10]
Trossen, D., Sarela, M., and K. Sollins, "Arguments for an
information-centric internetworking architecture", ACM
SIGCOMM Computer Communication Review vol. 40, no. 2, pp.
26-33, DOI 10.1145/1764873.1764878, April 2010,
<https://doi.org/10.1145/1764873.1764878>.
[VOIGT17] Voigt, P. and A. von dem Bussche, "The EU General Data
Protection Regulation (GDPR)", Springer International
Publishing book, DOI 10.1007/978-3-319-57959-7, 2017,
<https://doi.org/10.1007/978-3-319-57959-7>.
[WANG19] Wang, P., Zhang, J., Zhang, X., Yan, Z., Evans, B., and W.
Wang, "Convergence of Satellite and Terrestrial Networks:
A Comprehensive Survey", IEEE Access vol. 8, pp.
5550-5588, DOI 10.1109/access.2019.2963223, 2020,
<https://doi.org/10.1109/access.2019.2963223>.
[WION19] Wion, A., Bouet, M., Iannone, L., and V. Conan,
"Distributed Function Chaining with Anycast Routing",
Proceedings of the 2019 ACM Symposium on SDN Research,
DOI 10.1145/3314148.3314355, April 2019,
<https://doi.org/10.1145/3314148.3314355>.
Appendix A. Desirable Networking Features
The present section outlines the general features that are desirable
in a networked system at large, i.e., not specific to any
application/usage. Such list is a "by-product" of the addressing
discussion and completely created through mail exchanges.
1. Always-On: The world is getting more and more connected, leading
to being connected to the Internet, anywhere, by any technology
(e.g., cable, fiber, or radio), even simultaneously, "all the
time", and, most importantly, automatically (without any switch
turning). However, when defining "all the time" there is a clear
and important difference to be made between availability and
reliability vs "desired usage". In other words, "always on" can
be seen as a desirable perception at the end user level or as a
characteristic of the underlying system. From an end user
perspective, clearly the former is of importance, not necessarily
leading to an "always on" system notion but instead "always-app-
available", merely requiring the needed availability and
reliability to realize the perception of being "always on" (e.g.,
for earthquake alerts), possibly complemented by app-specific
methods to realize the "always on" perception (e.g., using local
caching rather than communication over the network).
Iannone Expires 28 December 2023 [Page 50]
Internet-Draft IP Addressing Considerations June 2023
2. Transparency: Being agnostic with respect to local domains
network protocols (Bluetooth, ZigBee, Thread, Airdrop, Airplay,
or any others) is key to provide an easy and straightforward
method for contacting people and devices without any knowledge of
network issues, particularly those specific to network-specific
solutions. While having a flexible addressing model that
accommodates a wide range of use cases is important, the
centrality of the IP protocol remains key as a mean to provide
global connectivity.
3. Multi-homing: Seamless multi-homing capability for the host is
key to best use the connectivity options that may be available to
an end user, e.g., for increasing resilience in cases of failures
of one available option. Protocols like LISP, SHIM6, QUIC,
MPTCP, SCTP (to cite a few) have been successful at providing
this capability in an incremental way, but too much of that
capability is realized within the specific application domain,
making it hard to leverage across all applications. While today
each transport protocol has its own way to perform multi-address
discovery, the network layer should provide the multi-homing
feature (e.g., SHIM6 can be used to discover all addresses on
both ends), and then leave the address selection to the
transport. With that, multi-address discovery remains a network
feature exposed to the upper layers. This may also mean to
update the Socket API (which may be actually the first thing to
do), which does not necessarily mean to expose more network
details to the applications but instead be more address agnostic,
yet, more expressive.
4. Mobility: A lot of work has been put in MobileIP ([RFC5944],
[RFC6275]) to provide seamless and lossless communications for
moving nodes (vehicle, satellites). However, it has never been
widely deployed for several reasons, like complexity of the
protocol and the fact that the problem has often been tackled at
higher layers, with applications resilient to address changes.
However, similar to multi-homing, solving the problem at higher
layers means that each and every transport protocol and
application have their own way to deal with mobility, leading to
similar observations as those for the previous multi-homing
aspect.
5. Security and Privacy: The COVID-19 pandemic has boosted end
users' desire to be protected and protect their privacy. The
balance among privacy, security, and accountability is not simple
to achieve. There exist different views on what those properties
should be, however the network should provide the means to
provide what is felt as the best trade-off for the specific use
case.
Iannone Expires 28 December 2023 [Page 51]
Internet-Draft IP Addressing Considerations June 2023
6. Performance: While certainly desirable, "performance" is a
complex issue that depends on the objectives of those building
for but also paying for performance. Examples are (i) speed
(shorter paths/direct communications), (ii) bandwidth (10petabit/
s for a link), (iii) efficiency (less overlays/encapsulations),
(iv) high efficacy or sustainability (avoid waste). From an
addressing perspective, length/format/semantics that may adapt to
the specific use case (e.g. use short addresses for low power
IoT, or, where needed, longer for addresses embedding
certificates for strong authentication, authorization and
accountability) may contribute to the performance aspects that
end users desire, such as reducing waste through not needed
encapsulation or needed conversion at network boundaries.
7. Availability, Reliability, Predictability: These three properties
are important to enable wide-range of services and applications
according to the desired usage (cf. point 1).
8. Do not do harm: Access to the Internet is considered a human
right [RFC8280]. Access to and expression through it should
align with this core principle. This issue transcends through a
variety of previously discussed 'features' that are desired, such
as privacy, security but also availability and reliability.
However, lifting the feature of network access onto a basic
rights level also brings in the aspect of "do not do harm"
through the use of the Internet with respect to wider societal
objectives. Similar to other industries, such as electricity or
cars, preventing harm usually requires an interplay of
commercial, technological, and regulatory efforts, such as the
enforcement of seat belt wearing to reduce accident death. As a
first step, the potential harmfulness of a novel method must be
recognized and weighted against the benefits of its introduction
and use. One increasingly important consideration in the
technology domain is "sustainability" of resource usage for an
end user's consumption of and participation in Internet services.
As an example, Distributed Ledger Technologies (DLT) are seen as
an important tool for a variety of applications, including
Internet decentralization ([DINRG]). However, the non-linear
increase in energy consumption means that extending proof-of-work
systems to the entire population of the planet would not only be
impractical but also possibly highly wasteful, not just at the
level of computation but also communication resource usage
[I-D.trossen-rtgwg-impact-of-dlts]. This poses the question on
how novel methods for addressing may improve on sustainability of
such technologies, particularly if adopted more widely.
Iannone Expires 28 December 2023 [Page 52]
Internet-Draft IP Addressing Considerations June 2023
9. Maximum Transmission Unit (MTU): One long standing issue in the
Internet is related to the MTU and how to discover the path MTU
in order to avoid fragmentation ([RFC9268],
[I-D.templin-6man-aero]). While it makes sense to always
leverage as much performance from local systems as possible, this
should come without sacrificing the ability to communicate with
all systems. Having a solid solution to solve the issue would
make the overall interconnection of systems more robust.
Appendix B. IP Addressing Extensions driven by Use-Cases
Over the years, a plethora of extensions has been proposed in order
to move beyond the native properties of IP addresses. The
development of those extensions can be interpreted as attempts, in a
limited scope, to go beyond the original properties of Internet
addressing and desired new capabilities that those developing the
extensions identified as being missing and yet needed and desirable.
The following sub-sections provide a more detailed and in-depth
discussion about IP Addressing Extensions dvelopped to cope with the
specific requirements of the use cases listed in Section 4.
B.1. Communication in Constrained Environments
In a number of communication scenarios, such as those encountered in
the Internet of Things (IoT), a simple, communication network
demanding minimal resources is required, allowing for a group of IoT
network devices to form a network of constrained nodes, with the
participating network and end nodes requiring as little computational
power as possible and having small memory requirements in order to
reduce the total cost of ownership of the network.Furthermore, in the
context of industrial IoT, real-time requirements and scalability
make IP technology not naturally suitable as communication technology
([OCADO]).
In the context of IoT, there are various technologies that allow to
connect small objects. In addition to IEEE 802.15.4, i.e., Low-Rate
Wireless Personal Area Network [IEEE-802.15.4-LR], several limited
domains exist through utilizing link layer technologies such as
Bluetooth Low Energy (BLE) [BLE], Digital European Cordless
Telecommunications (DECT) - Ultra Low Energy (ULE) [DECT-ULE],
Master-Slave/Token-Passing (MS/TP) [BACnet], Near-Field-Communication
(NFC) [ECMA-340], and Power Line Communication (PLC) [IEEE-1901.1].
The end-to-end principle (detailed in [RFC2775]) requires IP
addresses (e.g., IPv6 [RFC8200]) to be used on such constrained nodes
networks, allowing IoT devices using multiple communication
technologies to talk on the Internet. Often, devices located at the
Iannone Expires 28 December 2023 [Page 53]
Internet-Draft IP Addressing Considerations June 2023
edge of constrained networks act as gateway devices, usually
performing header compression ([RFC4919]). To ensure security and
reliability, multiple gateways must be deployed. IoT devices on the
network must select one of those gateways for traffic passthrough by
the devices on the (limited domain) network.
Given the constraints imposed on the computational and possibly also
communication technology, the usage of a single addressing semantic
in the form of a 128-bit endpoint identifier, i.e., IPv6 address, may
pose a challenge when operating such networks.
Another type of (differently) constrained environment is an aircraft,
which encompasses not only passenger communication but also the
integration of real-time data exchange to ensure that processes and
functions in the cabin are automatically monitored or actuated. For
aircraft networks, the goal is to be able to send and receive
information reliably and seamlessly. From this perspective, the
medium with which these packets of information are sent is of little
consequence so long as there is a level of determinism to it.
However, there is currently no effective method in implementing
wireless inter- and intra-communications between all subsystems. The
emerging wireless sensor network technology in commercial
applications such as smart thermostat systems, and smart washer/dryer
units could be transposed onto aircraft and fleet operations. The
proposal for having an Wireless Avionics Intra-Communications (WAIC)
system promises reduction in the complexity of electrical wiring
harness design and fabrication, reduction in wiring weight, increased
configuration, and potential monitoring of otherwise inaccessible
moving or rotating aircraft parts. Similar to the IoT concept, WAIC
systems consist of short-range communications and are a potential
candidate for passenger entertainment systems, smoke detectors,
engine health monitors, tire pressure monitoring systems, and other
kinds of aircraft maintenance systems.
While there are still many obstacles in terms of network security,
traffic control, and technical challenges, future WAIC can enable
real-time seamless communications between aircraft and between ground
teams and aircraft as opposed to the discrete points of data
leveraged today in aircraft communications. For that, WAIC
infrastructure should also be connected to outside IP based networks
in order to access edge/cloud facilities for data storage and mining.
However, the restricted capacity (energy, communication) of most
aircraft devices (e.g. sensors) and the nature of the transmitted
data – periodic transmission of small packets – may pose some
challenges for the usage of a single addressing semantic in the form
of a 128-bit endpoint identifier, i.e., an IPv6 address. Moreover,
most of the aircraft applications and services are focused on the
Iannone Expires 28 December 2023 [Page 54]
Internet-Draft IP Addressing Considerations June 2023
data (e.g. temperature of gas tank on left wing) and not on the
topological location of the data source. This means that the current
topological location semantic of IP addresses is not beneficial for
aircraft applications and services.
B.2. Communication within Dynamically Changing Topologies
Communication may occur over networks that exhibit dynamically
changing
topologies. One such example is that of satellite networks,
providing global Internet connections through a combination of inter-
satellite and ground station communication. With the convergence of
space-based and terrestrial networks, users can experience seamless
broadband access, e.g., on cruise ships, flights, and within cars,
often complemented by and seamlessly switching between Wi-Fi,
cellular, or satellite based networks at any time [WANG19].
The satellite network service provider will plan the transmission
path of user traffic based on the network coverage, satellite orbit,
route, and link load, providing potentially high-quality Internet
connections for users in areas that are not, or hard to be, covered
by terrestrial networks. With large scale LEO (Low Earth Orbit)
satellites, the involved topologies of the satellite network will be
changing constantly while observing a regular flight pattern in
relation to other satellites and predictable overflight patterns to
ground users [CHEN21].
Although satellite bearer services are capable of transporting IPv4
and IPv6 [CCSDS-702.1-B-1], as well as associated protocols such as
IP Multicast, DNS services and routing information, no IP
functionality is implemented on-board the spacecraft, limiting the
capability of leveraging for instance large scale satellite
constellations.
One of the major constraints of deploying routing capability on board
of a satellite is power consumption. Due to this, space routers may
end up being intermittently powered up during a daytime sunlit pass.
Another limitation of the first generation of IP routers in space was
the lack of capability to remotely manage and upgrade software while
in operation. Further, in order to reduce latency, which is the
major impairment of satellite networks, there was a need of a
networking solution able to perform in a scenario encompassing mobile
devices with the capability of storing data, leading to a significant
reduction of latency.
The limitations faced in early development of IP based satellite
communication payloads, showed the need to develop a flexible
networking solution that would enable delay tolerant communications
Iannone Expires 28 December 2023 [Page 55]
Internet-Draft IP Addressing Considerations June 2023
in the presence of intermittent connectivity. Further, in order to
reduce latency, which is the major impairment of satellite networks,
there was a need of a networking solution able to perform in a
scenario encompassing mobile devices with the capability of storing
data, leading to a significant reduction of latency.
Moreover, due to the current IP addressing scheme and its focus on IP
unicast addressing with extended deployment of IP multicast and some
IP anycast, current deployments do not take advantage of the
broadcast nature of satellite networks.
As a result of these constraints, the Consultative Committee for
Space Data Systems (CCSDS) has produced its own communication
standards distinct from those of the IETF. The conceptual model
shares many similarities with the Open Systems Interconnection model,
and individual CCSDS protocols often address comparable concerns to
those standardized by the IETF, but always under the distinct
concerns that connectivity may be intermittent, and while throughput
rates may be high, so is latency.
Furthermore, the aerospace industry necessarily distinguishes
strictly between "system" and "payload", largely for reasons of
operational safety. The "system" here consists of aerospace and
ground segments that together ensure the reliable operation of a
craft within its designated space. At the same time, the "payload"
describes any sensor or tool carried by a vehicle that is unrelated
to craft operations, even if it may constitute a vital part of the
overall mission.
The common practice today is to address system connectivity with the
CCSDS protocol stack, while treating payload connectivity
increasingly as an IP problem. It was to this end that
[CCSDS-702.1-B-1] was developed. By layering IP within the CCSDS
stack, it becomes just an opaque payload which may or may not be
transmitted depending on current mission parameters. The distinct
downside of this approach from a payload deployment perspective is
that it is next to impossible in practice to route between an IP-
based payload endpoints located on different satellites. The typical
deployment scenarios treat each craft's payload and associated ground
services as a private network, with no routing between them.
Networking platforms based on a name (data or service) based
addressing scheme would bring several potential benefits to satellite
network payloads aiming to tackle some of their major challenges,
including high propagation delay.
Iannone Expires 28 December 2023 [Page 56]
Internet-Draft IP Addressing Considerations June 2023
Concerning the vehicular networks use-case, the communication may
include Road Side Units (RSU) with the possibility to create
ephemeral connections to those RSUs for the purpose of workload
offloading, joint computation over multiple (vehicular) inputs, and
other purposes [I-D.ietf-lisp-nexagon]. Communication here may
exhibit a multi-hop nature, not just involving the vehicle and the
RSU over a direct link.
Those topologies are naturally changing constantly due to the dynamic
nature of the involved communication nodes.
The advent of Flying Ad-hoc NETworks (FANETs) has opened up an
opportunity to create new added-value services [CHRIKI19]. Although
these networks share common features with vehicular ad hoc networks,
they present several unique characteristics such as energy
efficiency, mobility degree, the capability of swarming, and the
potential large scale of swarm networks.
Due to high mobility of FANET nodes, the network topology changes
more frequently than in a typical vehicular ad hoc network. From a
routing point of view, although ad-hoc reactive and proactive routing
approaches can be used, there are other type of routing protocols
that have been developed for FANETS, such as hybrid routing protocols
and position based routing protocols, aiming to increase efficiency
in large scale networks with dynamic topologies.
Both type of protocols challenge the current Internet addressing
semantic: in the case of hybrid protocols, two different routing
strategies are used inside and outside a network zone. While inside
a zone packets are routed to a specific destination IP address,
between zones, query packets are routed to a subset of neighbors as
determined by a broadcast algorithm. In the case of position based
routing protocol, the IP addressing scheme is not used at all, since
packets are routed to a different identifier, corresponding to the
geographic location of the destination and not its topological
location. Hence, what is needed is to consolidate the geo-spatial
addressing with that of a locator-based addressing in order to
optimize routing policies across the zones.
Moreover most of the application/services deployed in FANETs tend to
be agnostic of the topological location of nodes, rather focusing on
the location of data or services. This distinction is even more
important because is dynamic network such as FANET robust networking
solutions may rely on the redundancy of data and services, meaning
that they may be found in more than one device in the network. This
in turn may bring into play a possible service-centric semantic for
addressing the packets that need routing in the dynamic network
towards a node providing said service (or content).
Iannone Expires 28 December 2023 [Page 57]
Internet-Draft IP Addressing Considerations June 2023
In the aforementioned network technologies, there is a significant
difference between the high dynamics of the underlying network
topologies, compared to the relative static nature of terrestrial
network topology, as reported in [HANDLEY18]. As a consequence, the
notion of a topological network location becomes restrictive in the
sense that not only the relation between network nodes and user
endpoint may change, but also the relation between the nodes that
form the network itself. This may lead to the challenge of
maintaining and updating the topological addresses in this constantly
changing network topology.
In attempts to utilize entirely different semantics for the
addressing itself, geographic-based routing, such as in [HUGHES03],
has been proposed for MANETs (Mobile Ad-hoc NETworks) through
providing geographic coordinates based addresses to achieve better
routing performance, lower overhead, and lower latency [ABDALLAH16].
B.3. Communication among Moving Endpoints
When packet switching was first introduced, back in the 60s/70s, it
was intended to replace the rigid circuit switching with a
communication infrastructure that was more resilient to failures. As
such, the design never really considered communication endpoints as
mobile. Even in the pioneering ALOHA [KUO95] system, despite
considering wireless and satellite links, the network was considered
static (with the exception of failures and satellites, which fall in
what is discussed in Appendix B.2). Ever since, a lot of efforts
have been devoted to overcome such limitations once it became clear
that endpoint mobility will become a main (if not THE main)
characteristic of ubiquitous communication systems.
The IETF has for a long time worked on solutions that would allow
extending the IP layer with mobility support. Because of the
topological semantic of IP addresses, endpoints need to change
addresses each time they visit a different network. However, because
routing and endpoint identification is also IP address based, this
leads to a communication disruption.
The lack of an efficient mobility management solution at network
layer enabled the opportunity to involve the transport layer in
mobility solutions, either by introducing explicit in-band signaling
to allow for communicating IP address changes (e.g., in SCTP
[RFC5061] and MPTCP [RFC6182]), or by introducing some form of
connection ID that allows for identifying a communication
independently from IP addresses (e.g., the connection ID used in QUIC
[RFC9000]).
Iannone Expires 28 December 2023 [Page 58]
Internet-Draft IP Addressing Considerations June 2023
Concerning network layer only solutions, anchor-based Mobile IP
mechanisms have been introduced ([RFC5177], [RFC6626] [RFC5944],
[RFC5275]). Mobile IP is based on a relatively complex and heavy
mechanism that makes it hard to deploy and it is not very efficient.
Furthermore, it is even less suitable than native IP in constrained
environments like the ones discussed in Appendix B.1.
Alternative approaches to Mobile IP often leverage the introduction
of some form of overlay. LISP [RFC9299], by separating the
topological semantic from the identification semantic of IP
addresses, is able to cope with endpoint mobility by dynamically
mapping endpoint identifiers with routing locators
[I-D.ietf-lisp-mn]. This comes at the price of an overlay that needs
its own additional control plane [RFC9301].
Similarly, the NVO3 (Network Virtualization Overlays) Working Group,
while focusing on Data Center environments, also explored an overlay-
based solution for multi-tenancy purposes, but also resilient to
mobility since relocating Virtual Machines (VMs) is common practice.
NVO3 considered for a long time several data planes that implement
slightly different flavors of overlays ([RFC8926], [RFC7348],
[I-D.ietf-intarea-gue]), but lacks an efficient control plane
specifically tailored for DCs.
Alternative mobility architectures have also been proposed in order
to cope with endpoint mobility outside the IP layer itself. The Host
Identity Protocol (HIP) [RFC7401] introduced a new namespace in order
to identify endpoints, namely the Host Identity (HI), while
leveraging the IP layer for topological location. On the one hand,
such an approach needs to revise the way applications interact with
the network layer, by modifying the DNS (now returning an HI instead
of an IP address) and applications to use the HIP socket extension.
On the other hand, early adopters do not necessarily gain any benefit
unless all communicating endpoints upgrade to use HIP. In spite of
this, such a solution may work in the context of a limited domain.
Another alternative approach is adopted by Information-Centric
Networking (ICN) [RFC7476]. By making content a first class citizen
of the communication architecture, the "what" rather than the "where"
becomes the real focus of the communication. However, as explained
in the next sub-section, ICN can run either over the IP layer or
completely replace it, which in turn can be seen as running the
Internet and ICN as logically completely separated limited domains.
Unmanned Aircraft Systems (UAS) are examples of moving devices that
require a stable mobility management scheme since they consist of a
number of Unmanned Aerial Vehicles (UAV; or drones) subordinated to a
Ground Control Station (GCS) [MAROJEVIC20]. The information produced
Iannone Expires 28 December 2023 [Page 59]
Internet-Draft IP Addressing Considerations June 2023
by the different sensors and electronic devices available at each UAV
is collected and processed by a software or hardware data acquisition
unit, being transmitted towards the GCS, where it is inspected and/or
analyzed. Analogously, control information transmitted from the GCS
to the UAV enables the execution of control operations over the
aircraft, such as changing the route planning or the direction
pointed by a camera.
Drones may be classified into several distinct categories, with
implications on regulatory requirements. Vehicles carrying people
generally fall under manned aircraft regulations whether they
manually or automatically piloted. At the opposite end of the
spectrum, toy drones require Line-of-Sight operations.
In the middle there are a variety of specialized UAVs that, although
may have redundant links to maintain communications in long-range
missions (e.g., satellite), perform most of the communications with
the GCS over wireless data links, e.g., based on a radio line-of-
sight technology such as Wi-Fi or 3G/4G/5G. While in some scenarios,
UAVs will operate always under the range of the same cellular base
station, in missions with large range, UAVs will move between
different cellular or wireless ground infrastructure, meaning that
the UAV needs to upload its topological locator and re-start the
ongoing communication sessions.
In particular, in Beyond Visual Line of Sight (BVLOS) operations,
legal requirements may include the use of multiple redundant radio
links (even employing different radio bands), but still require
unique identification of the vehicle. This implies that some
resolution mechanism is required that securely resolves drone
identifiers to link locators.
To this end, Drone Remote Identification Protocol
[I-D.ietf-drip-arch] uses hierarchical DRIP Entity Tags, which are
hierarchical versions of Host Identity Tags, and thus compatible with
HIP [RFC7401]. DRIP does not mandate the use of HIP, but suggests
its use in several places. Using the mobility extensions of HIP
provides for one way to ensure secure identifier resolution.
In addition to such connectivity considerations, data-centric
communication plays an increasing role, where information is named
and decoupled from its location, and applications/services operate
over these named data rather than on host-to-host communications.
In this context, the Data Distribution Service ([ALMADANI20]) has
emerged as an industry-oriented open standard that follows this
approach. The space and time decoupling allowed by DDS is very
relevant in any dynamic and distributed system, since interacting
Iannone Expires 28 December 2023 [Page 60]
Internet-Draft IP Addressing Considerations June 2023
entities are not forced to know each other and are not forced to be
simultaneously present to exchange data. Time decoupling can
significantly simplify the management of intermittent data-links, in
particular for wireless connectivity between UAS. This model of
communication, in turn, questions the locator-based addressing used
in IP and instead utilizes a data-centric naming.
In order to clarify and contrast these distinct approaches, it is
worth highlighting that in the aerospace industry, it is common
practice to distinguish between "system" and "payload" considerations
(see above). In principle, command, control (and communications)
(C2/C3) link connectivity is limited to system operations, while
payload communications is largely out of scope of regulatory
frameworks. Practically speaking, especially in light UAV, both
types of communications may be overlaid on the same data links.
From this follow legal reliability requirements that apply to systems
and C3 links which may make data-centric naming infeasible and making
the use of authenticated host-to-host communications a requirement
(such as via HIP). For payload communications, named data approaches
may be more desirable for their time decoupling properties above.
Both approaches share a need to resolve identifiers to locators.
When it comes to C3 link reliability, this translates into an end-
point selection problem, as multiple underlying links may be
available, but the determination of the "best" link depends on
specific radio characteristics [FINKHAUSER21] or even the vehicle's
spatial location.
In the case of using IP, mobility of UAVs introduces a significant
challenge. Consider the case where a GCS is receiving telemetry
information from a specific UAV. Assuming that the UAV moves and
changes its point of attachment to the network, it will have to
configure a new IP address on its wireless interface. However, this
is problematic, as the telemetry information is still being sent by
to the previous IP address of the UAV. This simple example
illustrates the necessity to deploy mobility management solutions to
handle this type of situations.
However, those technologies may not be suitable when the
communication includes interconnections of public Internet and
private networks (aka private limited domains), or when the movement
is so fast that the locator and/or topology update becomes the
limitation factor.
Scenarios from research projects such as [COMP4DRONES] and [ADACORSA]
regarding connectivity assume worse conditions. Consider an
emergency scenario in which 3GPP towers are inoperable. Emergency
Iannone Expires 28 December 2023 [Page 61]
Internet-Draft IP Addressing Considerations June 2023
services need to deploy a mobile ground control station that issues
emergency landing overrides to all UAV in the area. UAV must be able
to authenticate this mobile GCS to prevent malicious interference
with their opreations, but must be able to do so without access to
internet-connected authentication databases. HIP provides a means to
secure communications to this mobile GCS, with no means for
establishing its authority. While such considerations are not
directly part of the mechanism by which identifiers may be mapped to
locators, they illustrate the need for carrying authenticating and
authorizing information within identifiers.
Furthermore, mobility management solutions increase the complexity of
the deployment and may impact the performance of data distribution,
both in terms of signaling/data overhead and communication path
delay. Considering the specific case of multicast data streams,
mobility of content producers and consumers is inherently handled by
multicast routing protocols, which are able to react to changes of
location of mobile nodes by reconstructing the corresponding
multicast delivery trees. Nevertheless, this comes with a cost in
terms of signaling and data overhead (data may still flow through
branches of a multicast delivery tree where there are no receivers
while the routing protocol is still converging).
Another alternative is to perform the mobility management of
producers and consumers not at the application layer based on IP
multicast trees, but on the network layer based on an Information
Centric Network approach, which was already mentioned in this
section.
Some limited relief may be offered by in-network processing. Sensor
data used in autononmous operations becomes ever richer, while
available transmission throughput rates do not increase at the same
pace. For this reason, the general trend in autonomous vehicles is
to move away from transmitting raw sensor data and processing at the
ground station. Instead, aggregated Situational Awareness Data is
instead transmitted. In networking terms this implies in-network
processing, as individual sensor nodes on board a UAV network no
longer employ direct communications with a GCS. A similar approach
is taken in IoT sensors, where low-powered sensors may send raw data
via CoAP [RFC7252] or similar protocols to a processing router, and a
UAV collects aggregated data from this router to transmit it to where
it may be further processed.
Iannone Expires 28 December 2023 [Page 62]
Internet-Draft IP Addressing Considerations June 2023
B.4. Communication Across Services
As a communication infrastructure spanning many facets of life, the
Internet integrates services and resources from various aspects such
as remote collaboration, shopping, content production as well as
delivery, education, and many more. Accessing those services and
resources directly through URIs has been proposed by methods such as
those defined in ICN [RFC7476], where providers of services and
resources can advertise those through unified identifiers without
additional planning of identifiers and locations for underlying data
and their replicas. Users can access required services and resources
by virtue of using the URI-based identification, with an ephemeral
relationship built between user and provider, while the building of
such relationship may be constrained with user- as well as service-
specific requirements, such as proximity (finding nearest provider),
load (finding fastest provider), and others.
While systems like ICN [JACOBSON09] provide an alternative to the
topological addressing of IP, its deployment requires an overlay
(over IP) or native deployment (alongside IP), the latter with
dedicated gateways needed for translation. Underlay deployments are
also envisioned in [RFC8763], where ICN solutions are being used to
facilitate communication between IP addressed network endpoints or
URI-based service endpoints, still requiring gateway solutions for
interconnection with ICN-based networks as well as IP routing based
networks (cf.,
[I-D.irtf-icnrg-5gc-icn][I-D.trossen-icnrg-internet-icn-5glan]).
Although various approaches combining service and location-based
addressing have been devised, the key challenge here is to facilitate
a "natural", i.e., direct communication, without the need for
gateways above the network layer.
Another aspect of communication across services is that of chaining
individual services to a larger service. Here, an identifier would
be used that serves as a link to next hop destination within the
chain of single services, as done in the work on Service Function
Chaining (SFC). With this, services are identified at the level of
Layer 2/3 ([RFC7665], [RFC8754], [RFC8595]) or at the level of name-
based service identifiers like URLs [RFC8677] although the service
chain identification is carried as a Network Service header (NSH)
[RFC7665], separate to the packet identifiers. The forwarding with
the chain of services utilizes individual locator-based IP addressing
(for L3 chaining) to communicate the chained operations from one
Service Function Forwarder [RFC7665] to another, leading to concerns
regarding overhead incurred through the stacking of those chained
identifiers in terms of packet overhead and therefore efficiency in
handling in the intermediary nodes.
Iannone Expires 28 December 2023 [Page 63]
Internet-Draft IP Addressing Considerations June 2023
B.5. Communication Traffic Steering
Steering traffic within a communication scenario may involve at least
two aspects, namely (i) limiting certain traffic towards a certain
set of communication nodes and (ii) restraining the sending of
packets towards a given destination (or a chain of destinations) with
metrics that would allow the selection among one or more possible
destinations.
One possibility for limiting traffic inside limited domains, towards
specific objects, e.g., devices, users, or group of them, is subnet
partition with techniques such as VLAN [RFC5517], VxLAN [RFC7348], or
more evolved solution like TeraStream [TERASTREAM] realizing such
partitioning. Such mechanisms usually involve significant
configuration, and even small changes in network and user nodes could
result in a repartition and possibly additional configuration
efforts. Another key aspect is the complete lack of correlation of
the topological address and any likely more semantic-rich
identification that could be used to make policy decisions regarding
traffic steering. Suitably enriching the semantics of the packet
address, either that of the sender or receiver, so that such decision
could be made while minimizing the involvement of higher layer
mechanisms, is a crucial challenge for improving on network
operations and speed of such limited domain traffic.
When making decisions to select one out of a set of possible
destinations for a packet, IP anycast semantics can be applied albeit
being limited to the locator semantic of the IP address itself.
Recent work in [WION19] suggests utilizing the notion of IP anycast
address to encode a "service identifier", which is dynamically mapped
onto network locations where service instances fulfilling the service
request may be located. Scenarios where this capability may be
utilized are provided in [WION19] and include, but are not limited
to, scenarios such as edge-assisted VR/AR, transportation, smart
cities, smart homes, smart wearables, and digital twins.
The challenge here lies in the possible encoding of not only the
service information itself but the constraint information that helps
the selection of the "best" service instance and which is likely a
service-specific constraint in relation to the particular scenario.
The notion of an address here is a conditional (on those constraints)
one where this conditional part is an essential aspect of the
forwarding action to be taken. It needs therefore consideration in
the definition of what an address is, what is its semantic, and how
the address structure ought to look like.
Iannone Expires 28 December 2023 [Page 64]
Internet-Draft IP Addressing Considerations June 2023
As outlined in the previous sub-section, chaining services are
another aspect of steering traffic along a chain of constituent
services, where the chain is identified through either a stack of
individual identifiers, such as in Segment Routing [RFC8402], or as
an identifier that serves as a link to next hop destination within
the chain, such as in Service Function Chaining (SFC). The latter
can be applied to services identified at the level of Layer 2/3
([RFC7665], [RFC8754], [RFC8595]) or at the level of name-based
service identifiers like URLs [RFC8677]. However, the overhead
incurred through the stacking of those chained identifiers is a
concern in terms of packet overhead and therefore efficiency in
handling in the intermediary nodes.
B.6. Communication with built-in security
Today, strong security in the Internet is usually implemented as a
general network service ([KRAHENBUHL21], [RFC6158]). Among the
various reasons for such approach is the limited semantic of current
IP addresses, which do not allow to natively express security
features or trust relationships. In specific contexts strong
identification and tracking is necessary for safety and security
purposes, like for instance for UAS [RFC9153] or aeronautical
telecommunications networks [I-D.haindl-lisp-gb-atn]. This becomes
very cumbersome when communication goes beyond limited domains and in
the public Internet, where security and trust associated to those
identifier may be lost or just impossible to verify.
Efforts like Cryptographically Generated Addresses (CGA) [RFC3972],
provide some security features by embedding a truncated public key in
the last 57-bit of IPv6 address, thereby greatly enhancing
authentication and security within an IP network via asymmetric
cryptography and IPsec [RFC4301]. The development of the Host
Identity Protocol (HIP) [RFC7401] saw the introduction of
cryptographic identifiers for the newly introduced Host Identity (HI)
to allow for enhanced accountability, and therefore trust. The use
of those HIs, however, is limited by the size of IPv6 128bit
addresses.
Through a greater flexibility in addressing, any security-related
key, certificate, or identifier could instead be included in a
suitable address structure without any information loss (i.e., as-is,
without any truncation or operation as such), avoiding therefore
compromises such as those in HIP. Instead, CGAs could be created
using full length certificates, or being able to support larger HIP
addresses in a limited domain that uses it. This could significantly
help in constructing a trusted and secure communication at the
network layer, leading to connections that could be considered as
absolute secure (assuming the cryptography involved is secure). Even
Iannone Expires 28 December 2023 [Page 65]
Internet-Draft IP Addressing Considerations June 2023
more, anti-abuse mechanisms and/or DDoS protection mechanisms like
the one under discussion in PEARG ([PEARG]) Research Group may
leverage a greater flexibility of the overall Internet addressing, if
provided, in order to be more effective.
B.7. Communication protecting user privacy
The last decade has witnessed increasing concerns for user privacy
([RFC7258], [RFC6973]). IP Addresses are particularly exposed
because they can easily be associated to end users, allowing
fingerprinting and cross-site linking ([BUJLOW17], [MISHRA20]).
Indeed, while encryption is widely used to conceal the traffic
payload, the IP header remain, and particularly IP addresses, must be
transmitted in clear in order to forward packets.
One widely used approach to obfuscate the mapping between end users
and IP addresses is the use of temporary addresses [RFC8981]. The
idea here is to reduce the time window during which eavesdroppers and
information collectors can correlate network activity based on the
simple IP address. Ephemeral IP addresses have been in the working
for more than 30 years [I-D.irtf-pearg-numeric-ids-history], showing
that having a temporal semantic in IP addresses can provide improved
privacy protection.
B.8. Communication in Alternative Forwarding Architectures
The performance of communication networks has long been a focus for
optimization, due to the immediate impact on cost of ownership for
communication service providers. Technologies like MPLS [RFC3031]
have been introduced to optimize lower layer communication, e.g., by
mapping L3 traffic into aggregated labels of forwarding traffic for
the purposes of, e.g., traffic engineering.
Even further, other works have emerged in recent years that have
replaced the notion of packets with other concepts for the same
purpose of improved traffic engineering and therefore efficiency
gains. One such area is that of Software Defined Networks (SDN)
[RFC7426], which has highlighted how a majority of Internet traffic
is better identified by flows, rather than packets. Based on such
observation, alternate forwarding architectures have been devised
that are flow-based or path-based. With this approach, all data
belonging to the same traffic stream is delivered over the same path,
and traffic flows are identified by some connection or path
identifier rather than by complete routing information, possibly
enabling fast hardware based switching (e.g. [DETNETWG], [PANRG]).
Iannone Expires 28 December 2023 [Page 66]
Internet-Draft IP Addressing Considerations June 2023
On the one hand, such a communication model may be more suitable for
real-time traffic like in the context of Deterministic Networks
([DETNETWG]), where indeed a lot of work has focused on how to
"identify" packets belonging to the same DETNET flow in order to
jointly manage the forwarding within the desired deterministic
boundaries.
On the other hand, it may improve the communication efficiency in
constrained wireless environments (cf., Appendix B.1), by reducing
the overhead, hence increasing the number of useful bits per second
per Hertz.
Also, the delivery of information across similar flows may be
combined into a multipoint delivery of a single return flow, e.g.,
for scenarios of requests for a video chunk from many clients being
responded to with a single (multi-destination) flow, as outlined in
[I-D.ietf-bier-multicast-http-response] as an example. Another
opportunity to improve communication efficiency is being pursued in
ongoing IETF/IRTF work to deliver IP- or HTTP-level packets directly
over path-based or flow-based transport network solutions, such as in
[TROSSEN10], [I-D.ietf-bier-multicast-http-response],[I-D.trossen-icn
rg-internet-icn-5glan], and [I-D.irtf-icnrg-5gc-icn], with the
capability to bundle unicast forward communication streams flexibly
together in return path multipoint relations. Such capability is
particularly opportune in scenarios such as chunk-based video
retrieval or distributed data storage. However, those solutions
currently require gateways to "translate" the flow communication into
the packet-level addressing semantic in the peering IP networks.
Furthermore, the use of those alternative forwarding mechanisms often
require the encapsulation of Internet addressing information, leading
to wastage of bandwidth as well as processing resources.
Providing an alternative way of forwarding data has also been the
motivation for the efforts created in the European Telecommunication
Standards Institute (ETSI), which formed an Industry Specification
Group (ISG) named Non-IP Networking (NIN) [ETSI-NIN]. This group
sets out to develop and standardize a set of protocols leveraging an
alternative forwarding architecture, such as provided by a flow-based
switching paradigm. The deployment of such protocols may be seen to
form limited domains, still leaving the need to interoperate with the
(packet-based forwarding) Internet; a situation possibly enabled
through a greater flexibility of the addressing used across Internet-
based and alternative limited domains alike.
As an alternative to IP routing, EIBP (Extended Internet Bypass
Protocol) [SHENOY21] offers a communications model that can work with
IP in parallel and entirely transparent and independent to any
operation at network layer. For this, EIBP proposes the use of
Iannone Expires 28 December 2023 [Page 67]
Internet-Draft IP Addressing Considerations June 2023
physical and/or virtual structures in networks and among networks to
auto assign routable addresses that capture the relative position of
routers in a network or networks in a connected set of networks,
which can be used to route the packets between end domains. EIBP
operates at Layer 2.5 and provides encapsulation (at source domain),
routing, and de-encapsulation (at destination domain) for packets.
EIBP can forward any type of packets between domains. A resolver to
map the domain ID to EIBP's edge router addresses is required. When
queried for a specific domain, the resolver will return the
corresponding edge router structured addresses.
EIBP decouples routing operations from end domain operations,
offering to serve any domain, without point solutions to specific
domains. EIBP also decouples routing IDs or addresses from end
device/domain addresses. This allows for accommodation of new and
upcoming domains. A domain can extend EIBP's structured addresses
into the domain, by joining as a nested domain under one or more edge
routers, or by extending the edge router's structure addresses to its
devices.
Appendix C. Examples of Internet Addressing Properties Extensions
C.1. Length Extensions
C.1.1. Shorter Address Length Examples
* Header Compression/Translation: Considering one base station is
supposed to serve hundreds of user devices, maximizing the
effectiveness for specific spectrum directly improves user quality
of experience. To achieve the optimal utilization of the spectrum
resource in the wireless area, the RObust Header Compression
(ROHC) [RFC5795] mechanism, which has been widely adopted in
cellar network like WCDMA, LTE, and 5G, utilizes header
compression to shrink existing IPv6 headers onto shorter ones.
Similarly, header compression techniques for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPAN) have been around for
several years now, constituting a main example of using the notion
of a 'shared context' in order to reduce the size of the network
layer header ([RFC6282], [RFC7400], [BADENHOP15]). More recently,
other compression solutions have been proposed for Low Power Wide
Area Networks (LPWAN - [RFC8376]). Among them, the Static Context
Header Compression (SCHC - [RFC8724]) generalized the compression
mechanism developed by 6lo. Instead of a standard compression
behavior implemented in all 6lo nodes, SCHC introduces the notion
of rules shared by two nodes. The SCHC compression technique is
generic and can be applied to IPv6 and layers above. Regarding
the nature of the traffic, IPv6 addresses (source and destination)
Iannone Expires 28 December 2023 [Page 68]
Internet-Draft IP Addressing Considerations June 2023
can be elided, partially sent, or replaced by a small index.
Instead of the versatile IP packet, SCHC defines new packet
formats dedicated to specific applications. SCHC rules are
equivalence functions mapping this format to standard IP packets.
Also, constraints coming from either devices or carrier links
would lead to mixed scenarios and compound requirements for
extraordinary header compression. For native IPv6 communications
on DECT ULE and MS/TP Networks [RFC6282], dedicated compression
mechanisms are specified in [RFC8105] and [RFC8163], while the
transmission of IPv6 packets over NFC and PLC, specifications are
being developed in [I-D.ietf-6lo-nfc] and [RFC9354].
* Separate device from locator identifier: Solutions such as
proposed in Expedited Internet Bypass Protocol [SHENOY21] and
[RFC9300] can utilize a separation of device from locator, where
only the latter is used for routing between the different domains
using the same technology, therefore enabling the use of shorter
addresses in the (possibly constrained) local environment. Device
IDs used within such domains are carried as part of the payload by
EIBP and hence can be of shorter size suited to the domain, while,
for instance, in LISP a flexible address encoding [RFC8060] allows
shorter addresses to be supported in the LISP control plane
[RFC9301].
C.1.2. Longer Address Length Examples
* Split address zone by network realm: Network Address Translation
(NAT), which was first laid out in [RFC2663], using private
address and a stateful address binding to translate between the
realms. As outlined in [RFC2663], basic address translation is
usually extended to include port number information in the
translation process, supporting bidirectional or simple outbound
traffic only. Because the 16-bits port number is used in the
address translation, NAT theoretically increase IPv4 address
length from 32-bit to 48-bit, i.e., 281 trillion address space.
Similarly, EzIP [I-D.chen-ati-adaptive-ipv4-address-space] expects
to utilize a reserved address block, i.e., 240/4, and an IPv4
header option to include it. Based on this, it can be regarded as
EzIP is carrying a hierarchical address with two parts, where each
part is a partial 32-bit IPv4 address. The first part is a public
address residing in the "address field" of the header from
globally routable IPv4 pool [IPv4pool], i.e., ca. 3.84 billion
address space. The second part is the reserved address residing
in "option field" and belongs to the 240/4 prefix, i.e., ca.
2^28=268 million. Based on that, each EzIP deployment is tethered
on the existing Internet via one single IPv4 address, and EzIP
Iannone Expires 28 December 2023 [Page 69]
Internet-Draft IP Addressing Considerations June 2023
then have 3.84B * 268M address, ca. 1,000,000 trillion.
Collectively, the 240/4 can also be used as end point identifier
and form an overlay network providing services parallel to the
current Internet, yet independent of the latter in other aspects.
Compared to NAT, EzIP is able to establish a communication session
from either side of it, hence being completely transparent, and
facilitating a full end-to-end networking configuration.
C.2. Identity Extensions
C.2.1. Anonymous Address Identity Examples
* Traffic Proxy: Although not initially designed as a traffic proxy
approach, a Virtual Private Network (VPN [KHANVILKAR04]) is widely
utilized for packets origin hiding as a traffic detouring
methodology. As it evolved, VPN derivatives like WireGuard
[DONENFELD17] have become a mainstream instance for user privacy
and security enhancement.
With such methodology in mind, onion routing [GOLDSCHLAG99],
instantiated in the Tor Project [TOR], achieves high anonymity
through traffic hand over via intermediates, before reaching the
destination. Since the architecture of Tor requires at least
three proxies, none of them is aware of the entire route. Given
that the proxies themselves can be deployed all over cyberspace,
trust is not the prerequisite if proxies are randomly selected.
In addition, dedicated protocols are also expected to be
customized for privacy improvement via traffic proxy. For
example, Oblivious DNS over HTTPS (ODoH [RFC9230]) use a third-
party proxy to obscure identifications of user source addresses
during DNS over HTTPS (DoH [RFC8484]) resolution. Similarly,
Oblivious HTTP (OHTTP [I-D.thomson-http-oblivious]) involve proxy
alike in the HTTP environment.
* Source Address Rollover: As for source address rollover, it has
been standardized that IP addresses for Internet users should be
dynamic and temporary every time they are being generated
[RFC8981]. This benefits from the available address space in the
case of IPv6, through which address generation or assignment
should be unpredictable and stochastic for outside observers.
More radically, [I-D.gont-v6ops-ipv6-addressing-considerations]
advocates an 'ephemeral address', changing over time, for each
process. Through this, correlating user behaviors conducted by
different identifiers (i.e., source address) becomes much harder,
if not impossible, if based on the IP packet header alone.
Iannone Expires 28 December 2023 [Page 70]
Internet-Draft IP Addressing Considerations June 2023
* Private Addresses: The use and assignment of private addresses for
IPv4 is laid out in [RFC1918], while unique local addresses (ULAs)
in IPv6 [RFC4193] take over the role of private address spaces in
IPv4.
* Network Address Translation: Given address translation can be
performed several times in cascade, NATs may exist as part of
existing customer premise equipment (CPE), such as a cable or an
Ethernet router, with private wired/wireless connectivity, or may
be provided in a carrier environment to further translate ISP-
internal private addresses to a pool of (assigned) public IP
addresses. The latter is often dynamically assigned to CPEs
during its bootstrapping.
* Separate device from locator identifier: EIBP [SHENOY21] utilizes
a structured approach to addressing. It separates the routing ID
from the device ID, where only the former is used for routing. As
such, the device IDs can be encrypted, protecting the end device
identity. Similarly, LISP uses separate namespaces for routing
and identification allowing to 'hide' identifiers in encrypted
LISP packets that expose only known routing information [RFC8061].
C.2.2. Authenticated Address Identity Examples
* Self-certified Addresses: As an example of this methodology serves
[RFC3972], defining IPv6 cryptographically Generated Addresses
(CGA). A Cryptographically Generated Address is formed by
replacing the least-significant 64 bits of an IPv6 address with
the cryptographic hash of the public key of the address owner.
Packets are then signed with the private key of the sender.
Packets can be authenticate by the receiver by using the public
key of the sender and the address of the sender. The original
specifications have been already amended (cf., [RFC4581] and
[RFC4982]) in order to support multiple (stronger) cryptographic
algorithms.
* Collision-resistant addresses: In order to provide a mechanism for
IP mobility considerations, [RFC7343] defines Overlay Routable
Cryptographic Hash Identifiers (ORCHIDv2). ORCHIDs use a
determinstic scheme for generating statistically unique addresses
by concatenating a designated IPv6 prefix, a hash function
identifier, and a truncated hash. The hash input is a unique,
statically assigned context identifier concatenated with random
data. A variation of this scheme is proposed to solve
requirements of [RFC9153] in identification of unmanned aerial
vehicles using Drone Remote Identification Protocol Entity Tags
(DRIP Entity Tag; DET) [RFC9374]. This variation proposes a
distinct IPv6 prefix and new hash functions, but the major change
Iannone Expires 28 December 2023 [Page 71]
Internet-Draft IP Addressing Considerations June 2023
is to further truncate the hash, and use the freed bits for a two-
level registration authority hierarchy. The hierarchy is intended
for delegation both when registering and validating DETs globally.
* Third party granted addresses: [RFC3118] defines a DHCP option
through which authorization tickets can be generated and newly
attached hosts with proper authorization can be automatically
configured from an authenticated DHCP server. Solutions exist
where separate servers are used for user authentication like
[KOMORI02] and [RFC4014]. The former proposing to enhance the
DHCP system using registered user login and password before
actually providing an IP address lease and recording the MAC
address of the device the user used to sign-in. The latter,
couples the RADIUS authentication protocol ([RFC2865]) with DHCP,
basically piggybacking RADIUS attributes in a DHCP sub-option,
with the DHCP server contacting the RADIUS server to authenticate
the user.
C.3. Semantic Extensions
C.3.1. Extended Address Semantics Examples
* Semantic prefixes: Newer approaches to IP anycast suggest the use
of service identification in combination with a binding IP address
model [WION19] as a way to allow for metric-based traffic steering
decisions; approaches for Service Function Chaining (SFC)
[RFC7665] utilize the Network Service Header (NSH) information and
packet classification to determine the destination of the next
service.
Another example of the usage of different packet header extensions
based on IP addressing is Segment Routing. In this case, the
source chooses a path and encodes it in the packet header as an
ordered list of segments. Segments are encoded using new Routing
Extensions Header type, the Segment Routing Header (SRH), which
contains the Segment List, similar to what is already specified in
[RFC8200], i.e., a list of segment ID (SID) that dictate the path
to follow in the network. Such segment IDs are coded as 128 bit
IPv6 addresses [RFC8986].
Approaches such as [CAROFIGLIO19] utilize semantic prefixing to
allow for ICN forwarding behavior within an IPv6 network. In this
case, an HICN name is the hierarchical concatenation of a name
prefix and a name suffix, in which the name prefix is encoded as
an IPv6 128 bits word and carried in IPv6 header fields, while the
name suffix is encoded in transport headers fields such as TCP.
However, it is a challenge to determine which IPv6 prefixes should
be used as name prefixes. In order to know which IPv6 packets
Iannone Expires 28 December 2023 [Page 72]
Internet-Draft IP Addressing Considerations June 2023
should be interpreted based on an ICN semantic, it is desirable to
be able to recognize that an IPv6 prefix is a name prefix, e.g. to
define a specific address family (AF_HICN, b0001::/16). This
establishment of a specific address family allows the management
and control plane to locally configure HICN prefixes and announce
them to neighbors for interconnection.
* Separate device from locator identifier: EIBP [SHENOY21] separates
the routing locator from the device identifier, relaxing therefore
any semantic constraints on the device identifier. Similarly,
LISP uses a flexible encoding named LISP Canonical Address Format
(LCAF [RFC8061]), which allows to associate to routing locators
any possible form (and length) of identifier. ILNP [RFC6740]
introduces as well a different semantic of IP addresses, while
aligning to the IPv6 address format (128 bits). Basically, ILNP
introduces a sharper logical separation between the 64 most
significant bits and the 64 least significant bits of an IPv6
address. The former being a global locator, while the latter
being an identifier that can have different semantics (rather than
just being an interface identifier).
* Structured addressing: Network topology captures the physical
connectivity among devices in the network. There is a structure
associated with the topology. Examples are the core-distribution-
access router structure commonly used in enterprise networks and
clos topologies that are used to provide multiple connections
between Top of Rack (ToR) devices and multiple layers of spine
devices. Internet service providers use a tier structure that
defines their business relationships. A clear structure of
connected networks can be noticed in the Internet. EIBP
[SHENOY21] proposes to leverage the physical structure (or a
virtual structure overlaid on the physical structure) to auto
assign addresses to routers in a network or networks in an
internetwork to capture their relative position in the physical/
virtual topology. EIBP proposes to administratively identify
routers/networks with a tier value based on the structure.
* Localized forwarding semantics: Approaches such as those outlined
in [REED16] suggest using a novel forwarding semantic based on
path information carried in the packet itself, said path
information consists in a fixed size bit-field (see [REED16] for
more information on how to represent the path information in said
bit-field). In order to utilize existing, e.g., SDN-based,
forwarding switches, the direct use of the IPv6 source/destination
address is suggested for building appropriate match-action rules
(over the suitable binary information representing the local
output ports), while preserving the original IPv6 information in
the encapsulated packet. As mentioned above, such use of the
Iannone Expires 28 December 2023 [Page 73]
Internet-Draft IP Addressing Considerations June 2023
existing IPv6 address fields limits the size of the network to a
maximum of 256 bits (therefore paths in the network over which
such packets can be forwarded).
[I-D.trossen-icnrg-internet-icn-5glan], however, goes a step
further by suggesting to use the local forwarding as direct
network layer mechanism, removing the IP packet and only leaving
the transport/application layer, with the path identifier
constituting the network-level identifier albeit limited by using
the existing IP header for backward compatibility reasons (the
next section outlines the removal of this limitation).
C.3.2. Existing or Extended Header Semantics Examples
* In-Header extensions: In order to allow additional semantic with
respect to the pure Internet addressing, the original design of
IPv4 included the field 'Type of Service' [RFC2474], while IPv6
introduced the 'Flow label' and the 'Traffic Class' [RFC8200]
fields. In a certain way, those fields can be considered
'semantic extensions' of IP addresses, and they are 'in-header'
because natively present in the IP header (differently from
options and extension headers). However, they proved not to be
sufficient. Very often a variety of network operations are
performed on the well-known 5-tuple (source and destination
addresses; source and destination port number; and protocol
number). In some contexts all of the above-mentioned fields are
used in order to have a very fine grained solution ([RFC8939]).
* Headers option extensions: Header options have been largely under-
exploited in IPv4. However, the introduction of the more
efficient extension header model in IPv6 along with technology
progress made the use of header extensions more widespread in
IPv6. Segment Routing re-introduced the possibility to add path
semantic to the packet by encoding a loosely defined source
routing ([RFC8402]). Similarly, in the aim to overcome the
inherent shortcoming of the multi-homing in the IP context, SHIM6
([RFC5533]) also proposed the use of an extension header able to
carry multi-homing information which cannot be accommodated
natively in the IPv6 header.
To serve a moving endpoint, mechanisms like Mobile IPv6 [RFC6275]
are used for maintaining connection continuity by a dedicated IPv6
extension header. In such case, the IP address of the home agent
in Mobile IPv6 is basically an identification of the on-going
communication. In order to go beyond the interface identification
model of IP, the Host Identity Protocol (HIP) tries to introduce
an identification layer to provide (as the name says) host
identification. The architecture here relies on the use of
another type of extension header [RFC7401].
Iannone Expires 28 December 2023 [Page 74]
Internet-Draft IP Addressing Considerations June 2023
* Re-encapsulation extension: Differently from the previous
approach, re-encapsulation prepends complete new IP headers to the
original packet introducing a completely custom shim header
between the outer and inner header. This is the case for LISP,
adding a LISP specific header right after an IP+UDP header
([RFC9300]). A similar design is used by VxLAN ([RFC7348]) and
GENEVE ([RFC8926]), even if they are designed for a data center
context. IP packets can also be wrapped with headers using more
generic and semantically rich names, for instance with ICN
[I-D.trossen-icnrg-internet-icn-5glan].
* Structured addressing: Solutions such as those described in the
previous sub-section, e.g., EIBP [SHENOY21], can provide
structured addresses that are not limited to the IPv6 address
length but instead carry the information in an extension header to
remove such limitation.
Also, Information-Centric Networking (ICN) naming approaches
usually introduce structures in the (information) names without
limiting themselves to the IP address length; more so, ICN
proposes its own header format and therefore radically breaks with
not only IP addressing semantic but the format of the packet
header overall. For this, approaches such as those described in
[RFC8609] define a TLV-based binary application component
structure that is carried as a 'name' part of the CCN messages.
Such a name is a hierarchical structure for identifying and
locating a data object, which contains a sequence of name
components. Names are coded based on 2-level nested Type-Length-
Value (TLV) encodings, where the name-type field in the outer TLV
indicates this is a name, while the inner TLVs are name components
including a generic name component, an implicit SHA-256 digest
component and a SHA-256 digest of Interest parameters. For
textual representation, URIs are normally used to represent names,
as defined in [RFC3986].
In geographic addressing, position based routing protocols use the
geographic location of nodes as their addresses, and packets are
forwarded when possible in a greedy manner towards the
destination. For this purpose, the packet header includes a field
coding the geographic coordinates (x, y, z) of the destination
node, as defined in [RFC2009]. Some proposals also rely on extra
fields in the packet header to code the distance towards the
destination, in which case only the geographic coordinates of
neighbors are exchanged. This way the location of the destination
is protected even if routing packets are eavesdropped.
Iannone Expires 28 December 2023 [Page 75]
Internet-Draft IP Addressing Considerations June 2023
* Localized forwarding semantics: Unlike the original suggestion in
[REED16] to use existing SDN switches, the proliferation of P4
[BOSSHART14] opens up the possibility to utilize a locally limited
address semantic, e.g., expressed through the path identifier, as
an entirely new header (including its new address) with an
encapsulation of the IP packet for E2E delivery (including further
delivery outside the localized forwarding network) or positioning
the limited address semantic directly as the network address
semantic for the packet, i.e., removing any IP packet
encapsulation from the forwarded packet, as done in
[I-D.trossen-icnrg-internet-icn-5glan]. Removing the IPv6 address
size limitation by not utilizing the existing IP header for the
forwarding decision also allows for extensible length approaches
for building the path identifier with the potential for increasing
the supported network size. On the downside, this approach
requires to encapsulate the original IP packet header for
communication beyond the local domain in which the new header is
being used, such as discussed in the previous point above on 're-
encapsulation extension'.
Contributors
Dirk Trossen
Huawei Technologies Duesseldorf GmbH
Riesstr. 25C
80992 Munich
Germany
Email: dirk.trossen@huawei.com
Paulo Mendes
Airbus
Willy-Messerschmitt Strasse 1
81663 Munich
Germany
Email: paulo.mendes@airbus.com
Nirmala Shenoy
Rochester Institute of Technology
New-York, 14623
United States of America
Email: nxsvks@rit.edu
Laurent Toutain
IMT-Atlantique
2 rue de la Chataigneraie
Iannone Expires 28 December 2023 [Page 76]
Internet-Draft IP Addressing Considerations June 2023
CS 17607
35576 Cesson-Sevigne Cedex
France
Email: laurent.toutain@imt-atlantique.fr
Abraham Y. Chen
Avinta Communications, Inc.
142 N. Milpitas Blvd.
Milpitas, CA, 95035-4401
United States of America
Email: AYChen@Avinta.com
Dino Farinacci
lispers.net
United States of America
Email: farinacci@gmail.com
Jens Finkhaeuser
AnyWi Technologies B.V.
3e Binnenvestgracht 23H
2312 NR Leiden
Netherlands
Email: jens.finkhaeuser@anywi.com
Peng Liu
China Mobile
32 Xuanwumen West Ave
Xicheng, Beijing
100053
P.R. China
Email: liupengyjy@chinamobile.com
Yihao Jia
Email: yhjia03@gmail.com
Donald E. Eastlake 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL, 32703
United States of America
Email: d3e3e3@gmail.com
Iannone Expires 28 December 2023 [Page 77]
Internet-Draft IP Addressing Considerations June 2023
Author's Address
Luigi Iannone (editor)
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: luigi.iannone@huawei.com
Iannone Expires 28 December 2023 [Page 78]