idnits 2.17.00 (12 Aug 2021) /tmp/idnits44724/draft-schilcher-mobike-trigger-api-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 854. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 285: '... and MUST NOT have any effects on a ...' RFC 2119 keyword, line 299: '...onal information MAY be included (e.g....' RFC 2119 keyword, line 490: '...ered application MUST NOT respond to i...' RFC 2119 keyword, line 633: '... MUST be set to zero....' RFC 2119 keyword, line 675: '... then the field SHOULD be set to the ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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 (October 22, 2005) is 6054 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) -- Looks like a reference, but probably isn't: 'INTERFACE' on line 510 -- Looks like a reference, but probably isn't: 'ADDRESS' on line 510 ** Downref: Normative reference to an Informational RFC: RFC 2367 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: draft-ietf-mobike-design has been published as RFC 4621 == Outdated reference: A later version (-04) exists of draft-sugimoto-mip6-pfkey-migrate-01 -- No information found for draft-ietf-nsis-applicability-mobility-signalling - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IKEv2 Mobility and Multihoming U. Schilcher 3 (mobike) Universitaet Klagenfurt 4 Internet-Draft H. Tschofenig 5 Expires: April 25, 2006 F. Muenz 6 Siemens AG 7 October 22, 2005 9 Application Programming Interface to a Trigger Database for MOBIKE 10 draft-schilcher-mobike-trigger-api-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 25, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The purpose of MOBIKE is the creation and maintenance of a set of 44 available addresses and provide them to the communication partner. A 45 MOBIKE peer should have some information about the status of each 46 address and interface in order to execute the respective actions. 47 Examples may comprise switching from one address or interface to 48 another. This information, which will be referred as trigger, is 49 distributed over a number of protocol daemons at an end host. To 50 make this information available to a MOBIKE daemon, it is necessary 51 to store it centrally at the host (called trigger database) and to 52 enable the protocols to insert the triggers and to allow MOBIKE to 53 obtain timely information. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Trigger Database and MIH . . . . . . . . . . . . . . . . . . . 6 60 4. Trigger Classification . . . . . . . . . . . . . . . . . . . . 8 61 5. API for the Trigger Database . . . . . . . . . . . . . . . . . 10 62 6. Supported Message Types . . . . . . . . . . . . . . . . . . . 12 63 7. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 17 64 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 22 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 67 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 70 12.2. Informative References . . . . . . . . . . . . . . . . . 26 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 72 Intellectual Property and Copyright Statements . . . . . . . . . . 28 74 1. Introduction 76 When a MOBIKE daemon is started it first has to build a set of all 77 available addresses (or a subset of them for policy reasons; see [3]) 78 before communicating with another peer. From these addresses, it has 79 to select one of the addresses as the preferred address that will be 80 used as the source address in the communication with the MOBIKE peer. 82 This address set together with the preferred address may change 83 during operation because of several reasons, e.g. an interface is 84 disconnected, a handover between two different link layer 85 technologies takes place or the communication path becomes 86 unavailable due to router failure. Many of the events, which cause 87 the change of the address set, are out of the scope of the MOBIKE 88 protocol itself but need an interaction with other protocols daemons 89 locally at the end host. 91 In order to make MOBIKE working properly, it is really important to 92 know about the status of the available addresses for making 93 reasonable decisions. A number of other protocols running on the end 94 host might have various information necessary to derive a decision, 95 whether to switch from one preferred address to another or whether it 96 is necessary to modify the peer address set. 98 An example is the IEEE 802.21 Media Independent Handover (MIH) 99 standard [4], which is currently under development. The MIH is 100 defined as a shim layer in the mobility-management protocol stack of 101 both, the mobile node and the network elements, that provide mobility 102 support. The MIH Function provides abstracted services to higher 103 layers about the status and performance of any link layer technology. 105 To benefit from this information on higher layers, however, the MIH 106 services must be combined with information from upper layers in order 107 to facilitate a basis for decisions above network layer. 109 In this document, we therefore suggest to define an API that allows 110 protocol daemons to insert information (triggers) about addresses and 111 interfaces into a "database" that can later be made available to the 112 MOBIKE daemon (or other protocols). The API will provide similar 113 services to the MOBIKE daemon like MIH does for layer 3 and above. 114 It is based on the BSD routing socket API in a similar fashion as 115 PF_KEY [1] extends the same API for generic key management usage. 117 This document therefore heavily focuses on the functionality offered 118 by the PF_KEY specification and uses the MIH Function as an example 119 for retrieving necessary information for a decision making process. 121 Please note that the authors use the term 'database' in a symbolic 122 way. It is a container for storing information about events. 123 Information about the status of interfaces and addresses might not 124 even be stored directly in this database and could well be 125 implemented using a collection of pointers to the respective 126 information. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [2]. 134 Additionally, the following terms are introduced: 136 o Trigger: Information which is relevant for MOBIKE about an 137 address. 139 o Trigger Database (TDB): Collection of triggers which can be 140 accessed via the API defined in this document. 142 o Media Independent Handover (MIH): Described in IEEE draft 802.21 143 [4] which is currently under development. The MIH Function 144 provides abstracted services to higher layers about the status and 145 performance of any link layer technology. 147 3. Trigger Database and MIH 149 The following section should give a rough overview for the 150 interaction of Media Independent Handover (MIH) with Trigger Database 151 (TDB) and MOBIKE daemon. The services of MIH are used e.g. for 152 compiling relevant information about interface performance, which is 153 then signalled through the Trigger Database to the MOBIKE daemon. 154 Based on this data, the MOBIKE daemon may select a new preferred 155 address or continues using the current one. 157 +--------------------------------------+ 158 | MOBIKE daemon | 159 | +-------------------+ | 160 | | PF_TRIGGER socket | | 161 | +--------------+----+ | 162 | ^ | | 163 +-----------|-----------|--------------+ 164 | | 165 | | 166 TDB TDB 167 Events Commands 168 | | 169 | v 170 +-----------+--------------------------+ 171 | Trigger Database (TDB) | 172 | (Layer 3 an above) | 173 +--------------------------------------+ 174 ^ | ^ 175 | | | 176 MIH MIH Information 177 Events Commands Service 178 | | | 179 | v v 180 +--------------------------------------+ 181 | Media Independent Handover Function | 182 +--------------------------------------+ 183 ^ | ^ 184 | | | 185 Link Link Information 186 Events Commands Service 187 | | | 188 | v v 189 +--------------------------------------+ 190 | Lower Layers (Layer 2 and below) | 191 +--------------------------------------+ 193 To receive event notifications from the MIH, the Trigger Database 194 must perform two steps: 196 Capability discovery: 198 While the MIH provides many services, not all of them may be 199 supported on a given platform. For learning, which of them are 200 actually supported, the Trigger Database must query the MIH with a 201 "MIH_Capability_Discover.request". The response, a 202 "MIH_Capability_Discover.response" message will then indicate with 203 a bit mask which services are supported. Alternatives and 204 solutions for not supported but required services is done in a 205 future version of this draft. 207 Service registration: 209 Now knowing the supported services, the Trigger Database must 210 register to the services it is interested in with a 211 "MIH_Event_Register.request" message. To confirm registration, 212 the MIH answers with a "MIH_Event_Register.confirm" message and 213 notifies the Trigger Database in case of status change of 214 interfaces. 216 4. Trigger Classification 218 Many different events may cause a change in the address set used by 219 MOBIKE (see [3]). These events can be issued by many different 220 protocols running in kernel or user space. Since the reaction (if 221 any) on a given event depends on the type of the event, a 222 classification of these events is necessary. 224 As an example, we define the following triggers in this document: 226 Trigger type Value Description 227 ---------------------------+-------+------------------------------- 228 TDB_TTYPE_IF_ADDED | 1 | New interface added 229 TDB_TTYPE_IF_REMOVED | 2 | Interface removed 230 TDB_TTYPE_IF_REMOVEDSOON | 3 | Interface is expected to be 231 | | removed soon 232 TDB_TTYPE_IF_ADDRADDED | 4 | New address added to interface 233 TDB_TTYPE_IF_ADDRREMOVED | 5 | Address removed from interface 234 TDB_TTYPE_IF_ADDRCHANGED | 6 | Interface has changed one of its 235 | | addresses (e.g. new DHCP lease) 236 TDB_TTYPE_TUNNEL_ADDED | 7 | IPSec tunnel was established 237 TDB_TTYPE_TUNNEL_CHANGED | 8 | IPSec tunnel conf. changed 238 TDB_TTYPE_TUNNEL_REMOVED | 9 | IPSec tunnel was removed 239 TDB_TTYPE_CONN_ESTABLISHED | 10 | e.g. dial-in network 240 | | has connected 241 TDB_TTYPE_CONN_LOST | 11 | connection to network lost 242 TDB_TTYPE_DEST_UNREACHABLE | 12 | e.g. ICMP packet received 243 TDB_TTYPE_MAX | 13 | Maximum value for trigger types 245 The types TDB_TTYPE_TUNNEL_ADDED, TDB_TTYPE_TUNNEL_CHANGED and 246 TDB_TTYPE_TUNNEL_REMOVED are inspired by [5]. Any listed trigger 247 types will be signalled using the "tdb_trigger" message structure 248 described in Section 7 250 Details about the supported message types and their formats can be 251 found below: 253 TDB_TTYPE_IF_ADDED: 255 This message is signalled if a new interface comes up and directly 256 refers to the "Link_Up.indication" event notification of the MIH 257 Function. 259 TDB_TTYPE_IF_REMOVED: 261 This message is signalled if an interface is going down and 262 directly refers to the "Link_Down.indication" event notification 263 of the MIH Function. 265 TDB_TTYPE_IF_REMOVEDSOON: 267 This message is signalled if an interface is expected (predicted) 268 to go down within a certain time interval and directly refers to 269 the "Link_Going_Down.indication" event notification of the MIH 270 Function. 272 A future version of this document will add more triggers and a more 273 detailed description of them. 275 5. API for the Trigger Database 277 To access the trigger database, an API is defined. For that purpose 278 the new network protocol family ID PF_TRIGGER has to be defined. The 279 operation of the API is analogue to the PF_KEY interface (see [1]). 281 To access the API, a socket of the family PF_TRIGGER has to be 282 created. To communicate with the Trigger Database, messages are sent 283 and received through the socket with the send() and recv() functions. 284 Any other functions like bind(), connect(), etc. are not supported 285 and MUST NOT have any effects on a socket of the PF_TRIGGER family. 287 The following exhibits a sample socket creation: 289 int s = socket(PF_TRIGGER, SOCK_RAW, PF_TRIGGER); 291 The format of the messages is the following: Each message starts with 292 a fixed header. Appended to this header, there are some payloads 293 depending on the type of the message. The available message types 294 are described in Section 6. 296 Each time when a message is sent to the Trigger Database, it will 297 respond with a message of the same type. This response contains the 298 same payloads as transmitted to the Trigger Database, only some 299 additional information MAY be included (e.g., the Trigger Database 300 assigns an id to each trigger). 302 The normal operation works in the following way: A MOBIKE 303 implementation, which wants to be informed about changes in the 304 Trigger Database, registers itself to the Trigger Database by sending 305 a TDB_REGISTER message. 307 If a protocol daemon wants to add, delete or modify an existing 308 trigger it sends a TDB_ADD, TDB_DELETE or TDB_MODIFY message 309 respectively to the Trigger Database including information that is 310 important to add, delete or modify the trigger. 312 The Trigger Database acknowledges this message with a TDB_ADD, 313 TDB_DELETE or TDB_MODIFY response to the network protocol and with a 314 TDB_NOTIFY message to the registered MOBIKE implementation. This 315 notify message contains information about the newly added, deleted or 316 modified trigger including its ID. All information available about a 317 trigger can be requested with a TDB_GET message. 319 If a MOBIKE implementation no longer wants to receive notifications 320 for changes to the Trigger Database, it sends a TDB_DEREGISTER 321 message. 323 In a future version of this document, we will try to add some 324 information about scenarios to better illustrate the interaction. 326 6. Supported Message Types 328 Several different message types can be sent to the Trigger Database 329 using a PF_TRIGGER socket. The message type is indicated by the 330 tdb_header_msgtype field that is part of the generic message header 331 (see Section 7) and can be one of the following values: 333 Message type Value Description 334 ------------------+---------+------------------------------ 335 TDB_ADD | 1 | Add a trigger to the 336 | | Trigger Database 337 TDB_GET | 2 | Get information about an 338 | | existing trigger. 339 TDB_DELETE | 3 | Delete a trigger from the 340 | | Trigger Database 341 TDB_REGISTER | 4 | Registers an application 342 | | to receive messages for 343 | | each new trigger added. 344 TDB_DEREGISTER | 5 | Deregisters an application 345 | | from receiving messages for 346 | | each new trigger added. 347 TDB_NOTIFY | 6 | A new trigger has been 348 | | added, deleted or updated. 349 TDB_MODIFY | 7 | Modify a trigger in the 350 | | Trigger Database 351 TDB_DUMP | 8 | Dump all Trigger Database 352 | | entries 353 TDB_FLUSH | 9 | Delete all Trigger Database 354 | | entries 355 TDB_MAX | 10 | Generic maximum for message 356 | | types 358 Each message type requires different payloads to be appended. Each 359 payload starts with a generic payload header followed by payload 360 specific data. The generic header has the following structure: 362 struct tdb_payload { 363 uint16_t tdb_payload_len; 364 uint16_t tdb_payload_type; 365 } __attribute__( ( packed ) ); 366 /* sizeof( struct tdb_payload ) == 4 */ 368 The tdb_payload_len field contains the length of the payload divided 369 by 8. The type of the payload is determined by the tdb_payload_type 370 field, which contains one of the following values: 372 Payload type Value Description 373 ---------------------------+---------+------------------------------- 374 TDB_PT_INTERFACE | 1 | Information about an interface 375 TDB_PT_ADDRESS | 2 | The IP address of an interface 376 TDB_PT_TRIGGER | 3 | Trigger id, type, etc. 378 Details about the supported message types and their formats can be 379 found below: 381 TDB_ADD: 383 If an application or network protocol wants to add a new trigger, 384 it sends a TDB_ADD message to the Trigger Database. The new 385 trigger is stored in the Trigger Database and a corresponding 386 TDB_NOTIFY message that indicates that a new trigger has been 387 added is sent to all registered applications. 389 The format of the message is: 391 393 The TRIGGER payload indicates the type of the trigger and also 394 includes some trigger specific data. The INTERFACE payload is 395 needed to select the appropriate hardware interface, the new 396 trigger is related to. For many triggers, an additional address 397 payload is required. It contains, for example, the new address 398 for a TDB_TTYPE_IF_ADDRCHANGED trigger. 400 The response from the Trigger Database contains the same 401 information as the request: 403 405 TDB_DELETE: 407 A trigger, which is stored inside the Trigger Database, can be 408 deleted using the TDB_DELETE payload. In the request the only 409 information, which has to be specified is the id of the trigger, 410 which is stored in 'TRIGGER(*)'. A corresponding TDB_NOTIFY 411 message that indicates that a trigger has been deleted is sent to 412 all registered applications. 414 The format of the message is: 416 418 The Trigger Database responds with a message with the following 419 format: 421 423 In the response, the TRIGGER payload has all fields filled with 424 the correct values. 426 TDB_GET: 428 The TDB_GET message is used to request all available information 429 of a specified trigger. In the request the only information, 430 which has to be specified is the id of the trigger, which is 431 stored in 'TRIGGER(*)'. 433 The format of the message is: 435 437 The Trigger Database responds with a message of the following 438 format: 440 442 In the response a fully initialized TRIGGER payload is present. 443 Additionally, INTERFACE payload is present as well as and an 444 optional an ADDRESS payload, if an address is available for the 445 specified trigger. 447 TDB_REGISTER: 449 An application, which is interested in each new trigger, can 450 register itself to the Trigger Database. After the application 451 has registered, it receives a message each time a new trigger has 452 been added to the database. The format of the message is: 454
456 No additional payload has to be added. The Trigger Database 457 responds with a message of the same type and with the same 458 content, i.e. its format is: 460
462 TDB_DEREGISTER: 464 An application, which is no longer interested in receiving 465 notifications about trigger changes, can de-register itself from 466 the Trigger Database. The format of the message is: 468
470 No additional payload has to be added. The Trigger Database 471 responds with a message of the same type and with the same 472 content, i.e. its format is: 474
476 TDB_NOTIFY 478 An application that has registered itself to get informed about 479 the new triggers or updates to these triggers, receives a 480 TDB_NOTIFY message. The format of the message is the same as for 481 a TDB_ADD message. The only difference is that some field are 482 filled by the Trigger Database before sending the TDB_NOTIFY 483 message. 485 The format of the message is: 487 489 Since this message is sent by the Trigger Database itself, a 490 registered application MUST NOT respond to it. 492 TDB_MODIFY: 494 If an application or a network protocol wants to modify a trigger 495 (because its status has changed), it sends a TDB_MODIFY message to 496 the Trigger Database. The new trigger is stored and a 497 corresponding TDB_NOTIFY message that indicates that an existing 498 trigger has been modified is sent to all registered applications. 500 The format of the message is: 502 504 The TRIGGER payload indicates the type of the trigger and also 505 includes some trigger specific data. 507 The response from the Trigger Database contains the same 508 information as the request: 510 512 TDB_DUMP: 514 An application, that wants to learn all currently available 515 triggers should send a TDB_DUMP message. Since a TDB_GET message 516 requires a specific trigger id for retrieval, applications which 517 to not know all trigger IDs depend on this message class for 518 learning all unknown triggers. The format of the message is: 520
522 The Trigger Database will respond with all currently available 523 triggers entries by serially sending the following message: 525 527 TDB_FLUSH: 529 For deleting all entries in a Trigger Database, the TDB_FLUSH 530 message is used. Since the TDB_GET message requires a specific 531 trigger id for deletion, reliable cleaning of a Trigger Database 532 can be done with this message. The format of the message is: 534
536 The Trigger Database will respond with the following message: 538
540 7. Payload Format 542 HEADER: 544 Each message starts with the fixed header. It contains general 545 information about the message and determines, which payloads have 546 to be included in it. It has the following format: 548 struct tdb_header { 549 uint8_t tdb_header_version; 550 uint8_t tdb_header_msgtype; 551 uint8_t tdb_header_errno; 552 uint8_t tdb_header_reserved1; 553 uint16_t tdb_header_msglen; 554 uint16_t tdb_header_reserved2; 555 uint32_t tdb_header_seq; 556 uint32_t tdb_header_pid; 557 } __attribute__( ( packed ) ); 558 /* sizeof( struct tdb_header ) == 16 */ 560 The fields of this structure contain the following values: 562 tdb_header_version: The version of the used PF_TRIGGER interface. 563 This document specifies this API in version 1. 565 tdb_header_msgtype: This field contains the type of the message. 566 All possible values are listed in the table in Section 6. 568 tdb_header_errno: If an error occurred while processing a request, 569 the response will only include the message header without any 570 payloads. The type of the error is indicated by the value in 571 this field. The values are taken from the error number 572 specification of the operating system (e.g. the errno.h file). 574 tdb_header_msglen: The length of the message divided by 8 is 575 stored into this field. 577 tdb_header_seq: This field contains the number of the last message 578 sent incremented by 1. 580 tdb_header_pid: The process id of the program sending the message. 581 If the message is generated inside the kernel, this value is 582 set to zero. 584 INTERFACE: 586 The INTERFACE payload is used to provide all needed information 587 about an active network interface. 589 The format of the INTERFACE payload is the following: 591 struct tdb_interface { 592 uint16_t tdb_interface_len; 593 uint16_t tdb_interface_pltype; 594 uint32_t tdb_interface_selector; 595 uint32_t tdb_interface_type; 596 uint32_t tdb_interface_bandwidth; 597 uint32_t tdb_interface_quality; 598 uint32_t tdb_interface_reserved; 599 } __attribute__( ( packed ) ); 600 /* sizeof( struct tdb_interface ) == 16 */ 602 This fields contain the following values: 604 tdb_interface_len: This field contains the length of the payload 605 divided by 8. 607 tdb_interface_pltype: This field contains the value 608 TDB_PT_INTERFACE. 610 tdb_interface_selector: The tdb_interface_selector field stores 611 interface enumeration information for unique identification (IF 612 #0, #1, #2, ...). When a new interface comes up, this value 613 should be set by the kernel. 615 tdb_interface_type: Classification of an interface, for instance 616 fixed or wireless network link. The MIH Function provides this 617 information by issuing a "MIH_Poll.request" from the Trigger 618 Database, before creating any event notification destined for 619 the MOBIKE daemon. 621 tdb_interface_bandwidth: Information about the maximum bandwidth 622 of an interface. The MIH Function provides this information by 623 issuing a "MIH_Poll.request" from the Trigger Database, before 624 creating any event notification destined for the MOBIKE daemon. 626 tdb_interface_quality: Information about current connection 627 quality of an interface. The MIH Function provides this 628 information by issuing a "MIH_Poll.request" from the Trigger 629 Database, before creating any event notification destined for 630 the MOBIKE daemon. 632 tdb_interface_reserved: This field is reserved for future use and 633 MUST be set to zero. 635 Further information about an interface might be necessary. 636 Especially asymmetric link connectivity/availability in case of 637 wireless connections might be relevant. This is left for future 638 investigation. 640 ADDRESS: 642 The ADDRESS payload is used to provide the IP address of an 643 interface to the Trigger Database or registered application. This 644 information is important for most triggers. But it might be 645 possible that there are trigger types which do not need an ADDRESS 646 payload. 648 The format of the ADDRESS payload is: 650 struct tdb_address { 651 uint16_t tdb_address_len; 652 uint16_t tdb_address_pltype; 653 uint8_t tdb_address_proto; 654 uint8_t tdb_address_prefixlen; 655 uint16_t tdb_address_reserved; 656 } __attribute__( ( packed ) ); 657 /* sizeof( struct tdb_address ) == 8 */ 659 /* followed by some form of struct sockaddr */ 661 Information about IP address and probably ports is provided by a 662 sockaddr structure which is attached to the tdb_address structure. 663 A sockaddr structure is capable of storing both a IPv4 and IPv6 664 address. The fields of the tdb_address structure contains the 665 following values: 667 tdb_address_len: This field contains the length of the payload 668 including the sockaddr structure divided by 8. 670 tdb_address_pltype: The tdb_address_pltype field contains the 671 value TDB_PT_ADDRESS. 673 tdb_address_proto: The tdb_address_proto field is normally set to 674 zero. However, if is are set in the attached sockaddr needed, 675 then the field SHOULD be set to the protocol number of the 676 upper layer protocol. (e.g. TCP or UDP). This functionality 677 may become relevant for signalling IPSec related information 678 (e.g. tunnel changes) 680 tdb_address_prefixlen: This field contains the prefix length of 681 the address, which might be useful to key management 682 applications, which employ it in access control decisions. If 683 the tdb_address_prefixlen is non-zero the address has a prefix. 685 tdb_address_reserved: The tdb_address_reserved field is reserved 686 for future use and MUST be set to zero. 688 TRIGGER: 690 The TRIGGER payload is used to provide all needed information 691 about a trigger itself, e.g. the trigger type, an id, etc. The 692 notation TRIGGER(*) indicates that only the id field is used to 693 identify the trigger and all other fields SHOULD be set to zero. 695 The format of the TRIGGER payload is the following: 697 struct tdb_trigger { 698 uint16_t tdb_trigger_len; 699 uint16_t tdb_trigger_pltype; 700 uint16_t tdb_trigger_type; 701 uint16_t tdb_trigger_reserved1; 702 uint32_t tdb_trigger_id; 703 uint32_t tdb_trigger_reserved2; 704 } __attribute__( ( packed ) ); 705 /* sizeof( struct tdb_trigger ) == 16 */ 706 This fields contain the following values: 708 tdb_address_len: This field contains the length of the payload 709 divided by 8. 711 tdb_address_pltype: This field contains the value TDB_PT_TRIGGER. 713 tdb_address_type: The type of the trigger is stored into this 714 field. All possible values are listed in the table in section 715 Section 4. 717 tdb_address_id: The id of a trigger is assigned by the Trigger 718 Database itself. In the message sent by userspace programs, 719 which do not know this value (e.g. for TDB_ADD messages), this 720 value MUST be set to zero. 722 Further information about a trigger might be necessary. This is 723 left for future investigation. 725 8. Applicability 727 Even though this document is intended to give a solution for MOBIKE, 728 the API is generic enough to make information available for other 729 protocols as well. 731 The Next Step In Signaling (NSIS) protocol suite, for example, 732 requires access to up-to-date information about IP addresses, 733 interfaces and interactions with mobility protocols. In order to 734 react on mobility events some sort of interaction between the kernel, 735 various signalling protocols (including Mobile IP, IKE/IPsec, etc.) 736 and the NSIS daemon is required (see [6]). Hence, an NSIS daemon 737 supporting mobility could benefit from a generic interface to meet 738 it's requirements for fast and accurate detection of mobility events, 739 address and interface changes. GIMPS, for example, demands immediate 740 reaction in case of a mobility event (e.g., handover). Monitoring 741 procedures of mobility management protocols like Mobile IP are 742 required to react to these mobility events in an appropriate way. 744 The trigger database and it's API could provide necessary information 745 for detecting such a movement (new interface/IP address available, 746 expiring Mobile IP timers). 748 9. IANA Considerations 750 This document defines an IANA registry for the protocol family 751 PF_TRIGGER. 753 An IANA registry might be needed for the different trigger types (for 754 which examples are provided in Section 4). 756 10. Security Considerations 758 This document describes an API which allows information about IP 759 addresses to be obtained at a local host. A malicious application or 760 protocol daemon could disseminate wrong information. This would make 761 other protocols, such as MOBIKE, believe that the status of a 762 particular address has changed. This will likely lead to unexpected 763 protocol behaviour, such as switching between addresses back-and- 764 forth. Hence, a certain trust has to be placed into the applications 765 and protocol daemons that are allowed to access the database to 766 insert, modify or delete triggers. Access control mechanisms might 767 enforce certain rights to use the API or parts of it. 769 11. Acknowledgments 771 The authors would like to thank Murugaraj Shanmugam, Yu Xinwen, 772 Wolfgang Groeting and Stefan Berg for their comments. Furthermore, 773 the authors would like to thank Emanuel Corthay for pointing them to 774 the IEEE 802.21 draft. 776 12. References 778 12.1. Normative References 780 [1] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, 781 Version 2", RFC 2367, July 1998. 783 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 784 Levels", March 1997. 786 12.2. Informative References 788 [3] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", 789 draft-ietf-mobike-design-04 (work in progress), October 2005. 791 [4] Rajkumar, Ajay., Williams, Michael., Liu, Xiaoyu., and Vivek. 792 Gupta, "Media Independent Handover Services", IEEE-Draft Draft 793 IEEE Standard for Local and Metropolitan Area Networks / IEEE 794 P802.21/D00.01, July 2005. 796 [5] Sugimoto, S. and F. Dupont, "PF_KEY Extension as an Interface 797 between Mobile IPv6 and IPsec/IKE", 798 draft-sugimoto-mip6-pfkey-migrate-01 (work in progress), 799 August 2005. 801 [6] Lee, S., Jeong, S., Tschofenig, H., Fu, X., and J. Manner, 802 "Applicability Statement of NSIS Protocols in Mobile 803 Environments", 804 draft-ietf-nsis-applicability-mobility-signalling-02 (work in 805 progress), July 2005. 807 Authors' Addresses 809 Udo Schilcher 810 Universitaet Klagenfurt 811 Klagenfurt, Carinthia 9020 812 Austria 814 Email: udo.schilcher@edu.uni-klu.ac.at 816 Hannes Tschofenig 817 Siemens 818 Otto-Hahn-Ring 6 819 Munich, Bayern 81739 820 Germany 822 Email: Hannes.Tschofenig@siemens.com 824 Franz Muenz 825 Siemens AG 826 Otto-Hahn-Ring 6 827 Munich, Bayern 81739 828 Germany 830 Email: Franz.Muenz@thirdwave.de 832 Intellectual Property Statement 834 The IETF takes no position regarding the validity or scope of any 835 Intellectual Property Rights or other rights that might be claimed to 836 pertain to the implementation or use of the technology described in 837 this document or the extent to which any license under such rights 838 might or might not be available; nor does it represent that it has 839 made any independent effort to identify any such rights. Information 840 on the procedures with respect to rights in RFC documents can be 841 found in BCP 78 and BCP 79. 843 Copies of IPR disclosures made to the IETF Secretariat and any 844 assurances of licenses to be made available, or the result of an 845 attempt made to obtain a general license or permission for the use of 846 such proprietary rights by implementers or users of this 847 specification can be obtained from the IETF on-line IPR repository at 848 http://www.ietf.org/ipr. 850 The IETF invites any interested party to bring to its attention any 851 copyrights, patents or patent applications, or other proprietary 852 rights that may cover technology that may be required to implement 853 this standard. Please address the information to the IETF at 854 ietf-ipr@ietf.org. 856 Disclaimer of Validity 858 This document and the information contained herein are provided on an 859 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 860 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 861 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 862 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 863 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 864 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Copyright Statement 868 Copyright (C) The Internet Society (2005). This document is subject 869 to the rights, licenses and restrictions contained in BCP 78, and 870 except as set forth therein, the authors retain all their rights. 872 Acknowledgment 874 Funding for the RFC Editor function is currently provided by the 875 Internet Society.