Internet DRAFT - draft-iannone-internet-addressing-considerations

draft-iannone-internet-addressing-considerations







Network Working Group                                         L. Iannone
Internet-Draft                                                D. Trossen
Intended status: Informational                                    Huawei
Expires: 9 March 2023                                          P. Mendes
                                                                  Airbus
                                                               N. Shenoy
                                                                  R.I.T.
                                                              L. Toutain
                                                          IMT-Atlantique
                                                               A.Y. Chen
                                                                  Avinta
                                                            D. Farinacci
                                                             lispers.net
                                                          J. Finkhaeuser
                                                                   AnyWi
                                                                  Y. Jia
                                                        5 September 2022


                   Internet Addressing Considerations
          draft-iannone-internet-addressing-considerations-01

Abstract

   There exist many extensions to Internet addressing, as it is defined
   in RFC 791 for IPv4 and RFC 8200 for IPv6, respectively.  Those
   extensions have been developed to evolve the addressing capabilities
   beyond the basic properties of Internet addressing.  This document
   outlines those properties 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.

   While introducing such extensions, we outline the shortcomings we see
   with those extensions.  This ultimately leads to consider whether or
   not a more consistent approach to tackling the identified use cases,
   beyond point-wise extensions as done so far, would be beneficial.
   The benefits are the ones detailed in the companion document
   [I-D.iannone-scenarios-problems-addressing], where, leveraging on the
   shortcomings identified in this memo and scenarios provided in
   [I-D.iannone-scenarios-problems-addressing], a clear problem
   statement is provided.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.





Iannone, et al.           Expires 9 March 2023                  [Page 1]

Internet-Draft     Internet Addressing Considerations     September 2022


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 March 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Properties of Internet Addressing . . . . . . . . . . . . . .   4
     2.1.  Property 1: Fixed Address Length  . . . . . . . . . . . .   4
     2.2.  Property 2: Ambiguous Address Semantic  . . . . . . . . .   4
     2.3.  Property 3: Limited Address Semantic Support  . . . . . .   5
   3.  Extending the Internet Addressing Properties  . . . . . . . .   5
     3.1.  Length Extensions . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Shorter Address Length  . . . . . . . . . . . . . . .   6
       3.1.2.  Longer Address Length . . . . . . . . . . . . . . . .   8
       3.1.3.  Summary . . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Identity Extensions . . . . . . . . . . . . . . . . . . .  10
       3.2.1.  Anonymous Address Identity  . . . . . . . . . . . . .  10
       3.2.2.  Authenticated Address Identity  . . . . . . . . . . .  14
       3.2.3.  Summary . . . . . . . . . . . . . . . . . . . . . . .  16
     3.3.  Semantic Extensions . . . . . . . . . . . . . . . . . . .  16
       3.3.1.  Utilizing Extended Address Semantics  . . . . . . . .  17
       3.3.2.  Utilizing Existing or Extended Header Semantics . . .  20
       3.3.3.  Summary . . . . . . . . . . . . . . . . . . . . . . .  23
   4.  Overview of Approaches to Extend Internet Addressing  . . . .  24
   5.  A System View on Address  . . . . . . . . . . . . . . . . . .  26



Iannone, et al.           Expires 9 March 2023                  [Page 2]

Internet-Draft     Internet Addressing Considerations     September 2022


   6.  Concerns in Extensions to Internet Addressing . . . . . . . .  27
     6.1.  Limiting Address Semantics  . . . . . . . . . . . . . . .  27
     6.2.  Complexity and Efficiency . . . . . . . . . . . . . . . .  27
       6.2.1.  Repetitive encapsulation  . . . . . . . . . . . . . .  28
       6.2.2.  Compounding concerns with header compression  . . . .  29
       6.2.3.  Introducing Path Stretch  . . . . . . . . . . . . . .  29
       6.2.4.  Complicating Traffic Engineering  . . . . . . . . . .  29
     6.3.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  30
     6.4.  Fragility . . . . . . . . . . . . . . . . . . . . . . . .  30
   7.  Summary of concernss  . . . . . . . . . . . . . . . . . . . .  31
   8.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  33
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   11. Informative References  . . . . . . . . . . . . . . . . . . .  34
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  45
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  45

1.  Introduction

   [I-D.iannone-scenarios-problems-addressing] outlines scenarios and
   problems in Internet addressing through presenting a number of cases
   of communication that have emerged over the many years of utilizing
   the Internet and for which various extensions to the network
   interface-centric addressing of IPv6 have been developed.  In order
   to continue the discussion on the emerging needs for addressing,
   initiated with [I-D.iannone-scenarios-problems-addressing], this memo
   aims at identifying evolutions from the original Internet addressing
   model to add desirable features that have been added by various
   extensions, in various contexts.

   The approach to identifying the main evolution directions is guided
   by key properties of Internet addressing, outlined in Section 2,
   namely (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.

   Those basic properties, and the potential shortcomings that arise
   from those properties, give way to extensions that have been proposed
   over the course of deploying new Internet technologies.  Section 3
   discusses those extensions, summarized as evolution with respect to
   the the basic properties in Section 4.

   Finally, this memo outlines considerations and concerns that arise
   with the extension-driven approach to the basic Internet addressing,
   discussed in Section 6, arguing that any requirements for solutions



Iannone, et al.           Expires 9 March 2023                  [Page 3]

Internet-Draft     Internet Addressing Considerations     September 2022


   that would revise the basic Internet addressing would require to
   address those concerns.

2.  Properties of Internet Addressing

   As the Internet Protocol adoption has grown towards the global
   communication system we know today, its characteristics have evolved
   subtly, with [RFC6250] documenting various aspects of the IP service
   model and its frequent misconceptions, including Internet addressing.
   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.

   Section 3 elaborates on various extensions that aim to expand
   Internet addressing beyond those properties; those extensions are
   positioned as intentions to go beyond perceived shortcomings of those
   key properties.

2.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
   IPv6.  As a consequence, the 128-bit fixed address length of IPv6 is
   regarded as a balance between fast forwarding (i.e., fixed length)
   and practically boundless cyberspace (i.e., enabled by using 128-bit
   addresses).

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



Iannone, et al.           Expires 9 March 2023                  [Page 4]

Internet-Draft     Internet Addressing Considerations     September 2022


   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.

2.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]),
   hence, IPv6 [RFC4291] introduced some form of additional semantics
   based on specific prefix values, for instance link-local addresses or
   a more structured multicast addressing.  Nevertheless, systematic
   support for rich address semantics remains limited and basically
   prefix-based.

