Huawei Technologies Co., Ltd

156 Beiqing Rd. Beijing 100095 P.R. China jiayihao@huawei.com

Huawei Technologies Duesseldorf GmbH

Riesstr. 25C Munich 80992 Germany dirk.trossen@huawei.com

Huawei Technologies France S.A.S.U.

18, Quai du Point du Jour Boulogne-Billancourt 92100 France luigi.iannone@huawei.com

Rochester Institute of Technology

New-York 14623 USA nxsvks@rit.edu

Airbus

Willy-Messerschmitt Strasse 1 Munich 81663 Germany paulo.mendes@airbus.com

Internet Internet Area Working Group Internet-Draft There exist many extensions to Internet addressing, as it is defined in for IPv4 and for IPv6, respectively. Those extensions have been developed to fill gaps in capabilities beyond the basic properties of Internet addressing. This document outlines those properties as a baseline against which the extensions are categorized in terms of methodology used to fill the gap together with examples of solutions doing so. While introducing such extensions, we outline the issues we see with those extensions. This ultimately leads to consider whether or not a more consistent approach to tackling the identified gaps, beyond point-wise extensions as done so far, would be beneficial. The benefits are the ones detailed in the companion document , where, leveraging on the gaps identified in this memo and scenarios provided in , a clear problem statement is provided.

outlines scenarios and problems in Internet addressing through presenting a number of cases of communication that have emerged over the many years of utilizing the Internet and for which various extensions to the network interface-centric addressing of IPv6 have been developed. In order to continue the discussion on the emerging needs for addressing, initiated with , this memo aims at identifying gaps between the Internet addressing model and desirable features that have been added by various extensions, in various contexts. Our approach to identifying the gaps is guided by key properties of Internet addressing, outlined in , namely (i) the fixed length of the IP addresses, (ii) the ambiguity of IP addresses semantic, while still (iii) providing limited IP address semantic support only. We derive those properties directly as a consequence of the respective standards that provide the basis for Internet addressing, most notably for IPv4 and for IPv6, respectively. Those basic properties, and the potential issues that arise from those properties, give way to extensions that have been proposed over the course of deploying new Internet technologies. discusses those extensions, summarized as gaps against the basic properties in . Finally, we outline issues that arise with the extension-driven approach to the basic Internet addressing, discussed in . We argue that any requirements for solutions that would revise the basic Internet addressing would require to address those issues.

As the Internet Protocol adoption has grown towards the global communication system we know today, its characteristics have evolved subtly, with documenting various aspects of the IP service model and its frequent misconceptions, including Internet addressing. In this section, we articulate the three most acknowledged properties related to Internet addressing. Those are (i) fixed IP address length, (ii) ambiguous IP address semantic, and (iii) limited IP address semantic support. In , we elaborate on various extensions that aim to expand Internet addressing beyond those properties; we position those extensions as intentions to close perceived gaps against those key properties.

The fixed IP address length is specified as a key property of the design of Internet addressing, with 32 bits for IPv4 (), and 128 bits for IPv6 (), respectively. Given the capability of the hardware at the time of IPv4 design, a fixed length address was considered as a more appropriate choice for efficient packet forwarding. Although the address length was once considered to be variable during the design of Internet Protocol Next Generation (“IPng”, cf., ) in 1990s, it finally inherited the design of IPv4 and adopted a fixed length address towards the current IPv6. As a consequence, the 128-bit fixed address length of IPv6 is regarded as a balance between fast forwarding (i.e., fixed length) and practically boundless cyberspace (128-bit length).

Initially, the meaning of an IP address has been to identify an interface on a network device, although, when was written, there were no explicit definitions of the IP address semantic. With the global expansion of the Internet protocol, the semantic of the IP address is commonly believed to contain at least two notions, i.e., the explicit “locator”, and the implicit “identifier”. Because of the increasing use of IP addresses to both identify a node and to indicate the physical or virtual location of the node, the intertwined address semantics of identifier and locator was then gradually observed and first documented in as “locator/identifier overload” property. With this, the IP address is used as an identification for host and server, very often directly used, e.g., for remote access or maintenance.

Although IPv4 did not add any semantic to IP addresses beyond interface identification (and location), time has proven that additional semantics are desirable (c.f., the history of 127/8 or the introduction of private addresses ), hence, IPv6 introduced some form of additional semantics based on specific prefix values, for instance link-local addresses or a more structured multicast addressing. Nevertheless, systematic support for rich address semantics remains limited and basically prefix-based.

Over the years, a plethora of extensions has been proposed in order to move beyond the native properties of IP addresses. We interpret the development of those extensions as filling gaps between the original properties of Internet addressing, outlined in the previous section, and desired new capabilities that those developing the extensions identified as being needed and desirable.

Extensions in this subsection aim at extending the property described in , i.e., fixed IP address length. When IPv6 was designed, the main objective was to create an address space that would not lead to the same situation as IPv4, namely to address exhaustion. To this end, while keeping the same addressing model like IPv4, IPv6 adopted a 128-bit address length with the aim of providing a sufficient and future-proof address space. The choice was also founded on the assumption that advances in hardware and Moore’s law would still allow to make routing and forwarding faster, and IPv6 routing table manageable. We observe, however, that the rise of new use cases but also the number of new, e.g., industrial/home or small footprint devices, was possibly unforeseen. Sensor networks and more generally the Internet of Things (IoT) emerged after the core body of work in IPv6. Nevertheless, it was clear from the beginning that differently from IPv6 assumptions, 128-bit addresses were costly in certain scenarios. At the same time, new use cases emerged, where addresses even bigger than 128-bit are useful, like in the context of content centric networks, structured addresses, or cryptographically generated addresses.

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

