[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Internet Area Working Group                                       Y. Jia
Internet-Draft                                                D. Trossen
Intended status: Informational                                L. Iannone
Expires: August 26, 2021                                          Huawei
                                                         D. Eastlake 3rd
                                                               Futurewei
                                                                  P. Liu
                                                            China Mobile
                                                       February 22, 2021


       Challenging Scenarios and Problems in Internet Addressing
           draft-jia-intarea-scenarios-problems-addressing-00

Abstract

   The Internet Protocol (IP) has been the major technological success
   in information technology of the last half century.  As Internet
   become pervasive, IP start replacing communication technology for
   domain-specific solutions.  However, domains with specific
   requirements as well as communication behaviors and semantics still
   exists and represent what [RFC8799] recognizes as "limited domains".
   When communicating within limited domains, the address semantic and
   format may differ with respect to the IP address one.  As such, there
   is a need to adapt the domain-specific addressing to the Internet
   addressing paradigm.  In certain scenarios, such adaptation may raise
   challenges.

   This document describes well-recognized scenarios that showcase
   possibly different addressing requirements which are challenging to
   be accommodated in the IP addressing model.  These scenarios
   highlight issues related to the Internet addressing model and call
   for starting a discussion on a way to re-think/evolve the addressing
   model so to better accommodate different domain-specific
   requirements.

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Jia, et al.              Expires August 26, 2021                [Page 1]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   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 August 26, 2021.

Copyright Notice

   Copyright (c) 2021 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.  Communication Scenarios in Limited Domains  . . . . . . . . .   4
     2.1.  Communication in Constrained Environments . . . . . . . .   4
     2.2.  Communication within Dynamically Changing Topologies  . .   5
     2.3.  Communication among Moving Endpoints  . . . . . . . . . .   6
     2.4.  Communication Across Services . . . . . . . . . . . . . .   8
     2.5.  Steering Communication Traffic  . . . . . . . . . . . . .   9
     2.6.  Communication with built-in security  . . . . . . . . . .  10
     2.7.  Communication in Alternative Forwarding Architectures . .  11
   3.  Issues in Addressing  . . . . . . . . . . . . . . . . . . . .  13
     3.1.  Limiting Alternative Address Semantics  . . . . . . . . .  13
     3.2.  Hampering Security  . . . . . . . . . . . . . . . . . . .  13
     3.3.  Complicating Traffic Engineering  . . . . . . . . . . . .  14
     3.4.  Hampering Efficiency  . . . . . . . . . . . . . . . . . .  14
       3.4.1.  Header proportion . . . . . . . . . . . . . . . . . .  14
       3.4.2.  Introducing Path Stretch  . . . . . . . . . . . . . .  15
       3.4.3.  Repetitive encapsulation  . . . . . . . . . . . . . .  16
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .  16
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24





Jia, et al.              Expires August 26, 2021                [Page 2]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


1.  Introduction

   The Internet Protocol (IP), positioned as the unified protocol at the
   (Internet) network layer, is seen by many as key to the innovation
   stemming from Internet-based applications and services.  Even more
   so, with the success of TCP/IP protocol stack, IP has been gradually
   replacing existing domain-specific protocols, evolving into the core
   protocol of the entire communication system.  At its inception
   roughly 40 years ago [RFC0791], the Internet's addressing system,
   represented in the form of the IP address and its locator-based
   semantics, has brought the notion of a 'common addressing for all
   communication'.  Compared to proprietary technology-specific
   solutions, such 'common addressing for all communication' advance
   ensures end-to-end communication from any device connected to the
   Internet to another.

   However, scenarios, associated service, node behaviors, and
   requirements on packet delivery have since been significantly
   extended, with Internet technologies being developed to accommodate
   them in the framework of addressing that stood at the beginning of
   the Internet's development.  This evolution is reflected in the
   concept of the "Limited domain", first introduced in [RFC8799].  It
   refers to a single physical network, attached to or running in
   parallel with the Internet, or is defined by set of users and nodes
   distributed over a much wider area, but drawn together by a single
   virtual network over the Internet.  Key to a limited domain is that
   requirements, behaviors, and semantics could be noticeable local and,
   more importantly, specific to the limited domain.  Very often, the
   realization of a limited domain is defined by specific communication
   scenario(s) that exhibit the domain-specific behaviors and pose the
   requirements that lead to the establishment of the limited domain.

   One key architectural aspect, when communicating within limited
   domains, is that of addressing and, therefore, the address structure,
   as well as the semantic that is being used for the routing of
   packets.  The topological location centrality of IP is fundamental
   when reconciling the often differing semantics for 'addressing' that
   can be found in those limited domains.  The result of this
   fundamental role of the single IP addressing is that limited domains
   have to adopt specific solutions, e.g., translating/mapping/
   converting concepts, semantics, and ultimately, domain-specific
   addressing, into the common IP addressing used across limited
   domains.

   This document advocates the flexibility in addressing in order to
   accommodate limited domain specific semantics, while, if possible,
   ensuring a single holistic addressing scheme able to reduce, or even
   entirely remove, the need for aligning the address semantics of



Jia, et al.              Expires August 26, 2021                [Page 3]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   different limited domains, such as the current topological location
   semantic of the Internet.  Ultimately, such holistic addressing could
   be beneficial to those communication scenarios realized within
   limited domains by improving efficiency, removing of constraints
   imposed by needing to utilize the limited semantics of IP addressing,
   and/or in other ways.

   In other words, this document revolves around the following question:

      "Should limited domains purely rely on IP addresses and therefore
      deal with the complexity of translating any semantic mismatch
      themselves, or should flexibility for supporting those limited
      domains be a key focus for an evolved Internet addressing?"

   To that end, this document describes well-recognized scenarios in
   limited domains that could benefit from a greater flexibility in
   addressing and analyses problems encountered throughout these
   scenarios due to the lack of that flexibility.  The purpose of this
   draft is thus to stimulate discussion on the emerging needs for
   addressing at large with the possibility to fundamentally re-think
   the addressing in the Internet beyond the current objectives of IPv6.

   It is important to remark that any change in the addressing, hence at
   the data plane level, leads to changes and challenges on the control
   plane level, i.e., routing.  The latter is an even harder problem
   than just addressing and might need more research efforts that are
   beyond the objective of this document, which focuses solely on the
   data plane.

2.  Communication Scenarios in Limited Domains

   The following sub-section outlines a number of scenarios, all of
   which belong to the concept of "limited domains" [RFC8799].  While a
   list of scenarios may be long, this document focuses on scenarios
   with a number of aspects that we observe in those limited domains,
   captured in the sub-section titles.  For each scenarios, we point at
   possible challenges, which we will pick upon in Section 3 when
   describing more formally the issues existing in current Internet
   addressing.

2.1.  Communication in Constrained Environments

   In a number of communication scenarios, such as those encountered in
   the Internet of Things (IoT), a simple, low-cost communication
   network is required, and there are limitations for network devices in
   computational power, memory, and energy availability.  In addition to
   IEEE 802.15.4, i.e., Low-Rate Wireless Personal Area Network
   [LR-WPAN], several limited domains exists through utilizing link



Jia, et al.              Expires August 26, 2021                [Page 4]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   layer technologies such as Bluetooth Low Energy (BLE) [BLE], Digital
   European Cordless Telecommunications (DECT) - Ultra Low Energy (ULE)
   [DECT-ULE], Master-Slave/Token-Passing (MS/TP) [BACnet], Near-Field-
   Communication (NFC) [ECMA-340], and Power Line Communication (PLC)
   [IEEE_1901.1].  Generally, a group of IoT network devices form a
   constrained node network at the edge, and IoT terminals connect to
   these network devices for data transmission.  This type of networks
   and IoT devices in the network require as little computational power
   as possible, smaller memory requirements, better energy availability
   to reduce the total cost of ownership of the network.  Furthermore,
   in the context of industrial IoT, real-time requirements and
   scalability make IP technology not naturally suitable as
   communication technology ([OCADO]).

   The end-to-end principle (detailed in [RFC2775]) requires Internet
   protocols (e.g., IPv6 [RFC8200]) to run on such constrained node
   networks, allowing IoT devices using multiple communication
   technologies to talk on the Internet.  Often, devices located on the
   edge of constrained networks act as gateway devices, usually
   performing header compression ([RFC4919]).  To ensure security and
   reliability, multiple gateways must be deployed.  IoT devices on the
   network can easily select one of gateways for traffic passthrough by
   the devices on the (limited domain) network.

   Given the constraints imposed on the computational and possibly also
   communication technology, the usage of a single addressing semantic
   in the form of a 128-bit endpoint identifier, i.e., IPv6 address, may
   pose a challenge when operating such networks.

   Greater flexibility in Internet addressing may avoid complex and
   energy hungry operations, like header compression and fragmentation,
   necessary to translate protocol headers from one limited domain to
   another.

2.2.  Communication within Dynamically Changing Topologies

   Communication may occur over networks that exhibit dynamically
   changing topologies.  One such example is that of satellite networks,
   providing global Internet connections through a combination of inter-
   satellite and ground station communication.  With the convergence of
   space-based and terrestrial networks, users can experience seamless
   broadband access, e.g., on cruise ships, flights, and within cars,
   often complemented by and seamlessly switching between Wi-Fi,
   cellular, or satellite based networks at any time.  The satellite
   network service provider will plan the transmission path of user
   traffic based on the network coverage, satellite orbit, route, and
   link load, providing potentially high-quality Internet connections
   for users in areas that are not, or hard to be, covered by



Jia, et al.              Expires August 26, 2021                [Page 5]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   terrestrial networks.  The involved topologies of the satellite
   network will be changing constantly while observing a regular flight
   pattern in relation to other satellite and predictable overflight
   patterns to ground users.

   Another example is that of vehicular communication, where services
   may be accessed across vehicles, such as self-driving cars, for the
   purpose of collaborative objection recognition (e.g., for collision
   avoidance), road status conveyance (e.g., for pre-warning of road-
   ahead conditions) and other purposes.  Communication may include
   RoadSide Units (RSU) with the possibility to create ephemeral
   connections to those RSUs for the purpose of workload offloading,
   joint computation over multiple (vehicular) inputs and other purposes
   [I-D.ietf-lisp-nexagon].  Communication here may exhibit a multi-hop
   nature, not just involving the vehicle and the RSU over a direct
   link.  Those topologies are naturally changing constantly due to the
   dynamic nature of the involved communication nodes.

   In both network technologies, there is a significant difference
   between the high dynamics of the underlying network topologies,
   compared to the relative static nature of terrestrial network
   topology, as reported in [HANDLEY].  As a consequence, the notion of
   a topological network location becomes restrictive in the sense that
   not only the relation between network nodes and user endpoint may
   change, but also the relation between the nodes that form the network
   itself.  This may lead to the challenge of maintaining and updating
   the topological addresses in this constantly changing network
   topology.

   In attempts to utilize entirely different semantics for the
   addressing itself, geographic-based routing, such as in [CARTISEAN],
   has been proposed for MANETs (mobile ad-hoc networks) through
   providing geographic coordinates based addresses to achieve better
   routing performance, lower overhead, and lower latency [MANET1].

   Flexibility in Internet addressing here would allow for accommodating
   such geographic address semantics into the overall Internet
   addressing.

2.3.  Communication among Moving Endpoints

   When packet switching was first introduced, back in the 60s/70s, it
   was intended to replace the rigid circuit switching with a
   communication infrastructure that was more resilient to failures.  As
   such, the design never really considered communication endpoints as
   mobile.  Even in the pioneering ALOHA [ALOHA] system, despite
   considering wireless and satellite links, the network was considered
   static (with the exception of failures and satellites, which fall in



Jia, et al.              Expires August 26, 2021                [Page 6]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   what is discussed in Section 2.2).  Ever since, a lot of efforts have
   been devoted to overcome such limitations once that it became clear
   that endpoint mobility will become a main (if not THE main)
   characteristic of ubiquitous communication systems.

   The IETF has for a long time worked on solutions that would allow
   extending the IP layer with mobility support.  Because of the
   topological semantic of IP addresses, endpoints need to change
   addresses each time they visit a different network.  However, because
   routing and endpoint identification is also IP address based, this
   leads to a communication disruption.

   To cope with such a situation, anchor-based Mobile IP mechanisms have
   been introduced ([RFC5177], [RFC6626] [RFC5944], [RFC5275]).  Mobile
   IP is based on a relatively complex and heavy mechanism that makes it
   hard to deploy and not very efficient.  Furthermore, it is even less
   suitable than native IP in constrained environments like the ones
   discussed in Section 2.1.

   Alternative approaches to Mobile IP often leverage the introduction
   of some form of overlay.  LISP [I-D.ietf-lisp-introduction], by
   separating the topological semantic from the identification semantic
   of IP addresses, is able to cope with endpoint mobility by
   dynamically mapping endpoint identifiers with routing locators
   [I-D.ietf-lisp-mn].  This comes at the price of an overlay that needs
   its own additional control plane [I-D.ietf-lisp-rfc6833bis].
   Similarly, the NVO3 (Network Virtualization Overlays) Working Group,
   while focusing on Data Center Environments, also explored an overlay-
   based solution for multi-tenancy purposes, but also resilient to
   mobility since relocating Virtual Machines (VMs) is common practice.
   NVO3 considered for a long time several data planes that implement
   slightly different flavors of overlays ([RFC8926], [RFC7348],
   [I-D.ietf-intarea-gue]), but lack of an efficient control-plane
   specifically tailored for DCs.

   Alternative mobility architectures have also been proposed in order
   to cope with endpoint mobility outside the IP layer itself.  The Host
   Identity Protocol (HIP) [RFC7401] introduced a new namespace in order
   to identify endpoints, namely the Host Identity (HI), while
   leveraging the IP layer for topological location.  On the one hand,
   such an approach needs to revise the way applications interact with
   the network layer, by modifying the DNS (now returning an HI instead
   of an IP address) and applications to use the HIP socket extension.
   On the other hand, early adopters do not necessarily gain any benefit
   unless all communicating endpoints upgrade to use HIP.  In spite of
   this, such a solution may work in the context of a limited domain.





Jia, et al.              Expires August 26, 2021                [Page 7]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   Another alternative approach is adopted by Information-Centric
   Networking (ICN) [RFC7476].  By making content a first class citizen
   of the communication architecture, the "what" rather than the "where"
   becomes the real focus of the communication.  However, as explained
   in the next sub-section, ICN can run either over the IP layer or
   completely replace it, which in turn can be seen as running the
   Internet and ICN as logically completely separated limited domains.

   Sometimes, the transport layer gets involved in mobility solutions,
   either by introducing explicit in-band signaling to allow for
   communicating IP address changes (e.g., in SCTP [RFC5061] and MPTCP
   [RFC6182]), or by introducing some form of connection ID that allows
   for identifying a communication independently from IP addresses
   (e.g., the connection ID used in QUIC [QUIC]).

   Greater flexibility in addressing may help in dealing with mobility
   more efficienctly, e.g., through an augmented semantic that may
   fufill the mobility requirements [RFC7429].

2.4.  Communication Across Services

   As a communication infrastructure spanning many facets of life, the
   Internet integrates services and resources from various aspects such
   as remote collaboration, shopping, content production as well as
   delivery, education and many more.  Accessing those services and
   resources directly through URIs has been proposed by methods such as
   those defined in ICN [RFC7476], where providers of services and
   resources can advertise those through unified identifiers without
   additional planning of identifiers and locations for underlying data
   and their replicas.  Users can access required services and resources
   by virtue of using the URI-based identification, with an ephemeral
   relationship built between user and provider, while the building of
   such relationship may be constrained with user- as well as service-
   specific requirements, such as proximity (finding nearest provider),
   load (finding fastest provider), and others.

   While systems like ICN [CCN] provide an alternative to the locator-
   based addressing of IP, its deployment requires an overlay (over IP)
   or native deployment (alongside IP), the latter with dedicated
   gateways needed for translation.  Underlay deployments are also
   envisioned in [RFC8763], where ICN solutions are being used to
   facilitate communication between IP addressed network endpoints or
   URI-based service endpoints, still requiring gateway solutions for
   interconnection with ICN-based networks as well as IP routing based
   networks (cf., [ICN5G][ICNIP]).

   Although various approaches to combining service and location-based
   addressing have been devised, the key challenge here is to facilitate



Jia, et al.              Expires August 26, 2021                [Page 8]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   a "natural", i.e., direct communication, without the need for
   gateways above the network layer.

   Another aspect of communication across services is that of chaining
   individual services to a larger service.  Here, an identifier could
   be used that serves as a link to next hop destination within the
   chain of individual services, as done in the work on Service Function
   Chaining (SFC).  With this, services are identified at the level of
   Layer 2/3 ([RFC7665], [RFC8754], [RFC8595]) or at the level of name-
   based service identifiers like URLs [RFC8677] although the service
   chain identification is carried as an NSH header ([RFC7665] separate
   to the packet identifiers.  The forwarding with the chain of services
   utilizes individual locator-based IP addressing (for L3 chaining) to
   communicate the chained operations from one Service Function
   Forwarder [RFC7665] to another, leading to concerns regarding
   overhead incurred through the stacking of those chained identifiers
   in terms of packet overhead and therefore efficiency in handling in
   the intermediary nodes.

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

2.5.  Steering Communication Traffic

   Steering traffic within a communication scenario may involve at least
   two aspects, namely (i) limiting certain traffic towards a certain
   set of communication nodes and (ii) constraining the sending of
   packets towards a given destination (or a chain of destinations) with
   metrics that would allow the selection among one or more possible
   destinations.

   One possibility for limiting traffic inside limited domains, towards
   specific objects, e.g., devices, users, or group of them, is subnet
   partition with techniques such as VLAN [RFC5517], VxLAN [RFC7348], or
   more evolved solution like Terastream [TERASTREAM] realizing such
   partitioning.  Such mechanisms usually involve quite some
   configuration, and even small changes in network and user nodes could
   result in a repartition and possibly even more configuration efforts.
   Another key aspect is the complete lack of correlation of the
   topological address and any likely more semantic-rich identification
   that could be used to make policy decision regarding traffic
   steering.  Suitably enriching the semantics of the packet address,
   either that of the sender or receiver, so that such decision could be
   made while minimizing the involvement of higher layer mechanisms, is
   a crucial challenge for improving on network operations and speed of
   such limited domain traffic.




Jia, et al.              Expires August 26, 2021                [Page 9]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   When making decisions to select one out of a set of possible
   destinations for a packet, IP anycast semantics can be applied albeit
   being limited to the locator semantic of the IP address itself.
   Recent work in [DYNCAST] suggests utilizing the notion of IP anycast
   address to encode a "service identifier", which is dynamically mapped
   onto network locations where service instances fulfilling the service
   request may be located.  Scenarios where this capability may be
   utilized are provided in [DYNCAST] and include, but are not limited
   to, scenarios such as edge-assisted VR/AR, transportation and digital
   twins.

   The challenge here lies in the possible encoding of not only the
   service information itself but the constraint information that helps
   the selection of the "best" service instance and which is likely a
   service-specific constraint in relation to the particular scenario.
   The notion of an address here is a conditional (on those constraints)
   one where this conditional part is an essential aspect of the
   forwarding action to be taken.  It needs therefore consideration in
   the definition of what an address is, what is its semantic, and how
   the address structure ought to look like.

   As outlined in the previous sub-section, chaining services are
   another aspect of steering traffic along a chain of constituent
   services, where the chain is identified through either a stack of
   individual identifiers, such as in Segment Routing [RFC8402], or as
   an identifier that serves as a link to next hop destination within
   the chain, such as in Service Function Chaining (SFC).  The latter
   can be applied to services identified at the level of Layer 2/3
   ([RFC7665], [RFC8754], [RFC8595]) or at the level of name-based
   service identifiers like URLs [RFC8677].  However, the overhead
   incurred through the stacking of those chained identifiers is a
   concern in terms of packet overhead and therefore efficiency in
   handling in the intermediary nodes.

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

2.6.  Communication with built-in security

   Today, strong security and privacy in the Internet is usually
   implemented as an overlay based on the concept of Mix Networks
   ([TOR], [SPHINX]).  Among the various reasons for such approach is
   the limited semantic of current IP addresses, which do not allow to
   natively express security features or trust relationship.  Efforts
   like Cryptographically Generated Addresses (CGA) [RFC3972], provide
   some security features by embedding a truncated public key in the



Jia, et al.              Expires August 26, 2021               [Page 10]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   last 57-bit of IPv6 address, thereby greatly enhancing authentication
   and security within an IP network via asymmetric cryptography and
   IPsec [RFC4301].  The development of the Host Identity Protocol (HIP)
   [RFC7401] saw the introduction of cryptographic identifiers for the
   newly introduced Host Identity (HI) to allow for enhanced
   accountability, and therefore trust.  The use of those HIs, however,
   is limited by the size of IPv6 128bit addresses.

   Through a greater flexibility in addressing, any security-related
   key, certificate, or identifier could instead be included in a
   suitable address structure without any information loss (i.e., as-is,
   without any truncation or operation as such), avoiding therefore
   compromises such as those in HIP.  Instead, CGAs could be created
   using full length certificates, or being able to support larger HIP
   addresses in a limited domain that use it.

   Greater flexibility in addressing semantic could significantly help
   in constructing a trusted and secure communication at the network
   layer.  This could lead to connections that could be considered as
   absolute secure (assuming the cryptography involved is secure).  Even
   more, anti-abuse mechanisms and/or DDoS protection mechanisms like
   the one under discussion in PEARG ([PEARG]) Research Group may
   leverage a greater flexibility of the overall Internet addressing, if
   provided, in order to be more effective.

2.7.  Communication in Alternative Forwarding Architectures

   The performance of communication networks has long been a focus for
   optimization due to the immediate impact on cost of ownership for
   communication service providers.  Technologies like MPLS [RFC3031]
   have been introduced to optimize lower layer communication, e.g., by
   mapping L3 traffic into aggregated labels of forwarding traffic for
   the purposes of, e.g., traffic engineering.

   Even further, other works have emerged in recent years that have
   replaced the notion of packets with other concepts for the same
   purpose of improved traffic engineering and therefore efficiency
   gains.  One such area is that of Software Defined Networks (SDN)
   [RFC7426], which has highlighted how a majority of Internet traffic
   is better identified by flows, rather than packets.  Based on such
   observation, alternate forwarding architectures have been devised
   that are flow-based or path-based.  With this approach, all data
   belonging to the same traffic stream is delivered over the same path,
   and traffic flows are identified by some connection or path
   identifier rather than by complete routing information, possibly
   enabling fast hardware based switching.





Jia, et al.              Expires August 26, 2021               [Page 11]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   On the one hand, such a communication model may be more suitable to
   real-time traffic like that in the context of Deterministic Networks
   ([DETNET]), where indeed a lot of work has focused on how to
   "identify" packets belonging to the same DETNET flow in order to
   jointly manage the forwarding within the desired deterministic
   boundaries.

   On the other hand, it may improve the communication efficiency in
   constrained wireless environments (cf., Section 2.1), by reducing the
   overhead, hence increasing the number of useful bits per second per
   Hz.  Also, the delivery of information across similar flows may be
   combined into a multipoint delivery of a single return flow, e.g.,
   for scenarios of requests for a video chunk from many clients being
   responded to with a single (multi-destination) flow, as outlined in
   [BIER-MC] as an example.  Another opportunity to improve
   communication efficiency is being pursued in ongoing IETF/IRTF work
   to deliver IP- or HTTP-level packets directly over path-based or
   flow-based transport network solutions, such as in
   [TROSSEN][BIER-MC][ICNIP][ICN5G] with the capability to bundle
   unicast forward communication streams flexibly together in return
   path multipoint relations.  Such capability is particularly opportune
   in scenarios such as chunk-based video retrieval or distributed data
   storage.  However, those solutions currently require gateways to
   "translate" the flow communication into the packet-level addressing
   semantic in the peering IP networks.  Furthermore, the use of those
   alternative forwarding mechanisms often require the encapsulation of
   Internet addressing information, leading to wastage of bandwidth as
   well as processing resources.

   Alternative way of forwarding data has also been the motivation for
   the efforts created in the European Telecommunication Standards
   Institute (ETSI), who formed a Industry Specification Group (ISG)
   named Non-IP Networking (NIN) [ETSI-NIN].  This group sets out to
   develop and standardize a set of protocols leveraging an alternative
   forwarding architecture, such as provided by a flow-based switching
   paradigm.  The deployment of such protocols may be seen to form
   limited domains, still leaving the need to interoperate with the
   (packet-based forwarding) Internet; a situation possibly enabled
   through a greater flexibility of the addressing used across Internet-
   based and alternative limited domains alike.

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






Jia, et al.              Expires August 26, 2021               [Page 12]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


3.  Issues in Addressing

3.1.  Limiting Alternative Address Semantics

   Many approaches to changing the semantics of communication, e.g.,
   through separating host identification from network node
   identification [RFC7401] 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, as discussed in Section 3.4.  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.

3.2.  Hampering Security

   Fitting any new semantic into existing size constraints may hamper
   the original objectives for introducing the new semantics in the
   first place.  For instance, host identifiers [RFC7401] or security
   information may be limited by the IPv6 address size, as discussed in
   Section 2.6 with the example of CGA [RFC3972].  On the one hand,
   greater flexibility of addressing would allow to introduce fully
   featured security in endpoint identification, potentially able to
   eradicate the spoofing problem.  On the other hand, it may be used to
   include application gateways' certificates in order to provide more
   efficiency, e.g., using web certificates also used in the addressing
   of web services.

   While increasing security, privacy protection can be improved.  IP
   addresses, even temporary ones, have been long recognized as a
   "Personal Identification Information" that allows even to geolocating
   the communicating endpoints [RFC8280].  Greater flexibility in
   addressing may allow the use of cryptographically generated anonymous
   addresses when considered needed, and protect from geolocation by
   making such addresses topologically independent.  Such property
   potentially allows implemetation of secure architetures like [TOR]
   and [SPHINX] at network layer, improving the overall efficiency as
   described in Section 3.4.

   Alternative addressing semantics may also help in (D)DoS mitigation.
   This can be achieved by changing the service identification model,
   making it completely orthogonal from network topology semantic.  And



Jia, et al.              Expires August 26, 2021               [Page 13]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   by not exposing all of the topological information the attack
   exposes, the potential disruptions, may remain limited [ADDRLESS].
   In this way, mounting such type of attack may become harder.

3.3.  Complicating Traffic Engineering

   Efforts in traffic engineering have long shown that the IP address
   itself is not enough to steer traffic properly, seeing the
   introduction of differentiated service code points (DSCP), the use of
   header information of various kinds (such as ports) as flow
   information, and the entirely separate expression of path
   information, e.g., in the form of MPLS labels or through introducing
   bitposition-based path identifiers (cf., [BIER-MC], [REED]).  Newer
   approaches to IP anycast suggest the use of service identification in
   combination with a binding IP address model [DYNCAST] as a way to
   allow for metric-based traffic steering decisions; approaches for
   service function chaining [RFC7665] utilize the next service header
   (NSH) information and packet classification to determine the
   destination of the next packet hop.

   Overall, when it comes to providing capabilities for traffic
   engineering, 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.  Instead, various supplementary
   information needs to be taken into account for a successful delivery
   to take place.

3.4.  Hampering Efficiency

3.4.1.  Header proportion

   Although fiber and ethernet dominate the Internet infrastructure,
   numerous radio channels are expected to improve the wireless
   communication efficiency.  As IPv6 header fixedly occupies 40 byte in
   a packet [RFC8200], header compression techniques are introduced to
   shaping payload occupation within a packet.  RObust Header
   Compression (ROHC) [RFC5795], which customized for cellar network, is
   being widely adopted in radios like WCDMA, LTE, and 5G.  Considering
   one base station is supposed to serve hundreds of user devices,
   maximizing the effectiveness for specific spectrum directly improve
   user quality of experience.

   Similar header compression mechanisms are usually adopted for
   communications among constrained devices.  Due to the memory or
   battery constraint, constrained devices prefer maximize carrying
   efficiency for each packet they deliver.  For personal area network,
   the IEEE 802.15.4 enabled devices, which occupy the most share of the



Jia, et al.              Expires August 26, 2021               [Page 14]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   market, either equipped with customized proprietary protocols, or
   compress the header utterly as in [RFC4944].  Particular for
   proprietary protocols, e.g., Zigbee, an application level gateway
   should be introduced at the edge of the local network.  Terminations
   of the communications by such gateway break the end-to-end principle
   via uncondictional trust as potential weak points, thus looping back
   to the security crisis in Section 3.2.

   Also, constraints coming from either devices or carrier links would
   lead to a mixed scenarios and compound requirements for extraordinary
   header compression.  For native IPv6 communications on DECT ULE and
   MS/TP Networks, 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].  For low power wide-area network, a generic
   framework for static context header compression is depicted in
   [RFC8724] for efficiency improvement.

3.4.2.  Introducing Path Stretch

   To serve a moving endpoint (cf., Section 2.3), mechanisms like Mobile
   IP [RFC3775] are used for the maintenance of connection continuity.
   As the result of the locator semantic in IP address [RFC2101],
   traffic must follow a triangular route before arriving the updated
   location inevitably affecting the transmission efficiency as well as
   latency.

   Another example for introducing additional path lengthening is the
   routing in TOR (cf., Section 2.6).  As the address indicates
   identifications to a certain extent [RFC2101], privacy enhancement
   mechanisms usually involve the concealment of the source IP address
   during communications.  To achieve high anonymity, traffic should be
   handed over by several (at least three) intermediates before reaching
   the destination.  Undoubtedly, frequent relaying enhance the privacy
   at the cost of lower communication efficiency, no matter how close
   the destination is located.

   IP Anycast [RFC7094] is usually adopted for efficient content
   delivery through extensive replica distribution.  In most cases,
   request packets should be guided to the nearest server in relation
   to, e.g., geography or network topology, while occasionally, traffic
   may also be directed to a remote or suboptimal site.  Given that
   Autonomous Systems (AS) always select route according to their own
   preference, e.g., route of customer AS path (rather than shortest
   path), traffic guidance for the nearest site is hard to be guaranteed
   (cf., [ANYCAST]), while computing-related metrics are mostly ignored.





Jia, et al.              Expires August 26, 2021               [Page 15]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


3.4.3.  Repetitive encapsulation

   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 limited
   domain, effectively doubling the header overhead per packet.

   The problem is also present in a number of solutions tackling
   different issues, e.g., mobility [I-D.ietf-lisp-introduction], DC
   networking ([RFC8926], [RFC7348], [I-D.ietf-intarea-gue]), and
   privacy ([TOR], [SPHINX]).  Certainly these solutions are able to
   avoid other issues, like path lengthening or privacy, but they come
   at the price of multiple encapsulations that reduce the effective
   payload.

4.  Problem Statement

   This document highlights that, with the emergence of limited domains,
   novel approaches to addressing in communication scenarios are being
   developed and deployed within those limited domains.

   While this may be interpreted as a crucial point to the flexibility
   of addressing in the Internet, evidences exist (as describe in this
   document) that the existing Internet addressing structure itself is a
   potential hinderance in solving key problems for Internet service
   provisioning.  Such problems include supporting new, e.g., service-
   oriented, scenarios more efficiently, with improved security and
   efficient traffic engineering, as well as large scale mobility.

   As a problem statement, this document's goal is not to propose or
   promote specific solutions to the problems here portrayed.  Instead,
   this document aims at stimulating discussion on the emerging needs
   for addressing with the possibility to fundamentally re-think the
   addressing in the Internet beyond the current objectives of IPv6.

5.  Security Considerations

   TBD.








Jia, et al.              Expires August 26, 2021               [Page 16]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


6.  IANA Considerations

   This document does not include an IANA request.

7.  References

7.1.  Normative References

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

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

7.2.  Informative References

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

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

   [ANYCAST]  Li, Z., Levin, D., Spring, N., and B. Bhattacharjee,
              "Internet anycast: performance, problems, & potential",
              Proceedings of the 2018 Conference of the ACM Special
              Interest Group on Data Communication,
              DOI 10.1145/3230543.3230547, August 2018.

   [BACnet]   "BACnet-A Data Communication Protocol for Building
              Automation and Control Networks", ANSI/ASHRAE Standard
              135-2016, January 2016,
              <https://www.techstreet.com/ashrae/standards/ashrae-
              135-2016?product_id=1918140>.

   [BIER-MC]  Trossen, D., Rahman, A., Wang, C., and T. Eckert,
              "Applicability of BIER Multicast Overlay for Adaptive
              Streaming Services", draft-ietf-bier-multicast-http-
              response-05 (work in progress), January 2021.

   [BLE]      "Bluetooth Specification", Bluetooth SIG Working Groups,
              n.d., <https://www.bluetooth.com/specifications>.



Jia, et al.              Expires August 26, 2021               [Page 17]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


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

   [CCN]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking named content",
              Proceedings of the 5th international conference on
              Emerging networking experiments and technologies -
              CoNEXT '09, DOI 10.1145/1658939.1658941, 2009.

   [DECT-ULE]
              "Digital Enhanced Cordless Telecommunications (DECT);
              Common Interface (CI); Part 1: Overview", ETSI European
              Standard, EN 300 175-1, V2.6.1, May 2009,
              <https://www.etsi.org/deliver/
              etsi_en/300100_300199/30017501/02.06.01_60/
              en_30017501v020601p.pdf>.

   [DETNET]   "Deterministic Networking (DetNet)", n.d.,
              <https://datatracker.ietf.org/wg/detnet/about/>.

   [DYNCAST]  Geng, L., Liu, P., and P. Willis, "Dynamic-Anycast in
              Compute First Networking (CFN-Dyncast) Use Cases and
              Problem Statement", draft-geng-rtgwg-cfn-dyncast-ps-
              usecase-00 (work in progress), October 2020.

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

   [ETSI-NIN]
              ETSI - European Telecommunication Standards Institute,
              "Non-IP Networking - NIN", n.d.,
              <https://www.etsi.org/technologies/non-ip-networking>.

   [HANDLEY]  Handley, M., "Delay is Not an Option: Low Latency Routing
              in Space", Proceedings of the 17th ACM Workshop on Hot
              Topics in Networks, DOI 10.1145/3286062.3286075, November
              2018.

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




Jia, et al.              Expires August 26, 2021               [Page 18]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   [I-D.ietf-6lo-nfc]
              Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
              "Transmission of IPv6 Packets over Near Field
              Communication", draft-ietf-6lo-nfc-17 (work in progress),
              August 2020.

   [I-D.ietf-6lo-plc]
              Hou, J., Liu, B., Hong, Y., Tang, X., and C. Perkins,
              "Transmission of IPv6 Packets over PLC Networks", draft-
              ietf-6lo-plc-05 (work in progress), October 2020.

   [I-D.ietf-intarea-gue]
              Herbert, T., Yong, L., and O. Zia, "Generic UDP
              Encapsulation", draft-ietf-intarea-gue-09 (work in
              progress), October 2019.

   [I-D.ietf-lisp-introduction]
              Cabellos-Aparicio, A. and D. Saucez, "An Architectural
              Introduction to the Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-introduction-13 (work in
              progress), April 2015.

   [I-D.ietf-lisp-mn]
              Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", draft-ietf-lisp-mn-08 (work in progress),
              August 2020.

   [I-D.ietf-lisp-nexagon]
              sbarkai@gmail.com, s., Fernandez-Ruiz, B., Barkai, S.,
              Tamir, R., Rodriguez-Natal, A., Maino, F., Cabellos-
              Aparicio, A., and D. Farinacci, "Network-Hexagons: H3-LISP
              GeoState & Mobility Network", draft-ietf-lisp-nexagon-06
              (work in progress), October 2020.

   [I-D.ietf-lisp-rfc6833bis]
              Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-
              Aparicio, "Locator/ID Separation Protocol (LISP) Control-
              Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress),
              November 2020.

   [ICN5G]    Ravindran, R., suthar, P., Trossen, D., Wang, C., and G.
              White, "Enabling ICN in 3GPP's 5G NextGen Core
              Architecture", draft-irtf-icnrg-5gc-icn-04 (work in
              progress), January 2021.







