<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-jia-flex-ip-address-structure-00" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true">

<front>
<title abbrev="FlexIP">Flexible IP: An Adaptable IP Address Structure</title><seriesInfo value="draft-jia-flex-ip-address-structure-00" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author initials="Y." surname="Jia" fullname="Yihao Jia"><organization abbrev="Huawei">Huawei Technologies Co., Ltd</organization><address><postal><street>156 Beiqing Rd.</street>
<city>Haidian, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal><email>jiayihao@huawei.com</email>
</address></author>
<author initials="Z." surname="Chen" fullname="Zhe Chen"><organization abbrev="Huawei">Huawei Technologies Co., Ltd</organization><address><postal><street>156 Beiqing Rd.</street>
<city>Haidian, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal><email>chenzhe17@huawei.com</email>
</address></author>
<author initials="S." surname="Jiang" fullname="Sheng Jiang"><organization abbrev="Huawei">Huawei Technologies Co., Ltd</organization><address><postal><street>156 Beiqing Rd.</street>
<city>Haidian, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal><email>jiangsheng@huawei.com</email>
</address></author>
<date/>
<area>Internet</area>
<workgroup>Network Working Group</workgroup>

<abstract>
<t>Along as the popularization and adoption of IP in emerging scenarios, challenges emerge as well due to the ossified address structure.
To enable TCP/IP in networks that previously using exclusive protocol, a flexible address structure would be far more preferred for their particular properties <xref target="draft-jia-scenarios-flexible-address-structure"></xref>.</t>
<t>This document describes a flexible address structure -- Flexible IP (FlexIP) acting on limited domains <xref target="RFC8799"></xref>.
FlexIP is expected to proactively adapt scenarios under flexible address structure.
Meanwhile, FlexIP still benefit from global reachability based on the IPv6 interoperability.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>As Internet Protocol (IP) gradually turned into the &quot;waist&quot; of the &quot;TCP/IP&quot; protocol stack, it is considered to be the core pillar of the entire Internet <xref target="waist"></xref>.
Although numerous technologies in this &quot;TCP/IP&quot; protocol stack have emerged, evolved, or obsoleted by others, the IPv6 technology <xref target="RFC8200"></xref> is the only forward in network layer along with the Internet upgrades.
IPv6, as the unique successor of IPv4 <xref target="RFC0791"></xref> defined by IETF, fixes defects for most of its parts.
Most notably, the address space is enormously expanded from 32-bit to 128-bit in IPv6 reformation.
Despite that IPv6 is expected to serve almost infinite devices in the foreseeable future, several scenarios are found in trouble when IPv6 is in use.</t>
<t>For instance, due to the market and cost requirements, numerous Internet-of-things (IoTs) are devised to be tiny and resource constrained. However, such rigorous requirement induce manufactures to adopt lightweight protocols like bluetooth, other than TCP/IP, for inter communications <xref target="iot"></xref>. Energy consumption, which is sound in most terminal cases, becomes the greatest challenge when introducing IPv6 to IoTs. Document <xref target="draft-jia-scenarios-flexible-address-structure"></xref> details the challenges for more cases of IPv6.</t>
<t>To conquer these challenges, several improvements are promoted by the corporation of related standard organizations.
Document <xref target="RFC4944"></xref> depict the transmission of IPv6 over IEEE 802.15.4 network, and such a method enables indirectly support of IPv6 in IoTs, e.g., Thead Protocol <xref target="thread"></xref>.
Besides, document <xref target="RFC7668"></xref> describe the fusion of IPv6 and Bluetooth Low Energy, and such a method also enable the communications among nodes with Bluetooth and IPv6.
Although none of these proposal is superior on the basis of market sharing, all endeavour orientate to the comprehensive adoption of TCP/IP protocol stack in new communication cases.</t>
<t>This document proposes an adaptive IP address format -- Flexible IP (abbr. FlexIP) orienting
emerging scenarios <xref target="draft-jia-scenarios-flexible-address-structure"></xref> within limited domains <xref target="RFC8799"></xref>, and maintain global reachability with IPv6.
In general, FlexIP is composed through a hierarchical, self-explanatory address structure.
Compared to the patch-like solutions (e.g., <xref target="RFC4944"></xref>, <xref target="RFC8724"></xref>) that passively tune IP to be compatible with different scenarios, FlexIP proactively makes address structure flexible enough to adapt to various network cases.
This variation, opposite to the fixed form of IPv4/IPv6 address, is expected to make Internet Protocol agilely cover futuristic and unknown scenarios.</t>
<t>//TODO: more citations needed.</t>
</section>

