idnits 2.17.1 draft-ietf-shim6-locator-pair-selection-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 23, 2008) is 5662 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3484' is defined on line 390, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Informational October 23, 2008 5 Expires: April 26, 2009 7 Default Locator-pair selection algorithm for the SHIM6 protocol 8 draft-ietf-shim6-locator-pair-selection-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2009. 35 Abstract 37 In this note, we present a locator-pair selection mechanism for the 38 shim6 protocol. The presented mechanism provides an ordered list of 39 available locator-pairs that can be used for outgoing traffic. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Preliminary considerations . . . . . . . . . . . . . . . . . . 4 45 2.1. Candidate Locator-pair set . . . . . . . . . . . . . . . . 4 46 2.2. Locator-pair States . . . . . . . . . . . . . . . . . . . 5 47 2.3. Locator preferences . . . . . . . . . . . . . . . . . . . 5 48 2.3.1. Remote locator preferences . . . . . . . . . . . . . . 5 49 2.3.2. Source locator preferences . . . . . . . . . . . . . . 6 50 2.4. Locator-pair selection table . . . . . . . . . . . . . . . 6 51 3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 7 52 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 53 4.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 Intellectual Property and Copyright Statements . . . . . . . . . . 11 59 1. Introduction 61 Once that a shim6 context is established between two peers, they are 62 free to select the best locator pair to continue the communication. 63 In particular, when an outage is detected, they will need to select a 64 new locator pair to rehome the communication. Besides, policy or 65 other considerations may lead to change the locator pair used in the 66 communication even if no outage has occurred. 68 In this note, we present a locator-pair selection mechanism for the 69 shim6 protocol. The presented mechanism provides an ordered list of 70 available locator-pairs that can be used for outgoing traffic (note 71 that since unidirectional locator pairs are supported by the shim6 72 protocol, the locator pair used in the outgoing direction may not 73 affect the locator pair used by the peer to send incoming traffic). 75 The motivation for having a locator selection mechanism different 76 than RFC 3484 [RFC4291] is that RFC 3484 was designed to select 77 addresses that were both identifiers and locators, so, in some cases 78 the selection criteria differs from the one used when selecting 79 addresses that will used only as locators. In particular, when 80 addresses are to be used as identifiers and as locators, stable 81 addresses such as Home Addresses are preferred over more temporary 82 addresses as Care-Off Addresses. If an address is to be used only as 83 a locator, probably the stability property is not as important as 84 achieving a more direct path, making a Care-off Address more 85 attractive than a Home Address. Similar considerations can be made 86 with respect to private and public addresses. In addition, the 87 locator pair selection mechanism described in this document 88 incorporates into the selection mechanism shim-specific information, 89 such as available reachability information and local and remote 90 locator preferences obtained through the shim6 protocol. Finally, 91 the mechanism presented in this note is a locator pair selection 92 mechanism as opposed to separate source address and destination 93 address selection mechanisms as described in RFC 3484. We think that 94 such approach is more appropriate for the shim6 protocol, since 95 reachability seems to be a property of an address pair rather than a 96 property of a single address. 98 The presented mechanism takes into account general properties of the 99 available addresses, in particular the address family (v4 or v6), 100 address scope [RFC4291], mobility consideration (Home-Addresses and 101 Care-off Addresses) [RFC3775], status of the addresses (Preferred and 102 Deprecated addresses) [RFC2462], privacy considerations (Public and 103 Temporary addresses) [RFC3041]. In addition it also takes into 104 account shim6 specific information such as whether the addresses are 105 known to be locally operational (as defined in [faildet]), if locator 106 pairs are know to be unidirectionally operational [faildet], the 107 local and remote preferences for the different locators available in 108 the shim6 context. 110 Multicast addresses are out of the scope of the document. 112 2. Preliminary considerations 114 2.1. Candidate Locator-pair set 116 We define the local set of locally-operational locators (LOLs(local)) 117 as the local locators that are included in the local locator set 118 (Ls(local) as defined in [shim]) and that are locally operational as 119 defined in [faildet]. Locally operational addresses are discovered 120 through local means that are outside of the scope of this document. 122 We define the set of the locally-operational locators of the peer 123 (LOLs(peer)) as the remote locators that are included in the peer 124 locator set (Ls(peer) as defined in [shim]) and that are locally 125 operational in the peer as defined in [faildet]. The peers' locally 126 operational locators are discovered through the Locator List Option 127 and the Locator Preferences Option (in particular the BROKEN flag) 128 defined in the shim protocol [shim]. 130 The candidate locator-pair set is the set of locator pairs that can 131 be used to send packets in a shim context. 133 The candidate locator-pair set contains in all the possible locator 134 pairs formed with the first of them belonging to the local set of 135 locally-operational locators (LOLs(local)) and the second locator 136 belonging to the locally-operational locators of the peer 137 (LOLs(peer)). 139 This can be expressed as: 141 Cand_Loc_Pair_Set ={(x,y)/[x in LOLs(local) and y in LOLs(peer)} 143 Current shim6 protocol specification only supports IPv6 addresses as 144 locators. In case the shim6 protocol specification is updated and 145 IPv4 addresses are accepted as locators, the creation of the 146 Candidate Locator Pair Set must only accept locator pairs where both 147 source and destiantion address are of the same family. The result 148 would be the following formula:. 150 Cand_Loc_Pair_Set ={(x,y)/[family(x) = family(y)] AND [x in 151 LOLs(local) and y in LOLs(peer)]} 153 Question: should we allow locator pairs with all types of scope 154 combinations or should we restrict the type of scope combinations for 155 the inclusion in the cadidate set? If we don't allow all the 156 combinations, we can remove rule 1 aboput scopes 158 2.2. Locator-pair States 160 Locator pairs can be in the following state: 162 o Unidirectionally Operational state: As defined in [faildet], is 163 when packets send with the first locator as the source address and 164 the second locator as a destination address are known to reach the 165 destination. In the shim6 case, a locator pair is know to be 166 unidirectionally operational when there is fresh information about 167 packets reaching the peer, using the mechanisms defined in 168 [faildet] or thanks to recent ULP feedback. When the information 169 about reachability expires, the locator pair moves to Unknown 170 state. 171 o Non-Operational state: The locator pair is known to be non- 172 operational i.e. that packets containing the first locator as 173 source address and the second locator as destination address do 174 not reach the destination. In the shim6 case this can be known 175 because recent attempts to exchange packets have failed. When the 176 information about unreachability expires, the locator pair moves 177 to Unknown state. 178 o Unknown state: No recent reachability information is available for 179 this locator-pair. 181 2.3. Locator preferences 183 2.3.1. Remote locator preferences 185 Remote locator preferences can be obtained through the shim6 protocol 186 using the Locator Preference option. The preferences consist in a 187 Flag octet, a Priority octet and an optional Weight octet. 189 The weight field express the relative weight for locators with the 190 same priority, and as defined in [RFC2782] larger weights should be 191 given a proportionally higher probability of being selected. In 192 order to include this probability information in the locator-pair 193 selection algorithm, a new weight* information is generated from the 194 weight values as following: 196 We order each set of destination addresses with the same priority and 197 defined weight values using the following algorithm defined in 198 [RFC2782]: 200 Arrange all addresses (that have not been ordered yet) in any order, 201 except that all those with weight 0 are placed at the beginning of 202 the list. 204 Compute the sum of the weights of those addresses, and with each 205 address associate the running sum in the selected order. Then choose 206 a uniform (pseudo)random number between 0 and the sum computed 207 (inclusive), and select the address whose running sum value is the 208 first in the selected order which is greater than or equal to the 209 (pseudo)random number selected. This address is the next one to be 210 included in the ordered list. Remove this address from the set of 211 the unordered addresses and apply the described algorithm to the 212 unordered address set to select the next target address. Continue 213 the ordering process until there are no unordered addresses. 215 The weight* (W*1, W*2,...,W*N) values for each of the addresses is 216 their final position in the resulting ordered list. 218 The procedure is repeated for each one of the sets containing 219 destination addresses with equal priority. 221 The Weight information is not used in the locator-pair selection 222 mechanism, but the Weight* information is. 224 2.3.2. Source locator preferences 226 With respect to the local locator preferences, this document assumes 227 that the host will have a mechanism to express Priority and Weight 228 information for local locators similar to the one defined in 229 [RFC2782]. 231 The same procedure is used to assign Weight* values to the source 232 locators that have the same priority value. 234 Note that destination and source addresses are never included in the 235 same set, even if they have the same priority value. 237 The Weight information is not used in the locator-pair s election 238 mechanism, but the Weight* information is. 240 2.4. Locator-pair selection table 242 We define the Locator-pair selection table to express preferences 243 about which source address prefix to use when communicating with a 244 given destination address prefix. The table contains entries having 245 a source prefix and a destination prefix each. Given a locator pair, 246 it is then possible to find a match when both the source prefix is 247 contained in the source address and the destination prefix is 248 contained in the destination address. 250 3. Default Locator-Pair Selection Algorithm 252 The goal of the defualt locator-pair selection algorithm is to 253 produce an ordered list of locator pairs to be tried for rehoming an 254 ongoing communication. The ordered list can be produced with any 255 sorting algorithm. The set of rules described next are the 256 comparison criteria to be used in the locator-pair sorting algorithm. 257 This rules act must be processed in order and if a given rule selects 258 a locator pair over the other one, then the following rules don't 259 need to be processed and the selected locator pair is prefered. 261 We are comparing two locator pairs (src1,dst1) and (src2,dst2). Note 262 that in some cases the source or the destination addresses of the two 263 pairs may be equal. 264 Rule 1: Prefer appropriate scope: If scope(src1) >= scope(dst1) and 265 scope(src2) < scope(dst2), then prefer (src1,dst1). 267 Rule 2: Avoid Non-Operational pairs: If (src1,dst1) is in Non- 268 Operational state and (src2,dst2) is in Unidirectionally 269 Operational or in Unknown state, then prefer (src2,dst2). 271 Rule 3: Prefer Unidirectionally Operational state: If (src1,dst1) is 272 in Unknown state and (src2,dst2) is in Unidirectionally 273 Operational, then prefer (src2,dst2). 275 Rule 4: Prefer fresher reachability information: If (src1,dst1) and 276 (src2,dst2) are both in Unidirectionally Operational state, 277 then prefer the one with smallest age information i.e. the 278 one for which newer reachability information is available. 280 Rule 5: Prefer ULID-Pair: If (src1,dst1) is the ULID-pair of the 281 context, the prefer (src1,dst1) 283 Rule 6: Prefer matching scope: If scope(src1) = scope(dst1) and 284 scope(src2) < scope(dst2), then prefer (src1,dst1) 286 Rule 7: Prefer Locator-pair table match: If (dst1,src1) has a match 287 in the Locator-pair selection table and (src2,dst2) does not 288 have a match in the locator-pair selection table, then 289 prefer (dst1,src1). 291 Rule 8: Prefer Preferred addresses: If src1 address is a Preferred 292 address in the RFC2462 sense and src2 is a deprecated 293 address in the RFC2462 sense, then prefer (src1,dst1) 295 Rule 9: Prefer Local Priority: If src1 of (src1,dst1) has a lowest 296 Priority than src2 of (src2,dst2) then prefer (src1,dst1) 298 Rule 10: Prefer Local Weight*: If src1 of (src1,dst1) has a lowest 299 Weight* than src2 of (src2,dst2) then prefer (src1,dst1) 301 Rule 11: Prefer Local Care-off Addresses: If src1 is a Care-off 302 address [RFC3775] and src2 is a Home Address, the prefer 303 (src1,dst1). This only applies to Mobile IP [RFC3775]. 305 Rule 12: Prefer Remote Priority: If dst1 of (src1,dst1) has a lowest 306 Priority than dst2 of (src2,dst2) then prefer (src1,dst1) 308 Rule 13: Prefer Remote Weight*: If dst1 of (src1,dst1) has a lowest 309 Weight* than dst2 of (src2,dst2) then prefer (src1,dst1) 311 Rule 14: Prefer Remote Care-off Addresses: If dst1 is a Care-off 312 address (Temporary flag set in the Locator preferences 313 options defined in [shim]) and dst2 is not a Care-off 314 address, the prefer (src1,dst1). This only applies to 315 Mobile IP [RFC3775]. 317 Other rules that may be worth taking into account are: 318 o Prefer native transport 319 o Prefer smaller scope 320 o Prefer most dissimilar locator pair to the currently used 321 o Prefer locator pair contained in incoming packet 322 o Longest prefix match 323 o Should we eliminate the site and link local addresses from the 324 accpetable locator set? 326 4. Security considerations 328 Note that according to the shim6 protocol specification, locators are 329 included in the Ls(peer) only after HBA/CGA verification has been 330 successful. This eliminates the possibility of using locators that 331 do not belong to the peer. Besides, it should be noted that before 332 using a given locator pair to actually send data packets, a 333 reachability test is performed in order to prevent flooding attacks. 335 4.1. Privacy considerations 337 Including or not RFC3041 [RFC3041] addresses in the Locator set 338 available for a shim6 context may have privacy implications. This is 339 so because of two reaosns: First, the inclusion of RFC 3041 addresses 340 in the locator set discloses the RFC3041 addresses of the host to the 341 peer. Second, the locator sets of both peers are exchanged in clear 342 text during the shim6 context establishment and/or in the subsequent 343 UPDATE messages. This means that an attacker located along the path 344 that can observe such packets can discover that all the addresses 345 included in the locator set belong to the same host, beating the 346 purpose of RFC3041 private addresses. So, when forming the locator 347 set of a shim6 context the host must take into account these privacy 348 considerations in order to decide whether to include RFC3041 349 addresses in the locator set of a shim6 context. 351 5. Acknowledgements 353 The idea of pre-assigning Weight* values for introducing the Weight 354 probability in the locator-pair selection process was suggested by 355 Albert Banchs. 357 Marcelo Bagnulo worked on this document while visiting Ericsson 358 Research laboratory Nomadiclab. 360 Iljitsch van Beijnum provided a detailed review of this document. 362 6. References 364 [shim] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 365 protocol", draft-ietf-shim6-proto-04 (work in progress), 366 March 2006. 368 [faildet] Arkko, J. and I. Beijnum, "Failure Detection and Locator 369 Pair Exploration Protocol for IPv6 Multihoming", 370 draft-ietf-shim6-failure-detection-03 (work in progress), 371 December 2005. 373 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 374 Architecture", RFC 4291, February 2006. 376 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 377 in IPv6", RFC 3775, June 2004. 379 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 380 Autoconfiguration", RFC 2462, December 1998. 382 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 383 Stateless Address Autoconfiguration in IPv6", RFC 3041, 384 January 2001. 386 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 387 specifying the location of services (DNS SRV)", RFC 2782, 388 February 2000. 390 [RFC3484] Draves, R., "Default Address Selection for Internet 391 Protocol version 6 (IPv6)", RFC 3484, February 2003. 393 Author's Address 395 Marcelo Bagnulo 396 Universidad Carlos III de Madrid 397 Av. Universidad 30 398 Leganes, Madrid 28911 399 SPAIN 401 Phone: 34 91 6248814 402 Email: marcelo@it.uc3m.es 403 URI: http://www.it.uc3m.es 405 Full Copyright Statement 407 Copyright (C) The IETF Trust (2008). 409 This document is subject to the rights, licenses and restrictions 410 contained in BCP 78, and except as set forth therein, the authors 411 retain all their rights. 413 This document and the information contained herein are provided on an 414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 416 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 417 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 418 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 421 Intellectual Property 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at 443 ietf-ipr@ietf.org.