idnits 2.17.1 draft-chakrabarti-ipv6-addrselect-api-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 == Line 153 has weird spacing: '...rom the defau...' == Line 171 has weird spacing: '...cessful home-...' == Line 185 has weird spacing: '... a node may b...' == Line 222 has weird spacing: '...terface as so...' == Line 223 has weird spacing: '... source addr ...' == (5 more instances...) -- 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 (June 29, 2003) is 7606 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: '4' is defined on line 523, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 536, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (ref. '1') (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. '2') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-22 -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '6') (Obsoleted by RFC 4941) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 5 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: December 28, 2003 Sun Microsystems, Inc. 5 J. Laganier 6 ENS Lyon / Sun Microsystems, Inc. 7 June 29, 2003 9 IPv6 Socket API for source address selection 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 http:// 28 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 December 28, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 The IPv6 default address selection document describes the rules for 42 selecting default source address by the system and indicates that the 43 applications should be able to reverse the sense of system preference 44 of source address selection for that application through possible API 45 extensions. However, no such socket API exists in the basic or 46 advanced IPv6 socket API documents. Hence this document specifies 47 socket level options to prefer a particular source address as per 48 choice of the applications. It also discusses implications on the 49 name-to-address translation API that performs part of the default 50 address selection. The socket APIs described in this document will 51 be particularly useful for Mobile IPv6 enabled applications and other 52 IPv6 applications which want to choose between temporary and public 53 addresses, CGA (cryptographically generated addresses) and non-CGA 54 addresses etc.. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Example Usages . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Changes to the Socket Interface . . . . . . . . . . . . . . . 6 61 4. Changes to the protocol-independent nodename translation . . . 9 62 5. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . . . 12 63 6. Validation function for source address . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 67 Normative References . . . . . . . . . . . . . . . . . . . . . 17 68 Informative References . . . . . . . . . . . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 70 A. Intellectual Property Statement . . . . . . . . . . . . . . . 19 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 This document defines socket extensions to support the non-default 76 choice of source address by the applications. The IPv6 default 77 address selection [1] document has specified the rules for system 78 default source address selection for an outbound IPv6 packet. 79 Privacy considerations [6] have introduced "public" and "temporary" 80 addresses. IPv6 Mobility [3] introduces "home address" and "care- 81 of-address" definitions in the mobile systems. Although it is 82 desirable to have default algorithms for the system to choose the 83 source address of the outgoing IPv6 packet, an application may want 84 to reverse that rule for efficiency and other application specific 85 reasons. Currently IPv6 socket API extensions provide mechanism to 86 choose a specific source address through simple bind() operation or 87 IPV6_PKTINFO socket option [5]. Thus in order to use bind() or 88 IPV6_PKTINFO socket option, the application itself must make sure 89 that the source address is appropriate for the destination address 90 (e.g., with respect to the interface used to send packets to the 91 destination). The application also needs to make sure about the 92 appropriate scope of source address with respect to the destination 93 address and so on. The mechanism presented in this document allows 94 the application to specify attributes of the source addresses it 95 prefers while still having the system do the rest of the default 96 address selection. For instance, if an application prefers to use 97 care-of-address of a mobile node as the source address and if the 98 mobile node has two care-of-addresses (one public and one temporary), 99 then the node would select the public care-of-address by following 100 the default address selection rule for public and temporary address. 102 A socket option has been deemed useful for this purpose, as it 103 enables an application to make a choice of source address at per- 104 socket basis. It can also provide flexibility of enabling and 105 disabling choice of source addresses in non-connected sockets. The 106 socket option uses a set of flags for source address preferences. 107 Since source address selection and destination address ordering need 108 to be partially implemented in getaddrinfo() [2] the corresponding 109 set of flags are also defined for that routine. 111 Thus this document introduces several flags for source address 112 selection to alter the default source address selection [1] for a 113 number of cases. It also provides flags for choosing CGA [7] and 114 non-CGA source addresses when CGA addresses are available in the 115 system. In future, more flags can be added to designate a choice for 116 a certain type of source address as the needs may arise. 118 The approach in this document is to allow the application to specify 119 preferences on source addresses and not to be able to specify hard 120 requirements. Thus for instance, an application can set a flag in 121 order to prefer a temporary addresses, but if no temporary addresses 122 are available at the node, a public address would be chosen instead. 124 Specifying a 'requirement' for source address selection is not 125 adopted through the socket option flags due to the nature of 126 unreliable transport protocols where the failure of connect() 127 operation may appear late in the event of unavailability of the 128 required attribute of source address in the system. For example, if 129 an application 'requires' CGA addresses as the source address of its 130 outgoing packets and it fails without that, then the application may 131 verify the availability of the CGA address in the system after 132 setting the source address preference flags. This document defines a 133 verification function which applications may choose to use before 134 sending data on a connected socket. By "connected" socket we mean 135 that a connect() call is done after setting setsockopt() with the 136 preference attributes. Note that connect() can be used in UDP 137 datagram sockets as well. The purpose of checking the validation of 138 address after connect() call ensures the availability of the desired 139 address type; an application using only sendto() or sendmsg() cannot 140 guarantee that the validated address at the time of setsockopt() is 141 still being valid at the time of sending data . The configuration of 142 node may change or the address may expire between setsockopt() 143 setting and sendto() or sendmsg() call. 145 Furthermore, the approach is to define two flags for each purpose, so 146 that an application can specify either that it prefers 'X' or prefers 147 'not X', or it can choose not to set either of the flags relating to 148 'X' and leave it up to the system default, perhaps while specifying 149 its preferences for some other attribute of the source addresses. 150 For example, if setsockopt() with a preference to care-of-address is 151 set, but no flag is set to indicate a choice of temporary or public 152 address, then temporary vs. public source address selection will be 153 determined from the default source address selection [1] rules. 154 Thus not specifying either of "X" and "not X" leaves the "X" property 155 of the address selection at the system default. 157 2. Example Usages 159 The examples discussed here are limited to applications supporting 160 Mobile IPv6, IPv6 Privacy Extensions and Cryptographically Generated 161 Addresses. Address selection document [1] recommends that home 162 addresses should be preferred over care-of-address when both are 163 configured. However, a mobile node may want to prefer care-of- 164 address as source address for DNS query in the foreign network as it 165 normally means a shorter and local return path compared to the route 166 via the mobile node's home-agent when the query contains home-address 167 as source address. Another example is IKE application which requires 168 care-of-address as its source address for the initial security 169 association pair with Home Agent [3] while the mobile node boots up 170 at the foreign network and wants to do the key exchange before a 171 successful home-registration. Also a Mobile IPv6 aware application 172 may want to toggle between home-address and care-of-address depending 173 on its location and state of the application. It may also want to 174 open different sockets and use home-address as source address for one 175 socket and care-of-address for the others. 177 In a non-mobile environment, similarly an application may prefer to 178 use temporary address as source address for certain cases. By 179 default, the source address selction rule selects "public" address 180 when both are available. For example, an application supporting web 181 browser and mail-server may want to use "temporary" address for the 182 former and "public" address for the mail-server as a mail-server may 183 require reverse path for DNS records for anti-spam rules. 185 Similarly, a node may be configured to use the cryptographically 186 generated addresses by default, but an application may prefer not to 187 use it. For instance, fping, a debugging tool which tests basic 188 reachability of multiple destinations by sending packets in parallel, 189 may find that the cost and time incurred in proof-of- ownership by 190 CGA verification is not justified. On the other hand, when a node is 191 not configured for CGA as default, an application may prefer using 192 CGA by setting the socket option. It may subsequently verify that it 193 is truly bound to a CGA by first calling getsockname() and then 194 recomputing the CGA using the public key of the node. 196 Besides the above examples, the defined source address preference 197 flags can be used to specify or alter the system default values for 198 largest scope of addresses and native IPv6 vs. tunnel interface 199 addresses. 201 3. Changes to the Socket Interface 203 IPv6 Basic API [2] defines socket options for IPv6. This document 204 adds a new socket option at the IPPROTO_IPV6 level. This socket 205 option is called IPV6_SRC_PREFERENCES. It can be used with 206 setsockopt() and getsockopt() calls. This socket option takes a 207 32bit unsigned integer argument. The argument consists of a number 208 of flags which indicate the choice of source address selection. 210 The following flags are defined to alter or set the default rule of 211 source address selction algorithm discussed in the section 5 of 212 default address selection specification [1]. 214 . 216 IPV6_PREFER_SRC_HOME /* Prefer Home Address as source */ 217 IPV6_PREFER_SRC_COA /* Prefer Care-Of_address as source */ 218 IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */ 219 IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */ 220 IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */ 221 IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */ 222 IPV6_PREFER_SRC_TUNNEL /* Prefer tunnel interface as source */ 223 IPV6_PREFER_SRC_NATIVE /* Prefer native IPv6 source addr */ 224 IPV6_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope source */ 225 IPV6_PREFER_SRC_LOWERSCOPE /* Prefer less than largest scope */ 227 NOTE: No source preference flag for longest matching prefix is defined 228 here because it is beleived to be handled by the policy table defined 229 in the default address selection specificaiton. 231 The following example illustrates how it is used on a AF_INET6 232 socket: 234 uint32_t flags = IPV6_PREFER_SRC_COA; 236 if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES, 238 (char *) &flags, sizeof (flags)) == -1) { 240 perror("setsockopt IPV6_SRC_REFERENCES"); 242 } 243 When the IPV6_SRC_PREFERENCES is successfully set with setsockopt(), 244 the option value given is used to specify source address for any 245 connection initiation through the socket and all subsequent packets 246 sent via that socket. If no option is set, the system selects a 247 default value as per default address selction algorithm or by some 248 other equivalent means. 250 Setting conflicting flags at the same time results in the error 251 EINVAL. For example, setting 'X' and 'not X' is not allowed at the 252 same time. If flag is set as combination of 'X' and 'Y', and if 'Y' 253 is not applicable or available in the system, then the selected 254 source address contains property of 'X' and system default for the 255 property of 'Y'. For example, a possible valid combination of flags 256 can be: 258 IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_NATIVE 260 Sometimes an application being unaware of a previously set source 261 address preference may need to restore it after a while. In order to 262 achieve this, it needs to preserve the value of the previous source 263 address preference by doing a getsockopt() prior calling the 264 setsockopt() for IPV6_SRC_PREFERENCES. The returned preference flag 265 values should be saved by the application for restoring the 266 preference values in a later step. However, setsockopt() with a flag 267 value 0 resets the source address selection to the system default 268 policy. 270 Example: 272 uint32_t save_flag; 273 int optlen = sizeof (save_flag); 275 uint32_t flags = IPV6_PREFER_SRC_TMP; 277 /* Save the existing IPv6_SRC_PREFERENCE FLAG now */ 279 if (getsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES, 281 &save_flag, &optlen) == -1 { 283 perror("getsockopt IPV6_SRC_REFERENCES"); 285 } 286 if (!(save_flag & IPV6_PREFER_SRC_TMP)) { 287 if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES, 289 (char *) &flags, sizeof (flags)) == -1) { 291 perror("setsockopt IPV6_SRC_REFERENCES"); 293 } 295 } 297 If either bind() or IPV6_PKTINFO socket option is set with a specific 298 source address in the same application along with the address 299 preference socket option, then bind() or IPV6_PKTINFO option takes 300 precedence. 302 4. Changes to the protocol-independent nodename translation 304 Section 8 of Default Address Selection [1] document indicates 305 possible implementation strategies for getaddrinfo() [2]. One of 306 them suggests that getaddrinfo() collects available source/ 307 destination pair from the network layer after being sorted at the 308 network layer with full knowledge of source address selection. 309 Another strategy is to call down to network layer to retrieve source 310 address information and then sort the list in the context of 311 getaddrinfo(). 313 Thus if an application sets setsockopt() IPV6_SRC_PREFERENCES option 314 to alter the default address selection rules , it is recommended that 315 the apllication calls getaddrinfo() with the corresponding 316 AI_PREFER_SRC_* flags specified in this section. This ensures that 317 the first entry in the returned addrinfo structure has the matching 318 source address as chosen by the kernel due to the setsockopt() 319 IPV6_SRC_PREFERENCES operation, given all other rules being equal for 320 a specific destination. 322 There is no corresponding destination address selection rule for 323 source address selection rule 7, in default address selection 324 document. However, this API provides a way for an application to 325 make sure that the source address preference set in setsockopt() is 326 taken into account by the getaddrinfo() function. Let's consider an 327 example to understand this scenario. DA and DB are two global 328 destination addresses and the node has two global addresses SA and SB 329 through interface A and B respectively. SA is a temporary address 330 while SB is a public address. The application has set 331 IPV6_PREFER_SRC_TMP in the setsockopt() flag. The route to DA points 332 to interface A and route to DB points to interface B. Thus when 333 AI_PREFER_SRC_TMP is set , getaddrinfo() returns DA before DB and SA 334 before SB likewise. Similarly, getaddrinfo() returns DB before DA 335 when AI_PREFER_SRC_PUBLIC is set in this example. Thus the source 336 address preference is taking effect into destination address 337 selection and as well as source address selection by the 338 getaddrinfo() function. 340 The following numerical example clarifies the abover further. 342 Imagine a host with two addresses: 344 1234::1:1 public 346 9876::1:2 temporary 347 The destination has the following two addresses: 349 1234::9:3 351 9876::9:4 353 By default getaddrinfo() will return the destination addresses in the 354 order: 356 1234::9:3 358 9876::9:4 360 because the public source is preferred and 1234 matches more bits 361 with the public source address. On the other hand, if 362 AI_PREFER_SRC_TMP is set, getaddrinfo will return the addresses in 363 the reverse order since the temporary source address will be 364 preferred. 366 The following flags are added for the ai_flags in addrinfo data 367 structure defined in Basic IPv6 Socket API Extension [2]. 369 AI_PREFER_SRC_HOME /* Prefer Home Address */ 370 AI_PREFER_SRC_COA /* Prefer COA */ 371 AI_PREFER_SRC_TMP /* Prefer Temporary Address */ 372 AI_PREFER_SRC_PUBLIC /* Prefer Public Address */ 373 AI_PREFER_SRC_CGA /* Prefer CGA Address */ 374 AI_PREFER_SRC_NONCGA /* Prefer address other than CGA */ 375 AI_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope */ 376 AI_PREFER_SRC_LOWERSCOPE /* Prefer lower than largest scope */ 377 AI_PREFER_SRC_TUNNEL /* Prefer address of tunnel interface */ 378 AI_PREFER_SRC_NATIVE /* Prefer native IPv6 address */ 380 The above flags are ignored for the AF_INET address family as the 381 source address selection algorithm defined in section 5 of [1] only 382 applies to the IPv6 addresses. However, the flags may be applied to 383 IPv4-mapped addresses on a AF_INET6 socket. 385 If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_ 386 COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS [2]. 388 Some valid sequences of flags are: 390 AI_PREFER_SRC_HOME | AI_PREFER_SRC_PUBLIC 392 AI_PREFER_SRC_COA | AI_PREFER_SRC_PUBLIC 394 AI_PREFER_SRC_HOME | AI_PREFER_SRC_CGA 396 AI_PREFER_SRC_HOME | AI_PREFER_SRC_NONCGA 398 AI_PREFER_SRC_COA | AI_PREFER_SRC_CGA 400 AI_PREFER_SRC_COA | AI_PREFER_SRC_NONCGA 402 All the constants mentioned in this section for ai_flags are defined 403 in . 405 5. IPv4-mapped IPv6 Addresses 407 IPv4-mapped IPv6 addresses are supported in this API. In some cases 408 the IPv4-mapped addresses may not make much sense because the 409 attributes are IPv6 specific. For example, IPv6 temporary addresses 410 are not the same as IPv4 private addresses. However, the IPv4 411 mapped-address support may be useful for mobile home address and 412 care-of-address. At this point it is not understood, if this API has 413 any value to pure IPv4 addresses or AF_INET family of sockets. 415 Discussion: 417 Would it be simpler to define a seperate function for source address 418 selection purpose? 420 int get_srcaddrinfo(uint32_t srcflags, const struct addrinfo * hints, 422 struct addrinfo ** res); or some variant ? which operates only on 423 AF_INET6 sockets - it then does not overload the getaddrinfo AI flags 424 and also does not conflict with using original getaddrinfo() function 425 which deals with AF_INET and UNSPEC families. 427 6. Validation function for source address 429 Sometimes an application may have a requirement to set a specific 430 source address without which it chooses to fail. In that situation, 431 'preferred' addresses do not guarantee that the selected source 432 address for the outgoing packet is what the application wants. An 433 application which requires to set a specific type of source address 434 must verify that the system indeed has a valid source address for 435 the desired source address type. A validation function is defined 436 for this purpose: 438 . 440 boolean_t inet6_is_addr(struct in6_addr * srcaddr, uint32_t flags) 442 Where the flags contain the IPV6_PREFER_SRC_* flags. The function 443 expects a non-NULL input for srcaddr. It returns true when srcaddr 444 corresponds to a valid address in the node and that address type 445 satisfies the preference flag. If srcaddr input value does not 446 correspond to any address in the node or it does not match an 447 address which satisfy the preferences indicated, the function returns 448 false. 450 The above function is useful for an application in two ways: 452 1. verify the source address type with the preference choice after 453 calling setsockopt() and connect() followed by getsockname(). 455 2. verify that the source address returned in the addrinfo structure 456 in the getaddrinfo() function matches the choice of preference. 458 The verification function can be useful for both TCP and UDP socket 459 applications that use connect(). 461 Discussion 463 Does it make sense to make inet6_is_addr() function more flexible ? 464 i,e. one can pass NULL srcaddr and preference flag in order to find 465 out if such address type at all exists in the system. This is useful 466 feature for some applications which has hard requirement for the 467 address type. Although the validity result is not guaranteed to be 468 true all the time between the check and subsequent socket operation, 469 this feature may be useful for those address types which has higher 470 lifetime or validity expectancy such as scoped or tunnel interface 471 addresses. 473 7. Security Considerations 475 This document conforms to the same security implications as specified 476 in IPv6 Basic Socket API [2] document. Allowing applications to 477 specify a preference for temporary addresses provides per-application 478 (and per-socket) ability to use the privacy benefits of the temporary 479 addresses. 481 8. Open Issues 483 o Are there more flags we should define at this point in time? 485 o How about a separate func for get_srcadrinfo or something like 486 that? Should we ban IPv4 sockets to use this API ? Is 32bit flags 487 enough ? Would this API be used for other policy decisions such as 488 Security or Qos policy decision to choose an address ? It may be 489 easier to have separate API for IPSec and Qos, but then order of 490 preference of those API compared to the ones defined here, needs to 491 be defined. 493 o Should we make the validation function more generic and flexible ? 494 [See section 6 discussion ] 496 o Should we define a order of preference and combination of 497 attributes provided by IPV6_PREFER_SRC* flags ? 499 9. Acknowledgements 501 The authors like to thank members of mobile-ip and ipv6 working 502 groups for useful discussion on this topic. Richard Draves and Dave 503 Thaler suggested that getaddrinfo also needs to be considered along 504 with the new socket option. Gabriel Montenegro suggested that CGAs 505 may also be considered in this document. Thanks to Alain Durand, 506 Renee Danson, Alper Yegin and Francis Dupont for useful discussions. 508 Normative References 510 [1] Draves, R., "Default Address Selection for IPv6", RFC 3484, 511 August 2002. 513 [2] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, 514 "Basic Socket Interface Extensions for IPv6", RFC 3493, March 515 2003. 517 Informative References 519 [3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 520 IPv6", draft-ietf-mobileip-ipv6-22.txt (work in progress), May 521 2003. 523 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6), 524 Specification", RFC 2460, December 1998. 526 [5] Stevens, W., Thomas, M., Nordmark, E. and T. Jinmei, "Advanced 527 Sockets API for IPv6", RFC 3542, May 2003. 529 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 530 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 532 [7] Castelluccia, C. and G. Montenegro, "Securing Group Management 533 in IPv6 with Cryptographically Generated Addresses", draft- 534 irtf-gsec-sgmv6-01.txt (work in progress), July 2002. 536 [8] Montenegro, G. and C. Castelluccia, "Statistically Unique and 537 Cryptographically Verifiable (SUCV) Identifiers and 538 Addresses.", NDSS 2002, February 2002. 540 Authors' Addresses 542 Erik Nordmark 543 Sun Microsystems, Inc. 544 180, avenue de l'Europe 545 38334 Saint Ismier CEDEX 546 France 548 EMail: Erik.Nordmark@Sun.COM 550 Samita Chakrabarti 551 Sun Microsystems, Inc. 552 4150 Network Circle 553 Santa Clara, CA 95054 554 USA 556 EMail: Samita.Chakrabarti@Sun.COM 557 Julien Laganier 558 ENS Lyon / Sun Microsystems, Inc. 559 180, avenue de l'Europe 560 38334 Saint Ismier CEDEX 561 France 563 EMail: Julien.Laganier@Sun.COM 565 Appendix A. Intellectual Property Statement 567 This document defines a source preference flag to choose 568 Cryptographically Generated Address (CGA) as source address when 569 applicable. CGA are obtained using public keys and hashes to prove 570 address ownership. Several IPR claims have been made about such 571 methods. 573 Full Copyright Statement 575 Copyright (C) The Internet Society (2003). All Rights Reserved. 577 This document and translations of it may be copied and furnished to 578 others, and derivative works that comment on or otherwise explain it 579 or assist in its implementation may be prepared, copied, published 580 and distributed, in whole or in part, without restriction of any 581 kind, provided that the above copyright notice and this paragraph are 582 included on all such copies and derivative works. However, this 583 document itself may not be modified in any way, such as by removing 584 the copyright notice or references to the Internet Society or other 585 Internet organizations, except as needed for the purpose of 586 developing Internet standards in which case the procedures for 587 copyrights defined in the Internet Standards process must be 588 followed, or as required to translate it into languages other than 589 English. 591 The limited permissions granted above are perpetual and will not be 592 revoked by the Internet Society or its successors or assigns. 594 This document and the information contained herein is provided on an 595 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 596 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 597 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 598 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 599 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 601 Acknowledgement 603 Funding for the RFC Editor function is currently provided by the 604 Internet Society.