Jia, et al.              Expires August 26, 2021               [Page 19]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   [ICNIP]    Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and
              J. Riihijarvi, "Internet Services over ICN in 5G LAN
              Environments", draft-trossen-icnrg-internet-icn-5glan-04
              (work in progress), October 2020.

   [IEEE_1901.1]
              "Standard for Medium Frequency (less than 15 MHz) Power
              Line Communications for Smart Grid Applications", IEEE
              1901.1 IEEE-SA Standards Board, May 2018,
              <https://ieeexplore.ieee.org/document/8360785>.

   [LR-WPAN]  "IEEE 802.15.4 - IEEE Standard for Low-Rate Wireless
              Networks", IEEE 802.15 WPAN Task Group 4, May 2020,
              <https://standards.ieee.org/standard/802_15_4-2020.html>.

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

   [OCADO]    "Ocado Technology's robot warehouse a Hive of IoT
              innovation", n.d., <https://techmonitor.ai/tech-leaders/
              ocado-technology-robot-hive-innovation>.

   [PEARG]    "Privacy Enhancements and Assessments Research Group -
              PEARG", n.d., <https://irtf.org/pearg>.

   [QUIC]     Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-34 (work
              in progress), January 2021.

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

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

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              DOI 10.17487/RFC2775, February 2000,
              <https://www.rfc-editor.org/info/rfc2775>.





