idnits 2.17.1 draft-bagnulo-shim6-locator-pair-selection-00.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 3978, Section 5.5 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (May 24, 2006) is 6546 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) == Unused Reference: '9' is defined on line 368, 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 3344 (ref. '5') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 2462 (ref. '6') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (ref. '7') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3484 (ref. '9') (Obsoleted by RFC 6724) Summary: 10 errors (**), 0 flaws (~~), 5 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 Expires: November 25, 2006 May 24, 2006 6 Default Locator-pair selection algorithm for the SHIM6 protocol 7 draft-bagnulo-shim6-locator-pair-selection-00 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 months 22 and may be updated, replaced, or obsoleted by other documents at any 23 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/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 25, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 In this note, we present a locator-pair selection mechanism for the 41 shim6 protocol. The presented mechanism provides an ordered list of 42 available locator-pairs that can be used for outgoing traffic. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Preliminary considerations . . . . . . . . . . . . . . . . . . 4 48 2.1. Candidate Locator-pair set . . . . . . . . . . . . . . . . 4 49 2.2. Locator-pair States . . . . . . . . . . . . . . . . . . . 4 50 2.3. Locator preferences . . . . . . . . . . . . . . . . . . . 5 51 2.3.1. Remote locator preferences . . . . . . . . . . . . . . 5 52 2.3.2. Source locator preferences . . . . . . . . . . . . . . 6 53 2.4. Locator-pair selection table . . . . . . . . . . . . . . . 6 54 2.5. About IPv4 addresses . . . . . . . . . . . . . . . . . . . 6 55 3. Default Locator-Pair Selection Algorithm . . . . . . . . . . . 6 56 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 Intellectual Property and Copyright Statements . . . . . . . . . . 11 62 1. Introduction 64 Once that a shim6 context is established between two peers, they are 65 free to select the best locator pair to continue the communication. 66 In particular, when an outage is detected, they will need to select a 67 new locator pair to rehome the communication. Besides, policy or 68 other considerations may lead to change the locator pair used in the 69 communication even if no outage has occurred. 71 In this note, we present a locator-pair selection mechanism for the 72 shim6 protocol. The presented mechanism provides an ordered list of 73 available locator-pairs that can be used for outgoing traffic (note 74 that since unidirectional locator pairs are supported by the shim6 75 protocol, the locator pair used in the outgoing direction may not 76 affect the locator pair used by the peer to send incoming traffic). 78 The motivation for having a locator selection mechanism different 79 than RFC 3484 [3] is that RFC 3484 was designed to select addresses 80 that were both identifiers and locators, so, in some cases the 81 selection criteria differs from the one used when selecting addresses 82 that will used only as locators. In particular, when addresses are 83 to be used as identifiers and as locators, stable addresses such as 84 Home Addresses are preferred over more temporary addresses as Care- 85 Off Addresses. If an address is to be used only as a locator, 86 probably the stability property is not as important as achieving a 87 more direct path, making a Care-off Address more attractive than a 88 Home Address. Similar considerations can be made with respect to 89 private and public addresses. In addition, the locator pair 90 selection mechanism described in this document incorporates into the 91 selection mechanism shim-specific information, such as available 92 reachability information and local and remote locator preferences 93 obtained through the shim6 protocol. Finally, the mechanism 94 presented in this note is a locator pair selection mechanism as 95 opposed to separate source address and destination address selection 96 mechanisms as described in RFC 3484. We think that such approach is 97 more appropriate for the shim6 protocol, since reachability seems to 98 be a property of an address pair rather than a property of a single 99 address. 101 The presented mechanism takes into account general properties of the 102 available addresses, in particular the address family (v4 or v6), 103 address scope [3], mobility consideration (Home-Addresses and Care- 104 off Addresses) [5], [4], status of the addresses (Preferred and 105 Deprecated addresses) [6], privacy considerations (Public and 106 Temporary addresses) [7]. In addition it also takes into account 107 shim6 specific information such as whether the addresses are known to 108 be locally operational (as defined in [2]), if locator pairs are know 109 to be unidirectionally operational [2], the local and remote 110 preferences for the different locators available in the shim6 111 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 Cand_Loc_Pair_Set ={(x,y)/[x in LOLs(local) and y in LOLs(peer)} 144 2.2. Locator-pair States 146 Locator pairs can be in the following state: 148 o Unidirectionally Operational state: As defined in [2], is when 149 packets send with the first locator as the source address and the 150 second locator as a destination address are known to reach the 151 destination. In the shim6 case, a locator pair is know to be 152 unidirectionally operational when there is fresh information about 153 packets reaching the peer, using the mechanisms defined in [2] or 154 thanks to recent ULP feedback. When the information about 155 reachability expires, the locator pair moves to Unknown state. 157 o Non-Operational state: The locator pair is known to be non- 158 operational i.e. that packets containing the first locator as 159 source address and the second locator as destination address do 160 not reach the destination. In the shim6 case this can be known 161 because recent attempts to exchange packets have failed. When the 162 information about unreachability expires, the locator pair moves 163 to Unknown state. 164 o Unknown state: No recent reachability information is available for 165 this locator-pair. 167 2.3. Locator preferences 169 2.3.1. Remote locator preferences 171 Remote locator preferences can be obtained through the shim6 protocol 172 using the Locator Preference option. The preferences consist in a 173 Flag octet, a Priority octet and an optional Weight octet. 175 The weight field express the relative weight for locators with the 176 same priority, and as defined in [8] larger weights should be given a 177 proportionally higher probability of being selected. In order to 178 include this probability information in the locator-pair selection 179 algorithm, a new weight* information is generated from the weight 180 values as following: 182 We order each set of destination addresses with the same priority and 183 defined weight values using the following algorithm defined in [8]: 185 Arrange all addresses (that have not been ordered yet) in any order, 186 except that all those with weight 0 are placed at the beginning of 187 the list. 189 Compute the sum of the weights of those addresses, and with each 190 address associate the running sum in the selected order. Then choose 191 a uniform random number between 0 and the sum computed (inclusive), 192 and select the address whose running sum value is the first in the 193 selected order which is greater than or equal to the random number 194 selected. This address is the next one to be included in the ordered 195 list. Remove this address from the set of the unordered addresses 196 and apply the described algorithm to the unordered address set to 197 select the next target address. Continue the ordering process until 198 there are no unordered addresses. 200 The weight* (W*1, W*2,...,W*N) values for each of the addresses is 201 their final position in the resulting ordered list. 203 The procedure is repeated for each one of the sets containing 204 destination addresses with equal priority. 206 The Weight information is not used in the locator-pair selection 207 mechanism, but the Weight* information is. 209 2.3.2. Source locator preferences 211 With respect to the local locator preferences, this document assumes 212 that the host will have a mechanism to express Priority and Weight 213 information for local locators similar to the one defined in [8]. 215 The same procedure is used to assign Weight* values to the source 216 locators that have the same priority value. 218 Note that destination and source addresses are never included in the 219 same set, even if they have the same priority value. 221 The Weight information is not used in the locator-pair s election 222 mechanism, but the Weight* information is. 224 2.4. Locator-pair selection table 226 We define the Locator-pair selection table to express preferences 227 about which source address prefix to use when communicating with a 228 given destination address prefix. The table contains entries having 229 a source prefix and a destination prefix each. Given a locator pair, 230 it is then possible to find a match when both the source prefix is 231 contained in the source address and the destination prefix is 232 contained in the destination address. 234 2.5. About IPv4 addresses 236 IPv4 addresses are considered to be Public in the RFC3041 sense, 237 Preferred in the RFC2462 sense. 239 3. Default Locator-Pair Selection Algorithm 241 The goal of the defualt locator-pair selection algorithm is to 242 produce an ordered list of locator pairs to be tried for rehoming an 243 ongoing communication. The ordered list can be produced with any 244 sorting algorithm. The set of rules described next are the 245 comparison criteria to be used in the locator-pair sorting algorithm. 246 This rules act must be processed in order and if a given rule selects 247 a locator pair over the other one, then the following rules don't 248 need to be processed and the selected locator pair is prefered. 250 We are comparing two locator pairs (src1,dst1) and (src2,dst2). Note 251 that in some cases the source or the destination addresses of the two 252 pairs may be equal. 254 Rule 1: Prefer the same address: If src1 = dst1 and src2 <> dst2, 255 then prefer (src1,dst1). 257 Rule 2: Prefer appropriate scope: If scope(src1) >= scope(dst1) and 258 scope(src2) < scope(dst2), then prefer (src1,dst1). 260 Rule 3: Avoid Non-Operational pairs: If (src1,dst1) is in Non- 261 Operational state and (src2,dst2) is in Unidirectionally 262 Operational or in Unknown state, then prefer (src2,dst2). 264 Rule 4: Prefer Unidirectionally Operational state: If (src1,dst1) is 265 in Unknown state and (src2,dst2) is in Unidirectionally 266 Operational, then prefer (src2,dst2). 268 Rule 5: Prefer fresher reachability information: If (src1,dst1) and 269 (src2,dst2) are both in Unidirectionally Operational state, 270 then prefer the one with smallest age information i.e. the 271 one for which newer reachability information is available. 273 Rule 6: Prefer same address family: If (src1,dst1) are both of the 274 same address family (v4/v6) and (src2,dst2) are of different 275 address family, then prefer (src1,dst1) (This could also be 276 done with the Locator-pair selection table) 278 Rule 7: Prefer matching scope: If scope(src1) = scope(dst1) and 279 scope(src2) < scope(dst2), then prefer (src1,dst1) 281 Rule 8: Prefer Locator-pair table match: If (dst1,src1) has a match 282 in the Locator-pair selection table and (src2,dst2) does not 283 have a match in the locator-pair selection table, then 284 prefer (dst1,src1). 286 Rule 9: Prefer Preferred addresses: If src1 address is a Preferred 287 address in the RFC2462 sense and src2 is a deprecated 288 address in the RFC2462 sense, then prefer (src1,dst1) 290 Rule 10: Prefer Local Priority: If src1 of (src1,dst1) has a lowest 291 Priority than src2 of (src2,dst2) then prefer (src1,dst1) 293 Rule 11: Prefer Local Weight*: If src1 of (src1,dst1) has a lowest 294 Weight* than src2 of (src2,dst2) then prefer (src1,dst1) 296 Rule 12: Prefer Temporary addresses: If src1 is a temporary address 297 [7] and src2 is a public address, the prefer (src1,dst1) 298 over (src2,dst2) 300 Rule 13: Prefer Local Care-off Addresses: If src1 is a Care-off 301 address [4] [5] and src2 is a Home Address, the prefer 302 (src1,dst1) 304 Rule 14: Prefer Remote Priority: If dst1 of (src1,dst1) has a lowest 305 Priority than dst2 of (src2,dst2) then prefer (src1,dst1) 307 Rule 15: Prefer Remote Weight*: If dst1 of (src1,dst1) has a lowest 308 Weight* than dst2 of (src2,dst2) then prefer (src1,dst1) 310 Rule 16: Prefer Remote Care-off Addresses: If dst1 is a Care-off 311 address (Temporary flag set in the Locator preferences 312 options defined in [1]) and dst2 is not a Care-off address, 313 the prefer (src1,dst1) 315 Rule 17: Prefer ULID-Pair: If (src1,dst1) is the ULID-pair of the 316 context, the prefer (src1,dst1) 318 Other rules that may be worth taking into account are: 319 o Prefer native transport 320 o Prefer smaller scope 321 o Prefer most dissimilar locator pair to the currently used 322 o Prefer locator pair contained in incoming packet 323 o Longest prefix match 325 4. Security considerations 327 TBD 329 5. Acknowledgements 331 The idea of pre-assigning Weight* values for introducing the Weight 332 probability in the locator-pair selection process was suggested by 333 Albert Banchs. 335 Marcelo Bagnulo worked on this document while visiting Ericsson 336 Research laboratory Nomadiclab. 338 6. References 340 [1] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 341 protocol", draft-ietf-shim6-proto-04 (work in progress), 342 March 2006. 344 [2] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 345 Exploration Protocol for IPv6 Multihoming", 346 draft-ietf-shim6-failure-detection-03 (work in progress), 347 December 2005. 349 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 350 Architecture", RFC 4291, February 2006. 352 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 353 IPv6", RFC 3775, June 2004. 355 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 356 August 2002. 358 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 359 Autoconfiguration", RFC 2462, December 1998. 361 [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless 362 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 364 [8] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 365 specifying the location of services (DNS SRV)", RFC 2782, 366 February 2000. 368 [9] Draves, R., "Default Address Selection for Internet Protocol 369 version 6 (IPv6)", RFC 3484, February 2003. 371 Author's Address 373 Marcelo Bagnulo 374 Universidad Carlos III de Madrid 375 Av. Universidad 30 376 Leganes, Madrid 28911 377 SPAIN 379 Phone: 34 91 6248814 380 Email: marcelo@it.uc3m.es 381 URI: http://www.it.uc3m.es 383 Intellectual Property Statement 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org. 407 Disclaimer of Validity 409 This document and the information contained herein are provided on an 410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 412 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 413 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 414 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 417 Copyright Statement 419 Copyright (C) The Internet Society (2006). This document is subject 420 to the rights, licenses and restrictions contained in BCP 78, and 421 except as set forth therein, the authors retain all their rights. 423 Acknowledgment 425 Funding for the RFC Editor function is currently provided by the 426 Internet Society.