idnits 2.17.1 draft-gao-fsp-motivations-02.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 15, 2019) is 1654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8126' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1472, but no explicit reference was found in the text == Unused Reference: 'RFC4297' is defined on line 1476, but no explicit reference was found in the text == Unused Reference: 'RFC4422' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: 'RFC5218' is defined on line 1530, but no explicit reference was found in the text == Unused Reference: 'RFC5723' is defined on line 1534, but no explicit reference was found in the text == Unused Reference: 'RFC5889' is defined on line 1539, but no explicit reference was found in the text == Unused Reference: 'RFC5942' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: 'RFC6177' is defined on line 1552, but no explicit reference was found in the text == Unused Reference: 'RFC6250' is defined on line 1557, but no explicit reference was found in the text == Unused Reference: 'RFC6741' is defined on line 1569, but no explicit reference was found in the text == Unused Reference: 'RFC6832' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: 'RFC6833' is defined on line 1595, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 1624, but no explicit reference was found in the text == Unused Reference: 'RFC7401' is defined on line 1634, but no explicit reference was found in the text == Unused Reference: 'RFC7402' is defined on line 1639, but no explicit reference was found in the text == Unused Reference: 'RFC7429' is defined on line 1645, but no explicit reference was found in the text == Unused Reference: 'RFC7525' is defined on line 1657, but no explicit reference was found in the text == Unused Reference: 'RFC7608' is defined on line 1668, but no explicit reference was found in the text == Unused Reference: 'RFC7721' is defined on line 1673, but no explicit reference was found in the text == Unused Reference: 'RFC7925' is defined on line 1678, but no explicit reference was found in the text == Unused Reference: 'RFC8170' is defined on line 1689, 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 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- 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 (~~), 23 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Gao 3 Intended Status: Informational Individual 4 Expires: April 17, 2020 October 15, 2019 6 Motivations and Design Choices of the Flexible Session Protocol 7 draft-gao-fsp-motivations-02 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 the routing scalability problem in 14 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) 2019 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 . . . . . 14 73 3.1. IKEv2 Mobility and Multihoming Protocol . . . . . . . . . . 14 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. Goal: Adaptable to Constrained-Node Networks . . . . . 23 92 5.1.4. Non-Goal: General Multicast Transport . . . . . . . . . 24 93 5.2. Optimizing towards IPv6 . . . . . . . . . . . . . . . . . . 24 94 5.2.1. Goal: Promoting Transition towards IPv6 . . . . . . . . 24 95 5.2.2. Goal: NAT friendliness in IPv4 network . . . . . . . . 24 96 5.2.3. Non-Goal: NAT friendliness in IPv6 network . . . . . . 24 97 5.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 24 98 5.3.1. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 24 99 5.3.2. Goal: Host-Aggregated Congestion Control . . . . . . . 24 100 5.3.3. Goal: Congestion Control Per Traffic Class . . . . . . 25 101 5.3.4. Debatable: TCP Friendliness . . . . . . . . . . . . . . 25 102 5.4. Infrastructure Independency . . . . . . . . . . . . . . . . 25 103 5.4.1. Goal: More Efficient Use of the IPv6 Address Space . . 25 104 5.4.2. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 25 105 5.4.3. Non-Goal: Inventing New Rendezvous Mechanism . . . . . 25 106 5.5. Feasibility of Hardware Acceleration . . . . . . . . . . . 26 107 5.5.1. Goal: Hardware-Accelerated Cryptography . . . . . . . . 26 108 5.5.2. Goal: Hardware-assisted Header Processing . . . . . . . 26 109 5.6. QoS and Multipath Issues . . . . . . . . . . . . . . . . . 26 110 5.6.1. Goal: Minimal Delay Service for Milk Like Payload . . . 26 111 5.6.2. To be studied: Resource Reservation . . . . . . . . . . 26 112 5.6.3. To be studied: PMTU Discovery . . . . . . . . . . . . . 27 113 5.7. On-the-wire Compression . . . . . . . . . . . . . . . . . . 27 114 5.7.1. Goal: Compatibility with Pre-compression . . . . . . . 27 115 5.7.2. Goal: Decompression Speed . . . . . . . . . . . . . . . 27 116 5.7.3. Goal: System Robustness . . . . . . . . . . . . . . . . 27 117 5.7.4. Non-Goal: Versatility of On-the-Wire Compression . . . 28 118 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 119 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 120 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 121 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 122 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 125 1. Introduction 127 The motivation of designing the Flexible Session Protocol, which sits 128 at the transport layer along with TCP [RFC0793], is to provide 129 mobility and multihoming support, thus to make routing scalability 130 problem [RFC4984] in the IPv6 [RFC8200] internetwork thoroughly 131 avoidable. 133 FSP means to be programmer-friendly by adding session semantics in 134 the transport layer and providing security services that is flexible 135 to adapt to new cryptography key establishment algorithm implemented 136 at the application layer. 138 FSP is originally intent to be an alternative of TLS [RFC8446], 139 bundled with TCP, in application scenarios that favor high- 140 performance and strong-security in IPv6 networks with mobility 141 support. 143 FSP can be easily tuned to work well for constrained-node networks 144 [RFC7228]. 146 The document serves to explain some design choices of FSP as well. 148 1.1. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 1.2. Mobility and Multihoming Support in the IPv6 Internet 156 Various solutions exist in the IPv6 Internet that support mobility 157 and/or multihoming. In this documents we survey infrastructure- 158 dependent solutions such as HIP [RFC4423], ILNP [RFC6740], LISP 159 [RFC6830], NEMO [RFC3963], MinimalT [MinimaLT], MIPv6 [RFC6275], 160 PMIPv6 [RFC5213], HMIPv6 [RFC5380] and DMM [RFC7333], and 161 infrastructure-independent solutions such as MOBIKE [RFC4555], Mobile 162 SCTP, MPTCP [RFC7430] and REpresentation State Transfer architecture 163 style [RESTful]. 165 This document draws heavily from earlier RFCs and other references 166 when discusses these known solutions. 168 2. Survey of Infrastructure-Dependent Mobility Support 170 Various solutions exist in the IPv6 Internet that support mobility 171 and/or multihoming. Infrastructure-dependent proposals that support 172 mobility often require some change of current Internet architecture. 174 In this documents we surveys infrastructure-dependent solutions such 175 as HIP, ILNP, LISP, NEMO, MinimalT, MIPv6, PMIPv6 and HMIPv6. 177 2.1. Separation of Identifier and Locator 179 2.1.1. Host Identity Protocol 181 HIP architecture proposes Host Identity namespace that fills an 182 important gap between the IP and DNS namespaces. The Host Identity 183 namespace consists of Host Identifiers (HIs). A Host Identifier is 184 cryptographic in its nature; it is the public key of an asymmetric 185 key-pair. Each host will have at least one Host Identity, but it will 186 typically have more than one. Each Host Identity uniquely identifies 187 a single host; i.e., no two hosts have the same Host Identity. The 188 Host Identity, and the corresponding Host Identifier, can be either 189 public (e.g., published in the DNS) or unpublished. Client systems 190 will tend to have both public and unpublished Identities. 192 Service ------ Socket Service ------ Socket 193 | | 194 | | 195 | | 196 | | 197 End-point | End-point --- Host Identity 198 \ | | 199 \ | | 200 \ | | 201 \ | | 202 Location --- IP address Location --- IP address 204 Figure 1 New Stack Architecture Presented by HIP 206 HIP decouples the transport from the internetworking layer, and binds 207 the transport associations to the Host Identities. Consequently, HIP 208 can provide for a degree of internetworking mobility and multihoming 209 at a low infrastructure cost. HIP mobility [RFC8046] includes IP 210 address changes (via any method) to either party. HIP links IP 211 addresses together, when multiple IP addresses correspond to the same 212 Host Identity, and if one address becomes unusable, or a more 213 preferred address becomes available, existing transport associations 214 can easily be moved to another address. 216 When a node moves while communication is already ongoing, address 217 changes are rather straightforward. The peer of the mobile node can 218 just accept a HIP or an integrity protected IPsec packet from any 219 address and ignore the source address. 221 In order to start the HIP exchange, the initiator node has to know 222 how to reach the mobile node. Although infrequently moving HIP nodes 223 could use Dynamic DNS [RFC2136] to update their reachability 224 information in the DNS, an alternative to using DNS in this fashion 225 is to use a piece of new static infrastructure to facilitate 226 rendezvous between HIP nodes. 228 The mobile node keeps the rendezvous infrastructure continuously 229 updated with its current IP address(es). The mobile nodes must trust 230 the rendezvous mechanism to properly maintain their HIT and IP 231 address mappings. The rendezvous mechanism [RFC8004] is also needed 232 if both of the nodes happen to change their address at the same time, 233 either because they are mobile and happen to move at the same time, 234 because one of them is off-line for a while, or because of some other 235 reason. 237 2.1.2. Identifier-Locator Network Protocol 239 The key idea proposed for ILNP is to directly and specifically change 240 the overloaded semantics of the IP Address. The Internet community 241 has indicated explicitly, several times, that this use of overloaded 242 semantics is a significant problem with the use of the Internet 243 protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984]. 245 ILNP explicitly replaces the use of IP Addresses with two distinct 246 name spaces, each having distinct and different semantics: 248 a) Identifier: a non-topological name for uniquely identifying a 249 node. 251 b) Locator: a topologically bound name for an IP subnetwork. 253 The use of these two new namespaces in comparison to IP is given in 254 Table 1. The table shows where existing names are used for state 255 information in end-systems or protocols. 257 Layer | IP | ILNP 258 ---------------+----------------------+--------------- 259 Application | FQDN or IP Address | FQDN 260 Transport | IP Address | Identifier 261 Network | IP Address | Locator 262 Physical i/f | IP Address | MAC address 263 ---------------+----------------------+--------------- 265 FQDN = Fully Qualified Domain Name 266 i/f = interface 267 MAC = Media Access Control 269 Table 1: Use of Names for State Information in Various 270 Communication Layers for IP and ILNP 272 ILNP supports mobility directly. Essentially, for ILNP, mobility is 273 implemented by enabling: 275 a) Locator values to be changed dynamically by a node, including for 276 active network-layer sessions. 278 b) use of Locator Updates [RFC6743] to allow active network-layer 279 sessions to be maintained. 281 c) for those hosts that expect incoming network-layer or transport- 282 layer session requests (e.g., servers), updates to the relevant 283 DNS entries for those hosts [RFC6742]. 285 2.2.3. The Locator/ID Separation Protocol 287 The Locator/Identifier Separation Protocol provides a set of 288 functions for routers to exchange information used to map from 289 Endpoint Identifiers (EIDs) that are not globally routable to 290 routable Routing Locators (RLOCs). It also defines a mechanism for 291 these LISP routers to encapsulate IP packets addressed with EIDs for 292 transmission across a network infrastructure that uses RLOCs for 293 routing and forwarding. 295 The approach that LISP takes to solving the routing scalability 296 problem is to replace IP addresses with two new types of numbers: 297 Routing Locators (RLOCs), which are topologically assigned to network 298 attachment points (and are therefore amenable to aggregation) and 299 used for routing and forwarding of packets through the network; and 300 Endpoint Identifiers (EIDs), which are assigned independently from 301 the network topology, are used for numbering devices, and are 302 aggregated along administrative boundaries. LISP then defines 303 functions for mapping between the two numbering spaces and for 304 encapsulating traffic originated by devices using non-routable EIDs 305 for transport across a network infrastructure that routes and 306 forwards using RLOCs. Both RLOCs and EIDs are syntactically 307 identical to IP addresses; it is the semantics of how they are used 308 that differs. 310 LISP implementations must provide ITRs and ETRs. 312 An ITR is a router that resides in a LISP site. Packets sent by 313 sources inside of the LISP site to destinations outside of the site 314 are candidates for encapsulation by the ITR. The ITR treats the IP 315 destination address as an EID and performs an EID-to-RLOC mapping 316 lookup. The router then prepends an "outer" IP header with one of its 317 globally routable RLOCs in the source address field and the result of 318 the mapping lookup in the destination address field. 320 An ETR is a router that accepts an IP packet where the destination 321 address in the "outer" IP header is one of its own RLOCs. The router 322 strips the "outer" header and forwards the packet based on the next 323 IP header found. In general, an ETR receives LISP-encapsulated IP 324 packets from the Internet on one side and sends decapsulated IP 325 packets to site end-systems on the other side. ETR functionality does 326 not have to be limited to a router device. A server host can be the 327 endpoint of a LISP tunnel as well. 329 A mobile device can use the LISP infrastructure to achieve mobility 330 by implementing the LISP encapsulation and decapsulation functions 331 and acting as a simple ITR/ETR. By doing this, such a "LISP mobile 332 node" can use topologically independent EID IP addresses that are not 333 advertised into and do not impose a cost on the global routing 334 system. These EIDs are maintained at the edges of the mapping system 335 (in LISP Map-Servers and Map-Resolvers) and are provided on demand to 336 only the correspondents of the LISP mobile node. 338 It requires a index system that stores the mappings between EIDs and 339 RLOCs. The index system may be and usually is large-scale 340 distributed, such as Locator/ID Separation Protocol Alternative 341 Logical Topology [RFC6836], and constitutes the new infrastructure 342 that supports LISP. 344 2.2. Tunneling 346 2.2.1. Mobile IPv6 348 Mobility Support in IPv6, known as Mobile IPv6 or MIPv6, is a 349 protocol that allows nodes to remain reachable while moving around in 350 the IPv6 Internet. It allows a mobile node to move from one link to 351 another without changing the mobile node's "home address". Packets 352 may be routed to the mobile node using this address regardless of the 353 mobile node's current point of attachment to the Internet. The 354 mobile node may also continue to communicate with other nodes 355 (stationary or mobile) after moving to a new link. The movement of a 356 mobile node away from its home link is thus transparent to transport 357 and higher-layer protocols and applications. 359 In IPv4 mobility [RFC5944], when an endpoint is away from home, 360 packets to it are encapsulated and forwarded via a home agent that 361 resides in the home area the endpoint's address belongs to. The home 362 agent will encapsulate and forward packets either directly to the 363 endpoint or to a foreign agent that resides where the endpoint has 364 moved to. Packets from the endpoint may be sent directly to the 365 correspondent node, may be sent via the foreign agent, or may be 366 reverse-tunneled back to the home agent for delivery to the mobile 367 node. 369 Mobile IPv6 allows nodes to move within the Internet topology while 370 maintaining reachability and ongoing connections between mobile and 371 correspondent nodes as well. To do this, a mobile node sends binding 372 updates (BUs) to its home agent (HA) every time it moves. 374 The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both 375 from the experiences gained from the development of Mobile IP support 376 in IPv4 (Mobile IPv4), and from the opportunities provided by IPv6. 377 Mobile IPv6 thus shares many features with Mobile IPv4, but is 378 integrated into IPv6 and offers many other improvements. The major 379 differences between Mobile IPv4 and Mobile IPv6 is summarized as: 381 o There is no need to deploy special routers as "foreign agents", as 382 in Mobile IPv4. Mobile IPv6 operates in any location without any 383 special support required from the local router. 385 o Support for route optimization is a fundamental part of the 386 protocol, rather than a nonstandard set of extensions. 388 o Mobile IPv6 route optimization can operate securely even without 389 pre-arranged security associations. It is expected that route 390 optimization can be deployed on a global scale between all mobile 391 nodes and correspondent nodes. 393 o Support is also integrated into Mobile IPv6 for allowing route 394 optimization to coexist efficiently with routers that perform 395 "ingress filtering". 397 o The IPv6 Neighbor Unreachability Detection ensures symmetric 398 reachability between the mobile node and its default router in the 399 current location. 401 o Most packets sent to a mobile node while away from home in Mobile 402 IPv6 are sent using an IPv6 routing header rather than IP 403 encapsulation, reducing the amount of resulting overhead compared 404 to Mobile IPv4. 406 o Mobile IPv6 is decoupled from any particular link layer, as it 407 uses IPv6 Neighbor Discovery [RFC4861] instead of the Address 408 Resolution Protocol (ARP). This also improves the robustness of 409 the protocol. 411 o The use of IPv6 encapsulation (and the routing header) removes the 412 need in Mobile IPv6 to manage "tunnel soft state". 414 o The dynamic home agent address discovery mechanism in Mobile IPv6 415 returns a single reply to the mobile node. The directed broadcast 416 approach used in IPv4 returns separate replies from each home 417 agent. 419 2.2.2. Proxy Mobile IPv6 421 It is possible to support mobility for IPv6 nodes without host 422 involvement by extending Mobile IPv6 signaling messages between a 423 network node and a home agent. This approach to supporting mobility 424 does not require the mobile node to be involved in the exchange of 425 signaling messages between itself and the home agent. A proxy 426 mobility agent in the network performs the signaling with the home 427 agent and does the mobility management on behalf of the mobile node 428 attached to the network. Because of the use and extension of Mobile 429 IPv6 signaling and home agent functionality, this protocol is 430 referred to as Proxy Mobile IPv6 (PMIPv6). 432 The Mobile Access Gateway (MAG) is such a proxy function on an access 433 router. MAG manages the mobility-related signaling for a mobile node 434 that is attached to its access link. It is responsible for tracking 435 the mobile node's movements to and from the access link and for 436 signaling the mobile node's local mobility anchor. 438 IP mobility for nodes that have mobile IP client functionality in the 439 IPv6 stack as well as those nodes that do not, would be supported by 440 enabling Proxy Mobile IPv6 protocol functionality in the network. 441 The advantages of developing a network-based mobility protocol based 442 on Mobile IPv6 are: 444 o Reuse of home agent functionality and the messages/format used in 445 mobility signaling. Mobile IPv6 is a mature protocol with several 446 implementations that have undergone interoperability testing. 448 o A common home agent would serve as the mobility agent for all 449 types of IPv6 nodes. 451 2.2.3. Hierarchical Mobile IPv6 453 Hierarchical Mobile IPv6 (HMIPv6) mobility management specification 454 [RFC5380] introduces the concept of a hierarchical Mobile IPv6 455 network, utilising a new node called the Mobility Anchor Point (MAP). 457 MAP can be located at any level in a hierarchical network of routers, 458 including the Access Router (AR). The MAP will limit the amount of 459 Mobile IPv6 signaling outside the local domain. 461 The introduction of the MAP provides a solution that has these 462 benefits: 464 o The mobile node sends binding updates to the local MAP rather than 465 the home agent (HA) (which is typically further away) and 466 correspondent nodes (CNs). It mitigates delays caused by MIPv6 467 signaling. 469 o Only one binding update message needs to be transmitted by the 470 mobile node (MN) before traffic from the HA and all CNs is re- 471 routed to its new location. This is independent of the number of 472 CNs with which the MN is communicating. It mitigates the tunneling 473 burden on the home agent and alleviates the scalability problem. 475 A MAP is essentially a local home agent. The aim of introducing the 476 hierarchical mobility management model in Mobile IPv6 is to enhance 477 the performance of Mobile IPv6 while minimising the impact on Mobile 478 IPv6 or other IPv6 protocols. 480 It is pertinent to note that the use of the MAP does not rely on, or 481 assume the presence of, a permanent home agent. In other words, a 482 mobile node need not have a permanent home address or home agent in 483 order to be HMIPv6-aware or use the features of HMIPv6. A MAP may be 484 used by a mobile node in a nomadic manner to achieve mobility 485 management within a local domain. 487 2.2.4. Network Mobility (NEMO) Basic Support Protocol 489 Network Mobility (NEMO) Basic Support Protocol is protocol extensions 490 to Mobile IPv6 (MIPv6) to enable support for network mobility. The 491 extensions are backward compatible with Mobile IPv6. In particular, 492 a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent. 494 The NEMO Basic Support ensures session continuity for all the nodes 495 in the Mobile Network, even as the Mobile Router changes its point of 496 attachment to the Internet. It also provides connectivity and 497 reachability for all nodes in the Mobile Network as it moves. The 498 solution supports both mobile nodes and hosts that do not support 499 mobility in the Mobile Network. 501 The solution proposes a bi-directional tunnel between the Mobile 502 Router and its Home Agent. This tunnel is set up when the Mobile 503 Router sends a successful Binding Update to its Home Agent, informing 504 the Home Agent of its current point of attachment. All traffic 505 between the nodes in the Mobile Network and Correspondent Nodes 506 passes through the Home Agent. 508 The solution described here does not place any restriction on the 509 number of levels for nested mobility. But note that nested mobility 510 might introduce significant overhead on the data packets as each 511 level of nesting introduces another IPv6 header encapsulation. 513 Multihoming for Mobile Routers was not discussed in NEMO Basic 514 Support. 516 2.3. MinimalT 518 Minimal Latency Tunneling [MinimaLT] is a network protocol that 519 provides ubiquitous encryption for maximal confidentiality, including 520 protecting packet headers. MinimaLT provides server and user 521 authentication, extensive Denial-of-Service protections, and IP 522 mobility while approaching perfect forward secrecy. 524 A MinimaLT tunnel is a point-to-point entity that encapsulates the 525 set of connections between two hosts. MinimaLT creates a tunnel on 526 demand in response to the first packet received from a host or a 527 local application's outgoing connection request. Tunnels provide 528 server authentication, encryption, congestion control, and 529 reliability. 531 A MinimaLT tunnel contains a set of connections, that is, a single 532 tunnel between two hosts encapsulates an arbitrary number of 533 connections. Each connection is user-authenticated and provides two- 534 way communication between a client application and service. 536 MinimaLT identifies tunnels by their TID, the TID is pseudorandomly 537 generated by the initiator. A tunnel's IP and UDP port can change 538 without affecting communication. After changing its IP address or UDP 539 port, a host simply assumes the next TID as with a rekey. The other 540 host will recognize the new TID and will transition the tunnel to the 541 new key, IP address, and UDP port. 543 Central to the protocol is the MinimaLT directory service. The 544 directory service resolves queries for (server) hostname information. 545 It provides the server's directory certificate, signed by the 546 server's long-term key. This returned certificate contains the 547 server's IP address, UDP port, long-term key, zero padding (the 548 minimum payload size of the initial packet), and a server ephemeral 549 key. 551 As MinimalT requires new directory service provided by the network 552 infrastructure it is classified as infrastructure-dependent. 554 2.4. DMM 556 Requirements for DMM reveals that the background behind the interest 557 in studying DMM is primarily as follows. 559 (1) More than ever, mobile users are consuming Internet content, 560 including that of local Content Delivery Networks (CDNs). Such 561 traffic imposes new requirements on mobile core networks for 562 data traffic delivery. 564 Both traffic offloading and CDN mechanisms could benefit from 565 the development of mobile architectures with fewer hierarchical 566 levels introduced into the data path by the mobility management 567 system. This trend of "flattening" the mobile networks works 568 best for direct communications among peers in the same 569 geographical area. Distributed mobility management in the 570 flattening mobile networks would anchor the traffic closer to 571 the point of attachment of the user. 573 (2) Today's mobile networks present service providers with new 574 challenges. Mobility patterns indicate that mobile nodes often 575 remain attached to the same point of attachment for considerable 576 periods of time [LOCATING-USER]. Specific IP mobility 577 management support is not required for applications that launch 578 and complete their sessions while the mobile node is connected 579 to the same point of attachment. However, IP mobility support 580 is currently designed for always-on operation, maintaining all 581 parameters of the context for each mobile subscriber for as long 582 as they are connected to the network. This can result in a 583 waste of resources and unnecessary costs for the service 584 provider. Infrequent node mobility coupled with application 585 intelligence suggest that mobility support could be provided 586 selectively, thus reducing the amount of context maintained in 587 the network. 589 In centralized mobility management such as MIPv6, PMIPv6 or HMIPv6, 590 the location information in terms of a mapping between the session 591 identifier and the forwarding address is kept at a single mobility 592 anchor, and packets destined to the session identifier are forwarded 593 via this anchor. In other words, such mobility management systems 594 are centralized in both the control plane and the data plane (mobile 595 node IP traffic). 597 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 598 are the following: 600 1. Anchoring Function (AF): allocation to a mobile node of an IP 601 address, i.e., Home Address (HoA), or prefix, i.e., Home Network 602 Prefix (HNP), topologically anchored by the advertising node. 603 That is, the anchor node is able to advertise a connected route 604 into the routing infrastructure for the allocated IP prefixes. 605 This function is a control-plane function. 607 2. Internetwork Location Management (LM) function: managing and 608 keeping track of the internetwork location of an MN. It is a 609 control-plane function. 611 The location information may be a binding of the advertised IP 612 address/prefix, e.g., HoA or HNP, to the IP routing address of 613 the MN, or it may be a binding of a node that can forward packets 614 destined to the MN. 616 In a client-server protocol model, location query and update 617 messages may be exchanged between a Location Management client 618 (LMc) and a Location Management server (LMs). 620 3. Forwarding Management (FM) function: packet interception and 621 forwarding to/from the IP address/prefix assigned to the MN, 622 based on the internetwork location information, either to the 623 destination or to some other network element that knows how to 624 forward the packets to their destination. 626 FM may optionally be split into the control plane (FM-CP) and 627 data plane (FM-DP). 629 In Mobile IPv6, the home agent (HA) typically provides the AF; the 630 LMs is at the HA, whereas the LMc is at the MN; the FM function is 631 distributed between the ends of the tunnel at the HA and the MN. 633 In Proxy Mobile IPv6, the local mobility anchor (LMA) provides the 634 AF; the LMs is at the LMA, whereas the LMc is at the MAG; the FM 635 function is distributed between the ends of the tunnel at the LMA and 636 the MAG. 638 In HMIPv6, the Mobility Anchor Point (MAP) serves as a location 639 information aggregator between the LMs at the HA and the LMc at the 640 MN. The MAP also provides the FM function to enable tunneling 641 between HA and itself, as well as tunneling between the MN and 642 itself. 644 Requirements for Distributed Mobility Management [RFC7333] states 645 that distributed mobility management (DMM) is an alternative to the 646 centralized deployment of the location information. 648 While DMM does add scalability to mobile management tremendously it 649 requires substantial infrastructure enhancement to be effective. 651 3. Survey of Infrastructure-Independent Mobility Support 653 3.1. IKEv2 Mobility and Multihoming Protocol 654 IKEv2 [RFC7296] is used for performing mutual authentication, as well 655 as establishing and maintaining IPsec Security Associations (SAs). 656 In the base IKEv2 protocol, the IKE SAs and tunnel mode IPsec SAs are 657 created implicitly between the IP addresses that are used when the 658 IKE_SA is established. These IP addresses are then used as the outer 659 (tunnel header) addresses for tunnel mode IPsec packets. 661 There are scenarios where these IP addresses might change. One 662 example is mobility: a host changes its point of network attachment 663 and receives a new IP address. Another example is a multihoming host 664 that would like to change to a different interface if, for instance, 665 the currently used interface stops working for some reason. 667 The MOBIKE protocol provides a mechanism for updating the IP 668 addresses of existing IKE and IPsec SAs is needed. 670 MOBIKE allows both parties to have several addresses, and there are 671 up to N*M pairs of IP addresses that could potentially be used. The 672 party that initiated the IKE_SA is responsible for deciding which 673 address pair is used for the IPsec SAs and for collecting the 674 information it needs to make this decision (such as determining which 675 address pairs work or do not work). The other party simply tells the 676 initiator what addresses it has, but does not update the IPsec SAs 677 until it receives a message from the initiator to do so. This 678 approach applies to the addresses in the IPsec SAs; in the IKE_SA 679 case, the exchange initiator can decide which addresses are used. 681 In MOBIKE, the initiator decides what addresses are used in the IPsec 682 SAs. That is, the responder does not normally update any IPsec SAs 683 without receiving an explicit UPDATE_SA_ADDRESSES request from the 684 initiator. The responder can, however, update the IKE_SA in some 685 circumstances. 687 Assumes that the initiator has already decided what the new addresses 688 should be. When this decision has been made, the initiator: 690 o Updates the IKE_SA with the new addresses, and sets the 691 "pending_update" flag in the IKE_SA. 693 o Updates the IPsec SAs associated with this IKE_SA with the new 694 addresses (unless the initiator's policy requires a return 695 routability check before updating the IPsec SAs, and the check has 696 not been done for this responder address yet). 698 o If the IPsec SAs were updated in the previous step: If NAT 699 Traversal is not enabled, and the responder supports NAT 700 Traversal, and the initiator either suspects or knows that a NAT 701 is likely to be present, enables NAT Traversal. 703 o If there are outstanding IKEv2 requests (requests for which the 704 initiator has not yet received a reply), continues retransmitting 705 them using the addresses in the IKE_SA (the new addresses). 707 o When the window size allows, sends an INFORMATIONAL request 708 containing the UPDATE_SA_ADDRESSES notification (which does not 709 contain any data), and clears the "pending_update" flag. 711 o If a new address change occurs while waiting for the response, 712 starts again from the first step (and ignores responses to this 713 UPDATE_SA_ADDRESSES request). 715 When processing an INFORMATIONAL request containing the 716 UPDATE_SA_ADDRESSES notification, the responder: 718 o Determines whether it has already received a newer 719 UPDATE_SA_ADDRESSES request than this one. If it has, a normal 720 response message is sent, but no other action is taken. 722 o Checks that the (source IP address, destination IP address) pair 723 in the IP header is acceptable according to local policy. If it 724 is not, replies with a message containing the 725 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 727 o Updates the IP addresses in the IKE_SA with the values from the IP 728 header. 730 o Replies with an INFORMATIONAL response. 732 o If necessary, initiates a return routability check for the new 733 initiator address and waits until the check is completed. 735 o Updates the IPsec SAs associated with this IKE_SA with the new 736 addresses. 738 o If NAT Traversal is supported and NAT detection payloads were 739 included, enables or disables NAT Traversal. 741 When the initiator receives the reply: 743 o If an address change has occurred after the request was firs 744 sent, no MOBIKE processing is done for the reply message because a 745 new UPDATE_SA_ADDRESSES is going to be sent (or has already been 746 sent, if window size greater than one is in use). 748 o If the response contains an UNACCEPTABLE_ADDRESSES notification, 749 the initiator MAY select another addresses and retry the exchange, 750 keep on using the previously used addresses, or disconnect. 752 o It updates the IPsec SAs associated with this IKE_SA with the new 753 addresses (unless this was already done earlier before sending the 754 request; this is the case when no return routability check was 755 required). 757 o If NAT Traversal is supported and NAT detection payloads were 758 included, the initiator enables or disables NAT Traversal. 760 3.2. Mobile SCTP 762 A local host may have multiple points of attachment to the Internet, 763 giving it a degree of fault tolerance from hardware failures. Stream 764 Control Transmission Protocol was developed to take full advantage of 765 such a multi-homed host to provide a fast failover and association 766 survivability in the face of such hardware failures. However, many 767 modern computers allow for the dynamic addition and deletion of 768 network cards (sometimes termed a hot-pluggable interface). 769 Complicate this with the ability of a provider, in IPv6, to 770 dynamically renumber a network, and there still is a gap between 771 full-fault tolerance and the currently defined SCTP protocol. No 772 matter if a card is added or an interface is renumbered, in order to 773 take advantage of this new configuration, the transport association 774 must be restarted. For many fault-tolerant applications this restart 775 is considered an outage and is undesirable. 777 Stream Control Transmission Protocol (SCTP) Dynamic Address 778 Reconfiguration [RFC4960] [RFC5061] is an extension to SCTP to 779 attempt to correct this problem for the more demanding fault-tolerant 780 application. This extension will allow an SCTP stack to: 782 o Dynamically add an IP address to an association. 784 o Dynamically delete an IP address from an association. 786 o Request to set the primary address the peer will use when sending 787 to an endpoint. 789 The dynamic addition and subtraction of IP addresses allows an SCTP 790 association to continue to function through host and network 791 reconfigurations. These changes, brought on by provider or user 792 action, may mean that the peer would be better served by using the 793 newly added address; however, this information may only be known by] 794 the endpoint that had the reconfiguration occur. In such a case this 795 extension allows the local endpoint to advise the peer as to what it 796 thinks is the better primary address that the peer should be using. 798 One last thing this extension adds is a small, 32-bit integer called 799 an adaptation indication that can be exchanged at startup. This is 800 useful for applications where there are one or more specific layers 801 below the application, yet still above SCTP. In such a case, the 802 exchange of this indication can allow the proper layer to be enabled 803 below the application. 805 3.3. Multipath TCP 807 Seamless TCP mobility using lightweight MPTCP proxy [HAMPEL] utilizes 808 Multipath TCP (MPTCP) [RFC6824] to implement a TCP mobility solution. 809 However, Analysis of Residual Threats and Possible Fixes for 810 Multipath TCP found some security issues such as ADD_ADDR attack. 811 Hence inherent security of MPTCP is rather doubtful. 813 3.4. REST Architecture Style 815 REST stands for "Representational State Transfer" [RESTful]. The name 816 is intended to evoke an image of how a well-designed Web application 817 behaves: a network of Web pages forms a virtual state machine, 818 allowing a user to progress through the application by selecting a 819 link or submitting a short data-entry form, with each action 820 resulting in a transition to the next state of the application by 821 transferring a representation of that state to the user. 823 The REST architectural style consists of a set of architectural 824 constraints chosen for the properties they induce on candidate 825 architectures. For purpose of discussing mobility support we note 826 that the first constraints added to the hybrid style are those of the 827 client-server architectural style (CS). Separation of concerns is the 828 principle behind the client-server constraints. CS style is closely 829 followed by the client-stateless-server (CSS) style, such that each 830 request from client to server must contain all of the information 831 necessary to understand the request, and cannot take advantage of any 832 stored context on the server. Session state is therefore kept 833 entirely on the client. Communication must be stateless in nature. 835 It is observable that REST architecture style, or RESTful pattern 836 provides some degree of mobility support at the application layer. 838 There are abundant Web applications that rely on HTTP which are built 839 upon RESTful pattern. The Hypertext Transfer Protocol (HTTP) 840 [RFC1945] [RFC7230] [RFC7540] is a request/response protocol. A 841 client sends a request containing request headers that specify the 842 request method, URI, HTTP version, information about the client, some 843 additional information about the request, and optional application 844 data. The server responds with a status or error code followed by a 845 message containing information about the server and information about 846 the data. This may include a message body. 848 The browser that accesses the Web application built upon RESTful 849 pattern may change its transport layer address freely, not to mention 850 IP address, provided that each request from the browser contains all 851 of the information necessary to understand the request and the 852 browser can resolve the latest address of the server, as the 853 communication is stateless in nature if it obeys RESTful pattern. 854 Thus we conclude that REST architecture style inherently provides 855 mobility support. 857 4. A Solution at the Origin of the Problem 859 4.1. Separation of Identity and Locator at Transport Layer 861 Why we design a new transport protocol to solve the routing 862 scalability problem while provide mobility and multihoming support? 863 Because it is the dominating transport layer protocols, TCP and UDP 864 that take use of the IP address to identifying the end node, 865 introduce the controversial role of IP address both as the identifier 866 and as the routing locator. 868 FSP is meant to be transport layer protocol that keeps the IP address 869 as the routing locator but keeps it from being the key constituent of 870 the FSP identifier or any upper layer protocol built upon FSP. It is 871 a solution to avoid, if not to extirpate, the routing scalability 872 problem. 874 4.2. Adding Programmer-Friendly Session Semantics 876 It is hard to achieve the goal of making a new transport protocol 877 accepted by the programmers. The service provided by the transport 878 protocol should have some 'killer' features. FSP assumes that session 879 semantics is such a feature. 881 Here we define a session is a bundle of connections or streams that 882 share the same authentication and authorization context. 884 4.2.1. Intuitiveness 886 This concept is inspired by HTTP persistent connection. The 887 persistent connections of HTTP 1.1 [RFC7230] and HTTP 2.0 [RFC7540] 888 allow multiple request/response transactions (streams) during the 889 lifetime of a single HTTP connection. This reduces overhead during 890 connection establishment and mitigates transport-layer slow-start 891 that would have otherwise been incurred for each transaction. HTTP 892 2.0 connections can multiplex many request/response pairs in parallel 893 on a single transport connection. Both are important to reduce 894 latency for HTTP's primary use case. 896 These multiple request/response pairs, or streams in parallel, 897 constitute a session. Usually they share the same authentication and 898 authorization context. From a programmer's point of view they 899 constitute a session. 901 It is much more intuitive (and more efficient) than to save the user 902 authentication and authorization state in some representation form at 903 the client side and transfer the state in representation form along 904 with each request to the server side for authorization purpose. 906 4.2.2. Really Parallel Streams 908 There is head-of-line congestion in HTTP persistent connection. Such 909 head-of-line congestion is anti-intuitive and should be avoided. 910 Connection Multiplication mechanism is meant to solve such head-of- 911 line congestion problem. Connection multiplication makes a branch 912 connection reuse the security context of the master connection and 913 makes the new connection established in zero round trip. 915 As per [RFC8108] an endpoint may send multiple RTP streams in a 916 single RTP session. FSP is meant to cover such requirement as well. 918 4.2.3. Mixed Traffic Class 920 A real world application may consist mixed traffic classes of 921 streams, for example one control stream which does not tolerate 922 packet loss, and a bundle of streams that carry payloads favoring 923 low-latency while tolerating packet loss. All these streams belong to 924 the same session in the sense of same user authentication and 925 authorization context. 927 4.2.4. Session Adjournment and Resumption 929 It is not uncommon for an application to exploit TCP as the transport 930 protocol, and as TCP transmits the application data as an unbroken 931 stream of octets it is at the application layer to delimiter the 932 messages that are sent continually. 934 It would be convenient if the application data could still be sent in 935 stream mode and the transport service provides the 'commit' 936 programming interface, through which the application can explicitly 937 set the transmission check point where further sending of data is 938 prohibited until all of the data sent have been acknowledged at the 939 transport layer. 941 It is considered a weak, asymmetric, yet essential requirement for 942 session adjournment and resumption. FSP provides Transmit Transaction 943 mechanism to fulfill such requirement. 945 4.3. Adding Programmer-friendly Security Service 947 4.3.1. Ubiquitous Encryption and Authentication of Data 949 As revealed in "Datagram Transport Layer Security" (DTLS) [RFC6347] 950 even client/server applications that takes use of UDP needs to 951 communicate in a way that manages to prevent eavesdropping, 952 tampering, or message forgery. Transport layer protocol should 953 provide inherent support for ubiquitous encryption and/or 954 authentication of data. 956 4.3.2. Key Establishment versus Application of Keys 958 IPsec architecture [RFC4301] clearly separates the sub-protocol for 959 key establishment through Internet Key Exchange (IKE) [RFC7296], and 960 the sub-protocol for applying the established key through the 961 Authentication Header (AH) [RFC4302] and Encapsulating Security 962 Payload (ESP) [RFC4303]. 964 However, as the mechanism of security association (SA) is stateful it 965 is not convenient to solve the problems at the IP layer which should 966 better be stateless for sake of scalability. 968 Besides, as the IP layer services are often implemented in the kernel 969 of the operating systems the extensibility is limited, but various 970 classes of applications often require variable key establishment 971 process that could be directly managed by the end-node application. 973 It would be convenient if the key established at the application 974 layer could be applied at the transport layer to encrypt the payload 975 with authentication. 977 5. Choices of Design Goals 979 5.1. Featured Scenarios 981 5.1.1. Goal: Support for Mobile Computing 983 As stated in 'Report from the IAB Workshop on Routing and 984 Addressing', September 2007 [RFC4984], 'The workshop participants 985 recognized that the increase in the number of mobile devices can be 986 significant, and that if a scalable routing system supporting generic 987 identity-locator separation were developed and introduced, billions 988 of mobile gadgets could be supported without bringing undue impact on 989 global routing scalability and stability'. 991 FSP can be implemented in the user-space of the operating systems. It 992 is technically feasible to deploy FSP-dependent applications as the 993 Software-as-a-Service [SaaS] on the public cloud computing platform 994 and distribute the FSP-enabled client applications that act as the 995 agents of the SaaS platform through some online application store to 996 serve more than ever mobile users. It has high probability of earning 997 economical benefit to deploy such solution because FSP consume 998 considerably less computing resource than TLS over TCP or DTLS over 999 UDP. 1001 Unlike the help desks of the enterprise networks the public cloud 1002 service providers and the wireless communication service providers 1003 can be much more tolerant with the new transport protocol. 1005 5.1.2. Goal: Adaptable to Specific-Purpose Networks 1007 Here specific-purpose networks mean those networks that dedicatedly 1008 serve for some special purpose, such as Storage Area Network (SAN) at 1009 which Internet Small Computer Systems Interface (iSCSI) [RFC7143] is 1010 targeted. 1012 Such specific-purpose networks often favor high performance over 1013 privacy. It may find it is overkill to utilize FSP. However in such 1014 scenario the weak integrity protection mode that utilize CRC64 1015 [CRC64] may be exploited, where CRC64 calculation may be implemented 1016 in commoditized hardware. High-performance software implementation 1017 exists as well. 1019 And it should be feasible to realize FSP directly over layer 2 1020 jumbogram packet switch network in some specific-purpose network such 1021 as at the data center of the cloud service provider. 1023 It should be feasibility to exploit hardware acceleration for FSP in 1024 the specific-purpose networks. 1026 5.1.3. Goal: Adaptable to Constrained-Node Networks 1028 As defined in [RFC7228], a constrained-node network is a network 1029 whose characteristics are influenced by being composed of a 1030 significant portion of constrained nodes. A constrained-node network 1031 always is a constrained network because of the network constraints 1032 stemming from the node constraints. In the constrained network some 1033 of the characteristics pretty much taken for granted with link layers 1034 in common use in the Internet at the time of writing are not 1035 attainable, such as in the LLN (as described in Terms Used in Routing 1036 for Low-Power and Lossy Networks [RFC7102]). 1038 It is observed that key establishment almost always consumes much 1039 more CPU power and/or RAM resource than data encryption/decryption 1040 that applying the key, per octet transmitted in the network. 1042 FSP is designed to support persistent session, where it is possible 1043 to establish the connection securely between the constrained node and 1044 its more powerful peer during the provisioning phase, and keep the 1045 connection secure with the automatic re-keying mechanism, while the 1046 upper layer application is able to do transactional works by 1047 exploiting transmit transaction mechanism provided by FSP. The 1048 session key to be established may even be negotiated with some 1049 additional hardware acceleration attached to the constrained node at 1050 the provision phase. 1052 5.1.4. Non-Goal: General Multicast Transport 1054 Although there is some trace of supporting 'duplicate-cast' which 1055 means sending to two, at most three receivers in design of FSP, 1056 Duplication-cast Extensibility is yet to be studied. General 1057 multicast support is simply non-goal. 1059 5.2. Optimizing towards IPv6 1061 5.2.1. Goal: Promoting Transition towards IPv6 1063 FSP is intent on promoting IPv6 for sake of transparent end-to-end 1064 connectivity. 1066 5.2.2. Goal: NAT friendliness in IPv4 network 1068 Network Address Translation and Port Translation (NAPT) [RFC2663] 1069 works well for conserving global addresses and addressing multihoming 1070 requirements because an IPv4 NAPT router implements three functions: 1071 source address selection, next-hop resolution, and (optionally) DNS 1072 resolution. It is mandatory for FSP to keep NAT-friendliness in the 1073 IPv4 internetwork because NAT middleboxes are ubiquitous. 1075 5.2.3. Non-Goal: NAT friendliness in IPv6 network 1077 It is both feasible and preferable to avoid NAT in the IPv6 1078 internetwork for sake of transparent end-to-end connectivity. 1080 5.3. Congestion Control 1082 5.3.1. Goal: ECN Awareness 1084 The Benefits of Using Explicit Congestion Notification (ECN) 1085 [RFC8087] outlines the principal gains in terms of increased 1086 throughput, reduced delay, and other benefits when ECN is used over a 1087 network path that includes equipment that supports Congestion 1088 Experienced (CE) marking. 1090 FSP should take advantages of ECN [RFC3168]. 1092 5.3.2. Goal: Host-Aggregated Congestion Control 1094 We argue that congestion control should be end-to-end at the network 1095 layer instead of transport layer. All traffic between two network 1096 nodes shall be subjected aggregately to the congestion control. 1098 5.3.3. Goal: Congestion Control Per Traffic Class 1100 As it is a designed feature for FSP to carry mixed traffic class in 1101 one session, but there is no single congestion control mechanism will 1102 work for all traffic classes, it would be convenient that different 1103 traffic class is treated with different congestion control mechanism. 1105 5.3.4. Debatable: TCP Friendliness 1107 It is observable that traffics such as multi-thread downloading or 1108 video-streaming over RTP [RFC3550] that manage to avoid TCP 1109 congestion control are overwhelmingly increasing. It might be too 1110 conservative to keep up with such application trends to obey with 1111 TCP-friendliness. 1113 5.4. Infrastructure Independency 1115 FSP does not introduce any new namespace, nor does it depend on new 1116 network infrastructure. However it does make some assumption about 1117 the network layer infrastructure. 1119 5.4.1. Goal: More Efficient Use of the IPv6 Address Space 1121 The length of an IPv6 address is 128 bits. Practices of IPv6 NAPT 1122 show that address space of 48 bits is sufficient. There could be 1123 optimization space for more efficient use of the IPv6 address space. 1125 o Every IPv6 network node is effectively a router 1127 And it could be argued that this opinion is implicitly supported by 1128 "Unique IPv6 Prefix per Host" [RFC8273]. 1130 o The upper layer application is the ultimate IPv6 end-point 1132 Again, it could be argued that this opinion is implicitly supported 1133 by "Unique IPv6 Prefix per Host". 1135 5.4.2. Goal: ECN Awareness 1137 FSP should take advantages of ECN, which is a network infrastructure 1138 mechanism. 1140 5.4.3. Non-Goal: Inventing New Rendezvous Mechanism 1142 FSP should take advantages of Dynamic DNS [RFC2136] to provide 1143 rendezvous mechanism in case that the two participants change their 1144 IP addresses simultaneously. It does not intent to re-invent the 1145 wheel. 1147 5.5. Feasibility of Hardware Acceleration 1149 5.5.1. Goal: Hardware-Accelerated Cryptography 1151 Hardware implementation efficiency and popularity shall be the most 1152 important factors of selecting the data integrity and confidentiality 1153 protection algorithm. 1155 First version of FSP exploits AES-GCM [AES][GCM], liking in The Use 1156 of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload 1157 (ESP) [RFC4106]. 1159 Here it is explicitly proposed that the upper layer application 1160 should take care of key establishment, and install the key 1161 established onto the FSP layer, alike to the Use of Channel Bindings 1162 to Secure Channels [RFC5056]. Reason behind the proposal is alike to 1163 channel binding as well: 'the main goal of channel binding is to be 1164 able to delegate cryptographic session protection to network layers 1165 below the application in hopes of being able to better leverage 1166 hardware implementations of cryptographic protocols'. 1168 5.5.2. Goal: Hardware-assisted Header Processing 1170 FSP chooses to design fixed-size header for normal packet that 1171 imitates Reduced Instruction Set Computer (RISC) instructions that 1172 are easier to process in hardware. 1174 5.6. QoS and Multipath Issues 1176 5.6.1. Goal: Minimal Delay Service for Milk Like Payload 1178 An ordinary data flow is wine-like in the sense that the older data 1179 are more valuable. If it has to, data packet sent latest are dropped 1180 first. In the contrary, milk-like payload is that the newer data are 1181 more precious and outdated data packet can be discarded. 1183 FSP is designed to support mixed traffic class that providing service 1184 both for wine-like payload and milk-like payload. 1186 5.6.2. To be studied: Resource Reservation 1188 End-to-End resource reservation protocol packets MAY be piggybacked 1189 on the preliminary FSP packets that are exchanged in the connection 1190 establishment process to provide guaranteed quality of service. 1191 However as resource reservation [RFC2205] requires that the network 1192 layer nodes along the path that the protocol packets have passed to 1193 keep some state, the scalability is questionable. 1195 However, since resource reservation may assure higher quality of 1196 service, future version of FSP should be capable of reserving 1197 resource along the network path in the connection establishment 1198 process, at least for some special purpose network. 1200 5.6.3. To be studied: PMTU Discovery 1202 For sake of maximizing mobility and multi-path support it is not 1203 required to implement Packetization Layer Path MTU Discovery 1204 [RFC4821] for FSP. 1206 PMTU may be discovered together with resource reservation in the 1207 future. 1209 5.7. On-the-wire Compression 1211 Because lots of content is compressible and compression saves 1212 bandwidth, it is proposed that FSP shall support on-the-wire 1213 compression. 1215 LZ4 algorithm is chosen for it "features extremely fast decoder" 1216 [LZ4]. Few well-known loss-less compression algorithm has higher 1217 performance than LZ4 (in according to [LZTURBO]) in terms of 1218 decompression speed. The apparent one exception, LzTurbo, has not yet 1219 open-sourced. 1221 Besides, LZ4 offers a high compression derivative called LZ4_HC that 1222 shares the same "extremely fast decoder" with the default compressor. 1223 It is possible to pre-compress some content with LZ4_HC and serve it 1224 to mass client, while each client decodes and gets the original 1225 content with on-the-wire speed. 1227 5.7.1. Goal: Compatibility with Pre-compression 1229 From the sender side of view lots of content is pre-determined and 1230 pre-compressible. It would be welcomed if the on-the-wire compression 1231 algorithm chosen offers a high compression branch that share the same 1232 on-the-wire speed decoder with the on-the-wire encoder. 1234 5.7.2. Goal: Decompression Speed 1236 The decoder should run as fast as possible. 1238 5.7.3. Goal: System Robustness 1240 From the receiver point of view decompression may consume 1241 unpredictable amount of memory resource. On-the-wire compression 1242 service SHOULD be provided in the user space for sake of system 1243 robustness. And the decoder should consume memory resource less than 1244 the amount reasonably provided by a constrained node. 1246 5.7.4. Non-Goal: Versatility of On-the-Wire Compression 1248 Speed should take precedence over compression ratio on selecting the 1249 on-the-wire compression algorithm for FSP. 1251 6. Security Considerations 1253 FSP MUST provide mechanism to fight against connection hi-jack 1254 attack. 1256 FSP SHALL provide data encryption and decryption mechanism to protect 1257 confidentiality of the payload 1259 For sake of performance FSP chooses symmetric-key algorithm to 1260 achieve the goal. In the first version of FSP slightly modified 1261 AEAD_AES_128_GCM or AEAD_AES_256_GCM [RFC5116] is applied. 1263 FSP SHALL provide data integrity protection mechanism. In the first 1264 version Authenticated Encryption with Associated Data [R02] algorithm 1265 AES-GCM is applied to protect integrity of each FSP packet, unless 1266 the upper layer application explicitly relaxes the requirement. 1268 FSP does not intend to provide full-fledged cryptography support. 1269 Easy of use with reasonable flexibility takes precedence. 1271 It is explicitly proposed that the upper layer application should 1272 take care of key establishment, and install the key established onto 1273 the FSP layer. 1275 7. IANA Considerations 1277 This document has no actions for IANA. 1279 8. References 1281 8.1. Normative References 1283 [MinimaLT] W. Michael Petullo, Xu Zhang, Jon A. Solworth, Daniel J. 1284 Bernstein, Tanja Lange. MinimaLT: Minimal-latency 1285 networking through better security, October 2013, 1286 1288 [R02] Rogaway, P., "Authenticated encryption with Associated- 1289 Data", ACM Conference on Computer and Communication 1290 Security (CCS'02), pp. 98-107, ACM Press, 2002, 1291 . 1293 [RESTful] Fielding R. T. and R. N. Taylor, "Principled Design of the 1294 Modern Web Architecture", International Conference on 1295 Software Engineering, 2000: 407-416. 1297 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1298 RFC 793, DOI 10.17487/RFC0793, September 1981, 1299 . 1301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1302 Requirement Levels", BCP 14, RFC 2119, DOI 1303 10.17487/RFC2119, March 1997, . 1306 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1307 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1308 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1309 . 1311 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1312 Translator (NAT) Terminology and Considerations", 1313 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1314 . 1316 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1317 Jacobson, "RTP: A Transport Protocol for Real-Time 1318 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1319 July 2003, . 1321 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1322 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1323 RFC 3963, DOI 10.17487/RFC3963, January 2005, 1324 . 1326 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1327 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1328 December 2005, . 1330 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1331 (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 1332 2006, . 1334 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1335 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1336 . 1338 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1339 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1340 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1341 . 1343 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1344 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1345 Management", RFC 5380, DOI 10.17487/RFC5380, October 2008, 1346 . 1348 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1349 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1350 2011, . 1352 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1353 Protocol (ILNP) Architectural Description", RFC 6740, DOI 1354 10.17487/RFC6740, November 2012, . 1357 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1358 "TCP Extensions for Multipath Operation with Multiple 1359 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1360 . 1362 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1363 Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 1364 10.17487/RFC6830, January 2013, . 1367 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1368 Kivinen, "Internet Key Exchange Protocol Version 2 1369 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1370 2014, . 1372 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1373 Korhonen, "Requirements for Distributed Mobility 1374 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1375 . 1377 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1378 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 1379 October 2016, . 1381 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility 1382 with the Host Identity Protocol", RFC 8046, DOI 1383 10.17487/RFC8046, February 2017, . 1386 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1387 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1388 10.17487/RFC8087, March 2017, . 1391 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1392 Writing an IANA Considerations Section in RFCs", BCP 26, 1393 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1394 . 1396 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1397 (IPv6) Specification", STD 86, RFC 8200, DOI 1398 10.17487/RFC8200, July 2017, . 1401 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1402 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1403 . 1405 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1406 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1407 . 1409 8.2. Informative References 1411 [AES] NIST, "Advanced Encryption Standard (AES)", November 2001. 1412 1414 [CRC64] ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape 1415 Cartridges - DLT1 Format Standard, Annex B", ECMA-182, 1416 December 1992. 1418 [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: 1419 Galois/Counter Mode (GCM) and GMAC", November 2007. 1420 1422 [HAMPEL] Hampel, G., Rana, A., and T. Klein, "Seamless TCP mobility 1423 using lightweight MPTCP proxy", MobiWac '13: Proceedings 1424 of the 11th ACM international symposium on Mobility 1425 management and wireless access, DOI 1426 10.1145/2508222.2508226, November 2013. 1428 [LOCATING-USER] 1429 Kirby, G., "Locating the User", Communications 1430 International, 1995. 1432 [LZ4] https://lz4.github.io/lz4/ 1434 [LZTURBO] https://github.com/powturbo/TurboBench 1436 [SaaS] Peter, M. and G. Tim, "The NIST Definition of Cloud 1437 Computing", SP 800-145, September 2011, 1438 1440 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1441 Destinations", RFC 1498, DOI 10.17487/RFC1498, August 1442 1993, . 1444 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 1445 Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 1446 10.17487/RFC1945, May 1996, . 1449 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1450 Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101, 1451 February 1997, . 1453 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1454 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1455 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1456 September 1997, . 1458 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 1459 RFC 2956, DOI 10.17487/RFC2956, October 2000, 1460 . 1462 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1463 of Explicit Congestion Notification (ECN) to IP", 1464 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1465 . 1467 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1468 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1469 RFC 4106, DOI 10.17487/RFC4106, June 2005, 1470 . 1472 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1473 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1474 2006, . 1476 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote 1477 Direct Memory Access (RDMA) over IP Problem Statement", 1478 RFC 4297, DOI 10.17487/RFC4297, December 2005, 1479 . 1481 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1482 10.17487/RFC4302, December 2005, . 1485 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1486 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1487 . 1489 [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple 1490 Authentication and Security Layer (SASL)", RFC 4422, DOI 1491 10.17487/RFC4422, June 2006, . 1494 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1495 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1496 . 1498 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1499 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1500 . 1502 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1503 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1504 DOI 10.17487/RFC4861, September 2007, . 1507 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1508 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1509 . 1511 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 1512 from the IAB Workshop on Routing and Addressing", 1513 RFC 4984, DOI 10.17487/RFC4984, September 2007, 1514 . 1516 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1517 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1518 . 1520 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1521 Kozuka, "Stream Control Transmission Protocol (SCTP) 1522 Dynamic Address Reconfiguration", RFC 5061, DOI 1523 10.17487/RFC5061, September 2007, . 1526 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1527 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1528 . 1530 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 1531 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 1532 . 1534 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1535 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1536 DOI 10.17487/RFC5723, January 2010, . 1539 [RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing 1540 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 1541 September 2010, . 1543 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1544 Model: The Relationship between Links and Subnet 1545 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1546 . 1548 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1549 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1550 . 1552 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1553 Assignment to End Sites", BCP 157, RFC 6177, DOI 1554 10.17487/RFC6177, March 2011, . 1557 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 1558 10.17487/RFC6250, May 2011, . 1561 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1562 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1563 2011, . 1565 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1566 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1567 January 2012, . 1569 [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1570 Protocol (ILNP) Engineering Considerations", RFC 6741, DOI 1571 10.17487/RFC6741, November 2012, . 1574 [RFC6742] RJ Atkinson, SN Bhatti, and S. Rose, "DNS Resource Records 1575 for the Identifier-Locator Network Protocol (ILNP)", 1576 RFC 6742, DOI 10.17487/RFC6742, November 2012, 1577 . 1579 [RFC6743] RJ Atkinson and SN Bhatti, "ICMP Locator Update Message 1580 for the Identifier-Locator Network Protocol for IPv6 1581 (ILNPv6)", RFC 6743, DOI 10.17487/RFC6743, November 2012, 1582 . 1584 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1585 "TCP Extensions for Multipath Operation with Multiple 1586 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1587 . 1589 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1590 "Interworking between Locator/ID Separation Protocol 1591 (LISP) and Non-LISP Sites", RFC 6832, DOI 1592 10.17487/RFC6832, January 2013, . 1595 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1596 Protocol (LISP) Map-Server Interface", RFC 6833, DOI 1597 10.17487/RFC6833, January 2013, . 1600 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1601 "Locator/ID Separation Protocol Alternative Logical 1602 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1603 January 2013, . 1605 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1606 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1607 2014, . 1609 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 1610 "Internet Small Computer System Interface (iSCSI) Protocol 1611 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 1612 2014, . 1614 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1615 Constrained-Node Networks", RFC 7228, DOI 1616 10.17487/RFC7228, May 2014, . 1619 [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext 1620 Transfer Protocol (HTTP/1.1): Message Syntax and Routing", 1621 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1622 . 1624 [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext 1625 Transfer Protocol (HTTP/1.1): Semantics and Content", 1626 RFC 7231, DOI 10.17487/RFC7231, June 2014, 1627 . 1629 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1630 Kivinen, "Internet Key Exchange Protocol Version 2 1631 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1632 2014, . 1634 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 1635 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 1636 RFC 7401, DOI 10.17487/RFC7401, April 2015, 1637 . 1639 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 1640 Encapsulating Security Payload (ESP) Transport Format with 1641 the Host Identity Protocol (HIP)", RFC 7402, DOI 1642 10.17487/RFC7402, April 2015, . 1645 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1646 CJ. Bernardos, "Distributed Mobility Management: Current 1647 Practices and Gap Analysis", RFC 7429, DOI 1648 10.17487/RFC7429, January 2015, . 1651 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 1652 Raiciu, "Analysis of Residual Threats and Possible Fixes 1653 for Multipath TCP (MPTCP)", RFC 7430, DOI 1654 10.17487/RFC7430, July 2015, . 1657 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1658 "Recommendations for Secure Use of Transport Layer 1659 Security (TLS) and Datagram Transport Layer Security 1660 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1661 2015, . 1663 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1664 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 1665 10.17487/RFC7540, May 2015, . 1668 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 1669 Length Recommendation for Forwarding", BCP 198, RFC 7608, 1670 DOI 10.17487/RFC7608, July 2015, . 1673 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1674 Considerations for IPv6 Address Generation Mechanisms", 1675 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1676 . 1678 [RFC7925] Tschofenig, H., Ed., and T. Fossati, "Transport Layer 1679 Security (TLS) / Datagram Transport Layer Security (DTLS) 1680 Profiles for the Internet of Things", RFC 7925, DOI 1681 10.17487/RFC7925, July 2016, . 1684 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 1685 "Sending Multiple RTP Streams in a Single RTP Session", 1686 RFC 8108, DOI 10.17487/RFC8108, March 2017, 1687 . 1689 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 1690 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 1691 May 2017, . 1693 Author's Address 1695 Jun-an Gao 1696 Beijing Capital Highway Development Group Co.,Ltd. 1697 Shoufa Plaza-A, Liuliqiao South, Fengtai 1698 Beijing 1699 People's Republic of China 1701 EMail: jagao@outlook.com