Skip to main content

IP Addressing Considerations

Document Type Active Internet-Draft (individual)
Author Luigi Iannone
Last updated 2023-03-13
Replaces draft-iannone-internet-addressing-considerations, draft-iannone-scenarios-problems-addressing
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                    L. Iannone, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                             13 March 2023
Expires: 14 September 2023

                      IP Addressing Considerations


   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 document proposes a set of use cases showcasing the
   continuing need to extend the Internet addressing model and the
   methods used for doing so.  It further outlines the properties of
   Internet addressing as a baseline against which the extensions are
   categorized in terms of methodology used to extend the addressing
   model, together with examples of solutions 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 decides 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

   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."

Iannone                 Expires 14 September 2023               [Page 1]
Internet-Draft        IP Addressing Considerations            March 2023

   This Internet-Draft will expire on 14 September 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 (
   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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Desirable Networking Features . . . . . . . . . . . . . . . .   5
   4.  Sample of Use-Cases leading to IP Addressing Extensions . . .   8
     4.1.  Communication in Constrained Environments . . . . . . . .   9
     4.2.  Communication within Dynamically Changing Topologies  . .  10
     4.3.  Communication among Moving Endpoints  . . . . . . . . . .  14
     4.4.  Communication Across Services . . . . . . . . . . . . . .  18
     4.5.  Communication Traffic Steering  . . . . . . . . . . . . .  20
     4.6.  Communication with built-in security  . . . . . . . . . .  21
     4.7.  Communication protecting user privacy . . . . . . . . . .  22
     4.8.  Communication in Alternative Forwarding Architectures . .  22
   5.  Perceived Shortcomings in IP Addressing . . . . . . . . . . .  24
   6.  Current Properties of Internet Protocol Addressing  . . . . .  26
     6.1.  Property 1: Fixed Address Length  . . . . . . . . . . . .  26
     6.2.  Property 2: Ambiguous Address Semantic  . . . . . . . . .  27
     6.3.  Property 3: Limited Address Semantic Support  . . . . . .  27
   7.  Extending the Internet Addressing Properties  . . . . . . . .  27
     7.1.  Length Extensions . . . . . . . . . . . . . . . . . . . .  27
       7.1.1.  Shorter Address Length  . . . . . . . . . . . . . . .  28
       7.1.2.  Longer Address Length . . . . . . . . . . . . . . . .  30
       7.1.3.  Summary . . . . . . . . . . . . . . . . . . . . . . .  32
     7.2.  Identity Extensions . . . . . . . . . . . . . . . . . . .  32
       7.2.1.  Anonymous Address Identity  . . . . . . . . . . . . .  33
       7.2.2.  Authenticated Address Identity  . . . . . . . . . . .  36
       7.2.3.  Summary . . . . . . . . . . . . . . . . . . . . . . .  38
     7.3.  Semantic Extensions . . . . . . . . . . . . . . . . . . .  38
       7.3.1.  Utilizing Extended Address Semantics  . . . . . . . .  39
       7.3.2.  Utilizing Existing or Extended Header Semantics . . .  42
       7.3.3.  Summary . . . . . . . . . . . . . . . . . . . . . . .  45

Iannone                 Expires 14 September 2023               [Page 2]
Internet-Draft        IP Addressing Considerations            March 2023

     7.4.  Overall Internet Addressing Extensions Summary  . . . . .  46
   8.  Concerns Raised by IP Addressing Extensions . . . . . . . . .  48
     8.1.  Limiting Address Semantics  . . . . . . . . . . . . . . .  48
     8.2.  Complexity and Efficiency . . . . . . . . . . . . . . . .  48
       8.2.1.  Repetitive Encapsulation  . . . . . . . . . . . . . .  49
       8.2.2.  Compounding Concerns with Header Compression  . . . .  50
       8.2.3.  Introducing Path Stretch  . . . . . . . . . . . . . .  50
       8.2.4.  Complicating Traffic Engineering  . . . . . . . . . .  50
     8.3.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  51
     8.4.  Fragility . . . . . . . . . . . . . . . . . . . . . . . .  51
     8.5.  Summary of Concerns . . . . . . . . . . . . . . . . . . .  52
   9.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  54
   10. Looking Forward . . . . . . . . . . . . . . . . . . . . . . .  55
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  56
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  56
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  56
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  56
     13.2.  Informative References . . . . . . . . . . . . . . . . .  56
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  73
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  73
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  75

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 communication'.  Compared to proprietary
   technology-specific solutions, such 'common namespace for all
   communication' 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

Iannone                 Expires 14 September 2023               [Page 3]
Internet-Draft        IP Addressing Considerations            March 2023

   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

   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 documents does (or at least tries to) capture the
   discussion that the IETF community held about IP addressing model in
   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 and a (shorter) companion memo
   trying to formalize a related problem statement.  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.
   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 drafts 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 can be
   found, in addition to follow-on discussions since, with the purpose
   to document the inputs, thoughts, and opinions of a part of the IETF

2.  Introduction

   During the email exchanges and discussion the question raised about
   network features that end users (in the form of individuals or
   organizations alike) desire from the networked system at large.
   Answers to this question look at the network more from a horizontal
   perspective, i.e. not with a specific usage in mind beyond
   communication within and across networks.  The summary the discussion
   that took place on the INT Area mailing list after IETF112 on this
   issue is presented in Section 3.

   As the Internet Protocol adoption has grown towards the global
   communication system we know today, its characteristics have evolved

Iannone                 Expires 14 September 2023               [Page 4]
Internet-Draft        IP Addressing Considerations            March 2023

   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
   obeservation that in various use-cases, addressing has evolved and is
   somehow adapted or extended.  An overview of a sample of various such
   use-cases are presented in Section 4.  Then, Section 5 proposes a
   summary of the IP addressing limitations perceived thanks to these

   The desired features outlined in Section 3 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 6, 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.

   What is really important to note is that different use-cases may
   actually been handled with the same type of extension by evolving the
   properties discussed in Section 6.  This shows how a general
   solution, based on an architectural approach, is desirable and has
   the advantage to be designed in a coherent fashion, avoiding point-
   solutions which may create contention when deployed.  To this end,
   Section 7 discusses Internet addressing properties extensions,
   associating the different use-cases that take advantage of the
   property extension.

   While the various extensions proposed thrught he years certainly did
   a fine job in solving the problem at hand, this "patching" approach
   raises also concerns.  Section 8 outlines considerations and concerns
   that arise with the extension-driven approach to the basic Internet
   addressing, arguing that any requirements for solutions that would
   revise the basic Internet addressing would require to address those

3.  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

Iannone                 Expires 14 September 2023               [Page 5]
Internet-Draft        IP Addressing Considerations            March 2023

   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).

   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 application, 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

   4.  Mobility: A lot of work has been put in MobileIP ([RFC5944],
       [RFC6275]) to provide seamless and lossless communications for

