idnits 2.17.1 draft-ietf-mip6-mipext-advapi-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1164. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 207 has weird spacing: '...ggested name ...' == Line 271 has weird spacing: '... struct ip6_m...' == Line 283 has weird spacing: '... struct ip6_m...' == Line 295 has weird spacing: '... struct ip6_...' == Line 308 has weird spacing: '... struct ip6_...' == (36 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 (December 7, 2005) is 6708 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) == Missing Reference: '12' is mentioned on line 439, but not defined == Missing Reference: '16' is mentioned on line 521, but not defined == Missing Reference: '0' is mentioned on line 596, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3542 (ref. '1') ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '3') (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-chakrabarti-ipv6-addrselect-api-03 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 WG S. Chakrabarti 3 Internet-Draft E. Nordmark 4 Expires: June 10, 2006 Sun Microsystems 5 December 7, 2005 7 Extension to Sockets API for Mobile IPv6 8 draft-ietf-mip6-mipext-advapi-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 10, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes data structures and API support for Mobile 42 IPv6 as an extension to the Advanced Socket API for IPv6. 44 Just as the Advanced Sockets API for IPv6 gives access to various 45 extension headers and the ICMPv6 protocol, this document specifies 46 the same level of access for Mobile IPv6 components. It specifies a 47 mechanism for applications to retrieve and set information for 48 Mobility Header messages, Home Address destination options and 49 Routing Header Type 2 extension headers. It also specifies the 50 common data structures and definitions that might be used by certain 51 advanced Mobile IPv6 socket applications. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Common Structures and Definitions . . . . . . . . . . . . . 7 59 4.1 The Mobility Header Data Structures . . . . . . . . . . . 7 60 4.1.1 The ip6_mh Structure . . . . . . . . . . . . . . . . . 7 61 4.1.2 Binding Refresh Request Mobility Message . . . . . . . 8 62 4.1.3 Home Address Test Init (HoTI) Message . . . . . . . . 8 63 4.1.4 Care-of Address Test Init (CoTI) Message . . . . . . . 8 64 4.1.5 Home Address Test (HOT) Message . . . . . . . . . . . 9 65 4.1.6 Care Of Address Test (COT) Message . . . . . . . . . . 9 66 4.1.7 Binding Update Mobility Message . . . . . . . . . . . 9 67 4.1.8 Binding Acknowledgment Mobility Message . . . . . . . 10 68 4.1.9 Binding Error Mobility Message . . . . . . . . . . . . 10 69 4.1.10 Mobility Option TLV data structure . . . . . . . . . 10 70 4.1.11 Mobility Option Data Structures . . . . . . . . . . 11 71 4.2 Mobility Header Constants . . . . . . . . . . . . . . . . 11 72 4.3 IPv6 Home Address Destination Option . . . . . . . . . . . 13 73 4.4 Type 2 Routing Header . . . . . . . . . . . . . . . . . . 14 74 4.5 New ICMP Messages for Mobile IPv6 . . . . . . . . . . . . 14 75 4.6 IPv6 Neighbor Discovery Changes . . . . . . . . . . . . . 16 76 5. Access to Home Address Destination Option and Routing 77 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 5.1 Routing Header access functions . . . . . . . . . . . . . 19 79 5.2 Content of Type 2 Routing Header . . . . . . . . . . . . . 21 80 5.3 Order of extension headers for Home Address Destination 81 Options . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.4 Home Address Destination Option access functions . . . . . 22 83 5.5 Content of Home Address Destination option . . . . . . . . 23 84 6. Mobility Protocol Headers . . . . . . . . . . . . . . . . . 24 85 6.1 Receiving and Sending Mobility Header Messages . . . . . . 24 86 7. Protocols File . . . . . . . . . . . . . . . . . . . . . . . 26 87 8. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . 27 88 9. Security Considerations . . . . . . . . . . . . . . . . . . 28 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 90 11. Changes from last revisions . . . . . . . . . . . . . . . . 30 91 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 31 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 93 13.1 Normative References . . . . . . . . . . . . . . . . . . 32 94 13.2 Informative References . . . . . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 96 Intellectual Property and Copyright Statements . . . . . . . 34 98 1. Introduction 100 Mobility Support in IPv6 [2] defines a new Mobility Protocol header, 101 a Home Address destination option and a new Routing Header type. It 102 is expected that Mobile IPv6 user-level implementations and some 103 special applications will need to access and process these IPv6 104 extension headers. This document is an extension to the existing 105 Advanced Sockets API document [1]; it addresses the Advanced IPv6 106 Sockets API for these new protocol elements defined by Mobile IPv6. 108 The applicability of this API mainly targets user-level applications. 109 However, it has also shown to be useful within some Mobile IPv6 110 implementations; for instance, where part of the Mobile IPv6 protocol 111 is implemented at user-level and part in the kernel. It is up to any 112 such implementations to architect which part of the Mobile IPv6 and 113 IPSec packet processing should be done at the user-level in order to 114 meet the design needs of the particular platform and operating 115 system. 117 The target user-level applications for this socket API are believed 118 to be debugging and diagnostic applications as well as some policy 119 applications which would like to receive a copy of protocol 120 information at the application layer. 122 The packet information along with access to the extension headers 123 (Routing header and Destination options) are specified using the 124 "ancillary data" fields that were added to the 4.3BSD Reno sockets 125 API in 1990. The reason is that these ancillary data fields are part 126 of the Posix.1g standard and should therefore be adopted by most 127 vendors. This document is consistent with Advanced Sockets API for 128 IPv6 [1] in structure definitions, header files and function 129 definitions. Thus, the implementors of this API document are assumed 130 to be familiar with the data structures, data sending and receiving 131 procedures and the IPv6 extension header access funtions described in 132 the Advanced Sockets API for IPv6 [1]. 134 Non-goals 136 This document does not address application access to either the 137 authentication header or the encapsulating security payload header. 138 This document also does not address any API that might be necessary 139 for Mobile Network [4] specific needs. Furthermore, it should be 140 noted that this API document excludes discussion on application level 141 API. It assumes that address selection socket API [5] takes care of 142 selection of Care-of-address or home-address as the source address by 143 the application, when source address selection is required due to the 144 nature of the application. 146 Providing mobility "awareness" to applications, such as applications 147 being able to tell whether the host is at home or not, is out of 148 scope for this API. 150 2. Applicability 152 This API document can be applied in the following cases: 154 1. User-level debugging and monitoring tools: This socket API is 155 useful for accessing Mobility Headers, Home-address options and 156 Type 2 Routing Headers . For example, mh-ping might be a 157 monitoring tool which can process mobility headers on the 158 receiving side to check binding status. 160 2. Partial user-level implementation of Mobile IPv6: We assume that 161 some implementations may choose to do the Mobility header 162 processing at user level. In that case, this document recommends 163 implementing at least the handling of Home-address options and 164 Type 2 Routing Header in the main IP processing paths in the 165 kernel. The API can then be used to send and receive the 166 Mobility Header packets used for Mobile IPv6 signalling. 168 3. Complete header processing at the kernel-level: Many 169 implementations of Mobile IPv6 [2] perform processing of Home 170 Address Options, Routing Headers and Mobility headers at the 171 kernel level. However, the kernel keeps a copy of the received 172 extension headers and passes them up to the API which is used by 173 the user-level applications purely for monitoring and debugging 174 Mobile IPv6 packets. 176 On an IPv6 host which does not implement Mobile IPv6, the IPv6 177 specification [3] requires that packets with the Home Address option 178 or Routing Header of type 2 (where segments left is non-zero) be 179 dropped on receipt. This means that it is not possible to implement 180 Mobile IPv6 as an application on such a system. Thus on such a 181 system, the applicability of this API is limited to the first case 182 above of debugging and monitoring applications (such as tcpdump) 183 being able to parse and interpret Mobile IPv6 packets. 185 3. Overview 187 This document can be divided into the following parts: 189 1. Definitions of constants and structures for C programs that 190 capture the Mobile IPv6 packet formats on the wire. A common 191 definition of these is useful at least for packet snooping 192 applications. This is captured in Section 4. In addition, 193 Section 4 also defines data structures for Home Address 194 destination option, Type 2 Routing Header, and new ICMPv6 195 messages related to Mobile IPv6. 197 2. Notes on how to use the IPv6 Advanced API to access Home Address 198 options and type 2 Routing Headers. This is captured in 199 Section 5. 201 3. Notes on how user-level applications can observe MH (Mobility 202 Header) packets using raw sockets (in Section 6). The IPv6 RAW 203 socket interface described in this document allows applications 204 to receive MH packets whether or not the system's MH processing 205 takes place in the "kernel" or at the "user space". 207 4. Suggested name for /etc/protocols (in Section 7). 209 All examples in this document omit error checking in favor of 210 brevity, as it is following the same style as the Advanced Socket API 211 [1]. 213 We note that many of the functions and socket options defined in this 214 document may have error returns that are not defined in this 215 document. 217 Data types in this document follow the Posix.1g format: intN_t means 218 a signed integer of exactly N bits (e.g., int16_t) and uintN_t means 219 an unsigned integer of exactly N bits (e.g., uint32_t). 221 Once the API specification becomes mature and is deployed, it may be 222 formally standardized by a more appropriate body, such as has been 223 done with the Basic API [6]. However, since this specification 224 largely builds upon the Advanced Socket API [1], such standardization 225 would make sense only if the Advanced Socket API [1] were also 226 standardized. 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC 2119. 232 4. Common Structures and Definitions 234 ANSI-C provides few guarantees about the size and alignment of data 235 structures. Thus, depending on the implementation of a compiler, the 236 structures below might, when compiled, not match the packet formats 237 defined in RFC 3775 [2]. However, the structures are specified in a 238 way to maximize the probability that compilers will lay out the 239 structure in a way that is identical to the packet formats on the 240 wire. 242 Thus, the mobility header message data structures include the 243 mobility header fields such that they are consistent across different 244 compilers. 246 The structure definitions below are merely examples; the requirement 247 is that the structures contain the fields specified below. Depending 248 on the compiler used as well as the host byte order, the layout of 249 the structures might need to be different. But as long as they 250 provide the same fields as below we can ensure application 251 portability when using this API. 253 The constants shown below are in network byte order, so an 254 application needs to perform the appropriate byte order conversion 255 (ntohs(), etc) when using the constants. 257 The structures and constants below will be included when including 258 the (new) header file : 260 4.1 The Mobility Header Data Structures 262 4.1.1 The ip6_mh Structure 264 The following structure is defined as a result of including . This is the fixed part of the Mobility Header. Different 266 Mobility message types are defined Mobile IPv6 [2]. For portability 267 and alignment reasons, each mobility message type includes the 268 mobility header fields as opposed to including the ip6_mh structure 269 followed by the message-specific fields. 271 struct ip6_mh { 272 uint8_t ip6mh_proto; /* NO_NXTHDR by default */ 273 uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets 274 excluding the first 8 Octets */ 275 uint8_t ip6mh_type; /* Type of Mobility Header */ 276 uint8_t ip6mh_reserved; /* Reserved */ 277 uint16_t ip6mh_cksum; /* Mobility Header Checksum */ 278 /* Followed by type specific messages */ 279 }; 281 4.1.2 Binding Refresh Request Mobility Message 283 struct ip6_mh_binding_request { 284 uint8_t ip6mhbr_proto; 285 uint8_t ip6mhbr_hdrlen; 286 uint8_t ip6mhbr_type; 287 uint8_t ip6mhbr_reserved; 288 uint16_t ip6mhbr_cksum; 289 uint16_t ip6mhbr_reserved; 290 /* Followed by optional Mobility Options */ 291 }; 293 4.1.3 Home Address Test Init (HoTI) Message 295 struct ip6_mh_home_test_init { 296 uint8_t ip6mhhti_proto; 297 uint8_t ip6mhhti_hdrlen; 298 uint8_t ip6mhhti_type; 299 uint8_t ip6mhhti_reserved; 300 uint16_t ip6mhhti_cksum; 301 uint16_t ip6mhhti_reserved; 302 uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */ 303 /* Followed by optional Mobility Options */ 304 }; 306 4.1.4 Care-of Address Test Init (CoTI) Message 308 struct ip6_mh_careof_test_init { 309 uint8_t ip6mhcti_proto; 310 uint8_t ip6mhcti_hdrlen; 311 uint8_t ip6mhcti_type; 312 uint8_t ip6mhcti_reserved; 313 uint16_t ip6mhcti_cksum; 314 uint16_t ip6mhcti_reserved; 315 uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */ 316 /* Followed by optional Mobility Options */ 317 }; 319 4.1.5 Home Address Test (HOT) Message 321 struct ip6_mh_home_test { 322 uint8_t ip6mhht_proto; 323 uint8_t ip6mhht_hdrlen; 324 uint8_t ip6mhht_type; 325 uint8_t ip6mhht_reserved; 326 uint16_t ip6mhht_cksum; 327 uint16_t ip6mhht_nonce_index; 328 uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */ 329 uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */ 330 /* Followed by optional Mobility Options */ 331 }; 333 4.1.6 Care Of Address Test (COT) Message 335 struct ip6_mh_careof_test { 336 uint8_t ip6mhct_proto; 337 uint8_t ip6mhct_hdrlen; 338 uint8_t ip6mhct_type; 339 uint8_t ip6mhct_reserved; 340 uint16_t ip6mhct_cksum; 341 uint16_t ip6mhct_nonce_index; 342 uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */ 343 uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */ 344 /* Followed by optional Mobility Options */ 345 }; 347 4.1.7 Binding Update Mobility Message 349 struct ip6_mh_binding_update { 350 uint8_t ip6mhbu_proto; 351 uint8_t ip6mhbu_hdrlen; 352 uint8_t ip6mhbu_type; 353 uint8_t ip6mhbu_reserved; 354 uint16_t ip6mhbu_cksum; 355 uint16_t ip6mhbu_seqno; /* Sequence Number */ 356 uint16_t ip6mhbu_flags; 357 uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */ 358 /* Followed by optional Mobility Options */ 359 }; 361 /* Binding Update Flags, in network byte-order */ 362 #define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */ 363 #define IP6_MH_BU_HOME 0x4000 /* Home Registration */ 364 #define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */ 365 #define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */ 367 4.1.8 Binding Acknowledgment Mobility Message 369 struct ip6_mh_binding_ack { 370 uint8_t ip6mhba_proto; 371 uint8_t ip6mhba_hdrlen; 372 uint8_t ip6mhba_type; 373 uint8_t ip6mhba_reserved; 374 uint16_t ip6mhba_cksum; 375 uint8_t ip6mhba_status; /* Status code */ 376 uint8_t ip6mhba_flags; 377 uint16_t ip6mhba_seqno; 378 uint16_t ip6mhba_lifetime; 379 /* Followed by optional Mobility Options */ 380 }; 382 /* Binding Acknowledgement Flags */ 383 #define IP6_MH_BA_KEYM 0x80 /* Key management mobility */ 385 4.1.9 Binding Error Mobility Message 387 struct ip6_mh_binding_error { 388 uint8_t ip6mhbe_proto; 389 uint8_t ip6mhbe_hdrlen; 390 uint8_t ip6mhbe_type; 391 uint8_t ip6mhbe_reserved; 392 uint16_t ip6mhbe_cksum; 393 uint8_t ip6mhbe_status; /* Error Status */ 394 uint8_t ip6mhbe_reserved; 395 struct in6_addr ip6mhbe_homeaddr; 396 /* Followed by optional Mobility Options */ 397 }; 399 4.1.10 Mobility Option TLV data structure 401 struct ip6_mh_opt { 402 uint8_t ip6mhopt_type; /* Option Type */ 403 uint8_t ip6mhopt_len; /* Option Length */ 404 /* Followed by variable length Option Data in bytes */ 405 }; 407 4.1.11 Mobility Option Data Structures 409 4.1.11.1 Binding Refresh Advice 411 struct ip6_mh_opt_refresh_advice { 412 uint8_t ip6mora_type; 413 uint8_t ip6mora_len; 414 uint16_t ip6mora_interval; /* Refresh interval in 4 sec */ 415 }; 417 4.1.11.2 Alternate Care-of Address 419 struct ip6_mh_opt_altcoa { 420 uint8_t ip6moa_type; 421 uint8_t ip6moa_len; 422 struct in6_addr ip6moa_addr; /* Alternate CoA */ 423 }; 425 4.1.11.3 Nonce Indices 427 struct ip6_mh_opt_nonce_index { 428 uint8_t ip6moni_type; 429 uint8_t ip6moni_len; 430 uint16_t ip6moni_home_nonce; 431 uint16_t ip6moni_coa_nonce; 432 }; 434 4.1.11.4 Binding Authorization Data 436 struct ip6_mh_opt_auth_data { 437 uint8_t ip6moad_type; 438 uint8_t ip6moad_len; 439 uint8_t ip6moad_data[12]; 440 }; 442 4.2 Mobility Header Constants 444 IPv6 Next Header Value for Mobility: 446 448 #define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */ 450 Mobility Header Message Types: 452 454 #define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */ 455 #define IP6_MH_TYPE_HOTI 1 /* HOTI Message */ 456 #define IP6_MH_TYPE_COTI 2 /* COTI Message */ 457 #define IP6_MH_TYPE_HOT 3 /* HOT Message */ 458 #define IP6_MH_TYPE_COT 4 /* COT Message */ 459 #define IP6_MH_TYPE_BU 5 /* Binding Update */ 460 #define IP6_MH_TYPE_BACK 6 /* Binding ACK */ 461 #define IP6_MH_TYPE_BERROR 7 /* Binding Error */ 463 Mobility Header Message Option Types: 465 467 #define IP6_MHOPT_PAD1 0x00 /* PAD1 */ 468 #define IP6_MHOPT_PADN 0x01 /* PADN */ 469 #define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */ 470 #define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */ 471 #define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */ 472 #define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */ 474 Status values accompanied with Mobility Binding Acknowledgement: 476 477 #define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */ 478 #define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix 479 discovery Required */ 480 #define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */ 481 #define IP6_MH_BAS_PROHIBIT 129 /* Administratively 482 prohibited */ 483 #define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient 484 resources */ 485 #define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not 486 supported */ 487 #define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */ 488 #define IP6_MH_BAS_NOT_HA 133 /* Not HA for this 489 mobile node */ 490 #define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */ 491 #define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out 492 of range */ 494 #define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce 495 index */ 496 #define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of 497 nonce index */ 498 #define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce 499 Indices */ 500 #define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type 501 change disallowed */ 503 Status values for the Binding Error mobility messages: 505 507 #define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */ 508 #define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */ 510 4.3 IPv6 Home Address Destination Option 512 Due to alignment issues in the compiler, and the alignment 513 requirements for this option, the included IPv6 address must be 514 specified as an array of 16 octets. 516 517 /* Home Address Destination Option */ 518 struct ip6_opt_home_address { 519 uint8_t ip6oha_type; 520 uint8_t ip6oha_len; 521 uint8_t ip6oha_addr[16]; /* Home Address */ 522 }; 524 Option Type Definition: 526 #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */ 528 4.4 Type 2 Routing Header 530 532 /* Type 2 Routing header for Mobile IPv6 */ 533 struct ip6_rthdr2 { 534 uint8_t ip6r2_nxt; /* next header */ 535 uint8_t ip6r2_len; /* length : always 2 */ 536 uint8_t ip6r2_type; /* always 2 */ 537 uint8_t ip6r2_segleft; /* segments left: always 1 */ 538 uint32_t ip6r2_reserved; /* reserved field */ 539 struct in6_addr ip6r2_homeaddr; /* Home Address */ 540 }; 542 4.5 New ICMP Messages for Mobile IPv6 544 ICMP message types and definitions for Mobile IPv6 are defined in 546 548 #define MIP6_HA_DISCOVERY_REQUEST 144 549 #define MIP6_HA_DISCOVERY_REPLY 145 550 #define MIP6_PREFIX_SOLICIT 146 551 #define MIP6_PREFIX_ADVERT 147 553 The following data structures can be used for the ICMP message types 554 discussed in Section 6.5 through 6.8 in the base Mobile IPv6 [2] 555 specification. 557 struct mip6_dhaad_req { /* Dynamic HA Address Discovery */ 558 struct icmp6_hdr mip6_dhreq_hdr; 559 }; 561 #define mip6_dhreq_type mip6_dhreq_hdr.icmp6_type 562 #define mip6_dhreq_code mip6_dhreq_hdr.icmp6_code 563 #define mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum 564 #define mip6_dhreq_id mip6_dhreq_hdr.icmp6_data16[0] 565 #define mip6_dhreq_reserved mip6_dhreq_hdr.icmp6_data16[1] 567 struct mip6_dhaad_rep { /* HA Address Discovery Reply */ 568 struct icmp6_hdr mip6_dhrep_hdr; 569 /* Followed by Home Agent IPv6 addresses */ 570 }; 572 #define mip6_dhrep_type mip6_dhrep_hdr.icmp6_type 573 #define mip6_dhrep_code mip6_dhrep_hdr.icmp6_code 574 #define mip6_dhrep_cksum mip6_dhrep_hdr.icmp6_cksum 575 #define mip6_dhrep_id mip6_dhrep_hdr.icmp6_data16[0] 576 #define mip6_dhrep_reserved mip6_dhrep_hdr.icmp6_data16[1] 578 struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */ 579 struct icmp6_hdr mip6_ps_hdr; 580 }; 582 #define mip6_ps_type mip6_ps_hdr.icmp6_type 583 #define mip6_ps_code mip6_ps_hdr.icmp6_code 584 #define mip6_ps_cksum mip6_ps_hdr.icmp6_cksum 585 #define mip6_ps_id mip6_ps_hdr.icmp6_data16[0] 586 #define mip6_ps_reserved mip6_ps_hdr.icmp6_data16[1] 588 struct mip6_prefix_advert { /* Mobile Prefix Advertisements */ 589 struct icmp6_hdr mip6_pa_hdr; 590 /* Followed by one or more PI options */ 591 }; 593 #define mip6_pa_type mip6_pa_hdr.icmp6_type 594 #define mip6_pa_code mip6_pa_hdr.icmp6_code 595 #define mip6_pa_cksum mip6_pa_hdr.icmp6_cksum 596 #define mip6_pa_id mip6_pa_hdr.icmp6_data16[0] 597 #define mip6_pa_flags_reserved mip6_pa_hdr.icmp6_data16[1] 599 /* Mobile Prefix Advertisement Flags in network-byte order */ 600 #define MIP6_PA_FLAG_MANAGED 0x8000 601 #define MIP6_PA_FLAG_OTHER 0x4000 603 Prefix options are defined in IPv6 Advanced Socket API [1]. Mobile 604 IPv6 Base specification [2] describes the modified behavior in 605 'Modifications to IPv6 Neighbor Discovery' Section. Prefix Options 606 for Mobile IP are defined in the following Section. 608 4.6 IPv6 Neighbor Discovery Changes 610 IPv6 Neighbor Discovery changes are also defined in 612 New 'Home Agent' flag in router advertisement: 613 #define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */ 615 New Router flag with prefix information of the home agent: 616 #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */ 618 As per Mobile IPv6 specification [2] Section 7.2, a Home Agent MUST 619 include at least one prefix option with the Router Address (R) bit 620 set. Advanced Socket API [1] defines data structure for prefix 621 option as follows: 623 struct nd_opt_prefix_info { /* prefix information */ 624 uint8_t nd_opt_pi_type; 625 uint8_t nd_opt_pi_len; 626 uint8_t nd_opt_pi_prefix_len; 627 uint8_t nd_opt_pi_flags_reserved; 628 uint32_t nd_opt_pi_valid_time; 629 uint32_t nd_opt_pi_preferred_time; 630 uint32_t nd_opt_pi_reserved2; 631 struct in6_addr nd_opt_pi_prefix; 632 }; 634 New advertisement interval option and home agent information options 635 are defined in Mobile IPv6 [2] base specification. 637 struct nd_opt_adv_interval { /* Advertisement interval option */ 638 uint8_t nd_opt_ai_type; 639 uint8_t nd_opt_ai_len; 640 uint16_t nd_opt_ai_reserved; 641 uint32_t nd_opt_ai_interval; 642 }; 644 The option types for the new Mobile IPv6 specific options: 646 #define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */ 647 #define ND_OPT_HA_INFORMATION 8 /* HA Information option */ 649 struct nd_opt_homeagent_info { /* Home Agent information */ 650 uint8_t nd_opt_hai_type; 651 uint8_t nd_opt_hai_len; 652 uint16_t nd_opt_hai_reserved; 653 uint16_t nd_opt_hai_preference; 654 uint16_t nd_opt_hai_lifetime; 655 }; 657 5. Access to Home Address Destination Option and Routing Headers 659 Applications that need to be able to access home address destination 660 option and routing header type 2 information can do so by setting the 661 appropriate setsockopt option and using ancillary data objects. The 662 order of extension headers is defined in Mobile IPv6 [2] when sending 663 an IPv6 packet with a Home Address Destination Option with other 664 possible extension headers. Section 5.3 elaborates the extension 665 header order when all the possible cases are present. This document 666 does not recommend the user-level program to set Home Address 667 destination option or Routing Header Type 2 option; however, for 668 clarity it defines the order of extension headers. See Section 2 of 669 this document for appropriate usage of sending and receiving of Home 670 Address destination options and Routing Header Type 2 extension 671 headers. 673 This document defines a new socket option, IPV6_MIPDSTOPTS for 674 sending Home Address destination options. In order to receive a Home 675 Address destination option or Route Header Type 2 extension header, 676 applications must call setsockopt() to turn on the corresponding flag 677 ( for brevity, error checking is not performed in the examples): 679 int on = 1; 681 setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); 682 setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, 683 &on, sizeof(on)); 685 When any of these options are enabled, the corresponding data is 686 returned as control information by recvmsg(), as one or more 687 ancillary data objects. Receiving the above information for TCP 688 applications is not defined in this document (see Section 4.1 of 689 Advanced Sockets API for IPv6 [1]). 691 Note that if the IP implementation on the host does not implement the 692 handling of type 2 routing headers or Home Address options, then per 693 RFC 2460 [3], the IP stack is required to drop the packet. Hence 694 the applications using this mechanism only work on hosts where at 695 least those pieces of RFC 3775 [2] are implemented in the IP layer. 697 For receiving the Home Address destination option header, the Mobile 698 IPv6 implementation follows the initial processing of the Home 699 Address destination option (Section 9.3.1 of Mobile IPv6 [2]) before 700 passing the information to the API level. This includes initial 701 processing of IPSec authentication data in a packet when it exists. 702 Each Destination options header is returned as one ancillary data 703 object described by a cmsghdr structure with cmsg_level set to 704 IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS. 706 For sending Home Address destination option, ancillary data can be 707 used to specify the option content for a single datagram. This only 708 applies to datagram and raw sockets; not to TCP sockets. The 709 Advanced API [1] document restricts one IPV6_xxx ancillary data 710 object for a particular extension header in the control buffer. 711 Thus, there would be a single ancillary data object for the Home 712 address destination option in a ancillary data buffer. If multiple 713 destination options are present then the header order should be in 714 compliance with Section 6.3 and 9.3.2 of the Mobile IPv6 [2] base 715 specification. 717 For TCP data packets with Home Address destination option, the 718 "sticky" option may be used for all transmitted packets. The 719 application can remove the sticky Home Destination option header by 720 calling setsockopt() for IPV6_MIPSTOPTS with a zero option length. 722 Note that Section 2 of this document does not encourage setting the 723 Home Address destination option at the user-level. A Mobile IPv6 724 implementation should set and process the Home Address destination 725 option and Routing Header Type 2, at the kernel level. The setting 726 of Routing Header Type 2 and Home Address destination option are 727 described in this document for completeness and flexibility to use 728 them in future if there is a need. 730 The following socket option parameters and cmsghdr fields may be used 731 for sending: 733 opt level/ optname/ optval/ 734 cmsg_level cmsg_type cmsg_data[] 735 ------------ ------------ ------------------------ 736 IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure 737 IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure 739 Some IPv6 implementations may support "sticky" options [1] for IPv6 740 destination option for datagram and RAW sockets. 742 Behavior of legacy IPv6 socket applications: 744 Legacy IPv6 applications/implementations using the Advanced Socket 745 API [1] mechanisms, upon receiving Home Address destination options 746 or Routing headers(Type 2), will discard the packet as per Section 747 4.2 and 4.4 of IPV6 Protocol [3] specification respectively; 748 otherwise, they should properly handle the Home Address destination 749 option and the Routing Header Type 2 specified in this document. 751 5.1 Routing Header access functions 753 IPV6 Protocol [3] defines a Routing header extension header for Type 754 0. Thus, in order to access the IPv6 Routing header Type 2 extension 755 header, one MUST use type = 2 and segment = 1. The following 756 existing functions defined in Advanced API for IPv6 Sockets [1] are 757 supported for Mobile IPv6 applications for sending and receiving 758 Routing Header Type 2 headers: 760 For sending: 762 size_t inet6_rth_space(int type, int segments); 763 void *inet6_rth_init(void *bp, int bp_len, int type, int segments); 764 int inet6_rth_add(void *bp, const struct in6_addr *addr); 766 For receiving: 768 int inet6_rth_segments(const void *bp); 769 struct in6_addr *inet6_rth_getaddr(const void *bp, int index); 771 NOTE: Reversing operation is not possible using the Route Header Type 772 2 extension header. Thus inet6_rth_reverse() is not used. 774 Detailed descriptions and examples of accessing an IPv6 Routing 775 Header are discussed in the Advanced Sockets API for IPv6 [1]. 776 However, Section 7 of Advanced API for IPv6 Sockets [1] indicates 777 that multiple types of routing headers can be received as multiple 778 ancillary data objects to the application (with cmsg_type set to 779 IPV6_RTHDR). Currently there are no API functions defined to return 780 the routing header type. However, this document does not define a 781 helper function, since it is easy to access the Routing Header Type 782 field just as easily as the ip6r_segleft field. An excerpt of a code 783 sample is provided for extracting the type of the received routing 784 header: 786 if (msg.msg_controllen != 0 && 787 cmsgptr->cmsg_level == IPPROTO_IPV6 && 788 cmsgptr->cmsg_type == IPV6_RTHDR) { 789 struct in6_addr *in6; 790 char asciiname[INET6_ADDRSTRLEN]; 791 struct ip6_rthdr *rthdr; 792 int segments, route_type; 794 rthdr = (struct ip6_rthdr *)extptr; 795 segments = inet6_rth_segments(extptr); 796 printf("route (%d segments, %d left): ", 797 segments, rthdr->ip6r_segleft); 798 route_type = rthdr->ip6r_type; 799 if (route_type == 2) { 800 printf ("Routing header Type 2 present\n"); 801 } 802 } 804 The function inet6_rth_gettype() returns the routing header type on 805 success. It returns -1 on error. 807 5.2 Content of Type 2 Routing Header 809 It is recommended that no portable applications will send Routing 810 Header Type 2 ancillary data from the application layer, since many 811 implementations take care of that at the kernel layer and may not 812 support the API for sending routing header type 2. 814 For user-level applications that receive Routing Header Type 2, 815 inet6_rth_getaddr() returns the Care-Of Address or the original 816 destination address of the received packet. This complies with the 817 existing Routing header Type=0 processing for IPv6 [1]. 819 Thus on the receive side, the socket application will always receive 820 data packets at its original home-address. The implementations are 821 responsible for processing the routing header type 2 packet as per 822 Mobile IPv6 RFC [2], before passing the routing header type 2 823 information to the Socket API. 825 If a pure IPv6 [3] system receives the Routing Header Type 2 packets, 826 it will follow the process described in Section 4.4 of the IPv6 [3] 827 base specification. 829 5.3 Order of extension headers for Home Address Destination Options 831 Section 6.3 of Mobile IPV6 [2] defines the extension header order for 832 Home address destination option. 834 Routing Header 835 Home Address Destination Option 836 Fragment Header 837 AH/ESP Header 839 IPv6 [3] specifies that the destination header can be either before 840 the Routing header or after the AH/ESP header if they are all 841 present. 843 Thus, when the Home Address destination option is present along with 844 other extension headers, the order will be: 846 Hop-by-Hop Options header 847 Destination Options header (note 1) 848 Routing header 849 Destination Options [Home Address Option] 850 Fragment header 851 Authentication header (note 2) 852 Encapsulating Security Payload header (note 2) 853 Destination Options header (note 3) 854 upper-layer header 856 Any user-level implementation or application that sends Home address 857 destination option through ancillary data objects should follow the 858 order extension header defined in this document when using 859 IPV6_MIPDSTOPTS socket options. 861 5.4 Home Address Destination Option access functions 863 The application must enable the IPV6_RECVDSTOPTS socket option in 864 order to receive the Home Address destination option (error checking 865 is not performed in the example for brevity): 867 int on = 1; 869 setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); 871 Each Destination option header is returned as one ancillary data 872 object described by a cmsghdr structure with cmsg_level set to 873 IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS. 875 The received side Home Address destination option is further 876 processed by calling the inet6_opt_next(), inet6_opt_find(), and 877 inet6_opt_get_value() functions as defined in Advanced API for IPv6 878 sockets [1]. 880 This document assumes that portable Mobile IPv6 applications will not 881 send a Home Address Destination Option from the application level, as 882 the Mobile IPv6 implementation underneath takes care of sending the 883 Home Address option and the routing header type 2 at the kernel. 884 However, some embedded software implementations may implement the 885 IPv6 packet processing/sending at the user-level; those 886 implementations may choose to provide the API support for sending a 887 home-address option at the application layer. In this case, the Home 888 Address destination options are normally constructed by using the 889 inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and 890 inet6_opt_set_val() functions, described in Section 10 of the 891 Advanced sockets API for IPv6 [1]. 893 5.5 Content of Home Address Destination option 895 The received ancillary data object for the Home Address destination 896 option SHOULD contain the Care-Of-Address of the mobile node. It is 897 assumed that the initial processing of the Home Address destination 898 option will verify the validity of home-address as described in 6.3 899 and 9.5 of the Mobile IPv6 Specification [2] and swap the source 900 address of the packet (COA) with the contents of Home Address 901 destination option. 903 Note that whether or not these new APIs are used, the sender's home 904 address is contained in the source address (which is passed to the 905 application using the socket-level functions recvfrom(), recvmsg(), 906 accept() and getpeername()). This is necessary for: 908 maintaining consistency between simple user-level applications 909 running between mobile nodes and the diagnostic applications on 910 home-agent or on correspondent node, which use this API. 912 obtaining the COA address of the mobile node when the Home Address 913 destination option is used. 915 maintaining consistency of existing IPv6 Socket APIs and 916 processing of the Home Address destination option. 918 If an implementation supports send-side Home Address destination API, 919 then it must follow the same rule for data content as specified in 920 Mobile IPv6 RFC [2] for sending a home-address option. Thus the 921 home-address option will contain the home-address and the 922 implementation will use the care-of-address as the source address of 923 the outgoing packet. If the implementation uses IPSec, then it 924 should use the content of Home Address destination option as source 925 address of the packet for security association. Note that regular 926 user applications must not set the Home-address destination option. 928 6. Mobility Protocol Headers 930 Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility 931 messages between Mobile Nodes, Home Agents and Correspondent Nodes. 932 These protocol headers carry Mobile IPv6 Binding messages as well as 933 Return Routability [2] messages. Currently the specification [2] 934 does not allow transport packets (piggybacking) along with the 935 mobility messages. Thus the mobility protocol header can be accessed 936 through an IPv6 RAW socket. An IPv6 RAW socket that is opened for 937 protocol IPPROTO_MH should always be able to see all the MH (Mobility 938 Header) packets. It is possible that future applications may 939 implement part of Mobile IPv6 signal processing at the application 940 level. Having a RAW socket interface may also enable an application 941 to execute the Return Routability protocol or other future 942 authentication protocol involving the mobility header at the user- 943 level. 945 6.1 Receiving and Sending Mobility Header Messages 947 This specification recommends the IPv6 RAW sockets mechanism to send 948 and receive Mobility Header (MH) packets. The behavior is similar to 949 ICMPV6 processing, where the kernel passes a copy of the mobility 950 header packet to the receiving socket. Depending on the 951 implementation, the kernel may process the mobility header in 952 addition to passing the mobility header to the application. In order 953 to comply with the restriction in the Advanced Sockets API for IPv6 954 [1], applications should set the IPV6_CHECKSUM socket option with 955 IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that 956 supports the Mobile IPv6 API, must implement Mobility Header API 957 checksum calculations by default at the kernel for both incoming and 958 outbound path. A Mobile IPv6 implementation must not return error on 959 the IPV6_CHECKSUM socket option setting, even if the socket option is 960 a NO-OP function for that implementation because it verifies the 961 checksum at the kernel level. Mobility Header checksum procedure is 962 described in the Mobile IPv6 Protocol [2] specification. Again, for 963 application portability it is recommended that the applications set 964 the IPV6_CHECKSUM socket option along with the RAW sockets for 965 IPPROTO_MH protocol. 967 As an example, a program that wants to send or receive a mobility 968 header protocol(MH), could open a socket as following (for brevity, 969 the error checking is not performed in the example below): 971 fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH); 973 int offset = 4; 974 setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, 975 sizeof(offset)); 977 For example, if an implementation likes to handle HOTI/HOT and COTI/ 978 COT message processing, it can do so by using IPv6 RAW Sockets for 979 IPPROTO_MH at the application layer. The same application may also 980 set the IPV6_RECVDSTOPTS socket option for receiving home-address 981 option in a binding update [2] from the mobile node. 983 IPv6 RAW sockets are described in Section 3 of the IPv6 Advanced 984 Socket API [1] specification. All data sent and received via raw 985 sockets must be in network byte order. The data structures that are 986 defined in this document are in network byte order and they are 987 believed to be supported by most compilers to directly hold packet- 988 formats for transmission on the wire. 990 The usual send/recv functions for datagram should be used for the 991 Mobile IPv6 RAW sockets in order to send and receive data, 992 respectively. 994 7. Protocols File 996 Many hosts provide the file /etc/protocols that contains the names of 997 the various IP protocols and their protocol numbers. The protocol 998 numbers are obtained through function getprotoXXX() functions. 1000 The following addition should be made to the /etc/protocols file, in 1001 addition to what is defined in Section 2.4 of the Advanced Sockets 1002 API for IPv6 [1]. 1004 The protocol number for Mobility Header: 1005 (http://www.iana.org/assignments/protocol-numbers) 1007 ipv6-mh 135 # Mobility Protocol Header 1009 8. IPv4-Mapped IPv6 Addresses 1011 The various socket options and ancillary data specifications defined 1012 in this document apply only to true IPv6 sockets. It is possible to 1013 create an IPv6 socket that actually sends and receives IPv4 packets, 1014 using IPv4-mapped IPv6 addresses, but the mapping of the options 1015 defined in this document to an IPv4 datagram is beyond the scope of 1016 this document. The above statement is in compliance with Section 13 1017 of the IPv6 Socket API [1]. 1019 9. Security Considerations 1021 The setting of the Home Address Destination option and Route Header 1022 Type 2 IPV6_RTHDR socket option may not be allowed at the application 1023 level in order to prevent denial-of-service attacks or man-in-the- 1024 middle attacks by hackers. Sending and receiving of mobility header 1025 messages are possible by IPv6 RAW sockets. Thus it is assumed that 1026 this operation is only possible by privileged users. However, this 1027 API does not prevent the existing security threat from a hacker 1028 sending a bogus mobility header or other IPv6 packets using the Home 1029 Address option and Type 2 Routing Header extensions. 1031 10. IANA Considerations 1033 This document does not define a new protocol. However, it uses the 1034 Mobility Header Protocol for IPv6 to define an API for /etc/protocols 1035 file. (ref: http://www.iana.org/assignments/protocol-numbers) 1037 11. Changes from last revisions 1039 [ TO BE DELETED BY THE RFC EDITOR BEFORE PUBLISHING AS A RFC] 1041 Version 05 changes: 1042 * Addressed IESG review comments. 1044 Version 04 changes: 1045 * Addressed Last call comment remaining issues and Area Director 1046 review comments 1048 Version 03 changes: 1049 * Modified new ICMPv6 type definition values to match RFC3775. 1051 Version 02 changes: 1052 * Added section 3.1.1 and 3.2.1 to clarify content of routing 1053 header type 2 and destination options. 1055 * Clarified existing socket application behavior in section 3. 1057 * Updated introduction to clarify scope of the applications wrt 1058 this API 1060 * Added IANA section and Full Copyright statement and internet 1061 draft boiler plate 1063 * Updated acknowledgement section and fixed typo etc. 1065 The following changes were made in 01 version per feedback from 1066 the implementors at Connectathon 2004. 1068 * Section 2.1.11.2 now defines alternate COA address data 1069 structure as struct in6_addr for consistency. It was defined as 1070 16 unit of bytes. 1072 * Added Binding Update Authdata of 12 bytes in the 1073 struct ip6_mh_opt_auth_data 1075 * Added a new function inet6_rth_gettype() in section 3.1 in order 1076 to distinguish routing header type 2 ancillary data items from 1077 type 0 routing header ancillary data items on the receive side. 1079 * Updated the Acknowledgement and Authors' address section 1081 12. Acknowledgement 1083 Thanks to Brian Haley for the thorough review of this draft and many 1084 helpful comments. Keiichi Shima, Alexandru Petrescu, Ryuji Wakikawa, 1085 Vijay Devarapalli, Jim Bound, Suvidh Mathur, Karen Nielsen, Mark 1086 Borst, Vladislav Yasevich and other mobile-ip working group members 1087 provided valuable input. Antti Tuominen suggested the routing header 1088 type function for this API document. During IESG review, Bill Fenner 1089 suggested accessing routing header type directly for being consistent 1090 with RFC3542. A new socket option for Home Address Destination 1091 Option is added as per Bill Fenner's suggestion for clarity of 1092 extension header orders. Thanks to Thomas Narten and Jari Arkko for 1093 the review of this document. 1095 13. References 1097 13.1 Normative References 1099 [1] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced 1100 Sockets Application Program Interface (API) for IPv6", RFC 3542, 1101 May 2003. 1103 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1104 IPv6", RFC 3775, June 2004. 1106 13.2 Informative References 1108 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1109 Specification", RFC 2460, December 1998. 1111 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1112 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1113 January 2005. 1115 [5] Nordmark, E., "IPv6 Socket API for source address selection", 1116 draft-chakrabarti-ipv6-addrselect-api-03 (work in progress), 1117 July 2005. 1119 [6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1120 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 1121 February 2003. 1123 Authors' Addresses 1125 Samita Chakrabarti 1126 Sun Microsystems 1127 16 Network Circle 1128 Menlo Park, CA 94025 1129 USA 1131 Phone: +1 650 786 5068 1132 Email: samita.chakrabarti@sun.com 1133 Erik Nordmark 1134 Sun Microsystems 1135 17 Network Circle 1136 Menlo Park, CA 94025 1137 USA 1139 Phone: +1 650 786 2921 1140 Email: erik.nordmark@sun.com 1142 Intellectual Property Statement 1144 The IETF takes no position regarding the validity or scope of any 1145 Intellectual Property Rights or other rights that might be claimed to 1146 pertain to the implementation or use of the technology described in 1147 this document or the extent to which any license under such rights 1148 might or might not be available; nor does it represent that it has 1149 made any independent effort to identify any such rights. Information 1150 on the procedures with respect to rights in RFC documents can be 1151 found in BCP 78 and BCP 79. 1153 Copies of IPR disclosures made to the IETF Secretariat and any 1154 assurances of licenses to be made available, or the result of an 1155 attempt made to obtain a general license or permission for the use of 1156 such proprietary rights by implementers or users of this 1157 specification can be obtained from the IETF on-line IPR repository at 1158 http://www.ietf.org/ipr. 1160 The IETF invites any interested party to bring to its attention any 1161 copyrights, patents or patent applications, or other proprietary 1162 rights that may cover technology that may be required to implement 1163 this standard. Please address the information to the IETF at 1164 ietf-ipr@ietf.org. 1166 Disclaimer of Validity 1168 This document and the information contained herein are provided on an 1169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1171 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1172 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1173 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1176 Copyright Statement 1178 Copyright (C) The Internet Society (2005). This document is subject 1179 to the rights, licenses and restrictions contained in BCP 78, and 1180 except as set forth therein, the authors retain all their rights. 1182 Acknowledgment 1184 Funding for the RFC Editor function is currently provided by the 1185 Internet Society.