Jia, et al.              Expires August 26, 2021               [Page 20]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004,
              <https://www.rfc-editor.org/info/rfc3775>.

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, DOI 10.17487/RFC4919, August 2007,
              <https://www.rfc-editor.org/info/rfc4919>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061,
              DOI 10.17487/RFC5061, September 2007,
              <https://www.rfc-editor.org/info/rfc5061>.

   [RFC5177]  Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
              "Network Mobility (NEMO) Extensions for Mobile IPv4",
              RFC 5177, DOI 10.17487/RFC5177, April 2008,
              <https://www.rfc-editor.org/info/rfc5177>.

   [RFC5275]  Turner, S., "CMS Symmetric Key Management and
              Distribution", RFC 5275, DOI 10.17487/RFC5275, June 2008,
              <https://www.rfc-editor.org/info/rfc5275>.

   [RFC5517]  HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
              VLANs: Scalable Security in a Multi-Client Environment",
              RFC 5517, DOI 10.17487/RFC5517, February 2010,
              <https://www.rfc-editor.org/info/rfc5517>.




Jia, et al.              Expires August 26, 2021               [Page 21]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


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

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, DOI 10.17487/RFC5944, November 2010,
              <https://www.rfc-editor.org/info/rfc5944>.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
              <https://www.rfc-editor.org/info/rfc6182>.

   [RFC6626]  Tsirtsis, G., Park, V., Narayanan, V., and K. Leung,
              "Dynamic Prefix Allocation for Network Mobility for Mobile
              IPv4 (NEMOv4)", RFC 6626, DOI 10.17487/RFC6626, May 2012,
              <https://www.rfc-editor.org/info/rfc6626>.

   [RFC7094]  McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
              "Architectural Considerations of IP Anycast", RFC 7094,
              DOI 10.17487/RFC7094, January 2014,
              <https://www.rfc-editor.org/info/rfc7094>.

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

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

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

   [RFC7429]  Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
              CJ. Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429,
              DOI 10.17487/RFC7429, January 2015,
              <https://www.rfc-editor.org/info/rfc7429>.