3.  Extending the Internet Addressing Properties

   Over the years, a plethora of extensions has been proposed in order
   to move beyond the native properties of IP addresses, outlined in the
   previous section.  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.

3.1.  Length Extensions

   Extensions in this subsection aim at extending the property described
   in Section 2.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
   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, 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




Iannone, et al.           Expires 9 March 2023                  [Page 5]

Internet-Draft     Internet Addressing Considerations     September 2022


   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.

3.1.1.  Shorter Address Length

3.1.1.1.  Description:

   In the context of IoT [RFC7228], where bandwidth and energy are very
   scarce resources, the static length of 128-bit for an IP address is
   more a hindrance than a benefit since 128-bit for an IP address may
   occupy a lot of space, even to the point of being the dominant part
   of a packet.  In order to use bandwidth more efficiently and use less
   energy in end-to-end communication, solutions have been proposed that
   allow for very small network layer headers instead.

3.1.1.2.  Methodology:

   *  Header Compression/Translation: One of the main approaches to
      reduce header size in the IoT context is by compressing it.  Such
      technique is based on a stateful approach, utilizing what is
      usually called a 'context' on the IoT sensor and the gateway for
      communications between an IoT device and a server placed somewhere
      in the Internet - from the edge to the cloud.

      The role of the 'context' is to provide a way to 'compress' the
      original IP header into a smaller one, using shorter address
      information and/or dropping some field(s); the context here serves
      as a kind of dictionary.




Iannone, et al.           Expires 9 March 2023                  [Page 6]

Internet-Draft     Internet Addressing Considerations     September 2022


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

3.1.1.3.  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 rule shared by two nodes.  The SCHC compression technique is
      generic and can be applied to IPv6 and above layers.  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
      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
      [I-D.ietf-lisp-rfc6830bis] 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



Iannone, et al.           Expires 9 March 2023                  [Page 7]

Internet-Draft     Internet Addressing Considerations     September 2022


      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 [I-D.ietf-lisp-rfc6833bis].

3.1.2.  Longer Address Length

3.1.2.1.  Description

   Historically, obtaining adequate address space is considered as the
   primary and raw motivation to invent IPv6.  Longer address (more than
   32-bit of IPv4 address), which can accommodate almost inexhaustible
   devices, used to be considered as the surest direction in 1990s.
   Nevertheless, to protect the sunk cost of IPv4 deployment, certain
   efforts focus on IPv4 address space depletion question but engineer
   IPv4 address length in a more practical way.  Such effort, i.e., NAT
   (Network Address Translation), unexpectedly and significantly slows
   IPv6 deployment because of its high cost-effectiveness in practice.

   Another crucial need for longer address lengths comes from "semantic
   extensions" to IP addresses, where the extensions themselves do not
   fit within the length limitation of the IP address.  This sub-section
   focuses on address length extensions that aim at reducing the IPv4
   addresses depletion, while Section 3.3, i.e., address sematic
   extensions, may still refer to extensions when longer address length
   are suitable to accommodate different address semantic.  See
   Section 3.3 for details of sematic-driven address lengthening.

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



Iannone, et al.           Expires 9 March 2023                  [Page 8]

Internet-Draft     Internet Addressing Considerations     September 2022


      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.

3.1.2.3.  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 [EzIP] 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.

      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.

3.1.3.  Summary

   Table 1 summarizes methodologies and examples towards filling gaps on
   IP address length extensions.




Iannone, et al.           Expires 9 March 2023                  [Page 9]

Internet-Draft     Internet Addressing Considerations     September 2022


      +------------------------+----------------------+-------------+
      |                        | 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 1: Summary Length Extensions

3.2.  Identity Extensions

   Extensions in this subsection attempt extending the property
   described in Section 2.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
   privacy.

   For network regulation of sensitive information, on the other hand,
   dynamically allocated IP addresses are not sufficient to guarantee
   device or user identification.  As such, different address allocation
   systems, with stronger identification properties are necessary where
   security and authentication are at highest priority.  Hence, in order
   to protect information security within a network, additional
   mechanism are necessary to identify the users or the devices attached
   to the network.

3.2.1.  Anonymous Address Identity

3.2.1.1.  Description

   As discussed in Section 2.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



Iannone, et al.           Expires 9 March 2023                 [Page 10]

Internet-Draft     Internet Addressing Considerations     September 2022


   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.

3.2.1.2.  Methodology:

   *  Traffic Proxy: Detouring the traffic to a trusted proxy is a
      heuristic solution.  Since nodes between trusted proxy and
      destination (including the destination per se) can only observe
      the source address of the proxy, the 'identification' of the
      origin source can thereby be hidden.  To obfuscate the nodes
      between origin and the proxy, the traffic on such route would be
      encrypted via a key negotiated either in-band or off-band.
      Considering that all applications' traffic in such route can be
      seen as a unique flow directed to the same 'unknown' node, i.e.,
      the trusted proxy, eavesdroppers in such route have to make more
      efforts to correlate user behavior through statistical analysis
      even if they are capable of identifying the users via their source
      addresses.  The protection lays in the inability to isolate single
      application specific flows.  According to the methodology, such
      approach is IP version independent and works for both IPv4 and
      IPv6.

   *  Source Address Rollover: Privacy concerns related to address
      'identifier' semantic can be mitigated through regular change
      (beyond the typical 24 hours lease of DHCP).  Due to the semantics
      of 'identifier' that an IP address carries, such approach promotes
      to change the source IP address at a certain frequency.  Under
      such methodology, the refresh cycling window may reach to a
      balance between privacy protection and address update cost.  Due
      to the limited space that IPv4 contains, such approach usually
      works for IPv6 only.

   *  Private Address Spaces: Their introduction in [RFC1918] foresaw
      private addresses (assigned to specific address spaces by the
      IANA) as a means to communicate purely locally, e.g., within an