Iannone                 Expires 14 September 2023               [Page 6]
Internet-Draft        IP Addressing Considerations            March 2023

       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

   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

   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

Iannone                 Expires 14 September 2023               [Page 7]
Internet-Draft        IP Addressing Considerations            March 2023

       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 computational 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.

   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 ([I-D.ietf-6man-mtu-option],
       [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.

4.  Sample of Use-Cases leading to IP Addressing Extensions

   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 outline a number of scenarios, all of
   which belong to the concept of "limited domains" [RFC8799].  While
   the list of scenarios may look long, this document focuses on
   scenarios with a number of aspects that can be observed in those
   limited domains, captured in the sub-section titles.  For each
   scenario, possible challenges are highlighted, which are then picked
   upon in Section 5, when describing more formally the existing
   shortcomings in current Internet addressing.

Iannone                 Expires 14 September 2023               [Page 8]
Internet-Draft        IP Addressing Considerations            March 2023

4.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

   In addition to IEEE 802.15.4, i.e., Low-Rate Wireless Personal Area
   Network [LR-WPAN], 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
   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.  The
   goal for any aircraft network 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

Iannone                 Expires 14 September 2023               [Page 9]
Internet-Draft        IP Addressing Considerations            March 2023

   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
   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.

   Greater flexibility in Internet addressing may 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

4.2.  Communication within Dynamically Changing Topologies

   Communication may occur over networks that exhibit dynamically
   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].

Iannone                 Expires 14 September 2023              [Page 10]
Internet-Draft        IP Addressing Considerations            March 2023

   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

   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.

   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
   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.

Iannone                 Expires 14 September 2023              [Page 11]
Internet-Draft        IP Addressing Considerations            March 2023

   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.

   Another example is that of vehicular communication, where services
   may be accessed across vehicles, such as self-driving cars, for the
   purpose of collaborative objection recognition (e.g., for collision
   avoidance), road status conveyance (e.g., for pre-warning of road-
   ahead conditions), and other purposes.  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

Iannone                 Expires 14 September 2023              [Page 12]
Internet-Draft        IP Addressing Considerations            March 2023

   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).

   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 [HANDLEY].  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 [CARTISEAN],
   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 [MANET1].

   Flexibility in Internet addressing here would allow for accommodating
   such geographic address semantics into the overall Internet
   addressing, while also enabling name/content-based addressing,

Iannone                 Expires 14 September 2023              [Page 13]
Internet-Draft        IP Addressing Considerations            March 2023

   utilizing the redundancy of many network locations providing the
   possible data.

4.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 [ALOHA] 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 Section 4.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.

   To cope with such a situation, sometimes, the transport layer gets
   involved 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

   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 Section 4.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].

Iannone                 Expires 14 September 2023              [Page 14]
Internet-Draft        IP Addressing Considerations            March 2023

   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
   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.

Iannone                 Expires 14 September 2023              [Page 15]
Internet-Draft        IP Addressing Considerations            March 2023

   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 ([DDS]) 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 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

Iannone                 Expires 14 September 2023              [Page 16]
Internet-Draft        IP Addressing Considerations            March 2023

   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 [RELIABLE-C3-UAS] 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
   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,

Iannone                 Expires 14 September 2023              [Page 17]
Internet-Draft        IP Addressing Considerations            March 2023

   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

   Greater flexibility in addressing may help in dealing with mobility
   more efficiently, 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.

   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.

4.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

Iannone                 Expires 14 September 2023              [Page 18]
Internet-Draft        IP Addressing Considerations            March 2023

   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 [CCN] 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.,

   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.

   Greater flexibility in addressing may allow for incorporating
   different information, e.g., service as well as chaining semantics,
   into the overall Internet addressing.

Iannone                 Expires 14 September 2023              [Page 19]
Internet-Draft        IP Addressing Considerations            March 2023

4.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

   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 [SFCANYCAST] 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 [SFCANYCAST] 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 14 September 2023              [Page 20]
Internet-Draft        IP Addressing Considerations            March 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.

   Flexibility in addressing may enable more semantic rich encoding
   schemes that may help in steering traffic at hardware level and
   speed, without complex mechanisms usually resulting in handling
   packets in the slow path of routers.