Header Compression/Translation: One of the main approaches to reduce header size in the IoT context is by header compression. Such technique is based on a stateful approach, utilizing what is usually called a “context” on the IoT sensor and the gateway for communications between an IoT device and a server placed somewhere in the Internet - from the edge to the cloud. The role of the “context” is to provide a way to “compress” the original IP header in a smaller one, by using shorter address information and/or dropping some field, using the context as a kind of dictionary. Separate device from locator identifier: Approaches that can offer customized address length that is adequate for use in such constrained domains are preferred. Using different namespaces for the ‘device identifier’ and the ‘routing’ or ‘locator identifier’ is one such approach.

Header Compression/Translation: Considering one base station is supposed to serve hundreds of user devices, maximizing the effectiveness for specific spectrum directly improve user quality of experience. To achieve the optimal utilization of the spectrum resource in wireless area, the RObust Header Compression (ROHC) mechanism, which has been widely adopted in cellar network like WCDMA, LTE, and 5G, utilizes header compression to shrink existing IPv6 headers onto shorter ones. Similarly, header compression techniques for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) have been around for several years now, constituting a main example of using the notion of a shared context in order to reduce the size of the network layer header (, , ). More recently, other compression solution have been proposed for Low Power Wide Area Networks (LPWAN - ), but they basically rely on the same “context” approach (). Also, constraints coming from either devices or carrier links would lead to mixed scenarios and compound requirements for extraordinary header compression. For native IPv6 communications on DECT ULE and MS/TP Networks , dedicated compression mechanisms are specified in and , while the transmission of IPv6 packets over NFC and PLC, specifications are being developed in and . Separate device from locator identifier: Solutions such as proposed in and can utilize a separation of device from locator, where only the latter is used for routing between the different domains using the same technology, therefore enabling the use of shorter addresses in the (possibly constrained) local environment. Device IDs used within such domains are carried as part of the payload by EIBP and hence can be of shorter size suited to the domain, while, for instance, in LISP a flexible address encoding allows shorter addresses to be supported in the LISP control plane .

To address current networking demands it may be preferred to use variable and longer address lengths. For example in content delivery networks, longer addresses such as URLs are required to fetch content, an approach that information-centric networking (ICN) applied for any data packet sent in the network, using information-based addressing. Further, as an approach to address the routing challenges faced in the Internet, structured addresses may be used, avoiding the need for routing protocols. Further, as an approach to address the routing challenges such as scalability, stability and the complex interworking between OSPF, eBGP and iBGP faced in the Internet, structured addresses may be used, avoiding the need for routing protocols overall.

The crucial need for longer address lengths comes from semantic extensions to IP addresses, where the extensions themselves do not fit within the length limitation of the IP address. discusses those extensions, divided into those where limitations stemming from the IP address lengths are considered and those where information is either represented through a longer address and/or additional header information.

See for examples of solutions that consider extended address and header information to represent extended semantics that are not limited by the IP address length.

, summarize the methodologies and the examples towards filling the gaps on length extensions.   Methodology Examples Shorter Address Length Header compression/translation 6LoWPAN, ROHC   Separate device from locator identifier EIBP, LISP, ILNP, HIP Longer Address Length Same as Semantic Extension /

Extensions in this subsection try extending the property described in , i.e., “locator/identifier overload” of the ambiguous address semantic. From the perspective of Internet users, on the one hand, the implicit identifier semantic result in the privacy issue of network behavior tracking and association. Despite that IP address assignment may be dynamic, they are nowadays considered as a personal data and as such undergoes privacy protection regulations like General Data Protection Regulation (“GDPR”, cf. ). Hence, additional mechanism are necessary in order to protect end user privacy. For network regulation of sensitive information, on the other hand, dynamically allocated IP addresses are not sufficient to guarantee device or user identification. As such, different address allocation systems, with stronger identification properties are necessary where security and authentication are at highest priority. Hence, in order to protect information security within a network, additional mechanism are necessary to identify the users or the devices attached to the network.

As discussed in , IP addresses reveal both ‘network locations’ as well as implicit ‘identifier’ information to both traversed network elements and destination nodes alike. This enables recording, correlation, and profiling of user behaviors and historical network traces, possibly down to individual real user identity. The IETF, e.g., in , has taken a clear stand on preventing any such pervasive monitoring means by classifying them as an attack on end users’ right to be left along (i.e., privacy). Regulations such as the EU’s General Data Protection Regulation (GDPR) classifies, for instance, the ‘online identifier’ as personal data which must be carefully protected; this includes end users’ IP addresses . Even before pervasive monitoring , IP addresses have been seen as something that some organizational owners of networked system may not want to reveal at the individual level towards any non-member of the same organization.