Iannone, et al.           Expires 9 March 2023                 [Page 11]

Internet-Draft     Internet Addressing Considerations     September 2022


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

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

3.2.1.3.  Examples:




Iannone, et al.           Expires 9 March 2023                 [Page 12]

Internet-Draft     Internet Addressing Considerations     September 2022


   *  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] 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, [EPHEMERALv6] 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)
      in IPv6 [RFC4193] take over the role of private address spaces in
      IPv4.

   *  Network Address Translation: Given address translation can be
      performed several times in cascade, NATs may exist as part of
      existing customer premise equipment (CPE), such as a cable or an
      Ethernet router, with private wired/wireless connectivity, or may
      be provided in a carrier environment to further translate ISP-
      internal private addresses to a pool of (assigned) public IP
      addresses.  The latter is often dynamically assigned to CPEs
      during its bootstrapping.



Iannone, et al.           Expires 9 March 2023                 [Page 13]

Internet-Draft     Internet Addressing Considerations     September 2022


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

3.2.2.  Authenticated Address Identity

3.2.2.1.  Description

   In some scenarios (e.g., corporate networks) it is desirable to being
   able authenticate IP addresses in order to prevent malicious
   attackers spoofing IP addresses.  This is usually achieved by using a
   mechanism that allows to prove ownership of the IP address.  Another
   growing use case where identity verification is necessary for
   security and safety reasons is in the aeronautical context, for both
   manned and unmanned aerial vehicles ([RFC9153],
   [I-D.haindl-lisp-gb-atn]).

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

   *  Collision-resistant addresses: When self-certification cannot be
      used, an alternative approach is to generate addresses in a way
      that is statistically unique (collision-resistant).
      Authentication of the address then occurs in an out-of-band
      protocol, where the unique identifier is resolved to
      authenticating information.

   *  Third party granted addresses: DHCP (Dynamic Host Configuration
      Protocol) is widely used to provide IP addresses, however, in its
      basic form, it does not perform any check and even an unauthorized
      user without the right to use the network can obtain an IP
      address.  To solve this problem, a trusted third party has to
      grant access to the network before generating an address (via DHCP



Iannone, et al.           Expires 9 March 2023                 [Page 14]

Internet-Draft     Internet Addressing Considerations     September 2022


      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.

3.2.2.3.  Examples

   *  Self-certified Addresses: As an example of this methodology serves
      [RFC3972], defining IPv6 cryptographically Generated Addresses
      (CGA).  A Cryptographically Generated Address is formed by
      replacing the least-significant 64 bits of an IPv6 address with
      the cryptographic hash of the public key of the address owner.
      Packets are then signed with the private key of the sender.
      Packets can be authenticate by the receiver by using the public
      key of the sender and the address of the sender.  The original
      specifications have been already amended (cf., [RFC4581] and
      [RFC4982]) in order to support multiple (stronger) cryptographic
      algorithms.

   *  Collision-resistant addresses: In order to provide a mechanism for
      IP mobility considerations, [RFC7343] defines Overlay Routable
      Cryptographic Hash Identifiers (ORCHIDv2).  ORCHIDs use a
      determinstic scheme for generating statistically unique addresses
      by concatenating a designated IPv6 prefix, a hash function
      identifier, and a truncated hash.  The hash input is a unique,
      statically assigned context identifier concatenated with random
      data.  A variation of this scheme is proposed to solve
      requirements of [RFC9153] in identification of unmanned aerial
      vehicles using Drone Remote Identification Protocol Entity Tags
      (DRIP Entity Tag; DET) [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.

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




Iannone, et al.           Expires 9 March 2023                 [Page 15]

Internet-Draft     Internet Addressing Considerations     September 2022


3.2.3.  Summary

   Table 2, summarize the methodologies and the examples towards filling
   the gaps on identity extensions.

    +----------------------------+----------------------+-------------+
    |                            | 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 2: Summary Identity Extensions

3.3.  Semantic Extensions

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

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



Iannone, et al.           Expires 9 March 2023                 [Page 16]

Internet-Draft     Internet Addressing Considerations     September 2022


   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.

3.3.1.  Utilizing Extended Address Semantics

3.3.1.1.  Description

   Several extensions have been developed to extend beyond the limited
   IPv6 semantics.  Those approaches may include to apply structure to
   the address, utilize specific prefixes, or entirely utilize the IPv6
   address for different semantics, while re-encapsulating the original
   packet to restore the semantics in another part of the network.  For
   instance, structured addresses have the capability to introduce
   delimiters to identify semantic information in the header, therefore
   not constraining any semantic by size limitations of the address
   fields.

   We note here that extensions often start out as being proposed as an
   extended header semantic, while standardization may drive the
   solution to adopt an approach to accommodate their semantic within
   the limitations of an IP address.  This section does include examples
   of this kind.

3.3.1.2.  Methodology

   *  Semantic prefixes: Semantic prefixes are used to separate the IPv6
      address space.  Through this, new address families, such as for
      information-centric networking [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
      static binding of IP addresses to servers creates a strong binding
      between IP addresses and service/resources, which may be a
      limitation for large Content Distribution networks (CDNs)
      [FAYED21].

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




Iannone, et al.           Expires 9 March 2023                 [Page 17]

Internet-Draft     Internet Addressing Considerations     September 2022


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

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

      Another example of the usage of different packet header extensions
      based on IP addressing is Segment Routing.  In this case, the
      source chooses a path and encodes it in the packet header as an
      ordered list of segments.  Segments are encoded using new Routing
      Extensions Header type, the Segment Routing Header (SRH), which
      contains the Segment List, similar to what is already specified in
      [RFC8200], i.e., a list of segment ID (SID) that dictate the path
      to follow in the network.  Such segment IDs are coded as 128 bit
      IPv6 addresses [RFC8986].

      Approaches such as [HICN] utilize semantic prefixing to allow for
      ICN forwarding behavior within an IPv6 network.  In this case, an



Iannone, et al.           Expires 9 March 2023                 [Page 18]

Internet-Draft     Internet Addressing Considerations     September 2022


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



Iannone, et al.           Expires 9 March 2023                 [Page 19]

Internet-Draft     Internet Addressing Considerations     September 2022


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

3.3.2.  Utilizing Existing or Extended Header Semantics

3.3.2.1.  Description:

   While the former sub-section explored extended address semantic,
   thereby limiting any such extended semantic with that of the existing
   IPv6 semantic and length, additional semantics may also be placed
   into the header of the packet or the packet itself, utilized for the
   forwarding decision to the appropriate endpoint according to the
   extended semantic.

   Reasons for embedding such new semantics may be related to traffic
   engineering since it has long been shown that the IP address itself
   is not enough to steer traffic properly since the IP address itself
   is not semantically rich enough to adequately describe the forwarding
   decision to be taken in the network, not only impacting _where_ the
   packet will need to go, but also _how_ it will need to be sent.

3.3.2.2.  Methodology:

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

   *  Headers option extensions: Another mechanism to add additional
      semantics is to actually add additional fields, e.g., through
      Header Options in IPv4 or through Extension Headers in IPv6.

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



Iannone, et al.           Expires 9 March 2023                 [Page 20]

Internet-Draft     Internet Addressing Considerations     September 2022


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

3.3.2.3.  Examples:

   *  In-Header extensions: In order to allow additional semantic with
      respect to the pure Internet addressing, the original design of
      IPv4 included the field 'Type of Service' [RFC2474], while IPv6
      introduced the 'Flow label' and the 'Traffic Class' [RFC8200]
      fields.  In a certain way, those fields can be considered
      'semantic extensions' of IP addresses, and they are 'in-header'
      because natively present in the IP header (differently from
      options and extension headers).  However, they proved not to be
      sufficient.  Very often a variety of network operations are
      performed on the well-known 5-tuple (source and destination
      addresses; source and destination port number; and protocol
      number).  In some contexts all of the above-mentioned fields are
      used in order to have a very fine grained solution ([RFC8939]).

   *  Headers option extensions: Header options have been largely under-
      exploited in IPv4.  However, the introduction of the more
      efficient extension header model in IPv6 along with technology
      progress made the use of header extensions more widespread in
      IPv6.  Segment Routing re-introduced the possibility to add path
      semantic to the packet by encoding a loosely defined source
      routing ([RFC8402]).  Similarly, in the aim to overcome the
      inherent shortcoming of the multi-homing in the IP context, SHIM6
      ([RFC5533]) also proposed the use of an extension header able to
      carry multi-homing information which cannot be accommodated
      natively in the IPv6 header.

      To serve a moving endpoint, mechanisms like Mobile IPv6 [RFC6275]
      are used for maintaining connection continuity by a dedicated IPv6
      extension header.  In such case, the IP address of the home agent
      in Mobile IPv6 is basically an identification of the on-going
      communication.  In order to go beyond the interface identification
      model of IP, the Host Identity Protocol (HIP) tries to introduce



Iannone, et al.           Expires 9 March 2023                 [Page 21]

Internet-Draft     Internet Addressing Considerations     September 2022


      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
      ([I-D.ietf-lisp-rfc6830bis]).  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 [ICNIP].

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




Iannone, et al.           Expires 9 March 2023                 [Page 22]

Internet-Draft     Internet Addressing Considerations     September 2022


      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 [ICNIP].
      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'.

3.3.3.  Summary

   Table 3, summarize the methodologies and the examples towards filling
   the gaps on semantic extensions.

























Iannone, et al.           Expires 9 March 2023                 [Page 23]

Internet-Draft     Internet Addressing Considerations     September 2022


    +---------------------------+----------------------+-------------+
    |                           | 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 3: Summary Semantic Extensions

4.  Overview of Approaches to Extend Internet Addressing

   The following Table 4 describes the objectives of the extensions
   discussed in this memo with respect to the properties of Internet
   addressing (Section 2}. 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, et al.           Expires 9 March 2023                 [Page 24]

Internet-Draft     Internet Addressing Considerations     September 2022


    +------------+------------------+--------------------+-----------+
    | 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 4: Relationship between Extensions and Internet Addressing







Iannone, et al.           Expires 9 March 2023                 [Page 25]

Internet-Draft     Internet Addressing Considerations     September 2022


5.  A System View on Address

   In the following, we investigate in which parts of the overall
   Internet system extensions have been proposed and developed.  For
   this, we divide the possible innovation across two dimensions:

   *  Horizontal: Internet edge vs core.  The criticality, scale,
      investment on the core of the Internet makes it more difficult to
      introduce innovation, while at the edges there is more
      flexibility.  As general purpose processors have drastically
      improved in performance, data-plane features can be implemented in
      software.  At the edge of the Internet, it easier to introduce
      innovation for several reasons: Economics, faster ROI because of
      faster deployment; No need of large scale deployment (and hence
      less standardization effort); less stakeholders involved
      (sometimes just one, see following point).  Furthermore, the fact
      that the edge is a place where there is less coordination and
      cooperation from the core, is another factor that ease the
      innovation.

   *  Vertical: at which layer of the protocol stack.  The difficulty to
      innovate varies as well depending at which layer the innovation
      takes place.  One thing is to innovate at application layer where
      the app developer has large degree of freedom, another is to
      innovate at network layer, which is more constrained because of
      its central point in the architecture.  Innovation at higher
      layers sometimes leads to walled gardens (aka limited domains
      [RFC8799]).  Indeed, because of the centralization phenomena, an
      actor offering a certain service may very well develop and deploy
      a custom technology that does not need to be actually standardized
      because it is done for its own internal usage.

   *  Horizontal vs Vertical Innovation:

      -  In the public Internet, core innovation at lower layer is
         harder, often reduced to app-level innovation or building an
         overlay limited domain (aka a walled garden).

      -  At the edges it is easier to innovate at lower layers (more
         vertical flexibility) but some form of adaptation is needed if
         global reachability is wanted.

   Despite these two orthogonal dimensions, innovation does not happen
   either horizontally or vertically, rather in both dimensions
   simultaneously at various degree.






Iannone, et al.           Expires 9 March 2023                 [Page 26]

Internet-Draft     Internet Addressing Considerations     September 2022


6.  Concerns in Extensions to Internet Addressing

   While the extensions to the original Internet properties, discussed
   in Section 3, 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 4.  These considerations may not be present all the time and
   everywhere, since as explained in Section 5, extensions are developed
   and deployed in different part of the Internet, which may worsen
   things.

6.1.  Limiting Address Semantics

   Many approaches changing the semantics of communication, e.g.,
   through separating host identification from network node
   identification [RFC7401], separating the device identifier from the
   routing locator ([EIBP], [I-D.ietf-lisp-introduction]), 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 [ICNIP] 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.

6.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, et al.           Expires 9 March 2023                 [Page 27]

Internet-Draft     Internet Addressing Considerations     September 2022


   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.

6.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 [ICNIP] 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 6.4.





Iannone, et al.           Expires 9 March 2023                 [Page 28]

Internet-Draft     Internet Addressing Considerations     September 2022


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

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

6.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 6.4, but also requires careful planning of which mechanisms
   to use and in which combination, likely needing human-in-the-loop
   approaches alongside possible automation approaches for the
   individual solutions.






Iannone, et al.           Expires 9 March 2023                 [Page 29]

Internet-Draft     Internet Addressing Considerations     September 2022


6.3.  Security

   The properties described in Section 2 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 [EPHEMERALv6].  However, this may
   raise some issues, like the large overhead due to the Duplicate
   Address Detection, the impact on the Neighbor Discovery mechanism, in
   particular the cache, which can even lead to communication
   disruption.  With such drawbacks, the extensions may even lead to
   defeat the target, actually lowering security rather than increasing
   it.

   The introduction of alternative addressing semantics has also been
   used to help in (D)DoS attacks mitigation.  This leverages on
   changing the service identification model so to avoid topological
   information exposure, making the potential disruptions likely remain
   limited [ADDRLESS].  However, this increased robustness to DDoS comes
   at the price of important communication setup latency and fragility,
   as discussed next.

6.4.  Fragility

   From the extensions discussed in Section 3, 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.

   For instance, the re-writing of IP addresses to facilitate the use of
   private address spaces throughout the public Internet, realized



Iannone, et al.           Expires 9 March 2023                 [Page 30]

Internet-Draft     Internet Addressing Considerations     September 2022


   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.

7.  Summary of concernss

   Table 5, derived from Section 6, summarizes the concerns related to
   each extension.  While each extension involves at least one concern,
   some others, like ICNIP, may create several at the same time.

   +------------+------------------+------------+----------+-----------+
   |            | Limiting         | Complexity | Security | Fragility |
   |            | Address          | and        |          |           |
   |            | Semantics        | Efficiency |          |           |
   +============+==================+============+==========+===========+
   | 6LoWPAN    |                  | x          |          | x         |
   +------------+------------------+------------+----------+-----------+
   | ROHC       |                  | x          |          | x         |
   +------------+------------------+------------+----------+-----------+
   | EzIP       |                  | x          |          |           |
   +------------+------------------+------------+----------+-----------+



Iannone, et al.           Expires 9 March 2023                 [Page 31]

Internet-Draft     Internet Addressing Considerations     September 2022


   | 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 5: Concerns in Extensions to Internet Addressing










Iannone, et al.           Expires 9 March 2023                 [Page 32]

Internet-Draft     Internet Addressing Considerations     September 2022


8.  Conclusions

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

   The consideration documented in this memo, with the extension-
   specific solution approach, point to the need for a discussion on
   Internet addressing, as formulated in the companion document
   [I-D.iannone-scenarios-problems-addressing] that formalizes the
   problem statement through scenarios that highlight the shortcomings
   of the Internet addressing model.

   It is our conclusion that the existence of the many extensions to the
   original Internet addressing is clear evidence for evolution paths
   that have been identified over time by the wider Internet community,
   each of which come with a raft of issues that we need to deal with
   daily: We believe that it is time 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.

   To jumpstart any such effort from an addressing perspective, it will
   be key to suitable define what an address is 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 instead of being guided by the answers that the
   Internet can give us today, e.g., being a mere ephemeral token for
   accessing PoP-based services (as indicated in related arch-d mailing
   list discussions).

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



Iannone, et al.           Expires 9 March 2023                 [Page 33]

Internet-Draft     Internet Addressing Considerations     September 2022


   importantly, any inaction on our side in that regard will only
   compound the identified concerns, eventually hampering the future
   Internet's readiness for those new uses.

9.  Security Considerations

   The present memo does not introduce any new technology and/or
   mechanism and as such does not introduce any new security threat to
   the TCP/IP protocol suite.

   As an additional note, and as discussed in this document, security
   and privacy aspects were not considered as part of the key properties
   for Internet addressing, which led to the introduction of a number of
   extensions intending to fix those gaps.  The analysis presented in
   this memo (non-exhaustively) shows those concerns are either solved
   in an ad-hoc manner at application level, or at transport layer,
   while at network level only few extensions tackling specific aspects
   exist, albeit often with limitations due to the adherence to the
   Internet addressing model and its properties.

10.  IANA Considerations

   This document does not include any IANA request.

11.  Informative References

   [ADDRLESS] Hao, S., Liu, R., Weng, Z., Chang, D., Bao, C., Li, X.,
              Wang, H., Ed., and Public Library of Science (PLoS),
              "Addressless: A new internet server model to prevent
              network scanning", PLOS ONE, vol. 16, no. 2, pp. e0246293,
              DOI 10.1371/journal.pone.0246293, 2 February 2021,
              <http://dx.doi.org/10.1371/journal.pone.0246293>.

   [CLOUDFLARE_SIGCOMM]
              Fayed, M., Bauer, L., Giotsas, V., Kerola, S., Majkowski,
              M., Odintsov, P., Sitnicki, J., Chung, T., Levin, D.,
              Mislove, A., Wood, C. A., Sullivan, N., and ACM, "The ties
              that un-bind", Proceedings of the 2021 ACM SIGCOMM 2021
              Conference, DOI 10.1145/3452296.3472922, 9 August 2021,
              <http://dx.doi.org/10.1145/3452296.3472922>.

   [CONTIKI]  "Contiki-NG: The OS for Next Generation IoT Devices",
              n.d., <https://github.com/contiki-ng/contiki-ng>.

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



Iannone, et al.           Expires 9 March 2023                 [Page 34]

Internet-Draft     Internet Addressing Considerations     September 2022


   [EPHEMERALv6]
              Gont, F. and G. Gont, "IPv6 Addressing Considerations",
              Work in Progress, Internet-Draft, draft-gont-v6ops-ipv6-
              addressing-considerations-02, 1 June 2022,
              <https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-
              addressing-considerations-02.txt>.

   [EzIP]     Chen, A. Y., Ati, R. R., Karandikar, A., and D. R. Crowe,
              "Adaptive IPv4 Address Space", Work in Progress, Internet-
              Draft, draft-chen-ati-adaptive-ipv4-address-space-11, 10
              June 2022, <https://www.ietf.org/archive/id/draft-chen-
              ati-adaptive-ipv4-address-space-11.txt>.

   [FAYED21]  Fayed, M., Bauer, L., Giotsas, V., Kerola, S., Majkowski,
              M., Odintsov, P., Sitnicki, J., Chung, T., Levin, D.,
              Mislove, A., Wood, C. A., Sullivan, N., and ACM, "The ties
              that un-bind", Proceedings of the 2021 ACM SIGCOMM 2021
              Conference, DOI 10.1145/3452296.3472922, 9 August 2021,
              <http://dx.doi.org/10.1145/3452296.3472922>.

   [GDPR]     Voigt, P., Bussche, A. V. D., and Springer International
              Publishing, "The EU General Data Protection Regulation
              (GDPR)", DOI 10.1007/978-3-319-57959-7, 2017,
              <http://dx.doi.org/10.1007/978-3-319-57959-7>.

   [GNATCATCHER]
              "Global Network Address Translation Combined with Audited
              and Trusted CDN or HTTP-Proxy Eliminating
              Reidentification", n.d.,
              <https://github.com/bslassey/ip-blindness>.

   [HEADER_COMP_ISSUES1]
              Mesrinejad, F., Hashim, F., Noordin, N. K., Rasid, M. F.
              A., Abdullah, R. S. A. R., and IEEE, "The effect of
              fragmentation and header compression on IP-based sensor
              networks (6LoWPAN)", The 17th Asia Pacific Conference on
              Communications, DOI 10.1109/apcc.2011.6152926, October
              2011, <http://dx.doi.org/10.1109/apcc.2011.6152926>.

   [HICN]     Muscariello, L., "Hybrid Information-Centric Networking:
              ICN inside the Internet Protocol", March 2018,
              <https://datatracker.ietf.org/meeting/interim-2018-icnrg-
              01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-
              icn-hicn-luca-muscariello>.

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




Iannone, et al.           Expires 9 March 2023                 [Page 35]

Internet-Draft     Internet Addressing Considerations     September 2022


              <https://elists.isoc.org/pipermail/internet-
              history/2021-January/006920.html>.

   [I-D.haindl-lisp-gb-atn]
              Haindl, B., Lindner, M., Moreno, V., Comeras, M. P.,
              Maino, F., and B. Venkatachalapathy, "Ground-Based LISP
              for the Aeronautical Telecommunications Network", Work in
              Progress, Internet-Draft, draft-haindl-lisp-gb-atn-07, 22
              March 2022, <https://www.ietf.org/archive/id/draft-haindl-
              lisp-gb-atn-07.txt>.

   [I-D.iannone-scenarios-problems-addressing]
              Iannone, L., Trossen, D., Shenoy, N., Mendes, P., 3rd, D.
              E. E., Liu, P., Farinacci, D., Finkhaeuser, J., and Y.
              Jia, "Challenging Scenarios and Problems in Internet
              Addressing", Work in Progress, Internet-Draft, draft-
              iannone-scenarios-problems-addressing-00, 5 September
              2022, <https://www.ietf.org/archive/id/draft-iannone-
              scenarios-problems-addressing-00.txt>.

   [I-D.ietf-6lo-nfc]
              Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
              "Transmission of IPv6 Packets over Near Field
              Communication", Work in Progress, Internet-Draft, draft-
              ietf-6lo-nfc-17, 23 August 2020,
              <https://www.ietf.org/archive/id/draft-ietf-6lo-nfc-
              17.txt>.

   [I-D.ietf-6lo-plc]
              Hou, J., Liu, B., Hong, Y., Tang, X., and C. E. Perkins,
              "Transmission of IPv6 Packets over PLC Networks", Work in
              Progress, Internet-Draft, draft-ietf-6lo-plc-11, 18 May
              2022, <https://www.ietf.org/archive/id/draft-ietf-6lo-plc-
              11.txt>.

   [I-D.ietf-drip-rid]
              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-32, 3 August 2022,
              <https://www.ietf.org/archive/id/draft-ietf-drip-rid-
              32.txt>.

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




Iannone, et al.           Expires 9 March 2023                 [Page 36]

Internet-Draft     Internet Addressing Considerations     September 2022


              <https://www.ietf.org/archive/id/draft-ietf-intarea-gue-
              09.txt>.

   [I-D.ietf-intarea-tunnels]
              Touch, J. and M. Townsley, "IP Tunnels in the Internet
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-intarea-tunnels-10, 12 September 2019,
              <https://www.ietf.org/archive/id/draft-ietf-intarea-
              tunnels-10.txt>.

   [I-D.ietf-lisp-introduction]
              Cabellos, A. and D. S. (Ed.), "An Architectural
              Introduction to the Locator/ID Separation Protocol
              (LISP)", Work in Progress, Internet-Draft, draft-ietf-
              lisp-introduction-15, 20 September 2021,
              <https://www.ietf.org/archive/id/draft-ietf-lisp-
              introduction-15.txt>.

   [I-D.ietf-lisp-mn]
              Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", Work in Progress, Internet-Draft, draft-
              ietf-lisp-mn-12, 24 July 2022,
              <https://www.ietf.org/archive/id/draft-ietf-lisp-mn-
              12.txt>.

   [I-D.ietf-lisp-rfc6830bis]
              Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos, "The Locator/ID Separation Protocol (LISP)",
              Work in Progress, Internet-Draft, draft-ietf-lisp-
              rfc6830bis-38, 7 May 2022,
              <https://www.ietf.org/archive/id/draft-ietf-lisp-
              rfc6830bis-38.txt>.

   [I-D.ietf-lisp-rfc6833bis]
              Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              Work in Progress, Internet-Draft, draft-ietf-lisp-
              rfc6833bis-31, 2 May 2022,
              <https://www.ietf.org/archive/id/draft-ietf-lisp-
              rfc6833bis-31.txt>.

   [I-D.rafiee-6man-cga-attack]
              Rafiee, H. and C. Meinel, "Possible Attack on
              Cryptographically Generated Addresses (CGA)", Work in
              Progress, Internet-Draft, draft-rafiee-6man-cga-attack-03,
              8 May 2015, <https://www.ietf.org/archive/id/draft-rafiee-
              6man-cga-attack-03.txt>.




Iannone, et al.           Expires 9 March 2023                 [Page 37]

Internet-Draft     Internet Addressing Considerations     September 2022


   [ICNIP]    Trossen, D., Robitzsch, S., Reed, M., Al-Naday, M., and J.
              Riihijarvi, "Internet Services over ICN in 5G LAN
              Environments", Work in Progress, Internet-Draft, draft-
              trossen-icnrg-internet-icn-5glan-04, 1 October 2020,
              <https://www.ietf.org/archive/id/draft-trossen-icnrg-
              internet-icn-5glan-04.txt>.

   [IPv4pool] "IANA IPv4 Address Space Registry", n.d.,
              <https://www.iana.org/assignments/ipv4-address-space/ipv4-
              address-space.xhtml>.

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

   [OHTTP]    Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
              Progress, Internet-Draft, draft-thomson-http-oblivious-02,
              24 August 2021, <https://www.ietf.org/archive/id/draft-
              thomson-http-oblivious-02.txt>.

   [ONION]    Goldschlag, D., Reed, M., Syverson, P., and Association
              for Computing Machinery (ACM), "Onion routing",
              Communications of the ACM, vol. 42, no. 2, pp. 39-41,
              DOI 10.1145/293411.293443, February 1999,
              <http://dx.doi.org/10.1145/293411.293443>.

   [P4]       Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N.,
              Rexford, J., Schlesinger, C., Talayco, D., Vahdat, A.,
              Varghese, G., Walker, D., and Association for Computing
              Machinery (ACM), "P4", ACM SIGCOMM Computer Communication
              Review, vol. 44, no. 3, pp. 87-95,
              DOI 10.1145/2656877.2656890, 28 July 2014,
              <http://dx.doi.org/10.1145/2656877.2656890>.

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

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.



Iannone, et al.           Expires 9 March 2023                 [Page 38]

Internet-Draft     Internet Addressing Considerations     September 2022


   [RFC1752]  Bradner, S. and A. Mankin, "The Recommendation for the IP
              Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752,
              January 1995, <https://www.rfc-editor.org/info/rfc1752>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC2009]  Imielinski, T. and J. Navas, "GPS-Based Addressing and
              Routing", RFC 2009, DOI 10.17487/RFC2009, November 1996,
              <https://www.rfc-editor.org/info/rfc2009>.

   [RFC2101]  Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
              Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101,
              February 1997, <https://www.rfc-editor.org/info/rfc2101>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,
              <https://www.rfc-editor.org/info/rfc2663>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <https://www.rfc-editor.org/info/rfc2865>.

   [RFC3118]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
              <https://www.rfc-editor.org/info/rfc3118>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
              <https://www.rfc-editor.org/info/rfc3972>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4014]  Droms, R. and J. Schnizlein, "Remote Authentication Dial-
              In User Service (RADIUS) Attributes Suboption for the



Iannone, et al.           Expires 9 March 2023                 [Page 39]

Internet-Draft     Internet Addressing Considerations     September 2022


              Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Information Option", RFC 4014, DOI 10.17487/RFC4014,
              February 2005, <https://www.rfc-editor.org/info/rfc4014>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4581]  Bagnulo, M. and J. Arkko, "Cryptographically Generated
              Addresses (CGA) Extension Field Format", RFC 4581,
              DOI 10.17487/RFC4581, October 2006,
              <https://www.rfc-editor.org/info/rfc4581>.

   [RFC4982]  Bagnulo, M. and J. Arkko, "Support for Multiple Hash
              Algorithms in Cryptographically Generated Addresses
              (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,
              <https://www.rfc-editor.org/info/rfc4982>.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
              June 2009, <https://www.rfc-editor.org/info/rfc5533>.

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              DOI 10.17487/RFC5795, March 2010,
              <https://www.rfc-editor.org/info/rfc5795>.

   [RFC6250]  Thaler, D., "Evolution of the IP Model", RFC 6250,
              DOI 10.17487/RFC6250, May 2011,
              <https://www.rfc-editor.org/info/rfc6250>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,
              <https://www.rfc-editor.org/info/rfc6740>.



Iannone, et al.           Expires 9 March 2023                 [Page 40]

Internet-Draft     Internet Addressing Considerations     September 2022


   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7343]  Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
              Routable Cryptographic Hash Identifiers Version 2
              (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
              2014, <https://www.rfc-editor.org/info/rfc7343>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
              2014, <https://www.rfc-editor.org/info/rfc7400>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", RFC 7872,
              DOI 10.17487/RFC7872, June 2016,
              <https://www.rfc-editor.org/info/rfc7872>.

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <https://www.rfc-editor.org/info/rfc8060>.

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



Iannone, et al.           Expires 9 March 2023                 [Page 41]

Internet-Draft     Internet Addressing Considerations     September 2022


              DOI 10.17487/RFC8061, February 2017,
              <https://www.rfc-editor.org/info/rfc8061>.

   [RFC8105]  Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
              M., and D. Barthel, "Transmission of IPv6 Packets over
              Digital Enhanced Cordless Telecommunications (DECT) Ultra
              Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
              2017, <https://www.rfc-editor.org/info/rfc8105>.

   [RFC8163]  Lynn, K., Ed., Martocci, J., Neilson, C., and S.
              Donaldson, "Transmission of IPv6 over Master-Slave/Token-
              Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
              May 2017, <https://www.rfc-editor.org/info/rfc8163>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8280]  ten Oever, N. and C. Cath, "Research into Human Rights
              Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
              October 2017, <https://www.rfc-editor.org/info/rfc8280>.

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,
              <https://www.rfc-editor.org/info/rfc8609>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.





Iannone, et al.           Expires 9 March 2023                 [Page 42]

Internet-Draft     Internet Addressing Considerations     September 2022


   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC8926]  Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
              "Geneve: Generic Network Virtualization Encapsulation",
              RFC 8926, DOI 10.17487/RFC8926, November 2020,
              <https://www.rfc-editor.org/info/rfc8926>.

   [RFC8939]  Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane:
              IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
              <https://www.rfc-editor.org/info/rfc8939>.

   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions for Stateless Address
              Autoconfiguration in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,
              <https://www.rfc-editor.org/info/rfc8981>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9153]  Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
              Gurtov, "Drone Remote Identification Protocol (DRIP)
              Requirements and Terminology", RFC 9153,
              DOI 10.17487/RFC9153, February 2022,
              <https://www.rfc-editor.org/info/rfc9153>.

   [RFC9230]  Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
              Wood, "Oblivious DNS over HTTPS", RFC 9230,
              DOI 10.17487/RFC9230, June 2022,
              <https://www.rfc-editor.org/info/rfc9230>.

   [ROBUSTSDN]
              Canini, M., Kuznetsov, P., Levin, D., Schmid, S., and
              IEEE, "A distributed and robust SDN control plane for
              transactional network updates", 2015 IEEE Conference on
              Computer Communications (INFOCOM),
              DOI 10.1109/infocom.2015.7218382, April 2015,
              <http://dx.doi.org/10.1109/infocom.2015.7218382>.

   [ROHC]     Fitzek, F. H. P., Rein, S., Seeling, P., Reisslein, M.,
              and Springer Science and Business Media LLC, "RObust
              Header Compression (ROHC) Performance for Multimedia



Iannone, et al.           Expires 9 March 2023                 [Page 43]

Internet-Draft     Internet Addressing Considerations     September 2022


              Transmission over 3G/4G Wireless Networks", Wireless
              Personal Communications, vol. 32, no. 1, pp. 23-41,
              DOI 10.1007/s11277-005-7733-2, January 2005,
              <http://dx.doi.org/10.1007/s11277-005-7733-2>.

   [SFCANYCAST]
              Wion, A., Bouet, M., Iannone, L., Conan, V., and ACM,
              "Distributed Function Chaining with Anycast Routing",
              Proceedings of the 2019 ACM Symposium on SDN Research,
              DOI 10.1145/3314148.3314355, 3 April 2019,
              <http://dx.doi.org/10.1145/3314148.3314355>.

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

   [TOR]      "The Tor Project", n.d., <https://www.torproject.org/>.

   [TRANSACTIONSDN]
              Curic, M., Despotovic, Z., Hecker, A., Carle, G., and
              IEEE, "Transactional Network Updates in SDN", 2018
              European Conference on Networks and Communications
              (EuCNC), DOI 10.1109/eucnc.2018.8442793, June 2018,
              <http://dx.doi.org/10.1109/eucnc.2018.8442793>.

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

   [VPN]      Khanvilkar, S., Khokhar, A., and Institute of Electrical
              and Electronics Engineers (IEEE), "Virtual private
              networks: an overview with performance evaluation", IEEE
              Communications Magazine, vol. 42, no. 10, pp. 146-154,
              DOI 10.1109/mcom.2004.1341273, October 2004,
              <http://dx.doi.org/10.1109/mcom.2004.1341273>.

   [WireGuard]
              Donenfeld, J. A. and Internet Society, "WireGuard: Next
              Generation Kernel Network Tunnel", Proceedings 2017
              Network and Distributed System Security Symposium,
              DOI 10.14722/ndss.2017.23160, 2017,
              <http://dx.doi.org/10.14722/ndss.2017.23160>.






Iannone, et al.           Expires 9 March 2023                 [Page 44]

Internet-Draft     Internet Addressing Considerations     September 2022


Acknowledgments

   Thanks to all the people that shared insightful comments both
   privately to the authors as well as on various mailing list,
   especially on the INTArea Mailing List.  Also thanks for the
   interesting discussions to Carsten Borman, Brian E.  Carpenter, and
   Eric Vyncke.

Authors' Addresses

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

   Email: luigi.iannone@huawei.com


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

   Email: dirk.trossen@huawei.com


   Paulo Mendes
   Airbus
   Willy-Messerschmitt Strasse 1
   81663 Munich
   Germany

   Email: paulo.mendes@airbus.com


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

   Email: nxsvks@rit.edu


   Laurent Toutain
   IMT-Atlantique
   2 rue de la Chataigneraie



Iannone, et al.           Expires 9 March 2023                 [Page 45]

Internet-Draft     Internet Addressing Considerations     September 2022


   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Email: laurent.toutain@imt-atlantique.fr


   Abraham Y. Chen
   Avinta Communications, Inc.
   142 N. Milpitas Blvd.
   Milpitas, CA,  95035-4401
   United States of America

   Email: AYChen@Avinta.com


   Dino Farinacci
   lispers.net
   United States of America

   Email: farinacci@gmail.com


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

   Email: jens.finkhaeuser@anywi.com


   Yihao Jia

   Email: yhjia03@gmail.com
















Iannone, et al.           Expires 9 March 2023                 [Page 46]