<section anchor="terminology"><name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t>
</section>

<section anchor="targeted-scenario"><name>Targeted Scenario</name>
<t>As a architectural solution for scenarios detailed in <xref target="draft-jia-scenarios-flexible-address-structure"></xref>, FlexIP is expected to be adopted in limited domains <xref target="RFC8799"></xref>.
According to the definition in <xref target="RFC8799"></xref>, limited domain refers to a single physical network
attached to or running in parallel with the Internet, or a defined set of users and nodes distributed over a much wider area, but drawn together by a single virtual network over the Internet.
Within the limited domains, requirements, behaviors, and semantics could be noticeable local and network specific.</t>
<t><xref target="fig1"></xref> depicts the orientation of FlexIP in IPv6 and Internet.
Generally, Internet with its backbone is principally composed by IPv6, and networks with IPv4 are recognized as legacy and attached at the edge of the Internet with transition mechanisms.
The position of networks with FlexIP structure is quite similar as IPv4.
For networks within limited domains, FlexIP can be marginally adopted at the edge of the Internet.
Such network use FlexIP to fulfill proprietary capabilities, while retain global reachability through IPv6 via transition.</t>
<figure anchor="fig1" align="center"><name>Position for FlexIP in IPv6 Internet
</name>
<artwork align="center">.........
.........  -&gt;Attaching Point
||||||||| /
||||||+--+               +----------------+
||&lt;----------------------+ Google Network |
||||||+--+               |      IPv6      |
|||||||||                +----------------+
|||||||||      -&gt;Translator
|||||||||     /
||||||+--+  /-\          +----------------+
||||||&lt;------------------+ Legacy Network |
||||||+--+  \-/          |      IPv4      |
|||||||||                +----------------+
|||||||||
|||||||||
||||||+--+            +-------------------+
|&lt;--------------------+ Microsoft Network |
||||||+--+            |      IPv6         |
|||||||||             +-------------------+
|||||||||
|||||||||
||||||+--+               +----------------+
|||&lt;---------------------+ Amazon Network |
||||||+--+               |      IPv6      |
|||||||||                +----------------+
|||||||||
|||||||||                      ... ...
|||||||||       -&gt;Translator
|||||||||      /
||||||+--+  /-\  +------------------------+
||||&lt;-------------+ Limited Domain Network |
||||||+--+  \-/  |          FlexIP        |
|||||||||         +------------------------+
|||||||||              e.g., factory network
|||||||||
|||||||||
|||||||........IPv6 Internet Backbone
|||||||||
.........
</artwork>
</figure>
</section>

<section anchor="design-considerations"><name>Design Considerations</name>
<t>As described in document <xref target="draft-jia-scenarios-flexible-address-structure"></xref>, various address semantics and variable address length are main characteristics for a flexible IP.
However, several principles must be considered from the top if such featured address structure become truly practicable.
Points below details overall considerations and plannings behind FlexIP.</t>

<section anchor="multi-semantics"><name>Multi-Semantics</name>
<t>For networks with advanced routing, non-topological identifiers could be necessary for reachability <xref target="RFC7476"></xref>.
To enrich routing abilities in complex network, address structure should be flexible enough to accommodate multiple semantics and related identifiers, thus forwarding nodes within the network can dealing with these complex address according based on the routing system built.</t>
<t>Ideally, devices that resided in advanced networks construct special address format for customized routing, while devices that resided in conventional scenario can adopt IPv6 as routine (topology semantic) address.</t>
</section>

