idnits 2.17.00 (12 Aug 2021) /tmp/idnits37899/draft-thaler-mobility-comparison-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 535. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 497), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2007) is 5508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-mipshop-cga-cba has been published as RFC 4866 -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. 'HIP') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. 'HMIP6') (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIP6') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. Thaler 3 October 19, 2006 Microsoft 4 Expires April 2007 6 A Comparison of IP Mobility-Related Protocols 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2006). All Rights Reserved. 36 Abstract 38 Mobile IPv6 (MIP6), the Level 3 Multihoming Shim Protocol (SHIM6), 39 and the Host Identity Protocol (HIP) all address various aspects of 40 mobility and multi-homing in similar ways. This document gives a 41 brief comparison of their features. 43 1. Introduction 45 This document describes a number of commonalities and differences 46 between Mobile IPv6 [MIP6], the Level 3 Multihoming Shim Protocol 47 [SHIM6], and the Host Identity Protocol [HIP]. Each of them 48 addresses different aspects of the overall mobility and multi-homing 49 problems. The set of features compared herein was constructed based 50 on taking the union of the problem statements for each protocol. As 51 we will see, significant overlap exists, but each has unique aspects 52 that the others do not address. 54 Draft IP Mobility Comparison October 2006 56 This comparison shows a snapshot in time, and there may be 57 additional work not mentioned here which adds capabilities to one or 58 more of the protocols discussed herein. Only work currently within 59 the IETF has been considered in the tables below. Finally, only 60 IPv6 is considered within this document, although some protocols may 61 work for IPv4 as well. 63 In this document, three types of identifiers are referred to: 65 Name: A DNS fully-qualified domain name. 67 Upper-layer Identifier (ULID): An address used by protocols and 68 applications above the mobility/multi-homing sub-layer. In MIP6, 69 this is a Home Address (HoA). SHIM6 uses normal IPv6 addresses 70 as upper-layer identifiers, and calls them ULIDs when used as 71 such. In HIP, this is a Host Identity Tag (HIT). 73 Locator: An address used for routing below the mobility/multi-homing 74 sub-layer. In MIP6, this is a Care-of Address. SHIM6 and HIP 75 use normal IPv6 addresses and simply call them Locators. 77 2. Layering 79 MIP6, SHIM6, and HIP all insert a conceptual sub-layer between the 80 routing portion of the network layer, and the transport layer. Each 81 of them does some processing in the data path for specific headers. 83 MIP6 uses a Destination Options Header with a Home Address Option in 84 data packets sent from a home address, and a Type 2 Routing Header 85 in packets sent to a home address. SHIM6 defines a Payload 86 Extension Header. HIP uses the Encapsulating Security Payload 87 header itself. A theoretical packet with all of the above present, 88 plus other extension headers, would thus look like this: 90 +------+------+-------+---------+-------+------+-------+---------- 91 | IPv6 | HbH | Type2 | DstOpts | SHIM6 | Frag | ESP | Payload 92 | Hdr | Opts | RtHdr | (HoA) | PEH | Hdr | (HIP) | 93 +------+------+-------+---------+-------+------+-------+---------- 95 As can be seen from this, MIP6 headers appear first, followed by 96 SHIM6, followed by HIP. As such, a natural organization in an 97 implementation would be (ignoring other destination options): 99 Draft IP Mobility Comparison October 2006 101 +============================+ 102 | Transport layer | 103 +============================+ 104 | IPsec + HIP sub-layer | \ 105 +----------------------------+ \ 106 | Fragmentation/reassembly | \ 107 +----------------------------+ \ 108 | SHIM6 sub-layer | Network layer 109 +----------------------------+ / 110 | MIP6 sub-layer | / 111 +----------------------------+ / 112 | Routing sub-layer | / 113 +============================+ 115 3. Feature Comparison 117 The following table summarizes the features compared in this 118 section. Each line has a corresponding section below with a more 119 detailed explanation. 121 +-------------------+--------------+-------------+-----------------+ 122 | | MIP6 | SHIM6 | HIP | 123 +-------------------+--------------+-------------+-----------------+ 124 | Preserve | | | | 125 | established | Yes | Yes | Yes | 126 | connections | | | | 127 +-------------------+--------------+-------------+-----------------+ 128 | Support both ends | Yes | Only w/in | Yes | 129 | moving simultan. | | known set | | 130 +-------------------+--------------+-------------+-----------------+ 131 | Span path outages | No | Yes | No | 132 | | | | | 133 +-------------------+--------------+-------------+-----------------+ 134 | Resolve name to | | | | 135 | locators immed. | Yes | No | Yes | 136 | after move | | | | 137 +-------------------+--------------+-------------+-----------------+ 138 | Support referrals | Yes | Yes | Only by name | 139 +-------------------+--------------+-------------+-----------------+ 140 | Stable addresses | Yes | Assumed | Non-routable | 141 +-------------------+--------------+-------------+-----------------+ 142 | Support load | Yes | Yes | Yes | 143 | spreading | (monami6) | | | 144 +-------------------+--------------+-------------+-----------------+ 145 | Multicast support | Yes | Not mobile | No | 146 +-------------------+--------------+-------------+-----------------+ 148 3.1. Preserve established connections 150 All three protocols are able to preserve established connections 151 across a locator change, including by both sides simultaneously. 153 Draft IP Mobility Comparison October 2006 155 3.2. Support both ends moving simultan. 157 MIP6 and HIP both are able to preserve established connections even 158 if both ends move simultaneously. SHIM6 is only able to do so if at 159 least one end only moves to a new locator which has previously been 160 communicated to the other prior to the move. 162 3.3. Span path outages 164 A "path outage" here refers to a case where both ends of a 165 connection believe they have network connectivity and their locator 166 is valid, but the path between the locator pair is broken somewhere 167 in the middle of the network. 169 MIP6 is not able to preserve connections across such outages between 170 the correspondent node and the home address. HIP would be capable 171 of preserving connections across such outages, but has no mechanisms 172 for detecting failures end-to-end and testing alternate paths. 173 SHIM6 was designed for this scenario and is able to preserve 174 connections across such outages. 176 3.4. Resolve name to locators immed. after move 178 If the TTL in the DNS AAAA records is (say) 30 seconds, or if DNS 179 resolvers do not respect a TTL less than 30 seconds, then normally 180 new connections to a device would not be able to be established for 181 up to 30 seconds after the device moves to a new network location. 182 MIP6 and HIP are both able to accept new connections without waiting 183 for name resolution, since DNS records need not be updated when 184 moving. 186 SHIM6 does not attempt to address this problem. 188 3.5. Support referrals 190 In some applications and protocols, one device redirects another 191 device to a third device. Such a redirection may be by giving it 192 the name or the upper-layer identifier of the third party. Another 193 similar variation occurs when one device wants to connect back to 194 another device which previously connected to it. 196 MIP6 and SHIM6 both support such referrals by either name or upper- 197 layer identifier. 199 HIP, on the other hand, currently only supports referrals by name, 200 not upper-layer identifier. This is because there is currently no 201 way to get the locator corresponding to a HIT, without knowing the 202 name. As a result, applications and protocols that use address- 203 based referrals do not work with HIP. The IRTF is currently 204 investigating addressing this problem via a Distributed Hash Table. 206 Draft IP Mobility Comparison October 2006 208 3.6. Stable addresses 210 Many applications and higher-layer protocols today cache addresses 211 for a significant length of time. Because of this, there is often a 212 desire for stable (i.e., long-lived) upper-layer identifiers. 213 Typically this is desired to be able to accept new connections 214 immediately (section 3.2) and to support referrals (section 3.5). 215 It is also useful for management purposes. 217 MIP6 provides this by providing a stable Home Address. SHIM6 does 218 not attempt to address this problem, nor does it make the problem 219 any worse. HIP provides a stable upper-layer identifier, but it is 220 not a routable address. 222 3.7. Support load spreading 224 When multiple locators are advertised to another device, that other 225 device can do load spreading of different connections to the first 226 device by using different locators. 228 SHIM6 supports the ability to advertise multiple locators, whereas 229 MIP6 itself only advertises a single one, but there is work in 230 progress [MCOA] on extending MIP6 to advertise multiple locators. 231 HIP also supports the ability to advertise multiple locators, but 232 its ability to use them is not as mature as SHIM6. 234 3.8. Multicast support 236 MIP6 supports sourcing multicast from home addresses by tunneling it 237 through the home agent. In SHIM6, multicast can be sourced from any 238 address, but it does not support moving such sessions with SHIM6. 239 HIP, on the other hand, does not support sourcing multicast from 240 HITs. 242 4. Efficiency Considerations 244 The following table summarizes the efficiency metrics compared in 245 this section. Each line has a corresponding section below with a 246 more detailed explanation. 248 Draft IP Mobility Comparison October 2006 250 +--------------+-------------------+-------------+-----------------+ 251 | | MIP6 | SHIM6 | HIP | 252 +--------------+-------------------+-------------+-----------------+ 253 | Per-packet | 0 if both home / | 0 normally/ | 0 (beyond IPsec | 254 | overhead | 20/40 if src away | 8 if moved | transport mode) | 255 | (bytes) | + 24 if dest away | | | 256 +--------------+-------------------+-------------+-----------------+ 257 | Connect | 0 | 0 | 0 + 4 for IPsec | 258 | overhead | | | key negotiation | 259 | (messages) | | | | 260 +--------------+-------------------+-------------+-----------------+ 261 | Locator | 2 to update HA | | 3 to update RVS | 262 | change | + | | + | 263 | overhead | 6 / 4 (cga) / | 4 to update | 3 to update | 264 | (messages) | 0 if local (hmip6)| peer | peer | 265 | | to update peer | | | 266 +--------------+-------------------+-------------+-----------------+ 268 4.1. Per-packet overhead (bytes) 270 MIP6 uses a Destination Options Header with a Home Address Option 271 (20 bytes) in data packets sent from a home address. If packets are 272 reverse tunneled to a home agent, then there is instead an overhead 273 of at least 40 bytes (the size of an IPv6 Header), plus any other 274 extension headers used by the tunnel, if any, on packets between the 275 mobile node and the home agent 277 MIP6 uses a Type 2 Routing Header (24 bytes) in packets sent to a 278 home address. When both ends use home addresses, the overhead is 279 thus 44 bytes (or if reverse tunneling is used instead, 64 bytes 280 between the mobile node and the home agent). 282 If a packet is fragmented, the above overhead is added to every 283 fragment. 285 SHIM6 uses an 8-byte Payload Extension Header with data packets. If 286 a packet is fragment, this overhead is added to every fragment. 287 This overhead is only present after a locator change occurs. 289 HIP uses the IP Encapsulating Security Payload (ESP) within data 290 packets. As such, the overhead is equal to the size of the ESP 291 header, or 0 if IPsec transport mode would be used anyway. 292 Furthermore, its processing is per reassembled packet, not per 293 fragment. 295 4.2. Connect overhead 297 At the time data is first exchanged between a mobile node and a 298 correspondent node (e.g., a TCP connect), MIP6 generates no 299 additional messages prior to a switch to use route optimization. At 300 the time a mobile node is away from home and decides to use route 301 optimization, it generates 6 additional messages (Binding Update, 302 Draft IP Mobility Comparison October 2006 304 Binding Acknowledgement, Home Test Init, Home Test, Care-of Test 305 Init, and Care-of Test). 307 SHIM6 assumes the node is always at home and generates no messages 308 prior to a locator change. 310 In HIP, a node is always "away from home" in the sense that its 311 locator is never equal to the ULID (which is non-routable), and 312 hence it uses a 4-way handshake to negotiate IPsec state prior to 313 being able to send data. If IPsec would be used anyway, HIP 314 requires no additional messages (although whether this is the same, 315 more, or less overhead than typical IPsec overhead depends on the 316 key management protocol it is compared to). 318 4.3. Locator change overhead 320 To change a locator for existing communication, MIP6 generates 2 321 messages to update the Home Agent, and 6 (or 4 if the optimization 322 in [CGA] is used) to update the correspondent node. If the mobile 323 node is communicating with multiple correspondent nodes, the 2 to 324 update the Home Agent only applies once, not per correspondent node. 325 Hierarchical Mobile IPv6 [HMIP6] specifies an optimization which 326 avoids any messages to correspondent nodes in the case where the 327 mobile node moves within the same domain; it does so, however, at 328 the expense of requiring that a Mobility Anchor Point (MAP) is 329 deployed within that domain and routers are configured to advertise 330 it. 332 SHIM6 generates 4 messages to update the peer. HIP generates 3 333 messages to update the Rendezvous Server (RVS), and a 3 message 334 handshake to update each peer. 336 5. Deployment Considerations 338 The following table summarizes the deployment considerations 339 compared in this section. Each line has a corresponding section 340 below with a more detailed explanation. 342 +-------------------+----------------+-----------+-----------------+ 343 | | MIP6 | SHIM6 | HIP | 344 +-------------------+----------------+-----------+-----------------+ 345 | One-end benefit | Yes | No | No | 346 +-------------------+----------------+-----------+-----------------+ 347 | Typical | Home agent, | | Rendezvous Svr, | 348 | deployment | if hmip used: | None | New RR, IPsec | 349 | dependencies | MAP + config | | | 350 | | routers | | | 351 +-------------------+----------------+-----------+-----------------+ 353 5.1. One-end benefit 355 Protocols that allow some partial benefit when only one end of a 356 connection supports the protocol have a deployment advantage over 357 Draft IP Mobility Comparison October 2006 359 those that require support from both ends. This is because the 360 former allows a new device to gain immediate benefit, whereas the 361 latter only gives significant benefit once the majority of devices 362 it talks to are upgraded. 364 MIP6 provides benefit for a mobile node even without support in 365 correspondent nodes; traffic is simply less efficient since traffic 366 must be routed via the home agent rather than using route 367 optimization. 369 SHIM6 and HIP both require support in both ends before their 370 benefits can be realized. 372 5.2. Typical deployment dependencies 374 To gain the full benefits of a protocol, often additional deployment 375 dependencies exist on other protocols or servers. 377 MIP6 depends on the existence of a MIP6 Home Agent to be deployed. 378 As noted in section 4.3, the HMIP6 optimization also requires that a 379 Mobility Anchor Point be deployed within a domain desiring the 380 optimization for local movement, and also that routers in that 381 domain be configured to advertise it. 383 SHIM6 has no outside dependencies. 385 HIP depends on the IPsec [IPSEC] protocol for basic operation. It 386 also depends on the existence of a HIP Rendezvous Server for its 387 mobility mechanisms. Finally, it requires a new DNS resource 388 record, and to gain the full security benefit, it depends on the 389 DNSSec [DNSSEC] protocol. However, the dependency on DNSSec to 390 secure the name-to-ULID-related information is the same as for the 391 other protocols, which do not attempt to address the key negotiation 392 problem. 394 6. Security Considerations 396 Security considerations for each protocol discussed herein are 397 covered in the respective protocol documents. A brief comparison of 398 their security aspects is listed below. 400 Draft IP Mobility Comparison October 2006 402 +-------------------+--------------+-------------+-----------------+ 404 | | MIP6 | SHIM6 | HIP | 405 +-------------------+--------------+-------------+-----------------+ 406 | Control message | | | | 407 | auth check | | | | 408 | Minimum | On path | On path + | Cryptographic | 409 | | | same node | | 410 | --------+--------------+-------------+-----------------+ 411 | Maximum | Crypto. | Crypto. | Crypto. | 412 +-------------------+--------------+-------------+-----------------+ 413 | Maximum control | Crypto. | Crypto. | Crypto. | 414 | msg auth check | | | | 415 +-------------------+--------------+-------------+-----------------+ 416 | Data security | Optional | Optional | Required | 417 +-------------------+--------------+-------------+-----------------+ 419 6.1. Control message auth check 421 Control messages indicating a locator change must be authenticated. 422 MIP6 and SHIM6 at minimum only verify that control messages were 423 originated by someone on the path between the two ends. MIP6 at a 424 mimum only verifies that control messages were originated by someone 425 on the path between the two ends using a return routability test, 426 but allows optional cryptographic checks (using what is known as 427 Cryptographically Generated Addresses (CGAs) [CGA]) for more 428 security. SHIM6 also uses a return routability test, plus at least 429 a verification that the new locator is a locator of the same node 430 (but does not verify that the control message was actually sent by 431 that node) using a technique known as Hash-Based Addresses; it also 432 optionally allows CGAs for more security. 434 HIP, on the other hand, requires strong cryptographic checks on all 435 control messages. 437 6.2. Data security 439 HIP requires that IPsec [IPSEC] be used for data, whereas IPsec is 440 optional for MIP6 and SHIM6. 442 7. IANA Considerations 444 This document has no actions for IANA. 446 8. Acknowledgements 448 Marcelo Bagnulo, Tom Henderson, Vijay Devarapalli, and Hesham 449 Soliman provided valuable feedback and technical information 450 regarding this draft. 452 Draft IP Mobility Comparison October 2006 454 9. Informative References 456 [CGA] Arkko, J., Vogt, C., and W. Haddad, "Applying 457 Cryptographically Generated Addresses and Credit-Based 458 Authorization to Mobile IPv6", Internet Draft, draft-ietf- 459 mipshop-cga-cba-01.txt, September 2006. 461 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 462 Rose, "DNS Security Introduction and Requirements", RFC 463 4033, March 2005. 465 [HIP] Moskowitz, R. and P. Nikander, "Host Identity Protocol 466 (HIP) Architecture", RFC 4423, May 2006. 468 [HMIP6] Soliman, H., Castelluccia, C., El Malki, K., and L. 469 Bellier, "Hierarchical Mobile IPv6 Mobility Management 470 (HMIPv6)", RFC 4140, August 2005. 472 [IPSEC] Kent, S. And K. Seo, "Security Architecture for the 473 Internet Protocol", RFC 4301, December 2005. 475 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 476 in IPv6", RFC 3775, June 2004. 478 [MCOA] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of 479 Addresses Registration", Internet Draft, draft-ietf- 480 monami6-multiplecoa-00.txt, June 2006. 482 [SHIM6] Nordmark, E. And M. Bagnulo, "Level 3 multihoming shim 483 protocol", Internet Draft, draft-ietf-shim6-proto-05.txt, 484 May 2006. 486 Authors' Addresses 488 Dave Thaler 489 Microsoft 490 One Microsoft Way 491 Redmond, WA 98052 492 Phone: +1 425 703 8835 493 Email: dthaler@microsoft.com 495 Full Copyright Statement 497 Copyright (C) The Internet Society (2006). 499 This document is subject to the rights, licenses and restrictions 500 contained in BCP 78, and except as set forth therein, the authors 501 retain all their rights. 503 This document and the information contained herein are provided on 504 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 505 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 506 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 507 Draft IP Mobility Comparison October 2006 509 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 510 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Intellectual Property 515 The IETF takes no position regarding the validity or scope of any 516 Intellectual Property Rights or other rights that might be claimed 517 to pertain to the implementation or use of the technology described 518 in this document or the extent to which any license under such 519 rights might or might not be available; nor does it represent that 520 it has made any independent effort to identify any such rights. 521 Information on the procedures with respect to rights in RFC 522 documents can be found in BCP 78 and BCP 79. 524 Copies of IPR disclosures made to the IETF Secretariat and any 525 assurances of licenses to be made available, or the result of an 526 attempt made to obtain a general license or permission for the use 527 of such proprietary rights by implementers or users of this 528 specification can be obtained from the IETF on-line IPR repository 529 at http://www.ietf.org/ipr. 531 The IETF invites any interested party to bring to its attention any 532 copyrights, patents or patent applications, or other proprietary 533 rights that may cover technology that may be required to implement 534 this standard. Please address the information to the IETF at ietf- 535 ipr@ietf.org. 537 Thaler Expires August 2006 11