Traffic Proxy: Detouring the traffic to a trusted proxy is a heuristic solution. Since nodes between trusted proxy and destination (including the destination per se) can only observe the source address of the proxy, the “identification” of the origin source can thereby be hidden. To confuse the nodes between origin and the proxy, the traffic on such route would be encrypted via a key negotiated either in-band or off-band. Considering that all applications’ traffic in such route can be seen as a unique flow directed to the same “unknown” node, i.e., the trusted proxy, eavesdroppers in such route have to make more efforts to correlate user behavior through statistical analysis even if they are capable of identifying the users via their source addresses. The protection lays in the inability to isolate single application specific flows. According to the methodology, such approach is IP version independent and works for both IPv4 and IPv6. Source Address Rollover: Privacy issues related to address “identifier” semantic can be mitigated through regular change (beyond the typical 24 hours lease of DHCP). Built on the inevitabilities of “identifier” that IP address carries, such approach promote to change the source IP address at certain frequency. Under such methodology, refresh cycling window may reach to a balance between privacy protection and address update cost. Due to the limited space that IPv4 contains, such approach usually works for IPv6 only. Private Address Spaces: Their introduction in foresaw private addresses (assigned to specific address spaces by the IANA) as a means to communicate purely locally, e.g., within an enterprise, by separating private from public IP addresses. Considering that private addresses are never directly reachable from the Internet, hosts adopting private addresses are invisible and thus “anonymous” for the Internet. Besides, hosts for purely local communication used the latter while hosts requiring public Internet service access would still use public IP addresses. Address Translation: The aforementioned original intention for using private IP addresses, namely for purely local communication, resulted in a lack of flexibility in changing from local to public Internet access on the basis of what application would require which type of service. If eventually every end-system in an organization would require some form of public Internet access in addition to local one, an adequate number of public Internet addresses would be required for providing to all end systems. Instead, address translation enables to utilize many private IP addresses within an organization, while only relying on one (or few) public IP addresses for the overall organization. In principle, address translation can be applied recursively. This can be seen in modern broadband access where Internet providers may rely on carrier-grade address translation for all their broadband customers, who in turn employ address translation of their internal home or office addresses to those (private again) IP addresses assigned to them by their network provider. Two benefits arise from the use of (private to public IP) address translation, namely (i) the hiding of local end systems at the level of the (address) assigned organization, and (ii) the reduction of public IP addresses necessary for communication across the Internet. While the latter has been seen for long as a driver for address translation, we focus on the first issue in this section, also since we see such privacy benefit as well as objective as still being valid in addressing systems like IPv6 where address scarcity is all but gone . Separate device from locator identifier: Solutions that make a clear separation between the routing locator and the identifier, can allow for a device ID of any size, which in turn can be encrypted by a network element deployed at the border of routing domain (e.g., a router). Both source and end domain addresses can be encrypted and transported, as in the routing domain, only the routing locator is used.

Traffic Proxy: Although not initially designed for traffic proxy, Virtual Private Network (VPN, cf. ) is widely utilized for packets origin hiding as a traffic detouring methodology. As it evolved, VPN derivatives like WireGuard become a mainstream instance for user privacy and security enhancement. With such methodology in mind, onion routing , instantiated in the TOR Project , achieves high anonymity through traffic hand over via intermediates before reaching the destination. Since the architecture of TOR requires at least three proxies in traffic, none of them is aware of the entire route. Given that the proxies themselves can be deployed all over the cyberspace, trust will not be the prerequisite if proxies are randomly selected. In addition, dedicated protocols are also expected to be customized for privacy improvement via traffic proxy. For example, Oblivious DNS over HTTPS (ODoH, cf. ) use a third-part proxy to obscure identifications of user source addresses during DNS over HTTPS (DoH, cf. ) resolution. Similarly, Oblivious HTTP involve proxy alike in the HTTP environment. Source Address Rollover: As for source address rollover, it has been standardized that IP addresses for Internet users should be dynamic and temporary every time they are being generated . This benefits from the available address space in the case of IPv6, through which address generation or assignment should be unpredictable and stochastic for outside observers. More radically, advocates an ‘ephemeral address’ for each process that change over time. Through this, correlating user behaviors conducted by different identifiers (i.e., source address) becomes hard, if not impossible, based on the IP packet header alone. Private Addresses: The use and assignment of private address for IPv4 is laid out in , while unique local addresses (ULAs) in IPv6 take over the role of private address spaces in IPv4. Network Address Translation: The translation from one IP address realm into another is laid out in , using a stateful address binding to translate between the realms, e.g., from a private into a public address space. As outlined in , basic address translation is usually extended to include port information in the translation process, support bidirectional or simple outbound traffic only. Given address translation can be performed several times in cascade, NATs may exist as part of existing customer premise equipment (CPE), such as a cable or an Ethernet router, with private wired/wireless connectivity, or may be provided in a carrier environment to further translate ISP-internal private addresses to a pool of (assigned) public IP addresses. The latter is often dynamically assigned to CPEs upon bootstrapping of the CPE. Separate device from locator identifier: EIBP utilizes a structured approach to addressing. It separates the routing ID from the device ID, where only the routing ID is used for routing. Hence the device IDs can be encrypted. Similarly, LISP uses separate namespaces for routing and identification allowing to “hide” identifiers in encrypted LISP packets that expose only known routing information .

In some scenarios (e.g., corporate networks) it desirable to being able authenticate IP addresses so to prevent malicious attackers to spoof IP addresses. This is usually achieved by using a mechanism that allows to prove ownership of the IP address.