4.6.  Communication with built-in security

   Today, strong security in the Internet is usually implemented as a
   general network service ([PILA], [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

   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

Iannone                 Expires 14 September 2023              [Page 21]
Internet-Draft        IP Addressing Considerations            March 2023

   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
   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.

4.7.  Communication protecting user privacy

4.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.  [DETNET], [PANRG]).

   On the one hand, such a communication model may be more suitable for
   real-time traffic like in the context of Deterministic Networks
   ([DETNET]), 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

   On the other hand, it may improve the communication efficiency in
   constrained wireless environments (cf., Section 4.1), by reducing the
   overhead, hence increasing the number of useful bits per second per

   Also, the delivery of information across similar flows may be
   combined into a multipoint delivery of a single return flow, e.g.,

Iannone                 Expires 14 September 2023              [Page 22]
Internet-Draft        IP Addressing Considerations            March 2023

   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
   [TROSSEN], [I-D.ietf-bier-multicast-http-response],[I-D.trossen-icnrg
   -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) [EIBP] 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 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

Iannone                 Expires 14 September 2023              [Page 23]
Internet-Draft        IP Addressing Considerations            March 2023

   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

   A greater flexibility in addressing semantics may reduce the
   aforementioned wastage by accommodating Internet addressing in the
   light of such alternative forwarding architectures, instead enabling
   the direct use of the alternative forwarding information.

5.  Perceived Shortcomings in IP Addressing

   There are a number of shortcomings in IP addressing when targeting
   the features generally desired from the network (presented in
   Section 3) in the scenarios presented in Section 4.  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 of what
       constitute an 'address' of a packet traversing the Internet,
       which may fall foul of the defined network interface semantic of
       IP addresses.

   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: TBD

   1.  Complicating Traffic Engineering: Utilizing a plethora of non-
       address inputs into the traffic steering decision in real
       networks complicates traffic engineering in that it makes the
       development of suitable policies more complex, while also leading
       to possible contention between methods being used.

   2.  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.

Iannone                 Expires 14 September 2023              [Page 24]
Internet-Draft        IP Addressing Considerations            March 2023

   3.  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

   4.  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 table below shows how the above identified issues do arise
   somehow in our outlined communication scenarios in Section 4.

Iannone                 Expires 14 September 2023              [Page 25]
Internet-Draft        IP Addressing Considerations            March 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

6.  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.

6.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
   design of IPv4 and adopted a fixed length address towards the current

Iannone                 Expires 14 September 2023              [Page 26]
Internet-Draft        IP Addressing Considerations            March 2023

   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

6.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.

6.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

7.  Extending the Internet Addressing Properties

7.1.  Length Extensions

   Extensions in this subsection aim at extending the property described
   in Section 6.1, i.e., the fixed IP address length.

   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

Iannone                 Expires 14 September 2023              [Page 27]
Internet-Draft        IP Addressing Considerations            March 2023

   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 is 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 have a
   globally unique address.

7.1.1.  Shorter Address Length  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
   allow for very small network layer headers instead.  Methodology

   *  Header Compression/Translation: One of the main approaches to
      reduce header size in the IoT context is by compressing it.  Such

Iannone                 Expires 14 September 2023              [Page 28]
Internet-Draft        IP Addressing Considerations            March 2023

      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.  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], [ITU9959]).  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)
      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

Iannone                 Expires 14 September 2023              [Page 29]
Internet-Draft        IP Addressing Considerations            March 2023

      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 [I-D.ietf-6lo-plc].

   *  Separate device from locator identifier: Solutions such as
      proposed in Expedited Internet Bypass Protocol [EIBP] 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

7.1.2.  Longer Address Length  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 7.3, i.e., address sematic
   extensions, may still refer to extensions when longer address length
   are suitable to accommodate different address semantic.  Methodology

   *  Split address zone by network realm: This methodology first split
      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

Iannone                 Expires 14 September 2023              [Page 30]
Internet-Draft        IP Addressing Considerations            March 2023

      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
      realms.  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
      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.

Iannone                 Expires 14 September 2023              [Page 31]
Internet-Draft        IP Addressing Considerations            March 2023

      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.

7.1.3.  Summary

   Table 2 summarizes methodologies and examples on IP address length

      |                        | 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

7.2.  Identity Extensions

   Extensions in this subsection attempt extending the property
   described in Section 6.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" [GDPR]).  Hence,
   additional mechanisms are necessary in order to protect end user

   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
   mechanism are necessary to identify the users or the devices attached
   to the network.

Iannone                 Expires 14 September 2023              [Page 32]
Internet-Draft        IP Addressing Considerations            March 2023

7.2.1.  Anonymous Address Identity  Description

   As discussed in Section 6.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 [GDPR].

   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.  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

   *  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

Iannone                 Expires 14 September 2023              [Page 33]
Internet-Draft        IP Addressing Considerations            March 2023

      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
      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].

Iannone                 Expires 14 September 2023              [Page 34]
Internet-Draft        IP Addressing Considerations            March 2023

   *  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.  Examples

   *  Traffic Proxy: Although not initially designed as a traffic proxy
      approach, a Virtual Private Network (VPN [VPN]) is widely utilized
      for packets origin hiding as a traffic detouring methodology.  As
      it evolved, VPN derivatives like WireGuard [WireGuard] have become
      a mainstream instance for user privacy and security enhancement.

      With such methodology in mind, onion routing [ONION], 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.

   *  Private Addresses: The use and assignment of private addresses for
      IPv4 is laid out in [RFC1918], while unique local addresses (ULAs)

Iannone                 Expires 14 September 2023              [Page 35]
Internet-Draft        IP Addressing Considerations            March 2023

      in IPv6 [RFC4193] take over the role of private address spaces in

   *  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 [EIBP] 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].

