idnits 2.17.1 draft-ietf-mip6-mipext-advapi-07.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 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1167. ** 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 269 has weird spacing: '... struct ip6_m...' == Line 281 has weird spacing: '... struct ip6_m...' == Line 293 has weird spacing: '... struct ip6_...' == Line 306 has weird spacing: '... struct ip6_...' == Line 319 has weird spacing: '... struct ip6_m...' == (35 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 (February 17, 2006) is 6636 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 437, but not defined == Missing Reference: '16' is mentioned on line 519, but not defined == Missing Reference: '0' is mentioned on line 594, 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: August 21, 2006 Sun Microsystems 5 February 17, 2006 7 Extension to Sockets API for Mobile IPv6 8 draft-ietf-mip6-mipext-advapi-07.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 August 21, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . 20 79 5.2 Content of Type 2 Routing Header . . . . . . . . . . . . . 21 80 5.3 Order of extension headers for Home Address Destination 81 Options . . . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 25 85 6.1 Receiving and Sending Mobility Header Messages . . . . . . 25 86 7. Protocols File . . . . . . . . . . . . . . . . . . . . . . . 27 87 8. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . 28 88 9. Security Considerations . . . . . . . . . . . . . . . . . . 29 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 90 11. Changes from last revisions . . . . . . . . . . . . . . . . 31 91 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 32 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 13.1 Normative References . . . . . . . . . . . . . . . . . . 33 94 13.2 Informative References . . . . . . . . . . . . . . . . . 33 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 96 Intellectual Property and Copyright Statements . . . . . . . 35 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 and some policy 119 applications which would like to receive copies 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 destination 156 options and Type 2 Routing Headers . For example, mh-ping might 157 be a 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 destination 164 options and Type 2 Routing Header in the main IP processing paths 165 in the 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 destination options, Type 2 Routing Headers and Mobility 171 headers at the kernel level. However, the kernel keeps a copy of 172 the received extension headers and passes them up to the API 173 which is used by the user-level applications purely for 174 monitoring and debugging 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 Type 2 Routing Header (where segments left is non-zero) be dropped 179 on receipt. This means that it is not possible to implement Mobile 180 IPv6 as an application on such a system. Thus on such a system, the 181 applicability of this API is limited to the first case above enabling 182 debugging and monitoring applications (such as tcpdump) to parse and 183 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 a name for IPv6 Mobility Header protocol in /etc/ 208 protocols (in Section 7). 210 All examples in this document omit error checking in favor of 211 brevity, as it is following the same style as the Advanced Socket API 212 [1]. 214 We note that many of the functions and socket options defined in this 215 document may have error returns that are not defined in this 216 document. 218 Data types in this document follow the Posix.1g format: intN_t means 219 a signed integer of exactly N bits (e.g., int16_t) and uintN_t means 220 an unsigned integer of exactly N bits (e.g., uint32_t). 222 Once the API specification becomes mature and is deployed, it may be 223 formally standardized by a more appropriate body, such as has been 224 done with the Basic API [6]. However, since this specification 225 largely builds upon the Advanced Socket API [1], such standardization 226 would make sense only if the Advanced Socket API [1] were also 227 standardized. 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in RFC 2119. 233 4. Common Structures and Definitions 235 In this section, the structures are specified in a way so that they 236 maximize the probability that the compiler-layout of data structures 237 are identical to the packet formats on the wire. However, ANSI-C 238 provides few guarantees about the size and alignment of data 239 structures. Thus, depending on the implementation of a compiler, 240 there is a slim chance that in certain systems, the compiled layout 241 of the following data structures may not match the packet formats 242 defined in RFC 3775 [2]. 244 The structure definitions below are examples of contents or the 245 fields that match with the wired packet format in most Operating 246 Systems. Depending on the compiler used as well as the host byte 247 order, the layout of the structures might need to be different in 248 some cases. But as long as they provide the same fields as below we 249 can ensure application portability when using this API. 251 The constants and structures shown below are in network byte order, 252 so an application needs to perform the appropriate byte order 253 conversion (ntohs(), etc) when necessary. 255 The structures and constants below will be included when including 256 the (new) header file : 258 4.1 The Mobility Header Data Structures 260 4.1.1 The ip6_mh Structure 262 The following structure is defined as a result of including . This is the fixed part of the Mobility Header. Different 264 Mobility message types are defined in Mobile IPv6 [2]. For 265 portability and alignment reasons, each mobility message type 266 includes the mobility header fields as opposed to including the 267 ip6_mh structure followed by the message-specific fields. 269 struct ip6_mh { 270 uint8_t ip6mh_proto; /* NO_NXTHDR by default */ 271 uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets 272 excluding the first 8 Octets */ 273 uint8_t ip6mh_type; /* Type of Mobility Header */ 274 uint8_t ip6mh_reserved; /* Reserved */ 275 uint16_t ip6mh_cksum; /* Mobility Header Checksum */ 276 /* Followed by type specific messages */ 277 }; 279 4.1.2 Binding Refresh Request Mobility Message 281 struct ip6_mh_binding_request { 282 uint8_t ip6mhbr_proto; 283 uint8_t ip6mhbr_hdrlen; 284 uint8_t ip6mhbr_type; 285 uint8_t ip6mhbr_reserved; 286 uint16_t ip6mhbr_cksum; 287 uint16_t ip6mhbr_reserved; 288 /* Followed by optional Mobility Options */ 289 }; 291 4.1.3 Home Address Test Init (HoTI) Message 293 struct ip6_mh_home_test_init { 294 uint8_t ip6mhhti_proto; 295 uint8_t ip6mhhti_hdrlen; 296 uint8_t ip6mhhti_type; 297 uint8_t ip6mhhti_reserved; 298 uint16_t ip6mhhti_cksum; 299 uint16_t ip6mhhti_reserved; 300 uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */ 301 /* Followed by optional Mobility Options */ 302 }; 304 4.1.4 Care-of Address Test Init (CoTI) Message 306 struct ip6_mh_careof_test_init { 307 uint8_t ip6mhcti_proto; 308 uint8_t ip6mhcti_hdrlen; 309 uint8_t ip6mhcti_type; 310 uint8_t ip6mhcti_reserved; 311 uint16_t ip6mhcti_cksum; 312 uint16_t ip6mhcti_reserved; 313 uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */ 314 /* Followed by optional Mobility Options */ 315 }; 317 4.1.5 Home Address Test (HOT) Message 319 struct ip6_mh_home_test { 320 uint8_t ip6mhht_proto; 321 uint8_t ip6mhht_hdrlen; 322 uint8_t ip6mhht_type; 323 uint8_t ip6mhht_reserved; 324 uint16_t ip6mhht_cksum; 325 uint16_t ip6mhht_nonce_index; 326 uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */ 327 uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */ 328 /* Followed by optional Mobility Options */ 329 }; 331 4.1.6 Care Of Address Test (COT) Message 333 struct ip6_mh_careof_test { 334 uint8_t ip6mhct_proto; 335 uint8_t ip6mhct_hdrlen; 336 uint8_t ip6mhct_type; 337 uint8_t ip6mhct_reserved; 338 uint16_t ip6mhct_cksum; 339 uint16_t ip6mhct_nonce_index; 340 uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */ 341 uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */ 342 /* Followed by optional Mobility Options */ 343 }; 345 4.1.7 Binding Update Mobility Message 347 struct ip6_mh_binding_update { 348 uint8_t ip6mhbu_proto; 349 uint8_t ip6mhbu_hdrlen; 350 uint8_t ip6mhbu_type; 351 uint8_t ip6mhbu_reserved; 352 uint16_t ip6mhbu_cksum; 353 uint16_t ip6mhbu_seqno; /* Sequence Number */ 354 uint16_t ip6mhbu_flags; 355 uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */ 356 /* Followed by optional Mobility Options */ 357 }; 359 /* Binding Update Flags, in network byte-order */ 360 #define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */ 361 #define IP6_MH_BU_HOME 0x4000 /* Home Registration */ 362 #define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */ 363 #define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */ 365 4.1.8 Binding Acknowledgment Mobility Message 367 struct ip6_mh_binding_ack { 368 uint8_t ip6mhba_proto; 369 uint8_t ip6mhba_hdrlen; 370 uint8_t ip6mhba_type; 371 uint8_t ip6mhba_reserved; 372 uint16_t ip6mhba_cksum; 373 uint8_t ip6mhba_status; /* Status code */ 374 uint8_t ip6mhba_flags; 375 uint16_t ip6mhba_seqno; 376 uint16_t ip6mhba_lifetime; 377 /* Followed by optional Mobility Options */ 378 }; 380 /* Binding Acknowledgement Flags */ 381 #define IP6_MH_BA_KEYM 0x80 /* Key management mobility */ 383 4.1.9 Binding Error Mobility Message 385 struct ip6_mh_binding_error { 386 uint8_t ip6mhbe_proto; 387 uint8_t ip6mhbe_hdrlen; 388 uint8_t ip6mhbe_type; 389 uint8_t ip6mhbe_reserved; 390 uint16_t ip6mhbe_cksum; 391 uint8_t ip6mhbe_status; /* Error Status */ 392 uint8_t ip6mhbe_reserved; 393 struct in6_addr ip6mhbe_homeaddr; 394 /* Followed by optional Mobility Options */ 395 }; 397 4.1.10 Mobility Option TLV data structure 399 struct ip6_mh_opt { 400 uint8_t ip6mhopt_type; /* Option Type */ 401 uint8_t ip6mhopt_len; /* Option Length */ 402 /* Followed by variable length Option Data in bytes */ 403 }; 405 4.1.11 Mobility Option Data Structures 407 4.1.11.1 Binding Refresh Advice 409 struct ip6_mh_opt_refresh_advice { 410 uint8_t ip6mora_type; 411 uint8_t ip6mora_len; 412 uint16_t ip6mora_interval; /* Refresh interval in 4 sec */ 413 }; 415 4.1.11.2 Alternate Care-of Address 417 struct ip6_mh_opt_altcoa { 418 uint8_t ip6moa_type; 419 uint8_t ip6moa_len; 420 struct in6_addr ip6moa_addr; /* Alternate CoA */ 421 }; 423 4.1.11.3 Nonce Indices 425 struct ip6_mh_opt_nonce_index { 426 uint8_t ip6moni_type; 427 uint8_t ip6moni_len; 428 uint16_t ip6moni_home_nonce; 429 uint16_t ip6moni_coa_nonce; 430 }; 432 4.1.11.4 Binding Authorization Data 434 struct ip6_mh_opt_auth_data { 435 uint8_t ip6moad_type; 436 uint8_t ip6moad_len; 437 uint8_t ip6moad_data[12]; 438 }; 440 4.2 Mobility Header Constants 442 IPv6 Next Header Value for Mobility: 444 446 #define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */ 448 Mobility Header Message Types: 450 452 #define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */ 453 #define IP6_MH_TYPE_HOTI 1 /* HOTI Message */ 454 #define IP6_MH_TYPE_COTI 2 /* COTI Message */ 455 #define IP6_MH_TYPE_HOT 3 /* HOT Message */ 456 #define IP6_MH_TYPE_COT 4 /* COT Message */ 457 #define IP6_MH_TYPE_BU 5 /* Binding Update */ 458 #define IP6_MH_TYPE_BACK 6 /* Binding ACK */ 459 #define IP6_MH_TYPE_BERROR 7 /* Binding Error */ 461 Mobility Header Message Option Types: 463 465 #define IP6_MHOPT_PAD1 0x00 /* PAD1 */ 466 #define IP6_MHOPT_PADN 0x01 /* PADN */ 467 #define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */ 468 #define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */ 469 #define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */ 470 #define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */ 472 Status values accompanied with Mobility Binding Acknowledgement: 474 475 #define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */ 476 #define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix 477 discovery Required */ 478 #define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */ 479 #define IP6_MH_BAS_PROHIBIT 129 /* Administratively 480 prohibited */ 481 #define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient 482 resources */ 483 #define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not 484 supported */ 485 #define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */ 486 #define IP6_MH_BAS_NOT_HA 133 /* Not HA for this 487 mobile node */ 488 #define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */ 489 #define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out 490 of range */ 492 #define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce 493 index */ 494 #define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of 495 nonce index */ 496 #define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce 497 Indices */ 498 #define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type 499 change disallowed */ 501 Status values for the Binding Error mobility messages: 503 505 #define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */ 506 #define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */ 508 4.3 IPv6 Home Address Destination Option 510 Due to alignment issues in the compiler, and the alignment 511 requirements for this option, the included IPv6 address must be 512 specified as an array of 16 octets. 514 515 /* Home Address Destination Option */ 516 struct ip6_opt_home_address { 517 uint8_t ip6oha_type; 518 uint8_t ip6oha_len; 519 uint8_t ip6oha_addr[16]; /* Home Address */ 520 }; 522 Option Type Definition: 524 #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */ 526 4.4 Type 2 Routing Header 528 530 /* Type 2 Routing header for Mobile IPv6 */ 531 struct ip6_rthdr2 { 532 uint8_t ip6r2_nxt; /* next header */ 533 uint8_t ip6r2_len; /* length : always 2 */ 534 uint8_t ip6r2_type; /* always 2 */ 535 uint8_t ip6r2_segleft; /* segments left: always 1 */ 536 uint32_t ip6r2_reserved; /* reserved field */ 537 struct in6_addr ip6r2_homeaddr; /* Home Address */ 538 }; 540 4.5 New ICMP Messages for Mobile IPv6 542 ICMP message types and definitions for Mobile IPv6 are defined in 544 546 #define MIP6_HA_DISCOVERY_REQUEST 144 547 #define MIP6_HA_DISCOVERY_REPLY 145 548 #define MIP6_PREFIX_SOLICIT 146 549 #define MIP6_PREFIX_ADVERT 147 551 The following data structures can be used for the ICMP message types 552 discussed in Section 6.5 through 6.8 in the base Mobile IPv6 [2] 553 specification. 555 struct mip6_dhaad_req { /* Dynamic HA Address Discovery */ 556 struct icmp6_hdr mip6_dhreq_hdr; 557 }; 559 #define mip6_dhreq_type mip6_dhreq_hdr.icmp6_type 560 #define mip6_dhreq_code mip6_dhreq_hdr.icmp6_code 561 #define mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum 562 #define mip6_dhreq_id mip6_dhreq_hdr.icmp6_data16[0] 563 #define mip6_dhreq_reserved mip6_dhreq_hdr.icmp6_data16[1] 565 struct mip6_dhaad_rep { /* HA Address Discovery Reply */ 566 struct icmp6_hdr mip6_dhrep_hdr; 567 /* Followed by Home Agent IPv6 addresses */ 568 }; 570 #define mip6_dhrep_type mip6_dhrep_hdr.icmp6_type 571 #define mip6_dhrep_code mip6_dhrep_hdr.icmp6_code 572 #define mip6_dhrep_cksum mip6_dhrep_hdr.icmp6_cksum 573 #define mip6_dhrep_id mip6_dhrep_hdr.icmp6_data16[0] 574 #define mip6_dhrep_reserved mip6_dhrep_hdr.icmp6_data16[1] 576 struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */ 577 struct icmp6_hdr mip6_ps_hdr; 578 }; 580 #define mip6_ps_type mip6_ps_hdr.icmp6_type 581 #define mip6_ps_code mip6_ps_hdr.icmp6_code 582 #define mip6_ps_cksum mip6_ps_hdr.icmp6_cksum 583 #define mip6_ps_id mip6_ps_hdr.icmp6_data16[0] 584 #define mip6_ps_reserved mip6_ps_hdr.icmp6_data16[1] 586 struct mip6_prefix_advert { /* Mobile Prefix Advertisements */ 587 struct icmp6_hdr mip6_pa_hdr; 588 /* Followed by one or more PI options */ 589 }; 591 #define mip6_pa_type mip6_pa_hdr.icmp6_type 592 #define mip6_pa_code mip6_pa_hdr.icmp6_code 593 #define mip6_pa_cksum mip6_pa_hdr.icmp6_cksum 594 #define mip6_pa_id mip6_pa_hdr.icmp6_data16[0] 595 #define mip6_pa_flags_reserved mip6_pa_hdr.icmp6_data16[1] 597 /* Mobile Prefix Advertisement Flags in network-byte order */ 598 #define MIP6_PA_FLAG_MANAGED 0x8000 599 #define MIP6_PA_FLAG_OTHER 0x4000 601 Prefix options are defined in IPv6 Advanced Socket API [1]. Mobile 602 IPv6 Base specification [2] describes the modified behavior in 603 'Modifications to IPv6 Neighbor Discovery' Section. Prefix Options 604 for Mobile IP are defined in the following Section. 606 4.6 IPv6 Neighbor Discovery Changes 608 IPv6 Neighbor Discovery changes are also defined in 610 New 'Home Agent' flag in router advertisement: 611 #define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */ 613 New Router flag with prefix information of the home agent: 614 #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */ 616 As per Mobile IPv6 specification [2] Section 7.2, a Home Agent MUST 617 include at least one prefix option with the Router Address (R) bit 618 set. Advanced Socket API [1] defines data structure for prefix 619 option as follows: 621 struct nd_opt_prefix_info { /* prefix information */ 622 uint8_t nd_opt_pi_type; 623 uint8_t nd_opt_pi_len; 624 uint8_t nd_opt_pi_prefix_len; 625 uint8_t nd_opt_pi_flags_reserved; 626 uint32_t nd_opt_pi_valid_time; 627 uint32_t nd_opt_pi_preferred_time; 628 uint32_t nd_opt_pi_reserved2; 629 struct in6_addr nd_opt_pi_prefix; 630 }; 632 New advertisement interval option and home agent information options 633 are defined in Mobile IPv6 [2] base specification. 635 struct nd_opt_adv_interval { /* Advertisement interval option */ 636 uint8_t nd_opt_ai_type; 637 uint8_t nd_opt_ai_len; 638 uint16_t nd_opt_ai_reserved; 639 uint32_t nd_opt_ai_interval; 640 }; 642 The option types for the new Mobile IPv6 specific options: 644 #define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */ 645 #define ND_OPT_HA_INFORMATION 8 /* HA Information option */ 647 struct nd_opt_homeagent_info { /* Home Agent information */ 648 uint8_t nd_opt_hai_type; 649 uint8_t nd_opt_hai_len; 650 uint16_t nd_opt_hai_reserved; 651 uint16_t nd_opt_hai_preference; 652 uint16_t nd_opt_hai_lifetime; 653 }; 655 5. Access to Home Address Destination Option and Routing Headers 657 Applications that need to be able to access Home Address destination 658 option and Type 2 Routing Header information can do so by setting the 659 appropriate setsockopt option and using ancillary data objects. The 660 order of extension headers is defined in Mobile IPv6 [2] when sending 661 an IPv6 packet with a Home Address Destination Option with other 662 possible extension headers. Section 5.3 elaborates the extension 663 header order when all the possible cases are present. 665 This document does not recommend the user-level program to set Home 666 Address destination option or Type 2 Routing Header option; however, 667 for clarity it defines the order of extension headers. See 668 Section 2 of this document for appropriate usage of sending and 669 receiving of Home Address destination options and Type 2 Routing 670 Header extension headers. 672 This document defines a new socket option, IPV6_MIPDSTOPTS for 673 sending Home Address destination options. In order to receive a Home 674 Address destination option or Type 2 Route Header, applications must 675 call setsockopt() to turn on the corresponding flag as described in 676 IPv6 Advanced Socket API [1] ( for brevity, error checking is not 677 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 receiving Home Address desitnation option and Type 2 Routing Header 695 at the application layer requires implementation of respective 696 extension headers at the IP layer in the kernel as defined in RFC3775 697 [2]. 699 For receiving the Home Address destination option header, the Mobile 700 IPv6 implementation SHOULD follow the initial processing rules of the 701 Home Address destination option (Section 9.3.1 of Mobile IPv6 [2]) 702 before passing the information to the API level. This includes 703 initial processing of IPSec authentication data in a packet when it 704 exists. Each Destination options header is returned as one ancillary 705 data object described by a cmsghdr structure with cmsg_level set to 706 IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS. 708 For sending Home Address destination option, ancillary data can be 709 used to specify the option content for a single datagram. This only 710 applies to datagram and raw sockets; not to TCP sockets. The 711 Advanced API [1] document restricts one IPV6_xxx ancillary data 712 object for a particular extension header in the control buffer. 713 Thus, there would be a single ancillary data object for the Home 714 address destination option in a ancillary data buffer. If multiple 715 destination options are present then the header order should be in 716 compliance with Section 6.3 and 9.3.2 of the Mobile IPv6 [2] base 717 specification. 719 For TCP data packets with Home Address destination option, the 720 "sticky" option may be used for all transmitted packets. The 721 application can remove the sticky Home Destination option header by 722 calling setsockopt() for IPV6_MIPDSTOPTS with a zero option length. 724 Note that Section 2 of this document does not encourage setting the 725 Home Address destination option at the user-level. A Mobile IPv6 726 implementation should set and process the Home Address destination 727 option and Routing Header Type 2, at the kernel level. The setting 728 of Routing Header Type 2 and Home Address destination option are 729 described in this document for completeness and flexibility to use 730 them in future if there is a need. 732 The following socket option parameters and cmsghdr fields may be used 733 for sending (although not a recommended usage): 735 opt level/ optname/ optval/ 736 cmsg_level cmsg_type cmsg_data[] 737 ------------ ------------ ------------------------ 738 IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure 739 IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure 741 Some IPv6 implementations may support "sticky" options [1] for IPv6 742 destination option for datagram and RAW sockets. 744 Behavior of legacy IPv6 socket applications: 746 Legacy IPv6 applications/implementations using the Advanced Socket 747 API [1] mechanisms, upon receiving Home Address destination options 748 or Routing headers(Type 2), will discard the packet as per Section 749 4.2 and 4.4 of IPV6 Protocol [3] specification respectively; 750 otherwise, they should properly handle the Home Address destination 751 option and the Routing Header Type 2 specified in this document. 753 5.1 Routing Header access functions 755 IPV6 Protocol [3] defines a Routing header extension header for Type 756 0. Thus, in order to access the IPv6 Routing header Type 2 extension 757 header, one MUST use type = 2 and segment = 1. The following 758 existing functions defined in Advanced API for IPv6 Sockets [1] are 759 supported for Mobile IPv6 applications for sending and receiving 760 Routing Header Type 2 headers: 762 For sending: 764 size_t inet6_rth_space(int type, int segments); 765 void *inet6_rth_init(void *bp, int bp_len, int type, int segments); 766 int inet6_rth_add(void *bp, const struct in6_addr *addr); 768 For receiving: 770 int inet6_rth_segments(const void *bp); 771 struct in6_addr *inet6_rth_getaddr(const void *bp, int index); 773 NOTE: Reversing operation is not possible using the Route Header Type 774 2 extension header. Thus inet6_rth_reverse() is not used. 776 Detailed descriptions and examples of accessing an IPv6 Routing 777 Header are discussed in the Advanced Sockets API for IPv6 [1]. 778 However, Section 7 of Advanced API for IPv6 Sockets [1] indicates 779 that multiple types of routing headers can be received as multiple 780 ancillary data objects to the application (with cmsg_type set to 781 IPV6_RTHDR). Currently there are no API functions defined to return 782 the routing header type. However, this document does not define a 783 helper function, since it is easy to access the Routing Header Type 784 field just as easily as the ip6r_segleft field. An excerpt of a code 785 sample is provided for extracting the type of the received routing 786 header: 788 if (msg.msg_controllen != 0 && 789 cmsgptr->cmsg_level == IPPROTO_IPV6 && 790 cmsgptr->cmsg_type == IPV6_RTHDR) { 791 struct in6_addr *in6; 792 char asciiname[INET6_ADDRSTRLEN]; 793 struct ip6_rthdr *rthdr; 794 int segments, route_type; 796 rthdr = (struct ip6_rthdr *)extptr; 797 segments = inet6_rth_segments(extptr); 798 printf("route (%d segments, %d left): ", 799 segments, rthdr->ip6r_segleft); 800 route_type = rthdr->ip6r_type; 801 if (route_type == 2) { 802 printf ("Routing header Type 2 present\n"); 803 } 804 } 806 5.2 Content of Type 2 Routing Header 808 It is recommended that no portable applications will send Type 2 809 Routing Header ancillary data from the application layer, since many 810 implementations take care of that at the kernel layer and may not 811 support the API for sending Type 2 Routing Header. 813 Mobile IPv6 [2] defines the Type 2 Routing Header, to allow the 814 packet to be routed directly from a correspondent to the mobile 815 node's care-of address. The mobile node's care-of address is 816 inserted into the IPv6 Destination Address field. Once the packet 817 arrives at the care-of address, the mobile node retrieves its home 818 address from the routing header, and this is used as the final 819 destination address for the received IPv6 packet. 821 For user-level applications that receive Type 2 Routing Header, 822 inet6_rth_getaddr() returns the care-of Address or on-the-wire 823 destination address of the received packet. This complies with the 824 existing Routing header Type=0 processing for IPv6 [1]. 826 Thus on the receive side, the socket application will always receive 827 data packets at its original home-address. The implementations are 828 responsible for processing the Type 2 Routing Header packet as per 829 Mobile IPv6 RFC [2], before passing the Type 2 Routing Header 830 information to the Socket API. 832 If a pure IPv6 [3] system receives the Routing Header Type 2 packets, 833 it will follow the process described in Section 4.4 of the IPv6 [3] 834 base specification. 836 5.3 Order of extension headers for Home Address Destination Options 838 Section 6.3 of Mobile IPV6 [2] defines the extension header order for 839 Home address destination option. 841 Routing Header 842 Home Address Destination Option 843 Fragment Header 844 AH/ESP Header 846 IPv6 [3] specifies that the destination header can be either before 847 the Routing header or after the AH/ESP header if they are all 848 present. 850 Thus, when the Home Address destination option is present along with 851 other extension headers, the order will be: 853 Hop-by-Hop Options header 854 Destination Options header 855 Routing header 856 Destination Options [Home Address Option] 857 Fragment header 858 Authentication header 859 Encapsulating Security Payload header 860 Destination Options header 861 upper-layer header 863 Any user-level implementation or application that sends Home address 864 destination option through ancillary data objects should follow the 865 order extension header defined in this document when using 866 IPV6_MIPDSTOPTS socket options. 868 5.4 Home Address Destination Option access functions 870 The application must enable the IPV6_RECVDSTOPTS socket option in 871 order to receive the Home Address destination option (error checking 872 is not performed in the example for brevity): 874 int on = 1; 876 setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); 878 Each Destination option header is returned as one ancillary data 879 object described by a cmsghdr structure with cmsg_level set to 880 IPPROTO_IPV6 and cmsg_type set to IPV6_DSTOPTS. 882 The received side Home Address destination option is further 883 processed by calling the inet6_opt_next(), inet6_opt_find(), and 884 inet6_opt_get_value() functions as defined in Advanced API for IPv6 885 sockets [1]. 887 This document assumes that portable Mobile IPv6 applications will not 888 send a Home Address Destination Option from the application level, as 889 the Mobile IPv6 implementation underneath takes care of sending the 890 Home Address option and the routing header type 2 at the kernel. 891 However, some embedded software implementations may implement the 892 IPv6 packet processing/sending at the user-level; those 893 implementations may choose to provide the API support for sending a 894 home-address option at the application layer. In this case, the Home 895 Address destination options are normally constructed by using the 896 inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and 897 inet6_opt_set_val() functions, described in Section 10 of the 898 Advanced sockets API for IPv6 [1]. 900 5.5 Content of Home Address Destination option 902 The received ancillary data object for the Home Address destination 903 option SHOULD contain the Care-Of-Address of the mobile node. It is 904 assumed that the initial processing of the Home Address destination 905 option will verify the validity of home-address as described in 6.3 906 and 9.5 of the Mobile IPv6 Specification [2] and swap the source 907 address of the packet (COA) with the contents of Home Address 908 destination option. 910 Note that whether or not these new APIs are used, the sender's home 911 address is contained in the source address (which is passed to the 912 application using the socket-level functions recvfrom(), recvmsg(), 913 accept() and getpeername()). This is necessary for: 915 maintaining consistency between simple user-level applications 916 running between mobile nodes and the diagnostic applications on 917 home-agent or on correspondent node, which use this API. 919 obtaining the COA address of the mobile node when the Home Address 920 destination option is used. 922 maintaining consistency of existing IPv6 Socket APIs and 923 processing of the Home Address destination option. 925 If an implementation supports send-side Home Address destination API, 926 then it must follow the same rule for data content as specified in 927 Mobile IPv6 RFC [2] for sending a home-address option. Thus the 928 home-address option will contain the home-address and the 929 implementation will use the care-of-address as the source address of 930 the outgoing packet. If the implementation uses IPSec, then it 931 should use the content of Home Address destination option as source 932 address of the packet for security association. Note that regular 933 user applications must not set the Home-address destination option. 935 6. Mobility Protocol Headers 937 Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility 938 messages between Mobile Nodes, Home Agents and Correspondent Nodes. 939 These protocol headers carry Mobile IPv6 Binding messages as well as 940 Return Routability [2] messages. Currently the specification [2] 941 does not allow transport packets (piggybacking) along with the 942 mobility messages. Thus the mobility protocol header can be accessed 943 through an IPv6 RAW socket. An IPv6 RAW socket that is opened for 944 protocol IPPROTO_MH should always be able to see all the MH (Mobility 945 Header) packets. It is possible that future applications may 946 implement part of Mobile IPv6 signal processing at the application 947 level. Having a RAW socket interface may also enable an application 948 to execute the Return Routability protocol or other future 949 authentication protocol involving the mobility header at the user- 950 level. 952 6.1 Receiving and Sending Mobility Header Messages 954 This specification recommends the IPv6 RAW sockets mechanism to send 955 and receive Mobility Header (MH) packets. The behavior is similar to 956 ICMPV6 processing, where the kernel passes a copy of the mobility 957 header packet to the receiving socket. Depending on the 958 implementation, the kernel may process the mobility header in 959 addition to passing the mobility header to the application. In order 960 to comply with the restriction in the Advanced Sockets API for IPv6 961 [1], applications should set the IPV6_CHECKSUM socket option with 962 IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that 963 supports the Mobile IPv6 API, must implement Mobility Header API 964 checksum calculations by default at the kernel for both incoming and 965 outbound path. A Mobile IPv6 implementation must not return error on 966 the IPV6_CHECKSUM socket option setting, even if the socket option is 967 a NO-OP function for that implementation because it verifies the 968 checksum at the kernel level. Mobility Header checksum procedure is 969 described in the Mobile IPv6 Protocol [2] specification. Again, for 970 application portability it is recommended that the applications set 971 the IPV6_CHECKSUM socket option along with the RAW sockets for 972 IPPROTO_MH protocol. 974 As an example, a program that wants to send or receive a mobility 975 header protocol(MH), could open a socket as following (for brevity, 976 the error checking is not performed in the example below): 978 fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH); 980 int offset = 4; 981 setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, 982 sizeof(offset)); 984 For example, if an implementation likes to handle HOTI/HOT and COTI/ 985 COT message processing, it can do so by using IPv6 RAW Sockets for 986 IPPROTO_MH at the application layer. The same application may also 987 set the IPV6_RECVDSTOPTS socket option for receiving Home Address 988 destination option in a binding update [2] from the mobile node. 990 IPv6 RAW sockets are described in Section 3 of the IPv6 Advanced 991 Socket API [1] specification. All data sent and received via raw 992 sockets must be in network byte order. The data structures that are 993 defined in this document are in network byte order and they are 994 believed to be supported by most compilers to directly hold packet- 995 formats for transmission on the wire. 997 The usual send/recv functions for datagram should be used for the 998 Mobile IPv6 RAW sockets in order to send and receive data, 999 respectively. 1001 7. Protocols File 1003 Many hosts provide the file /etc/protocols that contains the names of 1004 the various IP protocols and their protocol numbers. The protocol 1005 numbers are obtained through function getprotoXXX() functions. 1007 The following addition should be made to the /etc/protocols file, in 1008 addition to what is defined in Section 2.4 of the Advanced Sockets 1009 API for IPv6 [1]. 1011 The protocol number for Mobility Header: 1012 (http://www.iana.org/assignments/protocol-numbers) 1014 ipv6-mh 135 # Mobility Protocol Header 1016 8. IPv4-Mapped IPv6 Addresses 1018 The various socket options and ancillary data specifications defined 1019 in this document apply only to true IPv6 sockets. It is possible to 1020 create an IPv6 socket that actually sends and receives IPv4 packets, 1021 using IPv4-mapped IPv6 addresses, but the mapping of the options 1022 defined in this document to an IPv4 datagram is beyond the scope of 1023 this document. The above statement is in compliance with Section 13 1024 of the IPv6 Socket API [1]. 1026 9. Security Considerations 1028 The setting of the Home Address Destination option and Route Header 1029 Type 2 IPV6_RTHDR socket option may not be allowed at the application 1030 level in order to prevent denial-of-service attacks or man-in-the- 1031 middle attacks by hackers. Sending and receiving of mobility header 1032 messages are possible by IPv6 RAW sockets. Thus it is assumed that 1033 this operation is only possible by privileged users. However, this 1034 API does not prevent the existing security threat from a hacker 1035 sending a bogus mobility header or other IPv6 packets using the Home 1036 Address option and Type 2 Routing Header extensions. 1038 10. IANA Considerations 1040 This document does not define a new protocol. However, it uses the 1041 Mobility Header Protocol for IPv6 to define an API for /etc/protocols 1042 file. (ref: http://www.iana.org/assignments/protocol-numbers) 1044 11. Changes from last revisions 1046 [ TO BE DELETED BY THE RFC EDITOR BEFORE PUBLISHING AS A RFC] 1048 Version 05 changes: 1049 * Addressed IESG review comments. 1051 Version 04 changes: 1052 * Addressed Last call comment remaining issues and Area Director 1053 review comments 1055 Version 03 changes: 1056 * Modified new ICMPv6 type definition values to match RFC3775. 1058 Version 02 changes: 1059 * Added section 3.1.1 and 3.2.1 to clarify content of routing 1060 header type 2 and destination options. 1062 * Clarified existing socket application behavior in section 3. 1064 * Updated introduction to clarify scope of the applications wrt 1065 this API 1067 * Added IANA section and Full Copyright statement and internet 1068 draft boiler plate 1070 * Updated acknowledgement section and fixed typo etc. 1072 The following changes were made in 01 version per feedback from 1073 the implementors at Connectathon 2004. 1075 * Section 2.1.11.2 now defines alternate COA address data 1076 structure as struct in6_addr for consistency. It was defined as 1077 16 unit of bytes. 1079 * Added Binding Update Authdata of 12 bytes in the 1080 struct ip6_mh_opt_auth_data 1082 * Updated the Acknowledgement and Authors' address section 1084 12. Acknowledgement 1086 Thanks to Brian Haley for the thorough review of this draft and many 1087 helpful comments. Keiichi Shima, Alexandru Petrescu, Ryuji Wakikawa, 1088 Vijay Devarapalli, Jim Bound, Suvidh Mathur, Karen Nielsen, Mark 1089 Borst, Vladislav Yasevich and other mobile-ip working group members 1090 provided valuable input. Antti Tuominen suggested the routing header 1091 type function for this API document. During IESG review, Bill Fenner 1092 suggested accessing routing header type directly for being consistent 1093 with RFC3542. A new socket option for Home Address Destination 1094 Option is added as per Bill Fenner's suggestion for clarity of 1095 extension header orders. Thanks to Thomas Narten and Jari Arkko for 1096 the review of this document. 1098 13. References 1100 13.1 Normative References 1102 [1] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced 1103 Sockets Application Program Interface (API) for IPv6", RFC 3542, 1104 May 2003. 1106 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1107 IPv6", RFC 3775, June 2004. 1109 13.2 Informative References 1111 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1112 Specification", RFC 2460, December 1998. 1114 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1115 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1116 January 2005. 1118 [5] Nordmark, E., "IPv6 Socket API for source address selection", 1119 draft-chakrabarti-ipv6-addrselect-api-03 (work in progress), 1120 July 2005. 1122 [6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1123 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 1124 February 2003. 1126 Authors' Addresses 1128 Samita Chakrabarti 1129 Sun Microsystems 1130 16 Network Circle 1131 Menlo Park, CA 94025 1132 USA 1134 Phone: +1 650 786 5068 1135 Email: samita.chakrabarti@sun.com 1136 Erik Nordmark 1137 Sun Microsystems 1138 17 Network Circle 1139 Menlo Park, CA 94025 1140 USA 1142 Phone: +1 650 786 2921 1143 Email: erik.nordmark@sun.com 1145 Intellectual Property Statement 1147 The IETF takes no position regarding the validity or scope of any 1148 Intellectual Property Rights or other rights that might be claimed to 1149 pertain to the implementation or use of the technology described in 1150 this document or the extent to which any license under such rights 1151 might or might not be available; nor does it represent that it has 1152 made any independent effort to identify any such rights. Information 1153 on the procedures with respect to rights in RFC documents can be 1154 found in BCP 78 and BCP 79. 1156 Copies of IPR disclosures made to the IETF Secretariat and any 1157 assurances of licenses to be made available, or the result of an 1158 attempt made to obtain a general license or permission for the use of 1159 such proprietary rights by implementers or users of this 1160 specification can be obtained from the IETF on-line IPR repository at 1161 http://www.ietf.org/ipr. 1163 The IETF invites any interested party to bring to its attention any 1164 copyrights, patents or patent applications, or other proprietary 1165 rights that may cover technology that may be required to implement 1166 this standard. Please address the information to the IETF at 1167 ietf-ipr@ietf.org. 1169 Disclaimer of Validity 1171 This document and the information contained herein are provided on an 1172 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1173 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1174 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1175 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1176 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1177 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1179 Copyright Statement 1181 Copyright (C) The Internet Society (2006). This document is subject 1182 to the rights, licenses and restrictions contained in BCP 78, and 1183 except as set forth therein, the authors retain all their rights. 1185 Acknowledgment 1187 Funding for the RFC Editor function is currently provided by the 1188 Internet Society.