Self-certified addresses: This method is usually based on the use of nodes’ public/private keys. A node creates its own interface ID (IID) by using a cryptographic hash of its public key (with some additional parameters). Messages are then signed using the nodes’ private key. The destination of the message will verify the signature through the information in the IP address. Self-certification has the advantage that no third party or additional security infrastructure is needed. Any node can generate its own address locally and then only the address and the public key are needed to verify the binding between the public key and the address. Third party granted addresses: DHCP (Dynamic Host Configuration Protocol) is widely used to provide IP addresses, however, in its basic form, it does not perform any check and even an unauthorized user without the right to use the network can obtain an IP address. To solve this problem, a trusted third party has to grant access to the network before generating an address (via DHCP or other) that identifies the user. User authentication done securely either based on physical parameters like MAC addresses or based on an explicit login/password mechanism.

Self-certified Addresses: Major example of this methodology is , where IPv6 cryptographically Generated Addresses (CGA) are defined. The original specs have been already amended (cf., and ) in order to support multiple (stronger) cryptographic algorithms. Third party granted addresses: defines a DHCP option through which authorization tickets can be generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. Solutions exists where separate servers are used for user authentication (, )

, summarize the methodologies and the examples towards filling the gaps on identity extensions.   Methodology Examples Anonymous Address Identity Traffic Proxy VPN, TOR, ODoH   Source Address Rollover SLAAC   Private Address Spaces ULA   Address Translation NAT   Separate device from locator identifier EIBP, LISP Authenticated Address Identity Self-certified Addresses CGA   Third party granted addresses DHCP-Option

Extensions in this subsection try extending the property described in , i.e., limited address semantic support. As explained in , IP addresses carry both locator and interface identification semantic. Some efforts exists in trying to separate these semantics either in different address spaces or through different address format. Beyond just identification, location, and the fixed address size, other efforts extended the semantic through existing or additional header fields (or header options) outside the Internet address.

Several extensions have been developed to extend beyond the limited IPv6 semantics. Those approaches may include to apply structure to the address, utilize specific prefixes or entirely utilize the IPv6 address for different semantics while re-encapsulating the original packet to restore the semantics in another part of the network. For instance, structured addresses have the capability to introduce delimiters to identify semantic information in the header, therefore not constraining any semantic by size limitations of the address fields. We note here that extensions often start out as being proposed as an extended header semantic, while standardization may drive the solution to adopt an approach to accommodate their semantic within the limitations of an IP address. This section does include examples of this kind.

Semantic prefixes: Semantic prefixes are used to separate the IPv6 address space. Through this, new address families, such as for information-centric networking , service routing or other semantically rich addressing, can be defined, albeit limited by the prefix length and structure as well as the overall length limitation of the IPv6 address. Separate device from locator identifier: The option to use separate namespaces for the device address (w.r.t. the router locator), would offer more freedom for the use of different semantics. Structured addressing: One approach to address the routing challenges faced in the internet proposes the use of structured addresses, to void the need for routing protocols. Benefits of this approach can be significant, with the structured addresses capturing the relative physical or virtual position of routers in the network, and being variable in length. Key to the approach, however, is that the structured addresses capturing the relative physical or virtual position of routers in the network, or networks in an internetwork may not fit within the fixed and limited IP address length (cf., ). Other approaches to structured approaches may be the definition of application-specific structured binary components as a generalization of the URL schema used for HTTP-level communication. Localized forwarding semantics: Layer 2 hardware, such as SDN switches, are limited to the use of specific header fields for forwarding decisions. Hence, devising new localized forwarding mechanisms may make use of existing header fields such as the IPv6 source/destination field to achieve the desired forwarding behavior, while encapsulating the original IPv6 packets into the payload in order to be restored at the local forwarding network boundary. Network sizes in those solutions are limited by the size of the utilized address field, e.g., 256 bits for IPv6, thereby limiting the size of networks where such techniques could be used. The IPv6 address information provided in the encapsulated packet purely serves identifying the network endpoint, not its location.

Semantic prefixes: Newer approaches to IP anycast suggest the use of service identification in combination with a binding IP address model as a way to allow for metric-based traffic steering decisions; approaches for Service Function Chaining (SFC) utilize the next service header (NSH) information and packet classification to determine the destination of the next packet hop. Another example of the usage of different packet header extensions based in IP addressing is Segment Routing. In this case the source chooses a path and encodes it in the packet header as an ordered list of segments. Segments are coded at header of IPv6 Packet, based on the definition of a new Routing Extensions Header type, the Segment Routing Header (SRH), which contains Segment List. This is similar to what is already specified in RFC2460. Packets are then transmitted from source node with a list of segment ID (SID) inserted at header List dictates the path to follow in the network. Such segment ID are coded as 128 bit IPv6 addresses. Approaches such as utilize semantic prefixing to allow for ICN forwarding behavior within an IPv6 network. In this case an HICN name is the hierarchical concatenation of a name prefix and a name suffix, in which the name prefix is encoded as an IPv6 128 bits word and carried in IPv6 header fields, while the name suffix is encoded in transport headers fields such as TCP. However, it is a challenge to determine which IPv6 prefixes should be used as name prefixes. In order to know which IPv6 packets should be interpreted based on an ICN semantic, it is desirable to be able to recognize that an IPv6 prefix is a name prefix, e.g. to define a specific address family (AF_HICN, b0001::/16). This establishment of a specific address family allows the management and control plane to locally configure HICN prefixes and announce them to neighbors for interconnection. Separate device from locator identifier: EIBP separates the routing locator from the device identifier, relaxing therefore any semantic constraints on the device identifier. Similarly, LISP uses a flexible encoding named LISP Canonical Address Format (LCAF ), which allows to associate to routing locators any possible form (and length) of identifier. ILNP introduces as well a different semantic of IP addresses, while aligning to the IPv6 address format (128 bits). Basically, ILNP introduces a sharper logical separation between the 64 most significant bits and the 64 least significant bits of an IPv6 address. The former being a global locator, while the latter being an identifier that can have different semantic (rather than just being an interface identifier). Structured addressing: Network topology captures the physical connectivity among devices in the network. There is a structure associated with the topology. Examples are the core-distribution-access router structure commonly used in enterprise networks and clos topologies that are used to provide multiple connections between Top of Rack (ToR) devices and multiple layers of spine devices. Internet service providers use a tier structure that defines their business relationships. A clear structure of connected networks can be noticed in the internet. EIBP proposes to leverage the physical structure (or a virtual structure overlaid on the physical structure) to auto assign addresses to routers in a network or networks in an internetwork to capture their relative position in the physical/virtual topology. EIBP proposes to administratively identify routers/networks with a tier value based on the structure. Localized forwarding semantics: Approaches such as those outlined in suggest using a novel forwarding semantic based on path information carried in the packet itself, said path information consists in a fixed size bitfield (see for more information on how to represent the path information in said bitfield). In order to utilize existing, e.g., SDN-based, forwarding switches, the direct use of the IPv6 source/destination address is suggested for building appropriate match-action rules (over the suitable binary information representing the local output ports), while preserving the original IPv6 information in the encapsulated packet. As mentioned above, such use of the existing IPv6 address fields limits the size of the network to a maximum of 256 bits (therefore paths in the network over which such packets can be forwarded). , however, goes a step further by suggesting to use the local forwarding as direct network layer mechanism, removing the IP packet and only leaving the transport/application layer, with the path identifier constituting the network-level identifier albeit limited by using the existing IP header for backward compatibility reason (the next section outlines the removal of this limitation).

