idnits 2.17.1 draft-chakrabarti-ipv6-addrselect-api-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 858. ** 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.) ** There are 2 instances of lines with control characters in the document. 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 (July 12, 2005) is 6853 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '5' is defined on line 780, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 796, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (ref. '1') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3513 (ref. '2') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. '3') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '4') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '5') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '7') (Obsoleted by RFC 4941) == Outdated reference: A later version (-06) exists of draft-ietf-send-cga-01 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-mipext-advapi-03 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nordmark 3 Internet-Draft S. Chakrabarti 4 Expires: January 13, 2006 Sun Microsystems, Inc. 5 J. Laganier 6 DoCoMo Euro-Labs 7 July 12, 2005 9 IPv6 Socket API for Address Selection 10 draft-chakrabarti-ipv6-addrselect-api-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 13, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The IPv6 default address selection document, RFC 3484, describes the 44 rules for selecting source and destination IP addresses, and 45 indicates that the applications should be able to reverse the sense 46 of some of the address selection rules through some unspecified API. 47 However, no such socket API exists in the basic or advanced IPv6 48 socket API documents. This document fills that gap by specifying 49 socket level options add new flags for the getaddrinfo() API to 50 specify preferences for address selection that modify the default 51 address selection algorithm. The socket APIs described in this 52 document will be particularly useful for IPv6 applications that want 53 to choose between temporary and public addresses, and for Mobile IPv6 54 aware applications that want to use the Care-of-address for 55 communication. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Design Alternatives . . . . . . . . . . . . . . . . . . . . 6 61 3. Example Usages . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Additions to the Socket Interface . . . . . . . . . . . . . 9 63 5. Additions to the protocol-independent nodename translation . 11 64 6. Application Requirements . . . . . . . . . . . . . . . . . . 14 65 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . 16 66 8. Mapping to Default Address Selection Rules . . . . . . . . . 17 67 9. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . . 19 68 10. Validation function for source address . . . . . . . . . . . 20 69 11. Security Considerations . . . . . . . . . . . . . . . . . . 22 70 12. Changes from previous version of draft . . . . . . . . . . . 23 71 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 73 14.1 Normative References . . . . . . . . . . . . . . . . . . 25 74 14.2 Informative References . . . . . . . . . . . . . . . . . 25 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 76 A. Intellectual Property Statement . . . . . . . . . . . . . . 27 77 Intellectual Property and Copyright Statements . . . . . . . 28 79 1. Introduction 81 RFC 3484 [1] specifies the default address selection rules. This 82 document defines socket API extensions that allow the applications to 83 override the default choice of address selection. Privacy 84 considerations [7] have introduced "public" and "temporary" 85 addresses. IPv6 Mobility [4] introduces "home address" and "care-of- 86 address" definitions in the mobile systems. Some applications might 87 want to control whether large scope [2] or small scope IPv6 addresses 88 are preferred. 90 The default rules in [1] in summary are that a public address is 91 preferred over a temporary address, that a mobile IPv6 home address 92 is preferred over a care-of-address, and that a larger scope address 93 is preferred over a smaller scope address. Although it is desirable 94 to have default rules for address selection, an application may want 95 to reverse certain address selection rules for efficiency and other 96 application specific reasons. 98 Currently IPv6 socket API extensions provide mechanism to choose a 99 specific source address through simple bind() operation or 100 IPV6_PKTINFO socket option [6]. Thus in order to use bind() or 101 IPV6_PKTINFO socket option, the application itself must make sure 102 that the source address is appropriate for the destination address 103 (e.g., with respect to the interface used to send packets to the 104 destination). The application also needs to make sure about the 105 appropriate scope of source address with respect to the destination 106 address and so on. This can be quite complex for the application, 107 since in effect it needs to implement all the default address 108 selection rules in order to change its preferences with respect to 109 one of the rules. 111 The mechanism presented in this document allows the application to 112 specify attributes of the source (and destination) addresses it 113 prefers while still having the system perform the rest of the address 114 selection rules. For instance, if an application specifies that it 115 prefers to use a care-of-address over a home address as the source 116 address and if the host has two care-of-addresses, one public and one 117 temporary, then the host would select the public care-of-address by 118 following the default address selection rule for preferring a public 119 over a temporary address. 121 A socket option has been deemed useful for this purpose, as it 122 enables an application to specify address selection preferences on a 123 per-socket basis. It can also provide the flexibility of enabling 124 and disabling address selection preferences in non-connected (UDP) 125 sockets. The socket option uses a set of flags for address 126 preferences. Since source address selection and destination address 127 ordering need to be partially implemented in getaddrinfo() [3] the 128 corresponding set of flags are also defined for that routine. 130 As a result, this document introduces several flags for address 131 selection preferences that alter the default address selection [1] 132 for a number of rules. It analyzes the usefulness of providing API 133 functionality for different default address selection rules; it 134 provides API to alter only those rules that are possibly used by 135 certain classes of applications. In addition, it also considers CGA 136 [8][9] and non-CGA source addresses when CGA addresses are available 137 in the system. In the future, more destination or source flags may 138 be added to expand the API as the needs may arise. 140 The approach in this document is to allow the application to specify 141 preferences for address selection and not to be able to specify hard 142 requirements. Thus for instance, an application can set a flag to 143 prefer a temporary source address, but if no temporary source 144 addresses are available at the node, a public address would be chosen 145 instead. 147 Specifying hard requirements for address selection would be 148 problematic for several reasons. The major one is that in the vast 149 majority of cases the application would like to be able to 150 communicate even if an address with the 'optimal' attributes is not 151 available. For instance, an application that performs very short, 152 e.g., UDP, transactional exchanges, might prefer to use a care-of- 153 address when running on a mobile host which is away from home since 154 this provides a short round-trip time in many cases. But if the 155 application is running on a mobile host that is at home, or running 156 on a host which isn't providing Mobile IPv6, then it doesn't make 157 sense for the application to fail due to no care-of-address being 158 available. Also, in particular when using UDP sockets and the 159 sendto() primitive, the use of hard requirements would have been 160 problematic, since the set of available IP addresses might very well 161 have changed from when the application called getaddrinfo() until it 162 called sendto(), which would introduce new failure modes. 164 For the few applications that have hard requirements on the 165 attributes of the IP addresses it uses, this document defines a 166 verification function which such applications can use so that they 167 can properly fail to communicate if their address selection 168 requirements are not satisfied. 170 Furthermore, the approach is to define two flags for each rule that 171 can be modified, so that an application can specify either that it 172 prefers 'X' or prefers 'not X', or it can choose not to set either of 173 the flags relating to 'X' and leave it up to the system default (see 174 section 3.1). This approach allows different implementations to have 175 different system defaults, and works with getaddrinfo() as well as 176 setsockopt(). (For setsockopt a different approach could have been 177 chosen, but that would still require this approach for getaddrinfo.) 179 This document only specifies the extensions for the socket API since 180 the socket API is already specified in RFCs [3]. The intent is that 181 this document serve as a model for expressing preferences for 182 attributes of IP addresses, that also need to be expressable in other 183 networking API such as those found in middleware systems and the Java 184 environment. 186 2. Design Alternatives 188 Some suggested to have per-application flags instead of per-socket 189 flags. However, this design stays with per-socket flags for the 190 following reasons: 192 o While some system have per environment/application flags (such as 193 environment variables in Unix systems) this might not be available 194 in all systems which implement the socket API 196 o When an application links with some standard library that library, 197 unknown to the application, might be using the socket API. 198 Mechanisms that would provide per application flags may affect not 199 only the application itself but also the libraries creating risks 200 of unintended consequences. 202 Instead of the pair of 'X' and 'not X' flags for each rule that can 203 be modified, the socket option could have been defined to use a 204 single 'X' value for each rule. This would still have allowed 205 different implementations to have different default settings as long 206 as the applications were coded to first retrieve the default setting 207 (using getsockopt()), and then clear or set the 'X' flag according to 208 their preferences, and finally set the new value with setsockopt(). 210 But such an approach would not be possible for getaddrinfo(), because 211 all the preferences would need to be expressable in the parameters 212 that are passed with a single getaddrinfo() call. Hence, for 213 consistency, the 'X'/'not X' approach is used for both getaddrinfo() 214 and setsockopt(). 216 3. Example Usages 218 The examples discussed here are limited to applications supporting 219 Mobile IPv6, IPv6 Privacy Extensions and Cryptographically Generated 220 Addresses. Address selection document [1] recommends that home 221 addresses should be preferred over care-of-address when both are 222 configured. However, a mobile node may want to prefer care-of- 223 address as source address for DNS query in the foreign network as it 224 normally means a shorter and local return path compared to the route 225 via the mobile node's home-agent when the query contains home-address 226 as source address. Another example is IKE application which requires 227 care-of-address as its source address for the initial security 228 association pair with Home Agent [4] while the mobile node boots up 229 at the foreign network and wants to do the key exchange before a 230 successful home-registration. Also a Mobile IPv6 aware application 231 may want to toggle between home-address and care-of-address depending 232 on its location and state of the application. It may also want to 233 open different sockets and use home-address as source address for one 234 socket and care-of-address for the others. 236 In a non-mobile environment, similarly an application may prefer to 237 use temporary address as source address for certain cases. By 238 default, the source address selection rule selects "public" address 239 when both are available. For example, an application supporting web 240 browser and mail-server may want to use "temporary" address for the 241 former and "public" address for the mail-server as a mail-server may 242 require reverse path for DNS records for anti-spam rules. 244 Similarly, a node may be configured to use the cryptographically 245 generated addresses by default, as in Secure Neighbor Discovery, but 246 an application may prefer not to use it. For instance, fping, a 247 debugging tool which tests basic reachability of multiple 248 destinations by sending packets in parallel, may find that the cost 249 and time incurred in proof-of-ownership by CGA verification is not 250 justified. On the other hand, when a node is not configured for CGA 251 as default, an application may prefer using CGA by setting the socket 252 option. It may subsequently verify that it is truly bound to a CGA 253 by first calling getsockname() and then recomputing the CGA using the 254 public key of the node. 256 In addition to the above examples, the defined address preference 257 flags can be used to specify or alter the system default values for 258 largest scope of addresses as well. An application may want to use 259 only link-local source address to contact a node with global 260 destination address on the same link, it can do so by setting the 261 appropriate source address preference flag in the application. By 262 default the system would have chosen global source address. This 263 example assumes that only link-local and global addresses are 264 available on the nodes. 266 4. Additions to the Socket Interface 268 IPv6 Basic API [3] defines socket options for IPv6. This document 269 adds a new socket option at the IPPROTO_IPV6 level. This socket 270 option is called IPV6_ADDR_PREFERENCES. It can be used with 271 setsockopt() and getsockopt() calls. This socket option takes a 272 32bit unsigned integer argument. The argument consists of a number 273 of flags where each flag indicates an address selection preference 274 which modifies one of the rules in the default address selection 275 specification. 277 The following flags are defined to alter or set the default rule of 278 source and destination address selection rules discussed in default 279 address selection specification [1]. 281 . 283 IPV6_PREFER_SRC_HOME /* Prefer Home Address as source */ 285 IPV6_PREFER_SRC_COA /* Prefer Care-Of_address as source */ 287 IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */ 289 IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */ 291 IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */ 293 IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */ 295 IPV6_PREFER_SRC_LARGESCOPE /* Prefer larger scope source */ 297 IPV6_PREFER_SRC_SMALLSCOPE /* Prefer smaller scope source */ 299 NOTE: No source preference flag for longest matching prefix is 300 defined here because it is believed to be handled by the policy table 301 defined in the default address selection specification. 303 Flags corresponding to scoped destination address rules are defined 304 here as they make sense in the context of a sender. See section 8 305 for more analysis and mapping of rules and different flags. 307 IPV6_PREFER_DST_LARGESCOPE /* Prefer larger scope for dest */ 309 IPV6_PREFER_DST_SMALLSCOPE /* Prefer smaller scope for dest */ 311 The following example illustrates how it is used on a AF_INET6 312 socket: 314 uint32_t flags = IPV6_PREFER_SRC_COA; 316 if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, 317 (char *) &flags, sizeof (flags)) == -1) { 318 perror("setsockopt IPV6_ADDR_REFERENCES"); 319 } 321 When the IPV6_ADDR_PREFERENCES is successfully set with setsockopt(), 322 the option value given is used to specify address preference for any 323 connection initiation through the socket and all subsequent packets 324 sent via that socket. If no option is set, the system selects a 325 default value as per default address selection algorithm or by some 326 other equivalent means. 328 Setting conflicting flags at the same time results in the error 329 EINVAL. For example, setting 'X' and 'not X' is not allowed at the 330 same time. If flag is set as combination of 'X' and 'Y', and if 'Y' 331 is not applicable or available in the system, then the selected 332 address has attribute 'X' and system default for the attribute 'Y'. 333 For example, a possible valid combination of flags can be: 335 IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_LARGESCOPE 337 5. Additions to the protocol-independent nodename translation 339 Section 8 of Default Address Selection [1] document indicates 340 possible implementation strategies for getaddrinfo() [3]. One of 341 them suggests that getaddrinfo() collects available source/ 342 destination pair from the network layer after being sorted at the 343 network layer with full knowledge of source address selection. 344 Another strategy is to call down to network layer to retrieve source 345 address information and then sort the list in the context of 346 getaddrinfo(). 348 This implies that getaddrinfo() needs to be aware of the address 349 selection preferences of the application, since getaddrinfo() is 350 independent of any socket the application might be using. 352 Thus if an application uses setsockopt() with the 353 IPV6_ADDR_PREFERENCES option to alter the default address selection 354 rules, the application must also use the corresponding flags with its 355 getaddrinfo() call. The AI_PREFER_* flags that correspond to the 356 IPV6_PREFER_* flags are defined below. 358 There is no corresponding destination address selection rule for 359 source address selection rule 7, in default address selection 360 document. However, this API provides a way for an application to 361 make sure that the source address preference set in setsockopt() is 362 taken into account by the getaddrinfo() function. Let's consider an 363 example to understand this scenario. DA and DB are two global 364 destination addresses and the node has two global addresses SA and SB 365 through interface A and B respectively. SA is a temporary address 366 while SB is a public address. The application has set 367 IPV6_PREFER_SRC_TMP in the setsockopt() flag. The route to DA points 368 to interface A and route to DB points to interface B. Thus when 369 AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA 370 before SB likewise. Similarly, getaddrinfo() returns DB before DA 371 when AI_PREFER_SRC_PUBLIC is set in this example. Thus the source 372 address preference is taking effect into destination address 373 selection and as well as source address selection by the 374 getaddrinfo() function. 376 The following numerical example clarifies the above further. 378 Imagine a host with two addresses: 380 1234::1:1 public 382 9876::1:2 temporary 384 The destination has the following two addresses: 386 1234::9:3 388 9876::9:4 390 By default getaddrinfo() will return the destination addresses in the 391 order 393 1234::9:3 395 9876::9:4 397 because the public source is preferred and 1234 matches more bits 398 with the public source address. On the other hand, if 399 AI_PREFER_SRC_TMP is set, getaddrinfo will return the addresses in 400 the reverse order since the temporary source address will be 401 preferred. 403 The following flags are added for the ai_flags in addrinfo data 404 structure defined in Basic IPV6 Socket API Extension [3]. 406 AI_PREFER_SRC_HOME /* Prefer Home Address */ 408 AI_PREFER_SRC_COA /* Prefer COA */ 410 AI_PREFER_SRC_TMP /* Prefer Temporary Address */ 412 AI_PREFER_SRC_PUBLIC /* Prefer Public Address */ 414 AI_PREFER_SRC_CGA /* Prefer CGA Address */ 416 AI_PREFER_SRC_NONCGA /* Prefer address other than CGA */ 418 AI_PREFER_SRC_LARGESCOPE /* Prefer larger scope src */ 420 AI_PREFER_SRC_SMALLSCOPE /* Prefer smaller scope src */ 422 AI_PREFER_DST_LARGESCOPE /* Prefer larger scope dest. */ 424 AI_PREFER_DST_SMALLSCOPE /* Prefer smaller scope dest.*/ 426 The above flags are ignored for the AF_INET address family as the 427 address selection algorithm defined in section 5 of [1] only applies 428 to the IPv6 addresses. 430 If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_ 431 COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS [3]. 433 Some valid combinations of flags are: 435 AI_PREFER_SRC_HOME | AI_PREFER_SRC_PUBLIC 437 AI_PREFER_SRC_COA | AI_PREFER_SRC_PUBLIC 439 AI_PREFER_SRC_HOME | AI_PREFER_SRC_CGA 441 AI_PREFER_SRC_HOME | AI_PREFER_SRC_NONCGA 443 AI_PREFER_SRC_COA | AI_PREFER_SRC_CGA 445 AI_PREFER_SRC_COA | AI_PREFER_SRC_NONCGA 447 AI_PREFER_SRC_LARGESCOPE | AI_PREFER_DST_LARGESCOPE 449 AI_PREFER_SRC_SMALLSCOPE | AI_PREFER_DST_SMALLSCOPE 451 AI_PREFER_SRC_LARGESCOPE | AI_PREFER_DST_LARGESCOPE | 452 AI_PREFER_SRC_PUBLIC 454 All the constants mentioned in this section for ai_flags are defined 455 in . 457 6. Application Requirements 459 An application only needs to call getsockopt() prior calling 460 setsockopt() if the application needs to be able to restore the 461 socket back to the system default preferences. An application which 462 does not have this requirement can just use getaddrinfo() to specify 463 the preferences, followed by: 465 uint32_t flags; 467 flags = IPV6_PREFER_SRC_TMP; 468 if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, 469 (char *) &flags, sizeof (flags)) == -1) { 470 perror("setsockopt IPV6_ADDR_REFERENCES"); 471 } 473 An application which needs to be able to restore the default settings 474 on the socket would instead do this: 476 uint32_t save_flags, flags; 477 int optlen = sizeof (save_flags); 479 /* Save the existing IPv6_ADDR_PREFERENCE FLAG now */ 481 if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, 482 &save_flags, &optlen) == -1 { 483 perror("getsockopt IPV6_ADDR_REFERENCES"); 484 } 486 /* Set the new flags */ 487 flags = IPV6_PREFER_SRC_TMP; 488 if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, 489 (char *) &flags, sizeof (flags)) == -1) { 490 perror("setsockopt IPV6_ADDR_REFERENCES"); 491 } 493 /* Do some work with the socket */ 494 ; 495 / Restore the flags */ 496 flags = IPV6_PREFER_SRC_TMP; 497 if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, 498 (char *) &save_flags, sizeof (save_flags)) == -1) { 499 perror("setsockopt IPV6_ADDR_REFERENCES"); 500 } 502 Application must not set conflicting flags; the only conflicts that 503 are checked for are flag X and flag not-X being set at the same time. 505 Example of conflicting flags: IPV6_PREFER_SRC_TMP | 506 IPV6_PREFER_SRC_PUBLIC. 508 In order to allow different implementations to do different parts of 509 address selection in getaddrinfo() and in the protocol stack, this 510 specification requires that applications set the same flags when 511 calling getaddrinfo() and when calling setsockopt(). For example, if 512 the application sets IPV6_PREFER_SRC_COA flag, it must use 513 AI_PREFER_SRC_COA flag when calling getaddrinfo(). If applications 514 are not setting the same flags the behavior of the implementation is 515 undefined. 517 It is envisioned that Mobile IPv6 applications may want to choose 518 Care-of-Address as source for short transaction (for efficiency) 519 while roaming, but still keep Home address as source address for long 520 lived communication for address stability. Thus it is recommended 521 that applications take this idea into consideration and use the 522 source address selection API for home-address and care-of -address 523 selection appropriately. Similarly, an application may choose to set 524 IPV6_PREFER_SRC_COA flag for datagram services; it uses home-address 525 as source when at home and uses care-of-address outside home-network 526 for short datagram transactions. This is an advantage of having 527 flexibility of "preference" vs. "requirement". 529 7. Implementation Notes 531 o If either bind() or IPV6_PKTINFO socket option is set with a 532 specific source address in the same application along with the 533 address preference socket option, then bind() or IPV6_PKTINFO 534 option takes precedence. 536 o setsockopt() should silently ignore any address preference flags 537 that are not supported in the system. For example, a host which 538 does not implement Mobile IPv6, should not fail setsockopt() or 539 getaddrinfo() that specify preferences for home or care-of- 540 addresses. The socket option calls should return error when 541 invalid flag values are passed to them. The invalid flag values 542 are: flag X and flag not-X (set at the same time). 544 o If an implementation supports both stream and datagram sockets, it 545 should implement the address preference mechanism API described in 546 this document on types of sockets. 548 o Implementation supporting this API must implement both AI flags 549 and socket option flags processing for portability of 550 applications. 552 o An implementation may choose to set the following flags by default 553 on the system (which is consistent with [1] defaults): 555 IPV6_PREFER_SRC_HOME 557 IPV6_PREFER_SRC_PUBLIC 559 IPV6_PREFER_SRC_LARGESCOPE 561 IPV6_PREFER_SRC_CGA 563 IPV6_PREFER_DST_SMALLSCOPE 565 8. Mapping to Default Address Selection Rules 567 This API defines only those flags that are deemed to be useful by the 568 applications to alter default address selection rules. Thus we 569 discuss the mapping of each set of flags to the corresponding rule 570 number in the address selection document[1]. 572 Source address selection rule #4 (prefer home address): 574 IPV6_PREFER_SRC_HOME (default) 576 IPV6_PREFER_SRC_COA 578 AI_PREFER_SRC_HOME (default) 580 AI_PREFER_SRC_COA 582 Source address selection rule #7 (prefer public address) : 584 IPV6_PREFER_SRC_PUBLIC (default) 586 IPV6_PREFER_SRC_TMP 588 AI_PREFER_SRC_PUBLIC (default) 590 AI_PREFER_SRC_TMP 592 Source address selection rule #2 (prefer appropriate scope): 594 IPV6_PREFER_SRC_LARGESCOPE (default) 596 IPV6_PREFER_SRC_SMALLSCOPE 598 AI_PREFER_SRC_LARGESCOPE (default) 600 AI_PREFER_SRC_SMALLSCOPE 602 The LARGESCOPE default above is to prefer source addresses that 603 have a scope equal or larger than the scope of the destination 604 address. The inverse is to prefer source address that have a 605 scope smaller than the scope of the destination address. 607 Destination address selection rule #8 ( prefer smaller scope): 609 IPV6_PREFER_DST_SMALLSCOPE (default) 611 IPV6_PREFER_DST_LARGESCOPE 612 AI_PREFER_DST_SMALLSCOPE (default) 614 AI_PREFER_DST_LARGESCOPE 616 Other destination rules (#4-prefer home address; #7-prefer native 617 interfaces) could have been applicable. But the problem is that the 618 local system does not know whether a destination address is a tunnel- 619 address for destination rule #7. It can only know for sure if the 620 destination address is one of its own. The flags defined for source 621 address selection rule #4 ( prefer home address) should also take 622 care of destination address selection rule #4. Thus at this point, 623 it was decided not to define flags for these destination rules. 625 Other source address rules (that are not mentioned here) were also 626 deemed not applicable for changing its default notion per-application 627 basis. 629 9. IPv4-mapped IPv6 Addresses 631 IPv4-mapped IPv6 addresses, which are IPv4 addresses in a form that 632 can be used on an AF_INET6 socket, are supported in this API. In 633 some cases the IPv4-mapped addresses may not make much sense because 634 the attributes are IPv6 specific. For example, IPv6 temporary 635 addresses are not the same as private IPv4 addresses. However, the 636 IPv4 mapped-address support may be useful for mobile home address and 637 care-of-address. At this point it is not understood whether this API 638 has any value to IPv4 addresses or AF_INET family of sockets. 640 10. Validation function for source address 642 Sometimes an application may have a requirement to only use address 643 with some particular attribute, and if no such address is available 644 the application should fail to communicate instead of communicating 645 using the 'wrong' address. In that situation, address selection 646 preferences do not guarantee that the application's requirements are 647 met, but instead the application has to explicitly verify that the 648 chosen address satisfies its requirements. Such an application would 649 go through the following steps: 651 1. The application specifies one or more AI_PREFER_* flags with 652 getaddrinfo(). 654 2. The application specifies the corresponding IPV6_PREFER_* flags 655 with setsockopt() 657 3. The application calls connect(). This applies even for datagram 658 (UDP) sockets, as the connect call results in the stack selecting 659 a source address, for TCP as well as UDP. 661 4. Retrieve the selected source address using the getsockname() API 662 call. 664 5. Verifying that the retrieved address is satisfactory as specified 665 below. If not, abort the communication e.g., by closing the 666 socket. 668 If the application has hard requirements on the scope of the source 669 address, then it can perform the verification using the APIs 670 specified in [3] such as IN6_IS_ADDR_LINKLOCAL. 672 The verification of temporary vs. public, home vs. care-of, CGA vs. 673 not, are performed by a new function defined for this purpose: 675 #include 677 boolean_t inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, 678 uint32_t flags); 680 Where the flags contain the specified source preference flags. The 681 function expects a non-NULL input for srcaddr. sockaddr_in6 structure 682 must contain AF_INET6 as sin6_family. It also must contain the 683 scope_id information if the source address is a link-local address. 685 The function returns true when srcaddr corresponds to a valid address 686 in the node and that address type satisfies the preference flag(s). 687 If srcaddr input value does not correspond to any address in the node 688 or it does not match an address which satisfy the preferences 689 indicated, the function returns false. 691 This function can handle multiple valid flags combination as its 692 second parameter, for example IPV6_PREFER_SRC_COA | 693 IPV6_PREFER_SRC_TMP, which means that all flags must be satisfied for 694 the result to be true. Invalid flag values result in false return 695 value. 697 The function will return true for IPV6_PREFER_SRC_HOME even if the 698 host is not implementing mobile IPv6, as well as for a mobile node 699 which is at home (i.e., does not have any care-of-address). 701 11. Security Considerations 703 This document conforms to the same security implications as specified 704 in IPv6 Basic Socket API [3] document. Allowing applications to 705 specify a preference for temporary addresses provides per-application 706 (and per-socket) ability to use the privacy benefits of the temporary 707 addresses. 709 12. Changes from previous version of draft 711 o Changed IPV6_SRC_PREFERENCES option to IPV6_ADDR_PREFERENCES to 712 include destination address preference for scope and for further 713 future enhancement which may include both source and destination 714 addresses. 716 o Added implementation and application requirements. 718 o Removed IPV6_PREFER_SRC_NATIVE and IPV6_PREFER_SRC_TUNNEL flags as 719 there is no corresponding source address rule in RFC3484. 720 Moreover it doesn't seem to make sense to add preference flags for 721 this destination addresses since: 723 * The local system doesn't in general know whether there is a 724 tunnel at the destination end and 726 * In the case (6to4) where the local system can tell there will 727 be a tunnel for a destination address the default policy table 728 already has a rule (for the 6to4 prefix). 730 Perhaps there should have been a source rule for tunnel vs. native 731 interface in default address selection specification in which case 732 it might have made sense to add a preference flag for that. 734 o Added section on default address selection rule mapping. 736 o Added comments on using JAVA API. 738 o Added four new flags for destination scoped addresses as some 739 working group members felt the requirement of altering default 740 destination address scope. 742 o Clarified when getsockopt needs to be used. Removed text that 743 said a setsockopt with flags=0 would restore the preferences to 744 the system defaults. 746 o Added text showing the different ways the validation can be 747 performed. The validation of scope is quite different than the 748 validation function for other address selection preferences. 750 13. Acknowledgments 752 The authors like to thank members of mobile-ip and ipv6 working 753 groups for useful discussion on this topic. Richard Draves and Dave 754 Thaler suggested that getaddrinfo also needs to be considered along 755 with the new socket option. Gabriel Montenegro suggested that CGAs 756 may also be considered in this document. Thanks to Alain Durand, 757 Renee Danson, Alper Yegin, Francis Dupont, Michael Hunter, Sebastien 758 Roy, Robert Elz, Jinmei Tatuya, Pekka Savola, Itojun, Jim Bound, Jeff 759 Boote and Mika Liljeberg for useful discussions and suggestions. 761 14. References 763 14.1 Normative References 765 [1] Draves, R., "Default Address Selection for IPv6", RFC 3484, 766 August 2002. 768 [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 769 Addressing Architecture", RFC 3513, April 2003. 771 [3] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 772 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 773 March 2003. 775 14.2 Informative References 777 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 778 IPv6", RFC 3775, June 2004. 780 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 781 (IPv6), Specification", RFC 2460, December 1998. 783 [6] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced 784 Sockets API for IPv6", RFC 3542, May 2003. 786 [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless 787 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 789 [8] Aura, T., "Cryptographically Generated Addresses (CGA)", 790 draft-ietf-send-cga-01.txt (work in progress), August 2003. 792 [9] Montenegro, G. and C. Castelluccia, "Statistically Unique and 793 Cryptographically Verifiable (SUCV) Identifiers and 794 Addresses.", NDSS 2002, February 2002. 796 [10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for 797 Mobile IPv6", draft-ietf-mip6-mipext-advapi-03.txt (work in 798 progress), September 2004. 800 Authors' Addresses 802 Erik Nordmark 803 Sun Microsystems, Inc. 804 4150 Network Circle, UMPK17-308 805 Santa Clara, CA 95054 806 USA 808 Email: Erik.Nordmark@Sun.COM 810 Samita Chakrabarti 811 Sun Microsystems, Inc. 812 4150 Network Circle, UMPK16-157 813 Santa Clara, CA 95054 814 USA 816 Email: Samita.Chakrabarti@Sun.COM 818 Julien Laganier 819 DoCoMo Communications Laboratories Europe GmbH 820 Landsberger Strasse 312 821 Munich 80687 822 Germany 824 Phone: +49 89 56824 231 825 Email: julien.ietf@laposte.net 826 URI: http://www.docomolab-euro.com/ 828 Appendix A. Intellectual Property Statement 830 This document only defines a source preference flag to choose 831 Cryptographically Generated Address (CGA) as source address when 832 applicable. CGA are obtained using public keys and hashes to prove 833 address ownership. Several IPR claims have been made about such 834 methods. 836 Intellectual Property Statement 838 The IETF takes no position regarding the validity or scope of any 839 Intellectual Property Rights or other rights that might be claimed to 840 pertain to the implementation or use of the technology described in 841 this document or the extent to which any license under such rights 842 might or might not be available; nor does it represent that it has 843 made any independent effort to identify any such rights. Information 844 on the procedures with respect to rights in RFC documents can be 845 found in BCP 78 and BCP 79. 847 Copies of IPR disclosures made to the IETF Secretariat and any 848 assurances of licenses to be made available, or the result of an 849 attempt made to obtain a general license or permission for the use of 850 such proprietary rights by implementers or users of this 851 specification can be obtained from the IETF on-line IPR repository at 852 http://www.ietf.org/ipr. 854 The IETF invites any interested party to bring to its attention any 855 copyrights, patents or patent applications, or other proprietary 856 rights that may cover technology that may be required to implement 857 this standard. Please address the information to the IETF at 858 ietf-ipr@ietf.org. 860 Disclaimer of Validity 862 This document and the information contained herein are provided on an 863 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 864 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 865 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 866 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 867 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Copyright Statement 872 Copyright (C) The Internet Society (2005). This document is subject 873 to the rights, licenses and restrictions contained in BCP 78, and 874 except as set forth therein, the authors retain all their rights. 876 Acknowledgment 878 Funding for the RFC Editor function is currently provided by the 879 Internet Society.