<section anchor="elastic-address-space"><name>Elastic Address Space</name>
<t>The primary orientation of FlexIP is to adapt different network scale, and each network uses different address length that best fit the presumptive scale.
The alterable address length refers to a flexible address space, and such resilience makes IP highly adaptable to theoretically infinite space as well as tailored space specifically for low power scenarios.</t>
<t>Ideally, Autonomous System (AS) that composing the Internet is constituted by numerous networks. Each of the network hold the flexible address space that best fit their scenarios.</t>
</section>

<section anchor="scalability"><name>Scalability</name>
<t>A constrained space is impossible to accommodate communications among volume devices, while boundless space is unsustainable due to the explosion of global routing table.
To makes the flexibility truly values, FlexIP must reach a balance between rigorous requirements of expansive address space and efficient routing performance.</t>
<t>Ideally, the address should be expanded to boundless space, while the structure guarantees the performance of fast forwarding.</t>
</section>

<section anchor="interoperability"><name>Interoperability</name>
<t>FlexIP network is designed to be an attached network at edges of the Internet, thus interoperability is needed between IPv6 and FlexIP. Based on the interoperability, FlexIP, on the one hand, can benefit from the advanced network abilities and adapt to new scenarios. On the other hand, global reachability from IPv6 Internet makes the network truly values and convenient for realistic use.</t>
<t>Ideally, a translator module is needed wherever a boundary across FlexIP networks and IPv6 networks.
The translator depicted in <xref target="fig1"></xref> gives a brief architectural instance for interoperability.</t>
</section>
</section>

<section anchor="structure"><name>FlexIP Address structure</name>
<t>In general, FlexIP is composed through a hierarchical, self-explanatory address structure.
Such hierarchical, self-explanatory address structure brings FlexIP elastic address space and multi-semantics without sacrificing scalability.
<xref target="tab1"></xref> details the structure of the FlexIP address structure.</t>
<table anchor="tab1" align="center"><name>Flexible IP Address Structure
</name>
<thead>
<tr>
<th>Index</th>
<th>Type</th>
<th>Structure (default by topology semantic and 1 segment)</th>
</tr>
</thead>

<tbody>
<tr>
<td>0x01</td>
<td>Restrained Space</td>
<td>topology address - address 1</td>
</tr>

<tr>
<td>0x02</td>
<td>Restrained Space</td>
<td>topology address - address 2</td>
</tr>

<tr>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>

<tr>
<td>0xEF</td>
<td>Restrained Space</td>
<td>topology address - address 239</td>
</tr>

<tr>
<td>0xF0</td>
<td>Extendable Space</td>
<td>followed by address with 16-bit length</td>
</tr>

<tr>
<td>0xF1</td>
<td>Extendable Space</td>
<td>followed by address with 32-bit length</td>
</tr>

<tr>
<td>0xF2</td>
<td>Extendable Space</td>
<td>followed by address with 64-bit length</td>
</tr>

<tr>
<td>0xF3</td>
<td>Extendable Space</td>
<td>followed by address with 128-bit length</td>
</tr>

<tr>
<td>0xF4</td>
<td>Extendable Space</td>
<td>followed by address with 256-bit length</td>
</tr>

<tr>
<td>0xF5</td>
<td>Extendable Space</td>
<td>followed by address with X-bit length</td>
</tr>

<tr>
<td>0xF6</td>
<td>Hierarchical Segments</td>
<td>followed by address with 2 segments</td>
</tr>

<tr>
<td>0xF7</td>
<td>Hierarchical Segments</td>
<td>followed by address with 3 segments</td>
</tr>

<tr>
<td>0xF8</td>
<td>Hierarchical Segments</td>
<td>followed by address with Y segments</td>
</tr>

<tr>
<td>0xF9</td>
<td>Multi-Semantics</td>
<td>followed by Non-topological semantic address</td>
</tr>

<tr>
<td>0xFA - 0xFF</td>
<td>None</td>
<td>reserved</td>
</tr>
</tbody>
</table><t>Shapes in <xref target="tab1"></xref> describes the formal representation of FlexIP and should be used in programing.
Text representation of FlexIP is described in <xref target="representation"></xref>.
Particularly, formal representation of FlexIP in this document introduces &quot;/&quot; for readability only.
Such &quot;/&quot; <bcp14>MUST</bcp14> be omitted in practical use.</t>

