idnits 2.17.1 draft-gao-fsp-motivations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2018) is 2015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7928' is mentioned on line 1114, but not defined == Unused Reference: 'RFC6824' is defined on line 1544, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 1285, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 1309, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 1376, but no explicit reference was found in the text == Unused Reference: 'RFC3124' is defined on line 1385, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 1394, but no explicit reference was found in the text == Unused Reference: 'RFC3828' is defined on line 1399, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: 'RFC4192' is defined on line 1414, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1419, but no explicit reference was found in the text == Unused Reference: 'RFC4388' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'RFC4422' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'RFC5056' is defined on line 1468, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 1478, but no explicit reference was found in the text == Unused Reference: 'RFC5218' is defined on line 1482, but no explicit reference was found in the text == Unused Reference: 'RFC5723' is defined on line 1486, but no explicit reference was found in the text == Unused Reference: 'RFC5889' is defined on line 1491, but no explicit reference was found in the text == Unused Reference: 'RFC5942' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: 'RFC6177' is defined on line 1504, but no explicit reference was found in the text == Unused Reference: 'RFC6250' is defined on line 1509, but no explicit reference was found in the text == Unused Reference: 'RFC6434' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 1525, but no explicit reference was found in the text == Unused Reference: 'RFC6741' is defined on line 1529, but no explicit reference was found in the text == Unused Reference: 'RFC6832' is defined on line 1549, but no explicit reference was found in the text == Unused Reference: 'RFC6833' is defined on line 1555, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 1580, but no explicit reference was found in the text == Unused Reference: 'RFC7401' is defined on line 1590, but no explicit reference was found in the text == Unused Reference: 'RFC7429' is defined on line 1595, but no explicit reference was found in the text == Unused Reference: 'RFC7525' is defined on line 1607, but no explicit reference was found in the text == Unused Reference: 'RFC7608' is defined on line 1618, but no explicit reference was found in the text == Unused Reference: 'RFC7721' is defined on line 1623, but no explicit reference was found in the text == Unused Reference: 'RFC7805' is defined on line 1628, but no explicit reference was found in the text == Unused Reference: 'RFC7925' is defined on line 1633, but no explicit reference was found in the text == Unused Reference: 'RFC8003' is defined on line 1639, but no explicit reference was found in the text == Unused Reference: 'RFC8170' is defined on line 1648, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 37 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Gao 3 Intended Status: Informational 4 Expires: April 20, 2019 October 17, 2018 6 Motivations and Design Choices of the Flexible Session Protocol 7 draft-gao-fsp-motivations-00 9 Abstract 11 This document introduces the motivation to design the Flexible 12 Session Protocol which supports mobility and multihoming at the 13 transport layer. FSP is to avoid, if not to extirpate, the routing 14 scalability problem in the IPv6 internetwork. 16 The document serves to explain choices of design goals of FSP as 17 well. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Mobility and Multihoming Support in the IPv6 Internet . . . 4 60 2. Survey of Infrastructure-Dependent Mobility Support . . . . . . 4 61 2.1. Separation of Identifier and Locator . . . . . . . . . . . 5 62 2.1.1. Host Identity Protocol . . . . . . . . . . . . . . . . 5 63 2.1.2. Identifier-Locator Network Protocol . . . . . . . . . . 6 64 2.2.3. The Locator/ID Separation Protocol . . . . . . . . . . 7 65 2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.2.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 8 67 2.2.2. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . 10 68 2.2.3. Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . 10 69 2.2.4. Network Mobility (NEMO) Basic Support Protocol . . . . 11 70 2.3. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 2.4. DMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3. Survey of Infrastructure-Independent Mobility Support . . . . . 15 73 3.1. IKEv2 Mobility and Multihoming Protocol . . . . . . . . . . 15 74 3.2. Mobile SCTP . . . . . . . . . . . . . . . . . . . . . . . . 17 75 3.3. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . . 18 76 3.4. REST Architecture Style . . . . . . . . . . . . . . . . . . 18 77 4. A Solution at the Origin of the Problem . . . . . . . . . . . . 20 78 4.1. Separation of Identity and Locator at Transport Layer . . . 20 79 4.2. Adding Programmer-Friendly Session Semantics . . . . . . . 20 80 4.2.1. Intuitiveness . . . . . . . . . . . . . . . . . . . . . 20 81 4.2.2. Really Parallel Streams . . . . . . . . . . . . . . . . 21 82 4.2.3. Mixed Traffic Class . . . . . . . . . . . . . . . . . . 21 83 4.2.4. Session Adjournment and Resumption . . . . . . . . . . 21 84 4.3. Adding Programmer-friendly Security Service . . . . . . . . 21 85 4.3.1. Ubiquitous Encryption and Authentication of Data . . . 21 86 4.3.2. Key Establishment versus Application of Keys . . . . . 22 87 5. Choices of Design Goals . . . . . . . . . . . . . . . . . . . . 22 88 5.1. Featured Scenarios . . . . . . . . . . . . . . . . . . . . 22 89 5.1.1. Goal: Support for Mobile Computing . . . . . . . . . . 22 90 5.1.2. Goal: Adaptable to Specific-Purpose Networks . . . . . 23 91 5.1.3. Non-Goal: General Multicast Transport . . . . . . . . . 23 92 5.2. Optimizing towards IPv6 . . . . . . . . . . . . . . . . . . 23 93 5.2.1. Goal: Promoting Transition towards IPv6 . . . . . . . . 23 94 5.2.2. Goal: NAT friendliness in IPv4 network . . . . . . . . 23 95 5.2.3. Non-Goal: NAT friendliness in IPv6 network . . . . . . 23 96 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 24 97 5.3.1. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 24 98 5.3.2. Goal: Host-Aggregated Congestion Control . . . . . . . 24 99 5.3.3. Goal: Congestion Control Per Traffic Class . . . . . . 24 100 5.3.4. Non-Goal: TCP Friendliness . . . . . . . . . . . . . . 24 101 5.4. Infrastructure Independency . . . . . . . . . . . . . . . . 24 102 5.4.1. Goal: More Efficient Use of the IPv6 Address Space . . 24 103 5.4.2. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 25 104 5.4.3. Goal: AQM Awareness . . . . . . . . . . . . . . . . . . 25 105 5.4.4. Non-Goal: Adaptable to New Rendezvous Mechanism . . . . 25 106 5.5. Feasibility of Hardware Acceleration . . . . . . . . . . . 25 107 5.6. QoS and Multipath Issues . . . . . . . . . . . . . . . . . 26 108 5.6.1. Goal: Minimal Delay Service for Milk Like Payload . . . 26 109 5.6.2. To be studied: Resource Reservation . . . . . . . . . . 26 110 5.6.3. Non-Goal: PMTU discovery . . . . . . . . . . . . . . . 26 111 5.7. On-the-wire Compression . . . . . . . . . . . . . . . . . . 26 112 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 27 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 115 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 116 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 119 1. Introduction 121 The motivation of designing the Flexible Session Protocol, which sits 122 at the transport layer along with TCP [RFC0793], is to provide 123 mobility and multihoming support, thus to make routing scalability 124 problem [RFC4984] in the IPv6 [RFC8200] internetwork thoroughly 125 avoidable. 127 FSP means to be programmer-friendly by adding session semantics in 128 the transport layer and providing security services that is flexible 129 to adapt to new cryptography key establishment algorithm implemented 130 at the application layer. 132 FSP is to be an alternative of TCP in application scenarios that 133 favor high-performance and security in IPv6 networks, although no 134 fundamental obstacle exists that prevents it from being adapted to 135 the Internet of Things or constrained-node networks [RFC7228]. 137 FSP is intent on promoting IPv6. 139 The document serves to explain some design choices of FSP as well. 141 1.1. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 1.2. Mobility and Multihoming Support in the IPv6 Internet 149 Various solutions exist in the IPv6 Internet that support mobility 150 and/or multihoming. In this documents we survey infrastructure- 151 dependent solutions such as HIP [RFC4423], ILNP [RFC6740], LISP 152 [RFC6830], NEMO [RFC3963], MinimalT [MinimaLT], MIPv6 [RFC6275], 153 PMIPv6 [RFC5213], HMIPv6 [RFC5380] and DMM [RFC7333], and 154 infrastructure-independent solutions such as MOBIKE [RFC4555], Mobile 155 SCTP, MPTCP [RFC7430] and REpresentation State Transfer architecture 156 style [RESTful]. 158 This document draws heavily from earlier RFCs and other references 159 when discusses these known solutions. 161 2. Survey of Infrastructure-Dependent Mobility Support 163 Infrastructure-dependent proposals that support mobility often 164 require some change of current Internet architecture. Here we survey 165 HIP and ILNP. HIP has moderate impact on the Internet architectural 166 while ILNP seems call for fundamental change. 168 Various solutions exist in the IPv6 Internet that support mobility 169 and/or multihoming. In this documents we surveys infrastructure- 170 dependent solutions such as HIP, ILNP, LISP, NEMO, MinimalT, MIPv6, 171 PMIPv6 and HMIPv6. 173 2.1. Separation of Identifier and Locator 175 2.1.1. Host Identity Protocol 177 HIP architecture proposes Host Identity namespace that fills an 178 important gap between the IP and DNS namespaces. The Host Identity 179 namespace consists of Host Identifiers (HIs). A Host Identifier is 180 cryptographic in its nature; it is the public key of an asymmetric 181 key-pair. Each host will have at least one Host Identity, but it will 182 typically have more than one. Each Host Identity uniquely identifies 183 a single host; i.e., no two hosts have the same Host Identity. The 184 Host Identity, and the corresponding Host Identifier, can be either 185 public (e.g., published in the DNS) or unpublished. Client systems 186 will tend to have both public and unpublished Identities. 188 Service ------ Socket Service ------ Socket 189 | | 190 | | 191 | | 192 | | 193 End-point | End-point --- Host Identity 194 \ | | 195 \ | | 196 \ | | 197 \ | | 198 Location --- IP address Location --- IP address 200 Figure 1 New Stack Architecture Presented by HIP 202 HIP decouples the transport from the internetworking layer, and binds 203 the transport associations to the Host Identities. Consequently, HIP 204 can provide for a degree of internetworking mobility and multihoming 205 at a low infrastructure cost. HIP mobility includes IP address 206 changes (via any method) to either party. HIP links IP addresses 207 together, when multiple IP addresses correspond to the same Host 208 Identity, and if one address becomes unusable, or a more preferred 209 address becomes available, existing transport associations can easily 210 be moved to another address. 212 When a node moves while communication is already ongoing, address 213 changes are rather straightforward. The peer of the mobile node can 214 just accept a HIP or an integrity protected IPsec packet from any 215 address and ignore the source address. 217 In order to start the HIP exchange, the initiator node has to know 218 how to reach the mobile node. Although infrequently moving HIP nodes 219 could use Dynamic DNS [RFC2136] to update their reachability 220 information in the DNS, an alternative to using DNS in this fashion 221 is to use a piece of new static infrastructure to facilitate 222 rendezvous between HIP nodes. 224 The mobile node keeps the rendezvous infrastructure continuously 225 updated with its current IP address(es). The mobile nodes must trust 226 the rendezvous mechanism to properly maintain their HIT and IP 227 address mappings. 229 The rendezvous mechanism [RFC8004] is also needed if both of the 230 nodes happen to change their address at the same time, either because 231 they are mobile and happen to move at the same time, because one of 232 them is off-line for a while, or because of some other reason. 234 2.1.2. Identifier-Locator Network Protocol 236 The key idea proposed for ILNP is to directly and specifically change 237 the overloaded semantics of the IP Address. The Internet community 238 has indicated explicitly, several times, that this use of overloaded 239 semantics is a significant problem with the use of the Internet 240 protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984]. 242 ILNP explicitly replaces the use of IP Addresses with two distinct 243 name spaces, each having distinct and different semantics: 245 a) Identifier: a non-topological name for uniquely identifying a 246 node. 248 b) Locator: a topologically bound name for an IP subnetwork. 250 The use of these two new namespaces in comparison to IP is given in 251 Table 1. The table shows where existing names are used for state 252 information in end-systems or protocols. 254 Layer | IP | ILNP 255 ---------------+----------------------+--------------- 256 Application | FQDN or IP Address | FQDN 257 Transport | IP Address | Identifier 258 Network | IP Address | Locator 259 Physical i/f | IP Address | MAC address 260 ---------------+----------------------+--------------- 262 FQDN = Fully Qualified Domain Name 263 i/f = interface 264 MAC = Media Access Control 266 Table 1: Use of Names for State Information in Various 267 Communication Layers for IP and ILNP 269 ILNP supports mobility directly. Essentially, for ILNP, mobility is 270 implemented by enabling: 272 a) Locator values to be changed dynamically by a node, including for 273 active network-layer sessions. 275 b) use of Locator Updates [RFC6743] to allow active network-layer 276 sessions to be maintained. 278 c) for those hosts that expect incoming network-layer or transport- 279 layer session requests (e.g., servers), updates to the relevant 280 DNS entries for those hosts [RFC6742]. 282 2.2.3. The Locator/ID Separation Protocol 284 The Locator/Identifier Separation Protocol provides a set of 285 functions for routers to exchange information used to map from 286 Endpoint Identifiers (EIDs) that are not globally routable to 287 routable Routing Locators (RLOCs). It also defines a mechanism for 288 these LISP routers to encapsulate IP packets addressed with EIDs for 289 transmission across a network infrastructure that uses RLOCs for 290 routing and forwarding. 292 The approach that LISP takes to solving the routing scalability 293 problem is to replace IP addresses with two new types of numbers: 294 Routing Locators (RLOCs), which are topologically assigned to network 295 attachment points (and are therefore amenable to aggregation) and 296 used for routing and forwarding of packets through the network; and 297 Endpoint Identifiers (EIDs), which are assigned independently from 298 the network topology, are used for numbering devices, and are 299 aggregated along administrative boundaries. LISP then defines 300 functions for mapping between the two numbering spaces and for 301 encapsulating traffic originated by devices using non-routable EIDs 302 for transport across a network infrastructure that routes and 303 forwards using RLOCs. Both RLOCs and EIDs are syntactically 304 identical to IP addresses; it is the semantics of how they are used 305 that differs. 307 LISP implementations must provide ITRs and ETRs. 309 An ITR is a router that resides in a LISP site. Packets sent by 310 sources inside of the LISP site to destinations outside of the site 311 are candidates for encapsulation by the ITR. The ITR treats the IP 312 destination address as an EID and performs an EID-to-RLOC mapping 313 lookup. The router then prepends an "outer" IP header with one of its 314 globally routable RLOCs in the source address field and the result of 315 the mapping lookup in the destination address field. 317 An ETR is a router that accepts an IP packet where the destination 318 address in the "outer" IP header is one of its own RLOCs. The router 319 strips the "outer" header and forwards the packet based on the next 320 IP header found. In general, an ETR receives LISP-encapsulated IP 321 packets from the Internet on one side and sends decapsulated IP 322 packets to site end-systems on the other side. ETR functionality does 323 not have to be limited to a router device. A server host can be the 324 endpoint of a LISP tunnel as well. 326 A mobile device can use the LISP infrastructure to achieve mobility 327 by implementing the LISP encapsulation and decapsulation functions 328 and acting as a simple ITR/ETR. By doing this, such a "LISP mobile 329 node" can use topologically independent EID IP addresses that are not 330 advertised into and do not impose a cost on the global routing 331 system. These EIDs are maintained at the edges of the mapping system 332 (in LISP Map-Servers and Map-Resolvers) and are provided on demand to 333 only the correspondents of the LISP mobile node. 335 It requires a index system that stores the mappings between EIDs and 336 RLOCs. The index system may be and usually is large-scale 337 distributed, such as Locator/ID Separation Protocol Alternative 338 Logical Topology [RFC6836], and constitutes the new infrastructure 339 that supports LISP. 341 2.2. Tunneling 343 2.2.1. Mobile IPv6 345 Mobility Support in IPv6, known as Mobile IPv6 or MIPv6, is a 346 protocol that allows nodes to remain reachable while moving around in 347 the IPv6 Internet. It allows a mobile node to move from one link to 348 another without changing the mobile node's "home address". Packets 349 may be routed to the mobile node using this address regardless of the 350 mobile node's current point of attachment to the Internet. The 351 mobile node may also continue to communicate with other nodes 352 (stationary or mobile) after moving to a new link. The movement of a 353 mobile node away from its home link is thus transparent to transport 354 and higher-layer protocols and applications. 356 In IPv4 mobility [RFC5944], when an endpoint is away from home, 357 packets to it are encapsulated and forwarded via a home agent that 358 resides in the home area the endpoint's address belongs to. The home 359 agent will encapsulate and forward packets either directly to the 360 endpoint or to a foreign agent that resides where the endpoint has 361 moved to. Packets from the endpoint may be sent directly to the 362 correspondent node, may be sent via the foreign agent, or may be 363 reverse-tunneled back to the home agent for delivery to the mobile 364 node. 366 Mobile IPv6 allows nodes to move within the Internet topology while 367 maintaining reachability and ongoing connections between mobile and 368 correspondent nodes as well. To do this, a mobile node sends binding 369 updates (BUs) to its home agent (HA) every time it moves. 371 The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both 372 from the experiences gained from the development of Mobile IP support 373 in IPv4 (Mobile IPv4), and from the opportunities provided by IPv6. 374 Mobile IPv6 thus shares many features with Mobile IPv4, but is 375 integrated into IPv6 and offers many other improvements. The major 376 differences between Mobile IPv4 and Mobile IPv6 is summarized as: 378 o There is no need to deploy special routers as "foreign agents", as 379 in Mobile IPv4. Mobile IPv6 operates in any location without any 380 special support required from the local router. 382 o Support for route optimization is a fundamental part of the 383 protocol, rather than a nonstandard set of extensions. 385 o Mobile IPv6 route optimization can operate securely even without 386 pre-arranged security associations. It is expected that route 387 optimization can be deployed on a global scale between all mobile 388 nodes and correspondent nodes. 390 o Support is also integrated into Mobile IPv6 for allowing route 391 optimization to coexist efficiently with routers that perform 392 "ingress filtering". 394 o The IPv6 Neighbor Unreachability Detection ensures symmetric 395 reachability between the mobile node and its default router in the 396 current location. 398 o Most packets sent to a mobile node while away from home in Mobile 399 IPv6 are sent using an IPv6 routing header rather than IP 400 encapsulation, reducing the amount of resulting overhead compared 401 to Mobile IPv4. 403 o Mobile IPv6 is decoupled from any particular link layer, as it 404 uses IPv6 Neighbor Discovery [RFC4861] instead of the Address 405 Resolution Protocol (ARP). This also improves the robustness of 406 the protocol. 408 o The use of IPv6 encapsulation (and the routing header) removes the 409 need in Mobile IPv6 to manage "tunnel soft state". 411 o The dynamic home agent address discovery mechanism in Mobile IPv6 412 returns a single reply to the mobile node. The directed broadcast 413 approach used in IPv4 returns separate replies from each home 414 agent. 416 2.2.2. Proxy Mobile IPv6 418 It is possible to support mobility for IPv6 nodes without host 419 involvement by extending Mobile IPv6 signaling messages between a 420 network node and a home agent. This approach to supporting mobility 421 does not require the mobile node to be involved in the exchange of 422 signaling messages between itself and the home agent. A proxy 423 mobility agent in the network performs the signaling with the home 424 agent and does the mobility management on behalf of the mobile node 425 attached to the network. Because of the use and extension of Mobile 426 IPv6 signaling and home agent functionality, this protocol is 427 referred to as Proxy Mobile IPv6 (PMIPv6). 429 The Mobile Access Gateway (MAG) is such a proxy function on an access 430 router. MAG manages the mobility-related signaling for a mobile node 431 that is attached to its access link. It is responsible for tracking 432 the mobile node's movements to and from the access link and for 433 signaling the mobile node's local mobility anchor. 435 IP mobility for nodes that have mobile IP client functionality in the 436 IPv6 stack as well as those nodes that do not, would be supported by 437 enabling Proxy Mobile IPv6 protocol functionality in the network. 438 The advantages of developing a network-based mobility protocol based 439 on Mobile IPv6 are: 441 o Reuse of home agent functionality and the messages/format used in 442 mobility signaling. Mobile IPv6 is a mature protocol with several 443 implementations that have undergone interoperability testing. 445 o A common home agent would serve as the mobility agent for all 446 types of IPv6 nodes. 448 2.2.3. Hierarchical Mobile IPv6 450 Hierarchical Mobile IPv6 (HMIPv6) mobility management specification 451 [RFC5380] introduces the concept of a hierarchical Mobile IPv6 452 network, utilising a new node called the Mobility Anchor Point (MAP). 454 MAP can be located at any level in a hierarchical network of routers, 455 including the Access Router (AR). The MAP will limit the amount of 456 Mobile IPv6 signaling outside the local domain. 458 The introduction of the MAP provides a solution that has these 459 benefits: 461 o The mobile node sends binding updates to the local MAP rather than 462 the home agent (HA) (which is typically further away) and 463 correspondent nodes (CNs). It mitigates delays caused by MIPv6 464 signaling. 466 o Only one binding update message needs to be transmitted by the 467 mobile node (MN) before traffic from the HA and all CNs is re- 468 routed to its new location. This is independent of the number of 469 CNs with which the MN is communicating. It mitigates the tunneling 470 burden on the home agent and alleviates the scalability problem. 472 A MAP is essentially a local home agent. The aim of introducing the 473 hierarchical mobility management model in Mobile IPv6 is to enhance 474 the performance of Mobile IPv6 while minimising the impact on Mobile 475 IPv6 or other IPv6 protocols. 477 It is pertinent to note that the use of the MAP does not rely on, or 478 assume the presence of, a permanent home agent. In other words, a 479 mobile node need not have a permanent home address or home agent in 480 order to be HMIPv6-aware or use the features of HMIPv6. A MAP may be 481 used by a mobile node in a nomadic manner to achieve mobility 482 management within a local domain. 484 2.2.4. Network Mobility (NEMO) Basic Support Protocol 486 Network Mobility (NEMO) Basic Support Protocol is protocol extensions 487 to Mobile IPv6 (MIPv6) to enable support for network mobility. The 488 extensions are backward compatible with Mobile IPv6. In particular, 489 a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent. 491 The NEMO Basic Support ensures session continuity for all the nodes 492 in the Mobile Network, even as the Mobile Router changes its point of 493 attachment to the Internet. It also provides connectivity and 494 reachability for all nodes in the Mobile Network as it moves. The 495 solution supports both mobile nodes and hosts that do not support 496 mobility in the Mobile Network. 498 The solution proposes a bi-directional tunnel between the Mobile 499 Router and its Home Agent. This tunnel is set up when the Mobile 500 Router sends a successful Binding Update to its Home Agent, informing 501 the Home Agent of its current point of attachment. All traffic 502 between the nodes in the Mobile Network and Correspondent Nodes 503 passes through the Home Agent. 505 The solution described here does not place any restriction on the 506 number of levels for nested mobility. But note that nested mobility 507 might introduce significant overhead on the data packets as each 508 level of nesting introduces another IPv6 header encapsulation. 510 Multihoming for Mobile Routers was not discussed in NEMO Basic 511 Support. 513 2.3. MinimalT 515 Minimal Latency Tunneling [MinimaLT] is a network protocol that 516 provides ubiquitous encryption for maximal confidentiality, including 517 protecting packet headers. MinimaLT provides server and user 518 authentication, extensive Denial-of-Service protections, and IP 519 mobility while approaching perfect forward secrecy. 521 A MinimaLT tunnel is a point-to-point entity that encapsulates the 522 set of connections between two hosts. MinimaLT creates a tunnel on 523 demand in response to the first packet received from a host or a 524 local application's outgoing connection request. Tunnels provide 525 server authentication, encryption, congestion control, and 526 reliability. 528 A MinimaLT tunnel contains a set of connections, that is, a single 529 tunnel between two hosts encapsulates an arbitrary number of 530 connections. Each connection is user-authenticated and provides two- 531 way communication between a client application and service. 533 MinimaLT identifies tunnels by their TID, the TID is pseudorandomly 534 generated by the initiator. A tunnel's IP and UDP port can change 535 without affecting communication. After changing its IP address or UDP 536 port, a host simply assumes the next TID as with a rekey. The other 537 host will recognize the new TID and will transition the tunnel to the 538 new key, IP address, and UDP port. 540 Central to the protocol is the MinimaLT directory service. The 541 directory service resolves queries for (server) hostname information. 542 It provides the server's directory certificate, signed by the 543 server's long-term key. This returned certificate contains the 544 server's IP address, UDP port, long-term key, zero padding (the 545 minimum payload size of the initial packet), and a server ephemeral 546 key. 548 As MinimalT requires new directory service provided by the network 549 infrastructure it is classified as infrastructure-dependent. 551 2.4. DMM 552 Requirements for DMM reveals that the background behind the interest 553 in studying DMM is primarily as follows. 555 (1) More than ever, mobile users are consuming Internet content, 556 including that of local Content Delivery Networks (CDNs). Such 557 traffic imposes new requirements on mobile core networks for 558 data traffic delivery. 560 Both traffic offloading and CDN mechanisms could benefit from 561 the development of mobile architectures with fewer hierarchical 562 levels introduced into the data path by the mobility management 563 system. This trend of "flattening" the mobile networks works 564 best for direct communications among peers in the same 565 geographical area. Distributed mobility management in the 566 flattening mobile networks would anchor the traffic closer to 567 the point of attachment of the user. 569 (2) Today's mobile networks present service providers with new 570 challenges. Mobility patterns indicate that mobile nodes often 571 remain attached to the same point of attachment for considerable 572 periods of time [LOCATING-USER]. Specific IP mobility 573 management support is not required for applications that launch 574 and complete their sessions while the mobile node is connected 575 to the same point of attachment. However, IP mobility support 576 is currently designed for always-on operation, maintaining all 577 parameters of the context for each mobile subscriber for as long 578 as they are connected to the network. This can result in a 579 waste of resources and unnecessary costs for the service 580 provider. Infrequent node mobility coupled with application 581 intelligence suggest that mobility support could be provided 582 selectively, thus reducing the amount of context maintained in 583 the network. 585 In centralized mobility management such as MIPv6, PMIPv6 or HMIPv6, 586 the location information in terms of a mapping between the session 587 identifier and the forwarding address is kept at a single mobility 588 anchor, and packets destined to the session identifier are forwarded 589 via this anchor. In other words, such mobility management systems 590 are centralized in both the control plane and the data plane (mobile 591 node IP traffic). 593 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 594 are the following: 596 1. Anchoring Function (AF): allocation to a mobile node of an IP 597 address, i.e., Home Address (HoA), or prefix, i.e., Home Network 598 Prefix (HNP), topologically anchored by the advertising node. 600 That is, the anchor node is able to advertise a connected route 601 into the routing infrastructure for the allocated IP prefixes. 602 This function is a control-plane function. 604 2. Internetwork Location Management (LM) function: managing and 605 keeping track of the internetwork location of an MN. It is a 606 control-plane function. 608 The location information may be a binding of the advertised IP 609 address/prefix, e.g., HoA or HNP, to the IP routing address of 610 the MN, or it may be a binding of a node that can forward packets 611 destined to the MN. 613 In a client-server protocol model, location query and update 614 messages may be exchanged between a Location Management client 615 (LMc) and a Location Management server (LMs). 617 3. Forwarding Management (FM) function: packet interception and 618 forwarding to/from the IP address/prefix assigned to the MN, 619 based on the internetwork location information, either to the 620 destination or to some other network element that knows how to 621 forward the packets to their destination. 623 FM may optionally be split into the control plane (FM-CP) and 624 data plane (FM-DP). 626 In Mobile IPv6, the home agent (HA) typically provides the AF; the 627 LMs is at the HA, whereas the LMc is at the MN; the FM function is 628 distributed between the ends of the tunnel at the HA and the MN. 630 In Proxy Mobile IPv6, the local mobility anchor (LMA) provides the 631 AF; the LMs is at the LMA, whereas the LMc is at the MAG; the FM 632 function is distributed between the ends of the tunnel at the LMA and 633 the MAG. 635 In HMIPv6, the Mobility Anchor Point (MAP) serves as a location 636 information aggregator between the LMs at the HA and the LMc at the 637 MN. The MAP also provides the FM function to enable tunneling 638 between HA and itself, as well as tunneling between the MN and 639 itself. 641 Requirements for Distributed Mobility Management [RFC7333] states 642 that distributed mobility management (DMM) is an alternative to the 643 centralized deployment of the location information. 645 While DMM does add scalability to mobile management tremendously it 646 requires substantial infrastructure enhancement to be effective. 648 3. Survey of Infrastructure-Independent Mobility Support 650 3.1. IKEv2 Mobility and Multihoming Protocol 652 IKEv2 [RFC7296] is used for performing mutual authentication, as well 653 as establishing and maintaining IPsec Security Associations (SAs). 654 In the base IKEv2 protocol, the IKE SAs and tunnel mode IPsec SAs are 655 created implicitly between the IP addresses that are used when the 656 IKE_SA is established. These IP addresses are then used as the outer 657 (tunnel header) addresses for tunnel mode IPsec packets. 659 There are scenarios where these IP addresses might change. One 660 example is mobility: a host changes its point of network attachment 661 and receives a new IP address. Another example is a multihoming host 662 that would like to change to a different interface if, for instance, 663 the currently used interface stops working for some reason. 665 The MOBIKE protocol provides a mechanism for updating the IP 666 addresses of existing IKE and IPsec SAs is needed. 668 MOBIKE allows both parties to have several addresses, and there are 669 up to N*M pairs of IP addresses that could potentially be used. The 670 party that initiated the IKE_SA is responsible for deciding which 671 address pair is used for the IPsec SAs and for collecting the 672 information it needs to make this decision (such as determining which 673 address pairs work or do not work). The other party simply tells the 674 initiator what addresses it has, but does not update the IPsec SAs 675 until it receives a message from the initiator to do so. This 676 approach applies to the addresses in the IPsec SAs; in the IKE_SA 677 case, the exchange initiator can decide which addresses are used. 679 In MOBIKE, the initiator decides what addresses are used in the IPsec 680 SAs. That is, the responder does not normally update any IPsec SAs 681 without receiving an explicit UPDATE_SA_ADDRESSES request from the 682 initiator. The responder can, however, update the IKE_SA in some 683 circumstances. 685 Assumes that the initiator has already decided what the new addresses 686 should be. When this decision has been made, the initiator: 688 o Updates the IKE_SA with the new addresses, and sets the 689 "pending_update" flag in the IKE_SA. 691 o Updates the IPsec SAs associated with this IKE_SA with the new 692 addresses (unless the initiator's policy requires a return 693 routability check before updating the IPsec SAs, and the check has 694 not been done for this responder address yet). 696 o If the IPsec SAs were updated in the previous step: If NAT 697 Traversal is not enabled, and the responder supports NAT 698 Traversal, and the initiator either suspects or knows that a NAT 699 is likely to be present, enables NAT Traversal. 701 o If there are outstanding IKEv2 requests (requests for which the 702 initiator has not yet received a reply), continues retransmitting 703 them using the addresses in the IKE_SA (the new addresses). 705 o When the window size allows, sends an INFORMATIONAL request 706 containing the UPDATE_SA_ADDRESSES notification (which does not 707 contain any data), and clears the "pending_update" flag. 709 o If a new address change occurs while waiting for the response, 710 starts again from the first step (and ignores responses to this 711 UPDATE_SA_ADDRESSES request). 713 When processing an INFORMATIONAL request containing the 714 UPDATE_SA_ADDRESSES notification, the responder: 716 o Determines whether it has already received a newer 717 UPDATE_SA_ADDRESSES request than this one. If it has, a normal 718 response message is sent, but no other action is taken. 720 o Checks that the (source IP address, destination IP address) pair 721 in the IP header is acceptable according to local policy. If it 722 is not, replies with a message containing the 723 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 725 o Updates the IP addresses in the IKE_SA with the values from the IP 726 header. 728 o Replies with an INFORMATIONAL response. 730 o If necessary, initiates a return routability check for the new 731 initiator address and waits until the check is completed. 733 o Updates the IPsec SAs associated with this IKE_SA with the new 734 addresses. 736 o If NAT Traversal is supported and NAT detection payloads were 737 included, enables or disables NAT Traversal. 739 When the initiator receives the reply: 741 o If an address change has occurred after the request was firs 742 sent, no MOBIKE processing is done for the reply message because a 743 new UPDATE_SA_ADDRESSES is going to be sent (or has already been 744 sent, if window size greater than one is in use). 746 o If the response contains an UNACCEPTABLE_ADDRESSES notification, 747 the initiator MAY select another addresses and retry the exchange, 748 keep on using the previously used addresses, or disconnect. 750 o It updates the IPsec SAs associated with this IKE_SA with the new 751 addresses (unless this was already done earlier before sending the 752 request; this is the case when no return routability check was 753 required). 755 o If NAT Traversal is supported and NAT detection payloads were 756 included, the initiator enables or disables NAT Traversal. 758 3.2. Mobile SCTP 760 A local host may have multiple points of attachment to the Internet, 761 giving it a degree of fault tolerance from hardware failures. Stream 762 Control Transmission Protocol was developed to take full advantage of 763 such a multi-homed host to provide a fast failover and association 764 survivability in the face of such hardware failures. However, many 765 modern computers allow for the dynamic addition and deletion of 766 network cards (sometimes termed a hot-pluggable interface). 767 Complicate this with the ability of a provider, in IPv6, to 768 dynamically renumber a network, and there still is a gap between 769 full-fault tolerance and the currently defined SCTP protocol. No 770 matter if a card is added or an interface is renumbered, in order to 771 take advantage of this new configuration, the transport association 772 must be restarted. For many fault-tolerant applications this restart 773 is considered an outage and is undesirable. 775 Stream Control Transmission Protocol (SCTP) Dynamic Address 776 Reconfiguration [RFC4960] [RFC5061] is an extension to SCTP to 777 attempt to correct this problem for the more demanding fault-tolerant 778 application. This extension will allow an SCTP stack to: 780 o Dynamically add an IP address to an association. 782 o Dynamically delete an IP address from an association. 784 o Request to set the primary address the peer will use when sending 785 to an endpoint. 787 The dynamic addition and subtraction of IP addresses allows an SCTP 788 association to continue to function through host and network 789 reconfigurations. These changes, brought on by provider or user 790 action, may mean that the peer would be better served by using the 791 newly added address; however, this information may only be known by] 792 the endpoint that had the reconfiguration occur. In such a case this 793 extension allows the local endpoint to advise the peer as to what it 794 thinks is the better primary address that the peer should be using. 796 One last thing this extension adds is a small, 32-bit integer called 797 an adaptation indication that can be exchanged at startup. This is 798 useful for applications where there are one or more specific layers 799 below the application, yet still above SCTP. In such a case, the 800 exchange of this indication can allow the proper layer to be enabled 801 below the application. 803 3.3. Multipath TCP 805 Seamless TCP mobility using lightweight MPTCP proxy [HAMPEL] utilizes 806 Multipath TCP (MPTCP) to implement a TCP mobility solution. However, 807 Analysis of Residual Threats and Possible Fixes for Multipath TCP 808 found some security issues such as ADD_ADDR attack. Hence inherent 809 security of MPTCP is rather doubtful. 811 3.4. REST Architecture Style 813 REST stands for "Representational State Transfer" [RESTful]. The name 814 is intended to evoke an image of how a well-designed Web application 815 behaves: a network of Web pages forms a virtual state machine, 816 allowing a user to progress through the application by selecting a 817 link or submitting a short data-entry form, with each action 818 resulting in a transition to the next state of the application by 819 transferring a representation of that state to the user. 821 The REST architectural style consists of a set of architectural 822 constraints chosen for the properties they induce on candidate 823 architectures. For purpose of discussing mobility support we note 824 that the first constraints added to the hybrid style are those of the 825 client-server architectural style (CS). Separation of concerns is the 826 principle behind the client-server constraints. CS style is closely 827 followed by the client-stateless-server (CSS) style, such that each 828 request from client to server must contain all of the information 829 necessary to understand the request, and cannot take advantage of any 830 stored context on the server. Session state is therefore kept 831 entirely on the client. Communication must be stateless in nature. 833 It is observable that REST architecture style, or RESTful pattern 834 provides some degree of mobility support at the application layer. 836 There are abundant Web applications that rely on HTTP which are built 837 upon RESTful pattern. The Hypertext Transfer Protocol (HTTP) 838 [RFC1945] [RFC7230] [RFC7540] is a request/response protocol. A 839 client sends a request containing request headers that specify the 840 request method, URI, HTTP version, information about the client, some 841 additional information about the request, and optional application 842 data. The server responds with a status or error code followed by a 843 message containing information about the server and information about 844 the data. This may include a message body. 846 The browser that accesses the Web application built upon RESTful 847 pattern may change its transport layer address freely, not to mention 848 IP address, provided that each request from the browser contains all 849 of the information necessary to understand the request and the 850 browser can resolve the latest address of the server, as the 851 communication is stateless in nature if it obeys RESTful pattern. 852 Thus we conclude that REST architecture style inherently provides 853 mobility support. 855 4. A Solution at the Origin of the Problem 857 4.1. Separation of Identity and Locator at Transport Layer 859 Why we design a new transport protocol to solve the routing 860 scalability problem while provide mobility and multihoming support? 861 Because it is the dominating transport layer protocols, TCP and UDP 862 that take use of the IP address to identifying the end node, 863 introduce the controversial role of IP address both as the identifier 864 and as the routing locator. 866 FSP is meant to be transport layer protocol that keeps the IP address 867 as the routing locator but keeps it from being the key constituent of 868 the FSP identifier or any upper layer protocol built upon FSP. It is 869 a solution to avoid, if not to extirpate, the routing scalability 870 problem. 872 4.2. Adding Programmer-Friendly Session Semantics 874 It is hard to achieve the goal of making a new transport protocol 875 accepted by the programmers. The service provided by the transport 876 protocol should have some 'killer' features. FSP assumes that session 877 semantics is such a feature. 879 Here we define a session is a bundle of connections or streams that 880 share the same authentication and authorization context. 882 4.2.1. Intuitiveness 884 This concept is inspired by HTTP persistent connection. The 885 persistent connections of HTTP 1.1 [RFC7230] and HTTP 2.0 [RFC7540] 886 allow multiple request/response transactions (streams) during the 887 lifetime of a single HTTP connection. This reduces overhead during 888 connection establishment and mitigates transport-layer slow-start 889 that would have otherwise been incurred for each transaction. HTTP 890 2.0 connections can multiplex many request/response pairs in parallel 891 on a single transport connection. Both are important to reduce 892 latency for HTTP's primary use case. 894 These multiple request/response pairs, or streams in parallel, 895 constitute a session. Usually they share the same authentication and 896 authorization context. From a programmer's point of view they 897 constitute a session. 899 It is much more intuitive (and more efficient) than to save the user 900 authentication and authorization state in some representation form at 901 the client side and transfer the state in representation form along 902 with each request to the server side for authorization purpose. 904 4.2.2. Really Parallel Streams 906 There is head-of-line congestion in HTTP persistent connection. Such 907 head-of-line congestion is anti-intuitive and should be avoided. 908 Connection Multiplication mechanism is meant to solve such head-of- 909 line congestion problem. Connection multiplication makes a branch 910 connection reuse the security context of the master connection and 911 makes the new connection established in zero round trip. 913 As per [RFC8108] an endpoint may send multiple RTP streams in a 914 single RTP session. FSP is meant to cover such requirement as well. 916 4.2.3. Mixed Traffic Class 918 A real world application may consist mixed traffic classes of 919 streams, for example one control stream which does not tolerate 920 packet loss, and a bundle of streams that carry payloads favoring 921 low-latency while tolerating packet loss. All these streams belong to 922 the same session in the sense of same user authentication and 923 authorization context. 925 4.2.4. Session Adjournment and Resumption 927 It is not uncommon for an application to exploit TCP as the transport 928 protocol, and as TCP transmits the application data as an unbroken 929 stream of octets it is at the application layer to delimiter the 930 messages that are sent continually. 932 It would be convenient if the application data could still be sent in 933 stream mode and the transport service provides the 'commit' 934 programming interface, through which the application can explicitly 935 set the transmission check point where further sending of data is 936 prohibited until all of the data sent have been acknowledged at the 937 transport layer. 939 It is considered a weak, asymmetric, yet essential requirement for 940 session adjournment and resumption. FSP provides Transmit Transaction 941 mechanism to fulfill such requirement. 943 4.3. Adding Programmer-friendly Security Service 945 4.3.1. Ubiquitous Encryption and Authentication of Data 947 As revealed in "Datagram Transport Layer Security" (DTLS) [RFC6347] 948 even client/server applications that takes use of UDP needs to 949 communicate in a way that manages to prevent eavesdropping, 950 tampering, or message forgery. Transport layer protocol should 951 provide inherent support for ubiquitous encryption and/or 952 authentication of data. 954 4.3.2. Key Establishment versus Application of Keys 956 IPsec architecture [RFC4301] clearly separates the sub-protocol for 957 key establishment through Internet Key Exchange (IKE) [RFC7296], and 958 the sub-protocol for applying the established key through the 959 Authentication Header (AH) [RFC4302] and Encapsulating Security 960 Payload (ESP) [RFC4303]. 962 However, as the mechanism of security association (SA) is stateful it 963 is not convenient to solve the problems at the IP layer which should 964 better be stateless for sake of scalability. 966 Besides, as the IP layer services are often implemented in the kernel 967 of the operating systems the extensibility is limited, but various 968 classes of applications often require variable key establishment 969 process that could be directly managed by the end-node application. 971 It would be convenient if the key established at the application 972 layer could be applied at the transport layer to encrypt the payload 973 with authentication. 975 5. Choices of Design Goals 977 5.1. Featured Scenarios 979 5.1.1. Goal: Support for Mobile Computing 981 As stated in 'Report from the IAB Workshop on Routing and 982 Addressing', September 2007 [RFC4984], 'The workshop participants 983 recognized that the increase in the number of mobile devices can be 984 significant, and that if a scalable routing system supporting generic 985 identity-locator separation were developed and introduced, billions 986 of mobile gadgets could be supported without bringing undue impact on 987 global routing scalability and stability'. 989 FSP can be implemented in the user-space of the operating systems. It 990 is technically feasible to deploy FSP-dependent applications as the 991 Software-as-a-Service [SaaS] on the public cloud computing platform 992 and distribute the FSP-enabled client applications that act as the 993 agents of the SaaS platform through some online application store to 994 serve more than ever mobile users. It has high probability of earning 995 economical benefit to deploy such solution because FSP consume 996 considerably less computing resource than TLS [RFC8446] over TCP or 997 DTLS over UDP. 999 Unlike the help desks of the enterprise networks the public cloud 1000 service providers and the wireless communication service providers 1001 can be much more tolerant with the new transport protocol. 1003 5.1.2. Goal: Adaptable to Specific-Purpose Networks 1005 Here specific-purpose networks mean those networks that dedicatedly 1006 serve for some special purpose, such as Storage Area Network (SAN) at 1007 which Internet Small Computer Systems Interface (iSCSI) [RFC7143] is 1008 targeted. 1010 Such specific-purpose networks often favor high performance over 1011 privacy. It may find it is overkill to utilize FSP. However in such 1012 scenario the weak integrity protection mode that utilize CRC64 1013 [CRC64] may be exploited, where CRC64 calculation may be implemented 1014 in commoditized hardware. High-performance software implementation 1015 exists as well. 1017 And it should be feasible to realize FSP directly over layer 2 1018 jumbogram packet switch network in some specific-purpose network such 1019 as at the data center of the cloud service provider. 1021 It should be feasibility to exploit hardware acceleration for FSP in 1022 the specific-purpose networks. 1024 5.1.3. Non-Goal: General Multicast Transport 1026 Although there is some trace of supporting 'duplicate-cast' which 1027 means sending to two, at most three receivers in design of FSP, 1028 Duplication-cast Extensibility is yet to be studied. General 1029 multicast support is simply non-goal. 1031 5.2. Optimizing towards IPv6 1033 5.2.1. Goal: Promoting Transition towards IPv6 1035 FSP is intent on promoting IPv6 for sake of transparent end-to-end 1036 connectivity. 1038 5.2.2. Goal: NAT friendliness in IPv4 network 1040 Network Address Translation and Port Translation (NAPT) [RFC2663] 1041 works well for conserving global addresses and addressing multihoming 1042 requirements because an IPv4 NAPT router implements three functions: 1043 source address selection, next-hop resolution, and (optionally) DNS 1044 resolution. It is mandatory for FSP to keep NAT-friendliness in the 1045 IPv4 internetwork because NAT middleboxes are ubiquitous. 1047 5.2.3. Non-Goal: NAT friendliness in IPv6 network 1048 It is both feasible and preferable to avoid NAT in the IPv6 1049 internetwork for sake of transparent end-to-end connectivity. 1051 5.3. Congestion Control 1053 5.3.1. Goal: ECN Awareness 1055 The Benefits of Using Explicit Congestion Notification (ECN) 1056 [RFC8087] outlines the principal gains in terms of increased 1057 throughput, reduced delay, and other benefits when ECN is used over a 1058 network path that includes equipment that supports Congestion 1059 Experienced (CE) marking. 1061 FSP should take advantages of ECN [RFC3168]. 1063 5.3.2. Goal: Host-Aggregated Congestion Control 1065 We argue that congestion control should be end-to-end at the network 1066 layer instead of transport layer. All traffic between two network 1067 nodes shall be subjected aggregately to the congestion control. 1069 5.3.3. Goal: Congestion Control Per Traffic Class 1071 As it is a designed feature for FSP to carry mixed traffic class in 1072 one session, but there is no single congestion control mechanism will 1073 work for all traffic classes, it would be convenient that different 1074 traffic class is treated with different congestion control mechanism. 1076 5.3.4. Non-Goal: TCP Friendliness 1078 It is observable that traffics such as multi-thread downloading or 1079 video-streaming over RTP [RFC3550] that managed to avoid TCP 1080 congestion control are overwhelmingly increasing. It would be too 1081 conservative to keep up with such application trends to obey with 1082 TCP-friendliness. 1084 5.4. Infrastructure Independency 1086 FSP does not introduce any new namespace, nor does it depend on new 1087 network infrastructure. However it does make some assumption about 1088 the network layer infrastructure. 1090 5.4.1. Goal: More Efficient Use of the IPv6 Address Space 1092 The length of an IPv6 address is 128 bits. Practices of IPv6 NAPT 1093 show that address space of 48 bits is sufficient. There could be 1094 optimization space for more efficient use of the IPv6 address space. 1096 o Every IPv6 network node is effectively a router 1098 And it could be argued that this opinion is implicitly supported by 1099 "Unique IPv6 Prefix per Host" [RFC8273]. 1101 o The upper layer application is the ultimate IPv6 end-point 1103 Again, it could be argued that this opinion is implicitly supported 1104 by "Unique IPv6 Prefix per Host". 1106 5.4.2. Goal: ECN Awareness 1108 FSP should take advantages of ECN, which is a network infrastructure 1109 mechanism. 1111 5.4.3. Goal: AQM Awareness 1113 Characterization Guidelines for Active Queue Management (AQM) 1114 [RFC7928] describes various criteria for performing characterizations 1115 of AQM schemes that can be used in lab testing during development, 1116 prior to deployment. 1118 FSP should be designed in a way that is aware of AQM on dealing with 1119 mixed traffic class. 1121 5.4.4. Non-Goal: Adaptable to New Rendezvous Mechanism 1123 FSP should take advantages of Dynamic DNS [RFC2136] to provide 1124 rendezvous mechanism in case that the two participants change their 1125 IP addresses simultaneously. It does not intent to re-invent the 1126 wheel. 1128 5.5. Feasibility of Hardware Acceleration 1130 FSP exploits AES-GCM [AES][GCM], liking in The Use of Galois/Counter 1131 Mode (GCM) in IPsec Encapsulating Security Payload (ESP) [RFC4106] 1132 because hardware implementation efficiency is one goal of selecting 1133 the AES algorithm and GCM mode. 1135 FSP chooses to design fixed-size header for normal packet that is 1136 alike Reduced Instruction Set Computer (RISC) instructions that are 1137 easier to process in hardware. 1139 FSP chooses to separate headers and payload instantly with the design 1140 of the "header stack" instead of conventional type-length-value 1141 header list for sake of implementing single host approaches mentioned 1142 in Remote Direct Memory Access (RDMA) over IP Problem Statement 1143 [RFC4297]. 1145 5.6. QoS and Multipath Issues 1147 5.6.1. Goal: Minimal Delay Service for Milk Like Payload 1149 An ordinary data flow is wine-like in the sense that the older data 1150 are more valuable. If it has to, data packet sent latest are dropped 1151 first. In the contrary, milk-like payload is that the newer data are 1152 more precious and outdated data packet can be discarded. 1154 FSP is designed to support mixed traffic class that providing service 1155 both for wine-like payload and milk-like payload. 1157 5.6.2. To be studied: Resource Reservation 1159 End-to-End resource reservation protocol packets MAY be piggybacked 1160 on the preliminary FSP packets that are exchanged in the connection 1161 establishment process to provide determinant quality of service. 1162 However as resource reservation [RFC2205] requires that the network 1163 layer nodes along the path the protocol packets have passed to keep 1164 some state, the scalability is questionable. 1166 Nevertheless as resource reservation may assure highest quality of 1167 service FSP may be resource reservation aware in the future, maybe 1168 for specific purpose network only. 1170 5.6.3. Non-Goal: PMTU discovery 1172 For sake of maximizing mobility and multi-path support it is not 1173 required to implement Packetization Layer Path MTU Discovery 1174 [RFC4821] for FSP. 1176 5.7. On-the-wire Compression 1178 Because lots of content is compressible and compression saves 1179 bandwidth, it is proposed that FSP shall support on-the-wire 1180 compression. 1182 LZ4 algorithm is chosen for it "features extremely fast decoder" 1183 [LZ4]. Few well-known loss-less compression algorithm has higher 1184 performance than LZ4 (in according to [LZTURBO]) in terms of 1185 decompression speed. The apparent one exception, LzTurbo, has not yet 1186 open-sourced. 1188 Besides, LZ4 offers a high compression derivative called LZ4_HC that 1189 shares the same "extremely fast decoder" with the default compressor. 1190 It is possible to pre-compress some content with LZ4_HC and serve it 1191 to mass client, while each client decodes and gets the original 1192 content with on-the-wire speed. 1194 On-the-wire compression service SHOULD be provided in the user space 1195 for sake of system robustness. 1197 6. Security Considerations 1199 FSP MUST provide mechanism to fight against connection hi-jack 1200 attack. 1202 7. IANA Considerations 1204 This document has no actions for IANA. 1206 8. References 1208 8.1. Normative References 1210 [MinimaLT] W. Michael Petullo, Xu Zhang, Jon A. Solworth, Daniel J. 1211 Bernstein, Tanja Lange. MinimaLT: Minimal-latency 1212 networking through better security, October 2013, 1213 1215 [RESTful] Fielding R. T. and R. N. Taylor, "Principled Design of the 1216 Modern Web Architecture", International Conference on 1217 Software Engineering, 2000: 407-416. 1219 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1220 RFC 793, DOI 10.17487/RFC0793, September 1981, 1221 . 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, DOI 1225 10.17487/RFC2119, March 1997, . 1228 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1229 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1230 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1231 . 1233 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1234 Translator (NAT) Terminology and Considerations", 1235 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1236 . 1238 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1239 Jacobson, "RTP: A Transport Protocol for Real-Time 1240 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1241 July 2003, . 1243 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1244 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1245 RFC 3963, DOI 10.17487/RFC3963, January 2005, 1246 . 1248 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1249 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1250 December 2005, . 1252 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1253 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 1254 2006, . 1256 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1257 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1258 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1259 . 1261 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1262 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1263 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 1264 . 1266 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1267 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1268 2011, . 1270 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1271 Protocol (ILNP) Architectural Description", RFC 6740, DOI 1272 10.17487/RFC6740, November 2012, . 1275 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1276 "TCP Extensions for Multipath Operation with Multiple 1277 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1278 . 1280 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1281 Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 1282 10.17487/RFC6830, January 2013, . 1285 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 1286 and D. Wing, "IPv6 Multihoming without Network Address 1287 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 1288 . 1290 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1291 Kivinen, "Internet Key Exchange Protocol Version 2 1292 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1293 2014, . 1295 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1296 Korhonen, "Requirements for Distributed Mobility 1297 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1298 . 1300 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1301 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 1302 October 2016, . 1304 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1305 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1306 10.17487/RFC8087, March 2017, . 1309 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1310 Writing an IANA Considerations Section in RFCs", BCP 26, 1311 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1312 . 1314 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1315 (IPv6) Specification", STD 86, RFC 8200, DOI 1316 10.17487/RFC8200, July 2017, . 1319 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1320 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1321 . 1323 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1324 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1325 . 1327 8.2. Informative References 1329 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 1330 1332 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 1333 Cartridges - DLT1 Format Standard, Annex B", ECMA-182, 1334 December 1992. 1336 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 1337 Galois/Counter Mode (GCM) and GMAC", November 2007. 1338 1340 [HAMPEL] Hampel, G., Rana, A., and T. Klein, "Seamless TCP mobility 1341 using lightweight MPTCP proxy", MobiWac '13: Proceedings 1342 of the 11th ACM international symposium on Mobility 1343 management and wireless access, DOI 1344 10.1145/2508222.2508226, November 2013. 1346 [LOCATING-USER] 1347 Kirby, G., "Locating the User", Communications 1348 International, 1995. 1350 [LZ4] https://lz4.github.io/lz4/ 1352 [LZTURBO] https://github.com/powturbo/TurboBench 1354 [SaaS] Peter, M. and G. Tim, "The NIST Definition of Cloud 1355 Computing", SP 800-145, September 2011, 1356 1358 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1359 Destinations", RFC 1498, DOI 10.17487/RFC1498, August 1360 1993, . 1362 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 1363 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 1364 10.17487/RFC1945, May 1996, . 1367 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1368 Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101, 1369 February 1997, . 1371 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1372 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1373 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1374 September 1997, . 1376 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1377 Defeating Denial of Service Attacks which employ IP Source 1378 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1379 May 2000, . 1381 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 1382 RFC 2956, DOI 10.17487/RFC2956, October 2000, 1383 . 1385 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1386 RFC 3124, DOI 10.17487/RFC3124, June 2001, 1387 . 1389 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1390 of Explicit Congestion Notification (ECN) to IP", 1391 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1392 . 1394 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1395 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1396 DOI 10.17487/RFC3633, December 2003, . 1399 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 1400 and G. Fairhurst, Ed., "The Lightweight User Datagram 1401 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 1402 2004, . 1404 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1405 "Randomness Requirements for Security", BCP 106, RFC 4086, 1406 DOI 10.17487/RFC4086, June 2005, . 1409 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1410 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1411 RFC 4106, DOI 10.17487/RFC4106, June 2005, 1412 . 1414 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1415 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1416 DOI 10.17487/RFC4192, September 2005, . 1419 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1420 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1421 2006, . 1423 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote 1424 Direct Memory Access (RDMA) over IP Problem Statement", 1425 RFC 4297, DOI 10.17487/RFC4297, December 2005, 1426 . 1428 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1429 10.17487/RFC4302, December 2005, . 1432 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1433 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1434 . 1436 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 1437 Protocol (DHCP) Leasequery", RFC 4388, DOI 1438 10.17487/RFC4388, February 2006, . 1441 [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple 1442 Authentication and Security Layer (SASL)", RFC 4422, DOI 1443 10.17487/RFC4422, June 2006, . 1446 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1447 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1448 . 1450 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1451 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1452 . 1454 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1455 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1456 DOI 10.17487/RFC4861, September 2007, . 1459 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1460 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1461 . 1463 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 1464 from the IAB Workshop on Routing and Addressing", 1465 RFC 4984, DOI 10.17487/RFC4984, September 2007, 1466 . 1468 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1469 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1470 . 1472 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1473 Kozuka, "Stream Control Transmission Protocol (SCTP) 1474 Dynamic Address Reconfiguration", RFC 5061, DOI 1475 10.17487/RFC5061, September 2007, . 1478 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1479 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1480 . 1482 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1483 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1484 . 1486 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1487 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1488 DOI 10.17487/RFC5723, January 2010, . 1491 [RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing 1492 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 1493 September 2010, . 1495 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1496 Model: The Relationship between Links and Subnet 1497 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1498 . 1500 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1501 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1502 . 1504 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1505 Assignment to End Sites", BCP 157, RFC 6177, DOI 1506 10.17487/RFC6177, March 2011, . 1509 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 1510 10.17487/RFC6250, May 2011, . 1513 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1514 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1515 2011, . 1517 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1518 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1519 January 2012, . 1521 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1522 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1523 2011, . 1525 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 1526 RFC 6691, DOI 10.17487/RFC6691, July 2012, 1527 . 1529 [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1530 Protocol (ILNP) Engineering Considerations", RFC 6741, DOI 1531 10.17487/RFC6741, November 2012, . 1534 [RFC6742] RJ Atkinson, SN Bhatti, and S. Rose, "DNS Resource Records 1535 for the Identifier-Locator Network Protocol (ILNP)", 1536 RFC 6742, DOI 10.17487/RFC6742, November 2012, 1537 . 1539 [RFC6743] RJ Atkinson and SN Bhatti, "ICMP Locator Update Message 1540 for the Identifier-Locator Network Protocol for IPv6 1541 (ILNPv6)", RFC 6743, DOI 10.17487/RFC6743, November 2012, 1542 . 1544 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1545 "TCP Extensions for Multipath Operation with Multiple 1546 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1547 . 1549 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1550 "Interworking between Locator/ID Separation Protocol 1551 (LISP) and Non-LISP Sites", RFC 6832, DOI 1552 10.17487/RFC6832, January 2013, . 1555 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1556 Protocol (LISP) Map-Server Interface", RFC 6833, DOI 1557 10.17487/RFC6833, January 2013, . 1560 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1561 "Locator/ID Separation Protocol Alternative Logical 1562 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1563 January 2013, . 1565 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 1566 "Internet Small Computer System Interface (iSCSI) Protocol 1567 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 1568 2014, . 1570 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1571 Constrained-Node Networks", RFC 7228, DOI 1572 10.17487/RFC7228, May 2014, . 1575 [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext 1576 Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 1577 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1578 . 1580 [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext 1581 Transfer Protocol (HTTP/1.1): Semantics and Content", 1582 RFC 7231, DOI 10.17487/RFC7231, June 2014, 1583 . 1585 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1586 Kivinen, "Internet Key Exchange Protocol Version 2 1587 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1588 2014, . 1590 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1591 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1592 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1593 . 1595 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1596 CJ. Bernardos, "Distributed Mobility Management: Current 1597 Practices and Gap Analysis", RFC 7429, DOI 1598 10.17487/RFC7429, January 2015, . 1601 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 1602 Raiciu, "Analysis of Residual Threats and Possible Fixes 1603 for Multipath TCP (MPTCP)", RFC 7430, DOI 1604 10.17487/RFC7430, July 2015, . 1607 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1608 "Recommendations for Secure Use of Transport Layer 1609 Security (TLS) and Datagram Transport Layer Security 1610 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1611 2015, . 1613 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1614 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 1615 10.17487/RFC7540, May 2015, . 1618 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 1619 Length Recommendation for Forwarding", BCP 198, RFC 7608, 1620 DOI 10.17487/RFC7608, July 2015, . 1623 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1624 Considerations for IPv6 Address Generation Mechanisms", 1625 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1626 . 1628 [RFC7805] Zimmermann, A., Eddy, W., and L. Eggert, "Moving Outdated 1629 TCP Extensions and TCP-Related Documents to Historic or 1630 Informational Status", RFC 7805, DOI 10.17487/RFC7805, 1631 April 2016, . 1633 [RFC7925] Tschofenig, H., Ed., and T. Fossati, "Transport Layer 1634 Security (TLS) / Datagram Transport Layer Security (DTLS) 1635 Profiles for the Internet of Things", RFC 7925, DOI 1636 10.17487/RFC7925, July 2016, . 1639 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1640 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 1641 October 2016, . 1643 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 1644 "Sending Multiple RTP Streams in a Single RTP Session", 1645 RFC 8108, DOI 10.17487/RFC8108, March 2017, 1646 . 1648 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 1649 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 1650 May 2017, . 1652 Authors' Addresses 1654 Jason Gao 1655 Beijing Static Traffic Investment and Operation Co.,Ltd. 1656 Shouke Plaza-A, Liuliqiao South, Fengtai 1657 Beijing 1658 People's Republic of China 1660 EMail: jagao@outlook.com