While the former sub-section explored extended address semantic, thereby limiting any such extended semantic with that of the existing IPv6 semantic and length, additional semantics may also be placed into the header of the packet or the packet itself, utilized for the forwarding decision to the appropriate endpoint according to the extended semantic. Reasons for embedding such new semantics may be related to traffic engineering since it has long been shown that the IP address itself is not enough to steer traffic properly since the IP address itself is not semantically rich enough to adequately describe the forwarding decision to be taken in the network, not only impacting WHERE the packet will need to go but also HOW it will need to be sent.

In-Header extensions: One way to add additional semantic besides the address fields is to use other fields already present in the header. Headers option extensions: Another mechanism to add additional semantic is to actually add additional fields, e.g., through Header Options in IPv4 or through Extension Headers in IPv6. Re-encapsulation extension: A more radical approach for additional semantic is the use of a complete new header that is designed so to carry the desired semantic in an efficient way (often as a shim header). Structured addressing: Similar to the methodology that structures addresses within the limitations of the IPv6 address length, outlined in the previous sub-sections, structured addressing can also be applied within existing or extended header semantics, e.g., utilizing a dedicated (extension) header to carry the structured address information. Localized forwarding semantics: This set of solutions apply capabilities of newer (programmable) forwarding technology, such as , to utilize any header information for a localized forwarding decision. This removes any limitation to use existing header or address information for embedding a new address semantic into the transferred packet.