7.2.2.  Authenticated Address Identity  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]).  Methodology

   *  Self-certified addresses: This method is usually based on the use
      of 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

Iannone                 Expires 14 September 2023              [Page 36]
Internet-Draft        IP Addressing Considerations            March 2023

   *  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.  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

   *  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) [I-D.ietf-drip-rid].  This variation
      proposes a distinct IPv6 prefix and new hash functions, but the
      major change 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.

Iannone                 Expires 14 September 2023              [Page 37]
Internet-Draft        IP Addressing Considerations            March 2023

   *  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
      [UA-DHCP] 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.

7.2.3.  Summary

   Table 3, summarize the methodologies and the examples on identity

    |                            | 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

7.3.  Semantic Extensions

   Extensions in this subsection try extending the property described in
   Section 6.3, i.e., limited address semantic support.

Iannone                 Expires 14 September 2023              [Page 38]
Internet-Draft        IP Addressing Considerations            March 2023

   As explained in Section 6.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.

7.3.1.  Utilizing Extended Address Semantics  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

   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.  Methodology

   *  Semantic prefixes: Semantic prefixes are used to separate the IPv6
      address space.  Through this, new address families, such as for
      information-centric networking [HICN], 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

Iannone                 Expires 14 September 2023              [Page 39]
Internet-Draft        IP Addressing Considerations            March 2023

      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)

      As an extreme form of separating resource from locator identifier,
      recent engineering approaches, described in [CLOUDFLARE_SIGCOMM],
      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

   *  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
      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 7.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.  Examples

   *  Semantic prefixes: Newer approaches to IP anycast suggest the use
      of service identification in combination with a binding IP address
      model [SFCANYCAST] 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

Iannone                 Expires 14 September 2023              [Page 40]
Internet-Draft        IP Addressing Considerations            March 2023

      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 [HICN] 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 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 [EIBP] 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 [EIBP]

Iannone                 Expires 14 September 2023              [Page 41]
Internet-Draft        IP Addressing Considerations            March 2023

      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 [REED] 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 [REED] 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 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).

7.3.2.  Utilizing Existing or Extended Header Semantics  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.  Methodology

Iannone                 Expires 14 September 2023              [Page 42]
Internet-Draft        IP Addressing Considerations            March 2023

   *  In-Header extensions: One way to add additional semantics besides
      the address fields is to use other fields already present in the

   *  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.

   *  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 [P4], 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.  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

Iannone                 Expires 14 September 2023              [Page 43]
Internet-Draft        IP Addressing Considerations            March 2023

      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].

   *  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

   *  Structured addressing: Solutions such as those described in the
      previous sub-section, e.g., EIBP [EIBP], 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

Iannone                 Expires 14 September 2023              [Page 44]
Internet-Draft        IP Addressing Considerations            March 2023

      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.

   *  Localized forwarding semantics: Unlike the original suggestion in
      [REED] to use existing SDN switches, the proliferation of P4 [P4]
      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'.

7.3.3.  Summary

   Table 4, summarize the methodologies and the examples on semantic

Iannone                 Expires 14 September 2023              [Page 45]
Internet-Draft        IP Addressing Considerations            March 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

7.4.  Overall Internet Addressing Extensions Summary

   The following Table 5 describes the objectives of the extensions
   discussed in this memo with respect to the properties of Internet
   addressing (Section 6).  As summarized, extensions may aim to extend
   one property of the Internet addressing, or extend other properties
   at the same time.

    |            | Length Extension | Identity Extension | Semantic  |
    |            |                  |                    | Extension |
    | 6LoWPAN    | x                |                    |           |
    | ROHC       | x                |                    |           |

Iannone                 Expires 14 September 2023              [Page 46]
Internet-Draft        IP Addressing Considerations            March 2023

    | EzIP       | x                |                    |           |
    | TOR        |                  | x                  |           |
    | ODoH       |                  | x                  |           |
    | SLAAC      |                  | x                  |           |
    | CGA        |                  | x                  | x         |
    | NAT        | x                | x                  |           |
    | HICN       |                  | x                  | x         |
    | ICNIP      | x                | x                  | x         |
    | CCNx names | x                | x                  | x         |
    | EIBP       | x                | x                  | x         |
    | Geo        | x                |                    | x         |
    | addressing |                  |                    |           |
    | REED       | x (with P4)      |                    | x         |
    | DetNet     |                  | x                  |           |
    | Mobile IP  |                  |                    | x         |
    | SHIM6      |                  |                    | x         |
    | SRv6       |                  |                    | x         |
    | HIP        |                  | x                  | x         |
    | VxLAN      |                  | x                  | x         |
    | LISP       |                  | x                  | x         |
    | SFC        |                  | x                  | x         |

     Table 5: Relationship between Extensions and Internet Addressing

Iannone                 Expires 14 September 2023              [Page 47]
Internet-Draft        IP Addressing Considerations            March 2023

8.  Concerns Raised by IP Addressing Extensions

   While the extensions to the original Internet properties, discussed
   in Section 7, demonstrate the benefits of more flexibility in
   addressing, they also raise a number of concerns, which are discussed
   in the following section.  To this end, the problems hereafter
   outlined link to the approaches to extensions summarized in
   Section 7.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.

8.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 ([EIBP], [RFC9299]), or through identifying content
   and services directly [HICN], 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 [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 [HICN] or the size of supported networks [REED] due to relying on
   the limited bit positions usable in IPv6 addresses.

8.2.  Complexity and Efficiency

   A crucial concern is the additional complexity introduced for
   realizing the additional addressing semantics.  This is particularly
   a concern since we see those additional semantics 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 [ROHC] 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 14 September 2023              [Page 48]
Internet-Draft        IP Addressing Considerations            March 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 a 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.

8.2.1.  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], [SPHINX]).  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 8.4.