<section anchor="restrained-space-format"><name>Restrained Space Format</name>
<t>The first address format is called restrained space format and specific for small address space.
Such format includes a 1-byte space customized for constrained resource devices.
Structure in such format guarantees that within FlexIP structure, devices can reach the shortest address length under variable length structure and pursuit the maximal routing efficiency.</t>
</section>

<section anchor="extendable-space-format"><name>Extendable Space Format</name>
<t>The second address format is called extendable space format.
By adopting such format, administrator can choose address length that best fit the network.</t>
<t>Specifically, for networks larger than 239 address space, a 16-bit, 32-bit, 64-bit, 128-bit, and 256-bit can be used by the network with Index F0-F4, respectively, and then followed by address itself.
Particular, a IPv6 (128-bit) address is regarded as a special indexed by Index F3.</t>
<t>For networks prefer a customized space, a 1-byte LenIndex is emerged between Index and the address.
Structure in such format ensures that address space becomes theoretically elastic and boundless.
For example, a 56-bit address is presented by F5/07/3B3A297F50C24F under FlexIP structure.
Sequence value 07 refers to the 7-byte (56-bit) address length.</t>
</section>

<section anchor="hierarchical-segments-format"><name>Hierarchical Segments Format</name>
<t>The third address format is called hierarchical segments format.
By adopting such format, an FlexIP address is composed by multiple segments.
Logically, a segment inside the address could be considered as an individual routing identifier.
Thus within different routing areas, routers on the path should forward packets based on the exclusive segment.
The partitioning of the address logically splits the large address into several routing segment, and segments are regarded small enough that packets flowing in separate networks could be forwarded efficiently according to the segments.
For this reason, structure in such hierarchy format ensures the practicability with boundless space.</t>
<t>Taking an 2-segment address as an example, FlexIP F6/C8/F1/20C12AF2 present a 8-bit segment C8 and a 32-bit segment 220C12AF2, where index F6 indicates the 2 segments behind.</t>
</section>

<section anchor="multi-semantics-format"><name>Multi-Semantics Format</name>
<t>The forth address format is called multi-semantics format.
For address adopting such format, networks can forward packets based on the specific semantics.</t>
<t>Under such format, a 1 byte SemIndex is used as the indication of semantic when Index equal to F9.
Taking the satellite network <xref target="space-routing"></xref> as an example, FlexIP F9/01/F2/A32F84C981002E9B can refer to a geographic position embedded address, where 01 refers to the geographic semantic, and F2 refers to a 64-bit address length.
Similarly, such pattern can be used for name based routing <xref target="ndn"></xref>, user based routing, or service based routing.</t>
<t>Given that non-topological semantics and addressing are still under open study, specifications for non-topological semantics will be depicted in independent documents when technics become mature.</t>
</section>
</section>

<section anchor="representation"><name>FlexIP Address Text Representation</name>
<t>Literally, text representation of FlexIP should be human friendly compared to the formal representation in <xref target="structure"></xref>.
Considering text representation would be used in extensive written places,
FlexIP is such representation should be eminently readable.</t>
<t>This document <bcp14>RECOMMENDED</bcp14> text representation of FlexIP through following structure: [Length]&lt;SEM&gt;<em>Value</em>[Length]&lt;SEM&gt;<em>Value</em>...[Length]&lt;SEM&gt;<em>Value</em>.
Generally, FlexIP address is concatenated directly by multiple segments.
For each of the segment, the text representation is composed by [Length]&lt;SEM&gt;<em>Value</em>.
Specifically, i.e., for components inside an segment,
[Length] refers to the length of current segment with the Byte unit;<br />
Then followed by &lt;SEM&gt;, &lt;SEM&gt; refers to the semantic the segment use.
Within a segment, &lt;SEM&gt; is the only field can be omitted if segment points to the default topology semantic -- &lt;TOPO&gt;.
Last, <em>Value</em> refers to the address itself.
Particularly, <em>Value</em> inherits the same text representation as IPv6 that recommended in <xref target="RFC5952"></xref>.</t>
<t><xref target="tab2"></xref> depicts examples for FlexIP representation in text shape.
Noted that &quot;/&quot; in the formal representation is for readability only and <bcp14>MUST</bcp14> be removed in practice.</t>
<table anchor="tab2" align="center"><name>Examples of Flexible IP Address Text Representation
</name>
<thead>
<tr>
<th>Formal Representation</th>
<th>Text Representation</th>
</tr>
</thead>

