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