Iannone                 Expires 14 September 2023              [Page 49]
Internet-Draft        IP Addressing Considerations            March 2023

8.2.2.  Compounding Concerns with Header Compression

   IP header overhead 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 [HEADER_COMP_ISSUES1], 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.

8.2.3.  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.

8.2.4.  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 ([ROBUSTSDN], [TRANSACTIONSDN]).

   This not only increases fragility, as discussed separately in
   Section 8.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.

Iannone                 Expires 14 September 2023              [Page 50]
Internet-Draft        IP Addressing Considerations            March 2023

8.3.  Security

   The properties described in Section 7 have, obviously, also
   consequences in terms of security and privacy related concerns, as
   already mentioned in other parts of this document.

   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

   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 [ADDRLESS].  However, this increased robustness to DDoS comes
   at the price of important communication setup latency and fragility,
   as discussed next.

8.4.  Fragility

   From the extensions discussed in Section 7, 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 14 September 2023              [Page 51]
Internet-Draft        IP Addressing Considerations            March 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 affects 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.

8.5.  Summary of Concerns

   Table 6, derived from the previous sections, summarizes the concerns
   related to each extension.  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 14 September 2023              [Page 52]
Internet-Draft        IP Addressing Considerations            March 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 14 September 2023              [Page 53]
Internet-Draft        IP Addressing Considerations            March 2023

9.  Discussion

   This document identifies a number of scenarios as well as general
   features end users would want from the network, positioning the
   existing Internet addressing structure itself as a key aspect to
   consider when solving key problems for Internet service provisioning.
   Such problems include supporting new, e.g., service-oriented,
   scenarios more efficiently, with improved security and efficient
   traffic engineering, as well as large scale mobility.  We can observe
   that those new forms of communication are particularly driven by the
   conceptual framework of limited domains, realizing the requirements
   of (an often limited set of) stakeholders for an optimized
   communication in those limited domains, while still utilizing the
   Internet for interconnection as well as for access to the wealth of
   existing Internet services.

   The examples of extensions discussed in Section 7 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
   but 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.

   A starting point would be to define what an address may constitute at
   which layer of the overall system, let alone the network layer.  We
   argue that any answer to this question must be derived from what
   features we may want from the network.

   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

Iannone                 Expires 14 September 2023              [Page 54]
Internet-Draft        IP Addressing Considerations            March 2023

   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.  Inaction of the community in that regard may
   lead to compound the identified concerns, eventually hampering the
   future Internet's readiness for those new uses.

   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.

10.  Looking Forward

   At this stage, this document does not provide a definite answer nor
   does it propose or promote specific solutions to the problems 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.

   We have 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

   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.

Iannone                 Expires 14 September 2023              [Page 55]
Internet-Draft        IP Addressing Considerations            March 2023

11.  Security Considerations

12.  IANA Considerations

   This document does not include any IANA request.

13.  References

13.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,

13.2.  Informative References

   [ADACORSA] "Airborne data collection on resilient system
              architectures", n.d.,

   [ADDRLESS] Hao, S., Liu, R., Weng, Z., Chang, D., Bao, C., and X. Li,
              "Addressless: A new internet server model to prevent
              network scanning", DOI 10.1371/journal.pone.0246293, PLOS
              ONE vol. 16, no. 2, pp. e0246293, February 2021,

   [ALOHA]    Kuo, F., "The ALOHA System", DOI 10.1145/205447.205451,
              ACM SIGCOMM Computer Communication Review vol. 25, no. 1,
              pp. 41-44, January 1995,

   [BACnet]   "BACnet-A Data Communication Protocol for Building
              Automation and Control Networks", ANSI/ASHRAE Standard
              135-2016, January 2016,

   [BLE]      "Bluetooth Specification", Bluetooth SIG Working Groups,
              n.d., <>.

              Hughes, L., Shumon, K., and Y. Zhang, "Cartesian Ad Hoc
              Routing Protocols", DOI 10.1007/978-3-540-39611-6_27, Ad-
              Hoc, Mobile, and Wireless Networks pp. 287-292, 2003,

   [CCN]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking named content",

Iannone                 Expires 14 September 2023              [Page 56]
Internet-Draft        IP Addressing Considerations            March 2023

              DOI 10.1145/1658939.1658941, Proceedings of the 5th
              international conference on Emerging networking
              experiments and technologies, December 2009,

              CCSDS - Consultative Committee for Space Data Systems, "IP
              over CCSDS Space Links", SIS Space Internetworking
              Services Area, n.d.,

   [CHEN21]   Chen, Y., Li, H., Liu, J., Wu, Q., and Z. Lai, "GAMS: An
              IP Address Management Mechanism in Satellite Mega-
              constellation Networks",
              DOI 10.1109/iwcmc51323.2021.9498722, 2021 International
              Wireless Communications and Mobile Computing (IWCMC), June
              2021, <>.

   [CHRIKI19] Chriki, A., Touati, H., Snoussi, H., and F. Kamoun,
              "FANET: Communication, mobility models and security
              issues", DOI 10.1016/j.comnet.2019.106877, Computer
              Networks vol. 163, pp. 106877, November 2019,

              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",
              DOI 10.1145/3452296.3472922, Proceedings of the 2021 ACM
              SIGCOMM 2021 Conference, August 2021,

              "COMP4DRONES", n.d.,

   [CONTIKI]  "Contiki-NG: The OS for Next Generation IoT Devices",
              n.d., <>.

   [DDS]      AL-Madani, B., Elkhider, S., and S. El-Ferik, "DDS-Based
              Containment Control of Multiple UAV Systems",
              DOI 10.3390/app10134572, Applied Sciences vol. 10, no. 13,
              pp. 4572, July 2020,