<tbody>
<tr>
<td>C8</td>
<td>[1]C8</td>
</tr>

<tr>
<td>F1/2A00012F</td>
<td>[4]2A::12F</td>
</tr>

<tr>
<td>F5/07/3B3A297F50C24F</td>
<td>[7]3B:3A29:7F50:C24F</td>
</tr>

<tr>
<td>F6/C8/F2/2001000000012F</td>
<td>[1]C8[8]2001::12F</td>
</tr>

<tr>
<td>F8/04/F0/2F5B/F0/6A3C/F0/9C2B/F0/735D</td>
<td>[2]2F5B[2]6A3C[2]9C2B[2]735D</td>
</tr>

<tr>
<td>F9/01/F2/A32F84C981002E9B</td>
<td>[8]&lt;GEO&gt;A32F84C981002E9B</td>
</tr>
</tbody>
</table><t>For example, [1]C8[8]2001::12F indicates two segments concatenation:
segment C8 with &lt;TOPO&gt; semantic and 1 byte length, and segment 200100000000012F with &lt;TOPO&gt; semantic and 8 byte length.
Particular, given that non-topological semantics and addressing are still under open study, &lt;SEM&gt; identification should be officially maintained in IANA.</t>
</section>

<section anchor="interoperability-1"><name>Interoperability</name>
<t>To enable global reachability and inter connectivity between FlexIP network and IPv6 network, an translator is needed wherever packets across the periphery. <xref target="fig2"></xref> depicts the core component of the translator, i.e., address mapper, and a sketch for packet traversing from a FlexIP network to a IPv6 network.
For any packet leave FlexIP network and enter IPv6 network, the IP addresses of the packet should be converted by rules configured in the mapper, and vice versa.</t>
<figure anchor="fig2" align="center"><name>Network Address Mapping between FlexIP network and IPv6 network.
</name>
<artwork align="center">.........       -&gt;Translator
|.|.|.|.|      /
|.|.|.+---+  /-\  +------------------------+
|.|.&lt;-------------+ Limited Domain Network |
|.|.|.+---+  \-/  |          FlexIP        |
|.|.|.|.|     |   +------------------------+
|.|.|.|.|     |
|.|.|.|.|     |
|.|.|.|.|     |            +-------------+    Rules
|.|.|.|.|     |          / |             | Distribution
|.|.|.|.|     +---------|  | +---------+ |      +
.........                \ | | Mapping | |      |
                           | |  Rules  &lt;--------+
Internet                   | +----+----+ |
Backbone                   |      |      |
                 Packet    | +----v----+ |    Packet
               +--------+  | | Mapping | |  +--------+
               |  IPv6  &lt;----+  Engine &lt;----+ FlexIP |
               +--------+  | +---------+ |  +--------+
               |  Data  |  |             |  |  Data  |
               |        |  |   Address   |  |        |
               +--------+  |    Mapper   |  +--------+
                           +-------------+

</artwork>
</figure>
<t>Specifically, there are two kind of mapping policy: stateful recording and stateless transforming.
Although both two policy is effective for address mapping, stateless transforming is <bcp14>RECOMMENDED</bcp14> for system efficiency and operation complexity.
Concrete processes of rules generation, distribution and mapping mechanisms are outside the scope of this specification and should be documented individually.</t>
<t>For FlexIP network with restrained space format <xref target="tab1"></xref>, for instance, a FlexIP C3 should be mapped into IPv6 2001::C3 when affiliated packet flow across the periphery.
Conversely, address mapper can simply peel of the prefix 2001:: of when packets flow back to FlexIP network.</t>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>As a address format of IP, FlexIP address itself do not involve security issues.
While from the viewpoint of the transmission of packets, FlexIP has security properties that are similar to IPv6. These security issues include:</t>

