idnits 2.17.1 draft-ietf-shim6-locator-pair-selection-03.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 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 441. 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 (February 22, 2008) is 5880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-04 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-03 ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (ref. '6') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3484 (ref. '8') (Obsoleted by RFC 6724) Summary: 7 errors (**), 0 flaws (~~), 4 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 February 22, 2008 5 Expires: August 25, 2008 7 Default Locator-pair selection algorithm for the SHIM6 protocol 8 draft-ietf-shim6-locator-pair-selection-03 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 August 25, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 In this note, we present a locator-pair selection mechanism for the 42 shim6 protocol. The presented mechanism provides an ordered list of 43 available locator-pairs that can be used for outgoing traffic. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Preliminary considerations . . . . . . . . . . . . . . . . . . 4 49 2.1. Candidate Locator-pair set . . . . . . . . . . . . . . . . 4 50 2.2. Locator-pair States . . . . . . . . . . . . . . . . . . . 5 51 2.3. Locator preferences . . . . . . . . . . . . . . . . . . . 5 52 2.3.1. Remote locator preferences . . . . . . . . . . . . . . 5 53 2.3.2. Source locator preferences . . . . . . . . . . . . . . 6 54 2.4. Locator-pair selection table . . . . . . . . . . . . . . . 6 55 3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 6 56 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 57 4.1. Privacy considerations . . . . . . . . . . . . . . . . . . 8 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 Intellectual Property and Copyright Statements . . . . . . . . . . 11 63 1. Introduction 65 Once that a shim6 context is established between two peers, they are 66 free to select the best locator pair to continue the communication. 67 In particular, when an outage is detected, they will need to select a 68 new locator pair to rehome the communication. Besides, policy or 69 other considerations may lead to change the locator pair used in the 70 communication even if no outage has occurred. 72 In this note, we present a locator-pair selection mechanism for the 73 shim6 protocol. The presented mechanism provides an ordered list of 74 available locator-pairs that can be used for outgoing traffic (note 75 that since unidirectional locator pairs are supported by the shim6 76 protocol, the locator pair used in the outgoing direction may not 77 affect the locator pair used by the peer to send incoming traffic). 79 The motivation for having a locator selection mechanism different 80 than RFC 3484 [3] is that RFC 3484 was designed to select addresses 81 that were both identifiers and locators, so, in some cases the 82 selection criteria differs from the one used when selecting addresses 83 that will used only as locators. In particular, when addresses are 84 to be used as identifiers and as locators, stable addresses such as 85 Home Addresses are preferred over more temporary addresses as Care- 86 Off Addresses. If an address is to be used only as a locator, 87 probably the stability property is not as important as achieving a 88 more direct path, making a Care-off Address more attractive than a 89 Home Address. Similar considerations can be made with respect to 90 private and public addresses. In addition, the locator pair 91 selection mechanism described in this document incorporates into the 92 selection mechanism shim-specific information, such as available 93 reachability information and local and remote locator preferences 94 obtained through the shim6 protocol. Finally, the mechanism 95 presented in this note is a locator pair selection mechanism as 96 opposed to separate source address and destination address selection 97 mechanisms as described in RFC 3484. We think that such approach is 98 more appropriate for the shim6 protocol, since reachability seems to 99 be a property of an address pair rather than a property of a single 100 address. 102 The presented mechanism takes into account general properties of the 103 available addresses, in particular the address family (v4 or v6), 104 address scope [3], mobility consideration (Home-Addresses and Care- 105 off Addresses) [4], status of the addresses (Preferred and Deprecated 106 addresses) [5], privacy considerations (Public and Temporary 107 addresses) [6]. In addition it also takes into account shim6 108 specific information such as whether the addresses are known to be 109 locally operational (as defined in [2]), if locator pairs are know to 110 be unidirectionally operational [2], the local and remote preferences 111 for the different locators available in the shim6 context. 113 Multicast addresses are out of the scope of the document. 115 2. Preliminary considerations 117 2.1. Candidate Locator-pair set 119 We define the local set of locally-operational locators (LOLs(local)) 120 as the local locators that are included in the local locator set 121 (Ls(local) as defined in [1]) and that are locally operational as 122 defined in [2]. Locally operational addresses are discovered through 123 local means that are outside of the scope of this document. 125 We define the set of the locally-operational locators of the peer 126 (LOLs(peer)) as the remote locators that are included in the peer 127 locator set (Ls(peer) as defined in [1]) and that are locally 128 operational in the peer as defined in [2]. The peers' locally 129 operational locators are discovered through the Locator List Option 130 and the Locator Preferences Option (in particular the BROKEN flag) 131 defined in the shim protocol [1]. 133 The candidate locator-pair set is the set of locator pairs that can 134 be used to send packets in a shim context. 136 The candidate locator-pair set contains in all the possible locator 137 pairs formed with the first of them belonging to the local set of 138 locally-operational locators (LOLs(local)) and the second locator 139 belonging to the locally-operational locators of the peer 140 (LOLs(peer)). 142 This can be expressed as: 144 Cand_Loc_Pair_Set ={(x,y)/[x in LOLs(local) and y in LOLs(peer)} 146 Current shim6 protocol specification only supports IPv6 addresses as 147 locators. In case the shim6 protocol specification is updated and 148 IPv4 addresses are accepted as locators, the creation of the 149 Candidate Locator Pair Set must only accept locator pairs where both 150 source and destiantion address are of the same family. The result 151 would be the following formula:. 153 Cand_Loc_Pair_Set ={(x,y)/[family(x) = family(y)] AND [x in 154 LOLs(local) and y in LOLs(peer)]} 156 Question: should we allow locator pairs with all types of scope 157 combinations or should we restrict the type of scope combinations for 158 the inclusion in the cadidate set? If we don't allow all the 159 combinations, we can remove rule 1 aboput scopes 161 2.2. Locator-pair States 163 Locator pairs can be in the following state: 165 o Unidirectionally Operational state: As defined in [2], is when 166 packets send with the first locator as the source address and the 167 second locator as a destination address are known to reach the 168 destination. In the shim6 case, a locator pair is know to be 169 unidirectionally operational when there is fresh information about 170 packets reaching the peer, using the mechanisms defined in [2] or 171 thanks to recent ULP feedback. When the information about 172 reachability expires, the locator pair moves to Unknown state. 173 o Non-Operational state: The locator pair is known to be non- 174 operational i.e. that packets containing the first locator as 175 source address and the second locator as destination address do 176 not reach the destination. In the shim6 case this can be known 177 because recent attempts to exchange packets have failed. When the 178 information about unreachability expires, the locator pair moves 179 to Unknown state. 180 o Unknown state: No recent reachability information is available for 181 this locator-pair. 183 2.3. Locator preferences 185 2.3.1. Remote locator preferences 187 Remote locator preferences can be obtained through the shim6 protocol 188 using the Locator Preference option. The preferences consist in a 189 Flag octet, a Priority octet and an optional Weight octet. 191 The weight field express the relative weight for locators with the 192 same priority, and as defined in [7] larger weights should be given a 193 proportionally higher probability of being selected. In order to 194 include this probability information in the locator-pair selection 195 algorithm, a new weight* information is generated from the weight 196 values as following: 198 We order each set of destination addresses with the same priority and 199 defined weight values using the following algorithm defined in [7]: 201 Arrange all addresses (that have not been ordered yet) in any order, 202 except that all those with weight 0 are placed at the beginning of 203 the list. 205 Compute the sum of the weights of those addresses, and with each 206 address associate the running sum in the selected order. Then choose 207 a uniform (pseudo)random number between 0 and the sum computed 208 (inclusive), and select the address whose running sum value is the 209 first in the selected order which is greater than or equal to the 210 (pseudo)random number selected. This address is the next one to be 211 included in the ordered list. Remove this address from the set of 212 the unordered addresses and apply the described algorithm to the 213 unordered address set to select the next target address. Continue 214 the ordering process until there are no unordered addresses. 216 The weight* (W*1, W*2,...,W*N) values for each of the addresses is 217 their final position in the resulting ordered list. 219 The procedure is repeated for each one of the sets containing 220 destination addresses with equal priority. 222 The Weight information is not used in the locator-pair selection 223 mechanism, but the Weight* information is. 225 2.3.2. Source locator preferences 227 With respect to the local locator preferences, this document assumes 228 that the host will have a mechanism to express Priority and Weight 229 information for local locators similar to the one defined in [7]. 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 [4] and src2 is a Home Address, the prefer 303 (src1,dst1). This only applies to Mobile IP [4]. 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 [1]) and dst2 is not a Care-off address, 314 the prefer (src1,dst1). This only applies to Mobile IP [4]. 316 Other rules that may be worth taking into account are: 317 o Prefer native transport 318 o Prefer smaller scope 319 o Prefer most dissimilar locator pair to the currently used 320 o Prefer locator pair contained in incoming packet 321 o Longest prefix match 322 o Should we eliminate the site and link local addresses from the 323 accpetable locator set? 325 4. Security considerations 327 Note that according to the shim6 protocol specification, locators are 328 included in the Ls(peer) only after HBA/CGA verification has been 329 successful. This eliminates the possibility of using locators that 330 do not belong to the peer. Besides, it should be noted that before 331 using a given locator pair to actually send data packets, a 332 reachability test is performed in order to prevent flooding attacks. 334 4.1. Privacy considerations 336 Including or not RFC3041 [6] addresses in the Locator set available 337 for a shim6 context may have privacy implications. This is so 338 because of two reaosns: First, the inclusion of RFC 3041 addresses in 339 the locator set discloses the RFC3041 addresses of the host to the 340 peer. Second, the locator sets of both peers are exchanged in clear 341 text during the shim6 context establishment and/or in the subsequent 342 UPDATE messages. This means that an attacker located along the path 343 that can observe such packets can discover that all the addresses 344 included in the locator set belong to the same host, beating the 345 purpose of RFC3041 private addresses. So, when forming the locator 346 set of a shim6 context the host must take into account these privacy 347 considerations in order to decide whether to include RFC3041 348 addresses in the locator set of a shim6 context. 350 5. Acknowledgements 352 The idea of pre-assigning Weight* values for introducing the Weight 353 probability in the locator-pair selection process was suggested by 354 Albert Banchs. 356 Marcelo Bagnulo worked on this document while visiting Ericsson 357 Research laboratory Nomadiclab. 359 Iljitsch van Beijnum provided a detailed review of this document. 361 6. References 363 [1] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 364 protocol", draft-ietf-shim6-proto-04 (work in progress), 365 March 2006. 367 [2] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 368 Exploration Protocol for IPv6 Multihoming", 369 draft-ietf-shim6-failure-detection-03 (work in progress), 370 December 2005. 372 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 373 Architecture", RFC 4291, February 2006. 375 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 376 IPv6", RFC 3775, June 2004. 378 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 379 Autoconfiguration", RFC 2462, December 1998. 381 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 382 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 384 [7] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 385 specifying the location of services (DNS SRV)", RFC 2782, 386 February 2000. 388 [8] Draves, R., "Default Address Selection for Internet Protocol 389 version 6 (IPv6)", RFC 3484, February 2003. 391 Author's Address 393 Marcelo Bagnulo 394 Universidad Carlos III de Madrid 395 Av. Universidad 30 396 Leganes, Madrid 28911 397 SPAIN 399 Phone: 34 91 6248814 400 Email: marcelo@it.uc3m.es 401 URI: http://www.it.uc3m.es 403 Full Copyright Statement 405 Copyright (C) The IETF Trust (2008). 407 This document is subject to the rights, licenses and restrictions 408 contained in BCP 78, and except as set forth therein, the authors 409 retain all their rights. 411 This document and the information contained herein are provided on an 412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 414 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 415 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 416 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 419 Intellectual Property 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed to 423 pertain to the implementation or use of the technology described in 424 this document or the extent to which any license under such rights 425 might or might not be available; nor does it represent that it has 426 made any independent effort to identify any such rights. Information 427 on the procedures with respect to rights in RFC documents can be 428 found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use of 433 such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository at 435 http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at 441 ietf-ipr@ietf.org. 443 Acknowledgment 445 Funding for the RFC Editor function is provided by the IETF 446 Administrative Support Activity (IASA).