In-Header extensions: In order to allow additional semantic with respect to the pure Internet addressing, the original design of IPv4 included the field “Type of Service” , while IPv6 introduced the “Flow label” and the “Traffic Class” . In a certain way, those fields can be considered “semantic extensions” of IP addresses, and they are “in-header” because natively present in the IP header (differently from options and extension headers). However, they proved not to be sufficient. Very often a variety of network operation are performed on the well-known 5-tuple (source and destination addresses; source and destination port number; and protocol number). In some contexts all of the above mentioned fields are used in order to have a very fine grained solution (). Headers option extensions: Header options have been largely under exploited in IPv4. However, the introduction of the more efficient extension header model in IPv6 along with technology progress made the use of header extensions more widespread in IPv6. Segment Routing re-introduced the possibility to add path semantic to the packet by encoding a loosely defined source routing (). Similarly, in the aim to overcome the inherent shortcoming of the multi-homing in the IP context, SHIM6 () also proposed the use of an extension header able to carry multi-homing information which cannot be accommodated natively in the IPv6 header. To serve a moving endpoint, mechanisms like Mobile IPv6 are used for the maintenance of connection continuity by a dedicated IPv6 extension header. In such a case, the IP address of the home agent in Mobile IPv6 is basically an identification of the on-going communication. In order to go beyond the interface identification model of IP, the Host Identity Protocol (HIP) tries to introduce an identification layer to provide (as the name says) host identification. The whole architecture relies on the use of another type of extension header . Re-encapsulation extension: Differently from the previous approach, re-encapsulation prepends complete new IP headers to the original packet introducing a completely custom shim header between the outer and inner header. This is the case for LISP, adding a LISP specific header right after an IP+UDP header (). A similar design is used by VxLAN () and GENEVE (), even if they are designed for a data center context. IP packets can also be wrapped with headers using more generic and semantically rich names, for instance with ICN . Structured addressing: Solutions such as those described in the previous sub-section, e.g., EIBP , can provide structured addresses that are not limited to the IPv6 address length but instead carry the information in an extension header to remove such limitation. Also information-centric networking (ICN) naming approaches usually introduce structures in the (information) names without limiting themselves to the IP address length; more so, ICN proposes its own header format and therefore radically breaks with not only IP addressing semantic but the format of the packet header overall. For this, approaches such as those described in define a TLV-based binary application component structure that is carried as a ‘name’ part of the CCN messages. Such a name is a hierarchical structure for identifying and locating a data object, which contains a sequence of name components. Names are coded based on 2-level nested Type-Length-Value (TLV) encodings, where the name-type field in the outer TLV indicates this is a name, while the inner TLVs are name components including a generic name component, an implicit SHA-256 digest component and a SHA-256 digest of Interest parameters. For textual representation, URIs are normally used to represent names, as defined in . In geographic addressing, position based routing protocols use the geographic location of nodes as their addresses, and packets are forwarded when possible in a greedy manner towards the destination. For this purpose the packet header includes a field coding the geographic coordinates (x, y, z) of the destination node, as defined in . Some proposals also rely on extra fields in the packet header to code the distance towards the destination, in which case only the geographic coordinates of neighbors are exchanged. This way the location of the destination is protected even if routing packets are eavesdropped. Localized forwarding semantics: Unlike the original suggestion in to use existing SDN switches, the proliferation of P4 opens up the possibility to utilize a locally limited address semantic, expressed through the path identifier, as an entirely new header (including its new address) with an encapsulation of the IP packet for E2E delivery (including further delivery outside the localized forwarding network or positioning the limited address semantic directly as the network address semantic for the packet, i.e., removing any IP packet encapsulation from the forwarded packet, as done in . Removing the IPv6 address size limitation by not utilizing the existing IP header for the forwarding decision also allows for extensible length approaches for building the path identifier with the potential for increasing the supported network size. On the downside, this approach requires to encapsulate the original IP packet header for communication beyond the local domain in which the new header is being used, such as discussed in the previous point above on ‘re-encapsulation extension’.

, summarize the methodologies and the examples towards filling the gaps on semantic extensions.   Methodology Examples Utilizing Extended Address Semantics Semantic prefixes HICN   Separate device from locator identifier EIBP, ILNP, LISP, HIP   Structured addressing EIBP, ILNP   Localized forwarding semantics REED Utilizing Existing or Extended Header Semantics In-Header extensions DetNet   Headers option extensions SHIM6, SRv6, HIP   Re-encapsulation extension VxLAN, ICNIP   Structured addressing EIBP   Localized forwarding semantics REED

From the view of the extensions, describes the objectives these extensions in extending the properties of Internet addressing. As summarized, extensions may aim to extend one property of the Internet addressing, or extend other properties at the same time.   Length Extension Identity Extension Semantic Extension 6LoWPAN x     ROHC x     TOR   x   ODoH   x   SLAAC   x   CGA   x x NAT x x   HICN   x x ICNIP x x x CCNx names x x x EIBP x x x Geo addressing x   x REED x (with P4)   x DetNet   x   Mobile IP     x SHIM6     x SRv6     x HIP   x x VxLAN   x x LISP   x x SFC   x x

While the extensions to the original Internet properties discussed in demonstrate the flexibility of the basic proposed mechanisms, they also bring with them a number of issues, which we discuss in the following section. For this, we outline the problems caused, linking those to the approaches to extensions summarized in .

Many approaches changing the semantics of communication, e.g., through separating host identification from network node identification , separating the device identifier from the routing locator (, ), or through identifying content and services directly , 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 may override the addressing semantics, e.g., by replacing IPv6 source and destination information with path identification, a possible unawareness of endpoints still requires the carrying of other address information as part of the payload. Also, the expressible service or content semantic may be limited, as in or the size of supported networks due to relying on the limited bit positions usable in IPv6 addresses.

A crucial issue is the additional complexity introduced for realizing the additional addressing semantics. This is particularly an issue since we see those additional semantics particularly at the edge of the Internet, utilizing the existing addressing semantic of the Internet to interconnect the domains that require those additional semantics. Furthermore, any additional complexity can often come with an efficiency and cost penalty, particularly at the edge of the network, where resource constraints may play a significant role. Compression processes, taking ROHC as an example, require additional resources both for the sender generating the compressed header but also the gateway linking to the general Internet by re-establishing the full IP header (cf., ). Conversely, the performance requirements of core networks, in terms of packet processing speed, make the accommodation of extensions to addressing often prohibitive. This is not only due to the necessary extra processing that is specific to the extension, but also due to the complexity that will need to be managed in doing so at significantly higher speeds than at the edge of the network. The observations on the dropping of packets with IPv6 extension headers in the real world is (partially) due to such a implementation complexity . Another example for lowering the efficiency of packet forwarding is the routing in systems like TOR . As detailed before, traffic in TOR, for anonymity purposes, should be handed over by at least three intermediates before reaching the destination. Thus, frequent relaying enhances the privacy, however, because such kind of solutions have to be implemented at application level, which comes at the cost of lower communication efficiency. May be a different privacy enhanced address semantic would enable efficient implementation of TOR-like solutions at network layer.

Repetitive encapsulation is an issue ‘bloating’ packet sizes with additional encapsulation headers. Addressing proposals such as those in utilize path identification within an alternative forwarding architecture that acts upon the provided path identification. However, due to the limitation of existing flow-based architectures with respect to the supported header structures (in the form of IPv4 or IPv6 headers), the new routing semantics are being inserted into the existing header structure, while repeating the original, sender-generated header structure, in the payload of the packet as it traverses the local domain, effectively doubling the header overhead per packet. The problem is also present in a number of solutions tackling different issues, e.g., mobility , DC networking (, , ), traffic engineering , and privacy (, ). Certainly these solutions are able to avoid other issues, like path lengthening or privacy issues, as described later, but they come at the price of multiple encapsulations that reduce the effective payload. This not only hampers efficiency in terms of header-to-payload ratio but also introduces “encapsulation points”, which in turn add complexity to the (often edge) network as well as fragility due to introducing possible failure points; we discuss this aspect more in .

IP header overhead requires header compression in constrained environments, such as wireless sensor networks and IoT in general. Together with fragmentation, both tasks constitute significant energy consumption, as shown in , negatively impacting reduced function devices that often rely on battery for operation. Further, the reliance on the compression/decompression points creates a dependence on such gateways, which may be a problem for intermittent scenarios. According to implementation of contiki-ng , an example of operating system for IoT devices, the source codes for 6LowPan requires at least 600kb to include a header compression process. In certain use cases, such requirement can be an obstacle for extremely constrained devices, especially for the RAM and energy consumption.

Mobile IP , which was designed for connection continuity in the face of moving endpoints, is a typical case for path stretch. Since traffic must follow a triangular route before arriving at the destination, such detour routing inevitably impacts transmission efficiency as well as latency.

While many extensions to the original IP address semantic target to enrich the decisions that can be taken to steer traffic according to requirements for, e.g., QoS, mobility, chaining, compute/network metrics, flow treatment, path usage, etc., the realization of the mechanisms as individual solutions likely complicates the original goal of traffic engineering when individual solutions are being used in combination. Ultimately, this may even prevent the combined use of more than one mechanism and/or policies with a need to identify and prevent incompatibilities of mechanisms. Key here is not the issue arising from using conflicting traffic engineering polices but conflicting realizations of policies that may well generally work well alongside (, ). This not only increases fragility, as we will discuss separately in , but also requires careful planning for which mechanisms to use and in which combination, likely needing human-in-the-loop approaches alongside possible automation approaches for the individual solutions.

The properties described in have, obviously, also consequences in terms of security and privacy related issues, as already mentioned in other parts of this document. For instance, in the effort of being somehow backward compatible, HIP uses 128-bit Host Identity, which may be not sufficiently cryptographically strong in the future because of the limited size (future computational power may erode 128-bit security). Similarly, CGA also align to the 128-bit limit but may use only 59 bits of them, hence, the packet signature may not be sufficiently robust to attacks . IP addresses, even temporary ones meant to protect privacy, have been long recognized as a “Personal Identification Information” that allows even to geolocate the communicating endpoints . The use of temporary addresses provides sufficient privacy protection only if the renewal rate is high . However, this causes additional issues, like the large overhead due to the Duplicate Address Detection, the impact on the Neighbor Discovery mechanism, in particular the cache, which can even lead to communication disruption. With such drawbacks, the extensions may even lead to defeat the target actually lowering security rather than increasing it. The introduction of alternative addressing semantics has also been used to help in (D)DoS attacks mitigation. This leverages on changing the service identification model so to avoid topological information exposure, making the potential disruptions likely remain limited . However, this increased robustness to DDoS comes at the price of important communication setup latency and fragility, as discussed next.

From the extensions discussed in , it is evident that having alternative or additional address semantic and formats available for making routing as well as forwarding decisions dependent on these, is common place in the Internet. This, however, adds many extension-specific translation/adaptation points, mapping the semantic and format in one context into what is meaningful in another context, but also, more importantly, creating a dependency towards an additional component, often without explicit exposure to the endpoints that originally intended to communicate. For instance, the re-writing of IP addresses to facilitate the use of private address spaces throughout the public Internet, realized through network address translators (NATs), conflicts with the end-to-end nature of communication between two endpoints. Additional (flow) state is required at the NAT middlebox to smoothly allow communication, which in turn creates a dependency between the NAT and the end-to-end communication between those endpoints, thus increasing the fragility of the communication relation. A similar situation arises when supporting constrained environments through a header compression mechanism, adding the need for, e.g., a ROHC element in the communication path, with communication-related compression state being held outside the communicating endpoints. Failure will introduce some inefficiencies due to context regeneration, which may affects the communicating endpoints, increasing fragility of the system overall. Such translation/adaptation between semantic extensions to the original ‘semantic’ of an IP address is generally not avoidable when accommodating more than a single universal semantic. However, the solution-specific nature of every single extension is likely to noticeably increase the fragility of the overall system, since individual extensions will need to interact with other extensions that may be deployed in parallel, but were not designed taking into account such deployment scenario (cf., ). Considering that extensions to traditional per-hop-behavior (based on IP addresses) can essentially be realized over almost ‘any’ packet field, the possible number of conflicting behaviors or diverging interpretation of the semantic and/or content of such fields, among different extensions, may soon become an issue, requiring careful testing and delineation at the boundaries of the network within which the specific extension has been realized.

, derived from , summarize the issues related to each of the extension. As summarized, each extension involves at least one issue. For extension like ICNIP, several issues may be involved at the same time. Further, as explained in , “fragility” does not mean that the extensions are fragile per-se, they are robust for the task they have been designed for, rather we refer to the existence of additional components that may fail (as Murphy’s law teach us), hence, making the overall system more fragile.   Limiting Address Semantics Complexity and Efficiency Security Fragility 6LoWPAN   x   x ROHC   x   x TOR   x   x ODoH   x     SLAAC   x     CGA x   x   NAT   x   x HICN x       ICNIP x x     CCNx name x       EIBP x x     Geo addressing x     x REED x       DetNet   x     Mobile IP   x   x SHIM6       x SRv6       x HIP     x x VxLAN   x     LISP x x     SFC   x   x

The examples of extensions discussed in to the original Internet addressing scheme show that extensibility beyond the original model (and its underlying per-hop behavior) is a desired capability for networking technologies and has been so for a long time. Generally, we can observe that those extensions are driven by the requirements of stakeholders, expecting a desirable extended functionality from the introduction of the specific extension. If interoperability is required, those extensions require standardization of possibly new fields, new semantics as well as (network and/or end system) operations alike. One could argue that the power of the packet header (and the entire packet for that matter) lies in its potential to be used for extensions that satisfy the various requirements of those developing the extensions with given deployments and use cases in mind. The author in argues that this capability represents the ‘expressive power of the Internet design’, with developments such as Software-Defined Networking (SDN) enabling per-hop operations (to be specified in dedicated match-action rules) that take more than just the IP address as input, even beyond the strict IP header, albeit still limited to certain packet header(s) fields, as in the OpenFlow specification . Beyond the fragility, discussed in this document, caused by adding, overriding, amending semantics and behaviors (and deploying them in a running system), such approach to extensibility that opens up other header fields may, however, also be limiting the realization of per-hop operations. As an example, although the authors in utilize the power of SDN to enable extension-specific per-hop behaviors that follow path-based rather than endpoint locator semantics, they do so within the limitation of currently supported header fields in SDN. The result is the overriding of the IPv6 source/destination address with the semantic input (here the path forwarding identifier) for the desired per-hop behavior, which in turn creates the need for border translation to avoid ‘leaking’ such (malformed) IPv6-like packet into a standard IPv6 network. Leaving the IPv6 address information intact albeit unused is not possible due to the lack of accommodating the extended per-hop behavior information needed for the proposed solution. Since the publication of (and its realization in existing real world trials), the newer P4 technology has removed this limitation, therefore positioning the entire packet content as input into per-hop behavior and removing the need for overriding existing packet fields and restoring their semantics at the borders of the network. We see such evolution of per-hop behavior implementation as closing the loop to approaches to addressing considered in early days of the packet-based networking , based on structured and flexible addresses, similar to the heap or stack model suggestions found in . We believe that approaching addressing from such desire to enable extensions by design rather than through a pure extension engineering approach would also address possible fragility and security issues due to unwanted interactions between possibly incompatible extensions, while also enabling more efficient realization of the extensions through a common execution point in the forwarding element. The issues we identified with the extension-specific solution approach, point to the need for a discussion on Internet addressing, as formulated in the companion document that formalizes the problem statement through scenarios that highlight the shortcomings of the Internet addressing model. It is our conclusion that the existence of the many extensions to the original Internet addressing is clear evidence for gaps that have been identified over time by the wider Internet community: it is time to develop an architectural but more importantly a sustainable approach to make Internet addressing extensible in order to capture the many new uses we will still identify for the Internet to come. Any inaction on our side in that regard will only compound the issues we identified, eventually hampering the future Internet’s readiness for those new uses.

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

This document does not include any IANA request.

This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. lispers.net cisco Systems 1-4-5.net Logical Elegance This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. Quantonium Independent Microsoft This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. SI6 Networks SI6 Networks IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. Apple Inc. Fastly Apple Inc. Cloudflare Cloudflare This document describes an extension to DNS Over HTTPS (DoH) that allows hiding client IP addresses via proxying encrypted DNS transactions. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. Mozilla Cloudflare This document describes a system for the forwarding of encrypted HTTP messages. This allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests as having come from the same client. Huawei Technologies Duesseldorf GmbH InterDigital Inc. Essex University Essex University RWTH Aachen In this draft, we provide architecture and operations for enabling Internet services over ICN over (5G-enabled) LAN environments. Operations include ICN API to upper layers, HTTP over ICN, Service Proxy Operations, ICN Flow Management, Name Resolution, Mobility Handling, and Dual Stack Device Support. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Huawei Technologies Co., Ltd Huawei Technologies Duesseldorf GmbH Huawei Technologies France S.A.S.U. Futurewei Technologies China Mobile 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. This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. This document is not an Internet Standards Track specification; it is published for informational purposes. This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK] The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK] This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload. Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. Electronics and Telecommunications Research Institute Electronics and Telecommunications Research Institute DONG-EUI University Kyungpook National University Samsung Electronics Co., Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LoWPAN techniques. Huawei Technologies Huawei Technologies ETRI SGEPRI Lupin Lodge Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. lispers.net Cisco Systems vaf.net Internet Consulting UPC/BarcelonaTech This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. By using this Control-Plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems, which facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connecting EID addressable nodes of a LISP site, it the implementation and operational complexity of the overall cost and effort of deploying LISP. This document obsoletes RFC 6830 and RFC 6833. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community. This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks. This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK] This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK] This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK] This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK] The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK] This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK] This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK] This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK] This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. lispers.net vaf.net Internet Consulting 1-4-5.net Cisco Systems UPC/BarcelonaTech This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. This document obsoletes RFC 6830. This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs. Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community. This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document describes the possible attacks with the use of Cryptographically Generated Addresses. This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group. Independent consultant Cisco This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document are used to derive recommendations that update MTU and fragment issues in RFC 4459.

Thanks to Carsten Bormann for useful conversations.