<ul>
<li><t>Eavesdropping, where on-path elements can observe the whole packet (including both contents and metadata) of each datagram.</t>
</li>
<li><t>Replay, where the attacker records a sequence of packets off of the wire and plays them back to the party that originally received them.</t>
</li>
<li><t>Packet insertion, where the attacker forges a packet with some chosen set of properties and injects it into the network.</t>
</li>
<li><t>Packet deletion, where the attacker removes a packet from the wire.</t>
</li>
<li><t>Packet modification, where the attacker removes a packet from the wire, modifies it, and reinjects it into the network.</t>
</li>
<li><t>Man-in-the-middle (MITM) attacks, where the attacker subverts the communication stream in order to pose as the sender to receiver and the receiver to the sender.</t>
</li>
<li><t>Denial-of-service (DoS) attacks, where the attacker sends large amounts of legitimate traffic to a destination to overwhelm it.ss</t>
</li>
</ul>
<t>Specifically, there is not any mechanism for FlexIP to protect against IP spoofing. Defending against these type of attacks is outside the scope of this specification.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document does not include an IANA request.</t>
</section>

</middle>

<back>
<references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7476.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7668.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8724.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/>
<reference anchor="draft-jia-scenarios-flexible-address-structure" target="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-jia-scenarios-flexible-address-structure.xml">
  <front>
    <title>Scenarios and Requirements for Flexible Address structure</title>
    <author fullname="Y. Jia" initials="Y." surname="Jia"></author>
    <author fullname="G. Li" initials="G." surname="Li"></author>
    <author fullname="J. Jiang" initials="S." surname="Jiang"></author>
    <date year="2020" month="October"></date>
  </front>
</reference>


<reference anchor="iot" target="">
  <front>
    <title>The Internet of Everything through IPv6: An Analysis of Challenges, Solutions and Opportunities</title>
    <author fullname="AJ. Jara" initials="AJ." surname="Jara"></author>
    <author fullname="L. Ladid" initials="L." surname="Ladid"></author>
    <author fullname="AF. Gomez-Skarmeta" initials="AF." surname="Gomez-Skarmeta"></author>
    <date year="2013"></date>
  </front>
  <seriesInfo name="Networks Ubiquitous Comput. Dependable Appl." value="4(3): 97-118"></seriesInfo>
</reference>
<reference anchor="ndn" target="">
  <front>
    <title>Named data networking</title>
    <author fullname="L. Zhang" initials="L." surname="Zhang"></author>
    <author fullname="A. Afanasyev" initials="A." surname="Afanasyev"></author>
    <author fullname="J. Burke" initials="J." surname="Burke"></author>
    <date year="2014"></date>
  </front>
  <seriesInfo name="ACM SIGCOMM Computer Communication Review" value="44(3): 66-73"></seriesInfo>
</reference>
<reference anchor="space-routing" target="">
  <front>
    <title>Analyzing and optimizing BGP stability in future space-based internet</title>
    <author fullname="Z. Yang" initials="Z." surname="Yang"></author>
    <author fullname="H. Li" initials="H." surname="Li"></author>
    <author fullname="Q. Wu" initials="Q." surname="Wu"></author>
    <author fullname="J. Wu" initials="J." surname="Wu"></author>
    <date year="2017" month="December"></date>
  </front>
  <seriesInfo name="International Performance Computing and Communications Conference (IPCCC)" value=" "></seriesInfo>
</reference>
<reference anchor="thread" target="https://www.threadgroup.org/ThreadSpec">
  <front>
    <title>Thread Specification</title>
    <author>
      <organization>Thread Group</organization>
    </author>
    <date></date>
  </front>
</reference>
<reference anchor="waist" target="https://dl.acm.org/doi/abs/10.1145/2018436.2018460">
  <front>
    <title>The Evolution of Layered Protocol Stacks Leads to an Hourglass-shaped Architecture</title>
    <author fullname="S. Akhshabi" initials="S." surname="Akhshabi"></author>
    <author fullname="C. Dovrolis" initials="C." surname="Dovrolis"></author>
    <date year="2011" month="October"></date>
  </front>
  <seriesInfo name="Proceedings of the ACM SIGCOMM 2011 Conference" value="206-217"></seriesInfo>
</reference>
</references>

</back>

</rfc>