Jia, et al.              Expires August 26, 2021               [Page 22]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <https://www.rfc-editor.org/info/rfc7476>.

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

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

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

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

   [RFC8595]  Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
              Forwarding Plane for Service Function Chaining", RFC 8595,
              DOI 10.17487/RFC8595, June 2019,
              <https://www.rfc-editor.org/info/rfc8595>.

   [RFC8677]  Trossen, D., Purkayastha, D., and A. Rahman, "Name-Based
              Service Function Forwarder (nSFF) Component within a
              Service Function Chaining (SFC) Framework", RFC 8677,
              DOI 10.17487/RFC8677, November 2019,
              <https://www.rfc-editor.org/info/rfc8677>.

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




Jia, et al.              Expires August 26, 2021               [Page 23]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8763]  Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
              "Deployment Considerations for Information-Centric
              Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April
              2020, <https://www.rfc-editor.org/info/rfc8763>.

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

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

   [TERASTREAM]
              "Deutsche Telekom tests TeraStream, the network of the
              future, in Croatia", n.d.,
              <https://www.telekom.com/en/media/media-
              information/archive/deutsche-telekom-tests-terastream-the-
              network-of-the-future-in-croatia-358444>.

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

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

Authors' Addresses

   Yihao Jia
   Huawei Technologies Co., Ltd
   156 Beiqing Rd.
   Beijing  100095
   P.R. China

   Email: jiayihao@huawei.com





Jia, et al.              Expires August 26, 2021               [Page 24]


Internet-Draft    Scenarios and Problems in Addressing     February 2021


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

   Email: dirk.trossen@huawei.com


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

   Email: luigi.iannone@huawei.com


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

   Email: d3e3e3@gmail.com


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

   Email: liupengyjy@chinamobile.com

















Jia, et al.              Expires August 26, 2021               [Page 25]