Iannone                 Expires 14 September 2023              [Page 57]
Internet-Draft        IP Addressing Considerations            March 2023

   [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,

   [DETNET]   "Deterministic Networking (DetNet)", n.d.,

   [DINRG]    "Decentralized Internet Infrastructure - DINRG", n.d.,

   [ECMA-340] EECMA-340, "Near Field Communication - Interface and
              Protocol (NFCIP-1) 3rd Ed.", June 2013.

   [EIBP]     Shenoy, S Chandraiah, P Willis, N., "A Structured Approach
              to Routing in the Internet", June 2021, <First Intl
              Workshop on Semantic Addressing and Routing for Future

   [ETSI-NIN] ETSI - European Telecommunication Standards Institute,
              "Non-IP Networking - NIN", n.d.,

   [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",
              DOI 10.1145/3452296.3472922, Proceedings of the 2021 ACM
              SIGCOMM 2021 Conference, August 2021,

   [GDPR]     Voigt, P. and A. von dem Bussche, "The EU General Data
              Protection Regulation (GDPR)",
              DOI 10.1007/978-3-319-57959-7, Springer International
              Publishing book, 2017,

              "Global Network Address Translation Combined with Audited
              and Trusted CDN or HTTP-Proxy Eliminating
              Reidentification", n.d.,

   [HANDLEY]  Handley, M., "Delay is Not an Option: Low Latency Routing
              in Space", DOI 10.1145/3286062.3286075, Proceedings of the

Iannone                 Expires 14 September 2023              [Page 58]
Internet-Draft        IP Addressing Considerations            March 2023

              17th ACM Workshop on Hot Topics in Networks, November
              2018, <>.

              Mesrinejad, F., Hashim, F., Noordin, N., Rasid, M., and R.
              Abdullah, "The effect of fragmentation and header
              compression on IP-based sensor networks (6LoWPAN)",
              DOI 10.1109/apcc.2011.6152926, The 17th Asia Pacific
              Conference on Communications, October 2011,

   [HICN]     Muscariello, L., "Hybrid Information-Centric Networking:
              ICN inside the Internet Protocol", March 2018,

              "History of 127/8 as localhost/loopback addresses", n.d.,

              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-12, 11
              December 2022, <

              Gont, F. and G. Gont, "IPv6 Addressing Considerations",
              Work in Progress, Internet-Draft, draft-gont-v6ops-ipv6-
              addressing-considerations-02, 1 June 2022,

              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-08, 23
              September 2022,

              Choi, Y., Hong, Y., and J. Youn, "Transmission of IPv6
              Packets over Near Field Communication", Work in Progress,

Iannone                 Expires 14 September 2023              [Page 59]
Internet-Draft        IP Addressing Considerations            March 2023

              Internet-Draft, draft-ietf-6lo-nfc-22, 6 March 2023,

              Hou, J., Liu, B. R., Hong, Y., Tang, X., and C. E.
              Perkins, "Transmission of IPv6 Packets over Power Line
              Communication (PLC) Networks", Work in Progress, Internet-
              Draft, draft-ietf-6lo-plc-11, 18 May 2022,

              Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU
              Hop-by-Hop Option", Work in Progress, Internet-Draft,
              draft-ietf-6man-mtu-option-15, 10 May 2022,

              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,

              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,

              Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
              Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft
              System Remote ID (UAS RID)", Work in Progress, Internet-
              Draft, draft-ietf-drip-rid-37, 2 December 2022,

              Herbert, T., Yong, L., and O. Zia, "Generic UDP
              Encapsulation", Work in Progress, Internet-Draft, draft-
              ietf-intarea-gue-09, 26 October 2019,

              Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
              Architecture", Work in Progress, Internet-Draft, draft-

Iannone                 Expires 14 September 2023              [Page 60]
Internet-Draft        IP Addressing Considerations            March 2023

              ietf-intarea-tunnels-12, 27 December 2022,

              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,

              Barkai, S., Fernandez-Ruiz, B., Tamir, R., Rodriguez-
              Natal, A., Maino, F., Cabellos-Aparicio, A., Paillisse,
              J., and D. Farinacci, "Network-Hexagons:Geolocation
              Mobility Edge Network Based On H3 and LISP", Work in
              Progress, Internet-Draft, draft-ietf-lisp-nexagon-47, 14
              January 2023,

              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,

              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, <

              Templin, F., "Automatic Extended Route Optimization
              (AERO)", Work in Progress, Internet-Draft, draft-templin-
              6man-aero-63, 12 October 2022,

              Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
              Progress, Internet-Draft, draft-thomson-http-oblivious-02,
              24 August 2021, <

              Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and
              J. Riihijarvi, "Internet Services over ICN in 5G LAN

Iannone                 Expires 14 September 2023              [Page 61]
Internet-Draft        IP Addressing Considerations            March 2023

              Environments", Work in Progress, Internet-Draft, draft-
              trossen-icnrg-internet-icn-5glan-04, 1 October 2020,

              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, <

              "Standard for Medium Frequency (less than 15 MHz) Power
              Line Communications for Smart Grid Applications", IEEE
              1901.1 IEEE-SA Standards Board, May 2018,

   [IPv4pool] "IANA IPv4 Address Space Registry", n.d.,

   [ITU9959]  Badenhop, C., Fuller, J., Hall, J., Ramsey, B., and M.
              Rice, "Evaluating ITU-T G.9959 Based Wireless Systems Used
              in Critical Infrastructure Assets",
              DOI 10.1007/978-3-319-26567-4_13, IFIP Advances in
              Information and Communication Technology pp. 209-227,
              2015, <>.

   [LR-WPAN]  "IEEE 802.15.4 - IEEE Standard for Low-Rate Wireless
              Networks", IEEE 802.15 WPAN Task Group 4, May 2020,

   [MANET1]   Abdallah, A., Abdallah, E., Bsoul, M., and A. Otoom,
              "Randomized geographic-based routing with nearly
              guaranteed delivery for three-dimensional ad hoc network",
              DOI 10.1177/1550147716671255, International Journal of
              Distributed Sensor Networks vol. 12, no. 10, pp.
              155014771667125, October 2016,

              Marojevic, V., Guvenc, I., Dutta, R., Sichitiu, M., and B.
              Floyd, "Advanced Wireless for Unmanned Aerial Systems: 5G
              Standardization, Research Challenges, and AERPAW
              Architecture", DOI 10.1109/mvt.2020.2979494, IEEE
              Vehicular Technology Magazine vol. 15, no. 2, pp. 22-30,
              June 2020, <>.

Iannone                 Expires 14 September 2023              [Page 62]
Internet-Draft        IP Addressing Considerations            March 2023

   [OCADO]    "Ocado Technology's robot warehouse a Hive of IoT
              innovation", n.d., <

   [ONION]    Goldschlag, D., Reed, M., and P. Syverson, "Onion
              routing", DOI 10.1145/293411.293443, Communications of the
              ACM vol. 42, no. 2, pp. 39-41, February 1999,

   [P4]       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",
              DOI 10.1145/2656877.2656890, ACM SIGCOMM Computer
              Communication Review vol. 44, no. 3, pp. 87-95, July 2014,

   [PANRG]    "Path Aware Networking Research Group - PANRG", n.d.,

   [PEARG]    "Privacy Enhancements and Assessments Research Group -
              PEARG", n.d., <>.

   [PILA]     Krahenbuhl, C., Legner, M., Bitterli, S., and A. Perrig,
              "Pervasive Internet-Wide Low-Latency Authentication",
              DOI 10.1109/icccn52240.2021.9522235, 2021 International
              Conference on Computer Communications and
              Networks (ICCCN), July 2021,

   [REED]     Reed, M., Al-Naday, M., Thomos, N., Trossen, D.,
              Petropoulos, G., and S. Spirou, "Stateless multicast
              switching in software defined networks",
              DOI 10.1109/icc.2016.7511036, 2016 IEEE International
              Conference on Communications (ICC), May 2016,

              Finkhauser, J. and M. Larsen, "Reliable Command, Control
              and Communication Links for Unmanned Aircraft Systems:
              Towards compliance of commercial drones",
              DOI 10.1145/3444950.3444954, Proceedings of the 2021 Drone
              Systems Engineering and Rapid Simulation and Performance
              Evaluation: Methods and Tools Proceedings, January 2021,

   [RFC1752]  Bradner, S. and A. Mankin, "The Recommendation for the IP

Iannone                 Expires 14 September 2023              [Page 63]
Internet-Draft        IP Addressing Considerations            March 2023

              Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752,
              January 1995, <>.

   [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, <>.

   [RFC2009]  Imielinski, T. and J. Navas, "GPS-Based Addressing and
              Routing", RFC 2009, DOI 10.17487/RFC2009, November 1996,

   [RFC2101]  Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
              Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101,
              February 1997, <>.

   [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,

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              DOI 10.17487/RFC2775, February 2000,

   [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,

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,

   [RFC3118]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,

Iannone                 Expires 14 September 2023              [Page 64]
Internet-Draft        IP Addressing Considerations            March 2023

   [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,

   [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, <>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <>.

   [RFC4581]  Bagnulo, M. and J. Arkko, "Cryptographically Generated
              Addresses (CGA) Extension Field Format", RFC 4581,
              DOI 10.17487/RFC4581, October 2006,

   [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,

   [RFC4982]  Bagnulo, M. and J. Arkko, "Support for Multiple Hash
              Algorithms in Cryptographically Generated Addresses
              (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,

   [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,

   [RFC5177]  Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
              "Network Mobility (NEMO) Extensions for Mobile IPv4",

Iannone                 Expires 14 September 2023              [Page 65]
Internet-Draft        IP Addressing Considerations            March 2023

              RFC 5177, DOI 10.17487/RFC5177, April 2008,

   [RFC5275]  Turner, S., "CMS Symmetric Key Management and
              Distribution", RFC 5275, DOI 10.17487/RFC5275, June 2008,

   [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,

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
              June 2009, <>.

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              DOI 10.17487/RFC5795, March 2010,

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, DOI 10.17487/RFC5944, November 2010,

   [RFC6158]  DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines",
              BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011,

   [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,

   [RFC6250]  Thaler, D., "Evolution of the IP Model", RFC 6250,
              DOI 10.17487/RFC6250, May 2011,

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <>.

   [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,

Iannone                 Expires 14 September 2023              [Page 66]
Internet-Draft        IP Addressing Considerations            March 2023

   [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,

   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <>.

   [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, <>.

   [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,

   [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, <>.

   [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,

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-

Iannone                 Expires 14 September 2023              [Page 67]
Internet-Draft        IP Addressing Considerations            March 2023

              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <>.

   [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,

   [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,

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,

   [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,

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <>.

   [RFC8061]  Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
              (LISP) Data-Plane Confidentiality", RFC 8061,
              DOI 10.17487/RFC8061, February 2017,

   [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, <>.

   [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, <>.

Iannone                 Expires 14 September 2023              [Page 68]
Internet-Draft        IP Addressing Considerations            March 2023

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

   [RFC8280]  ten Oever, N. and C. Cath, "Research into Human Rights
              Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
              October 2017, <>.

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,

   [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, <>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,

   [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,

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,

   [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,

   [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,

   [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,

Iannone                 Expires 14 September 2023              [Page 69]
Internet-Draft        IP Addressing Considerations            March 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, <>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,

   [RFC8926]  Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
              "Geneve: Generic Network Virtualization Encapsulation",
              RFC 8926, DOI 10.17487/RFC8926, November 2020,

   [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,

   [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,

   [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,

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,

   [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,

   [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,

Iannone                 Expires 14 September 2023              [Page 70]
Internet-Draft        IP Addressing Considerations            March 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,

   [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,

   [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,

              Canini, M., Kuznetsov, P., Levin, D., and S. Schmid, "A
              distributed and robust SDN control plane for transactional
              network updates", DOI 10.1109/infocom.2015.7218382, 2015
              IEEE Conference on Computer Communications (INFOCOM),
              April 2015,

   [ROHC]     Fitzek, F., Rein, S., Seeling, P., and M. Reisslein,
              "RObust Header Compression (ROHC) Performance for
              Multimedia Transmission over 3G/4G Wireless Networks",
              DOI 10.1007/s11277-005-7733-2, Wireless Personal
              Communications vol. 32, no. 1, pp. 23-41, January 2005,

              Wion, A., Bouet, M., Iannone, L., and V. Conan,
              "Distributed Function Chaining with Anycast Routing",
              DOI 10.1145/3314148.3314355, Proceedings of the 2019 ACM
              Symposium on SDN Research, April 2019,

   [SIDE112]  IETF 112 Side Meetings, "Internet Addressing: problems and
              gap analysis", 2021,

   [SPHINX]   Danezis, G. and I. Goldberg, "Sphinx: A Compact and
              Provably Secure Mix Format", DOI 10.1109/sp.2009.15, 2009
              30th IEEE Symposium on Security and Privacy, May 2009,

Iannone                 Expires 14 September 2023              [Page 71]
Internet-Draft        IP Addressing Considerations            March 2023

              "Deutsche Telekom tests TeraStream, the network of the
              future, in Croatia", n.d.,

   [TOR]      "The Tor Project", n.d., <>.

              Curic, M., Despotovic, Z., Hecker, A., and G. Carle,
              "Transactional Network Updates in SDN",
              DOI 10.1109/eucnc.2018.8442793, 2018 European Conference
              on Networks and Communications (EuCNC), June 2018,

   [TROSSEN]  Trossen, D., Sarela, M., and K. Sollins, "Arguments for an
              information-centric internetworking architecture",
              DOI 10.1145/1764873.1764878, ACM SIGCOMM Computer
              Communication Review vol. 40, no. 2, pp. 26-33, April
              2010, <>.

   [UA-DHCP]  Komori, T. and T. Saito, "The secure DHCP system with user
              authentication", DOI 10.1109/lcn.2002.1181774, 27th Annual
              IEEE Conference on Local Computer Networks, 2002.
              Proceedings. LCN 2002., August 2003,

   [VPN]      Khanvilkar, S. and A. Khokhar, "Virtual private networks:
              an overview with performance evaluation",
              DOI 10.1109/mcom.2004.1341273, IEEE Communications
              Magazine vol. 42, no. 10, pp. 146-154, October 2004,

   [WANG19]   Wang, P., Zhang, J., Zhang, X., Yan, Z., Evans, B., and W.
              Wang, "Convergence of Satellite and Terrestrial Networks:
              A Comprehensive Survey", DOI 10.1109/access.2019.2963223,
              IEEE Access vol. 8, pp. 5550-5588, 2020,

              Donenfeld, J., "WireGuard: Next Generation Kernel Network
              Tunnel", DOI 10.14722/ndss.2017.23160, Proceedings 2017
              Network and Distributed System Security Symposium, 2017,

Iannone                 Expires 14 September 2023              [Page 72]
Internet-Draft        IP Addressing Considerations            March 2023


   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.  Also thanks for the
   interesting discussions to Carsten Borman, Brian E.  Carpenter, and
   Eric Vyncke.


   Dirk Trossen
   Huawei Technologies Duesseldorf GmbH
   Riesstr. 25C
   80992 Munich


   Paulo Mendes
   Willy-Messerschmitt Strasse 1
   81663 Munich


   Nirmala Shenoy
   Rochester Institute of Technology
   New-York,  14623
   United States of America


   Laurent Toutain
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex


   Abraham Y. Chen
   Avinta Communications, Inc.

Iannone                 Expires 14 September 2023              [Page 73]
Internet-Draft        IP Addressing Considerations            March 2023

   142 N. Milpitas Blvd.
   Milpitas, CA,  95035-4401
   United States of America


   Dino Farinacci
   United States of America


   Jens Finkhaeuser
   AnyWi Technologies B.V.
   3e Binnenvestgracht 23H
   2312 NR Leiden


   Peng Liu
   China Mobile
   32 Xuanwumen West Ave
   Xicheng, Beijing
   P.R. China


   Yihao Jia


   Donald E. Eastlake 3rd
   Futurewei Technologies
   2386 Panoramic Circle
   Apopka, FL,  32703
   United States of America


Iannone                 Expires 14 September 2023              [Page 74]
Internet-Draft        IP Addressing Considerations            March 2023

Author's Address

   Luigi Iannone (editor)
   Huawei Technologies France S.A.S.U.
   18, Quai du Point du Jour
   92100 Boulogne-Billancourt


Iannone                 Expires 14 September 2023              [Page 75]