idnits 2.17.00 (12 Aug 2021) /tmp/idnits30875/draft-schilcher-mobike-trigger-api-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 882. ** 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 292: '... and MUST NOT have any effects on a ...' RFC 2119 keyword, line 306: '...onal information MAY be included (e.g....' RFC 2119 keyword, line 497: '...ered application MUST NOT respond to i...' RFC 2119 keyword, line 640: '... MUST be set to zero....' RFC 2119 keyword, line 682: '... 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 [3], 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 (March 5, 2006) is 5914 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 517 -- Looks like a reference, but probably isn't: 'ADDRESS' on line 517 == Outdated reference: draft-ietf-mobike-protocol has been published as RFC 4555 ** Downref: Normative reference to an Informational RFC: RFC 2367 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' == 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 (~~), 5 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: September 6, 2006 F. Muenz 6 Siemens AG 7 S. Sugimoto 8 Ericsson 9 March 5, 2006 11 Application Programming Interface to a Trigger Database for MOBIKE 12 draft-schilcher-mobike-trigger-api-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 6, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 MOBIKE is a protocol which adds mobility and multihome support for 46 IKEv2. MOBIKE peers continuously exchange a list of available IP 47 addresses each other. A MOBIKE peer should have some information 48 about the status of each address and interface in order to execute 49 the respective actions. Examples may comprise switching from one 50 address or interface to another. This information, which will be 51 referred as trigger, is distributed over a number of protocol daemons 52 at an end host. To make this information available to a MOBIKE 53 daemon, it is necessary to store it centrally at the host (called 54 trigger database) and to enable the protocols to insert the triggers 55 and to allow MOBIKE to obtain timely information. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Trigger Database and MIH . . . . . . . . . . . . . . . . . . . 6 62 4. Trigger Classification . . . . . . . . . . . . . . . . . . . . 8 63 5. API for the Trigger Database . . . . . . . . . . . . . . . . . 10 64 6. Supported Message Types . . . . . . . . . . . . . . . . . . . 12 65 7. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 17 66 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 22 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 72 12.2. Informative References . . . . . . . . . . . . . . . . . 26 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 74 Intellectual Property and Copyright Statements . . . . . . . . . . 28 76 1. Introduction 78 When a MOBIKE daemon [1] is started it first has to build a set of 79 all available addresses (or a subset of them for policy reasons; see 80 [4]) before communicating with another peer. From these addresses, 81 it has to select one of the addresses as the preferred address that 82 will be used as the source address in the communication with the 83 MOBIKE peer. 85 This address set together with the preferred address may change 86 during operation because of several reasons, e.g. an interface is 87 disconnected, a handover between two different link layer 88 technologies takes place or the communication path becomes 89 unavailable due to router failure. Many of the events, which cause 90 the change of the address set, are out of the scope of the MOBIKE 91 protocol itself but need an interaction with other protocols daemons 92 locally at the end host. 94 In order to make MOBIKE working properly, it is really important to 95 know about the status of the available addresses for making 96 reasonable decisions. A number of other protocols running on the end 97 host might have various information necessary to determine whether to 98 switch from one preferred address to another or whether it is 99 necessary to modify the peer address set. 101 An example is the IEEE 802.21 Media Independent Handover (MIH) 102 standard [5], which is currently under development. The MIH is 103 defined as a shim layer in the mobility-management protocol stack of 104 both, the mobile node and the network elements, that provide mobility 105 support. The MIH Function provides abstracted services to higher 106 layers about the status and performance of any link layer technology. 108 To benefit from this information on higher layers, however, the MIH 109 services must be combined with information from upper layers in order 110 to facilitate a basis for decisions above network layer. 112 In this document, we therefore suggest to define an API that allows 113 protocol daemons to insert information (triggers) about addresses and 114 interfaces into a "database" that can later be made available to the 115 MOBIKE daemon (or other protocols). Although, there have been some 116 mechanisms [6][7] that can fulfill some of these requirements, we 117 still need a flexible framework that can handle asynchronous event 118 that takes place at L3 or below, including MIH events. The API will 119 provide similar services to the MOBIKE daemon like MIH does for layer 120 3 and above. It is based on the BSD routing socket API in a similar 121 fashion as PF_KEY [2] extends the same API for generic key management 122 usage. 124 This document therefore heavily focuses on the functionality offered 125 by the PF_KEY specification and uses the MIH Function as an example 126 for retrieving necessary information for a decision making process. 128 Please note that the authors use the term 'database' in a symbolic 129 way. It is a container for storing information about events. 130 Information about the status of interfaces and addresses might not 131 even be stored directly in this database and could well be 132 implemented using a collection of pointers to the respective 133 information. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [3]. 141 Additionally, the following terms are introduced: 143 o Trigger: Information which is relevant for MOBIKE about an 144 address. 146 o Trigger Database (TDB): Collection of triggers which can be 147 accessed via the API defined in this document. 149 o Media Independent Handover (MIH): Described in IEEE draft 802.21 150 [5] which is currently under development. The MIH Function 151 provides abstracted services to higher layers about the status and 152 performance of any link layer technology. 154 3. Trigger Database and MIH 156 The following section should give a brief overview for the 157 interaction of Media Independent Handover (MIH) with Trigger Database 158 (TDB) and MOBIKE daemon. The services of MIH are used e.g. for 159 compiling relevant information about interface performance, which is 160 then signalled through the Trigger Database to the MOBIKE daemon. 161 Based on this data, the MOBIKE daemon may select a new preferred 162 address or continues using the current one. 164 +--------------------------------------+ 165 | MOBIKE daemon | 166 | +-------------------+ | 167 | | PF_TRIGGER socket | | 168 | +--------------+----+ | 169 | ^ | | 170 +-----------|-----------|--------------+ 171 | | 172 | | 173 TDB TDB 174 Events Commands 175 | | 176 | v 177 +-----------+--------------------------+ 178 | Trigger Database (TDB) | 179 | (Layer 3 an above) | 180 +--------------------------------------+ 181 ^ | ^ 182 | | | 183 MIH MIH Information 184 Events Commands Service 185 | | | 186 | v v 187 +--------------------------------------+ 188 | Media Independent Handover Function | 189 +--------------------------------------+ 190 ^ | ^ 191 | | | 192 Link Link Information 193 Events Commands Service 194 | | | 195 | v v 196 +--------------------------------------+ 197 | Lower Layers (Layer 2 and below) | 198 +--------------------------------------+ 200 To receive event notifications from the MIH, the Trigger Database 201 must perform two steps: 203 Capability discovery: 205 While the MIH provides many services, not all of them may be 206 supported on a given platform. For learning, which of them are 207 actually supported, the Trigger Database must query the MIH with a 208 "MIH_Capability_Discover.request". The response, a 209 "MIH_Capability_Discover.response" message will then indicate with 210 a bit mask which services are supported. Alternatives and 211 solutions for not supported but required services is done in a 212 future version of this draft. 214 Service registration: 216 Now knowing the supported services, the Trigger Database must 217 register to the services it is interested in with a 218 "MIH_Event_Register.request" message. To confirm registration, 219 the MIH answers with a "MIH_Event_Register.confirm" message and 220 notifies the Trigger Database in case of status change of 221 interfaces. 223 4. Trigger Classification 225 Many different events may cause a change in the address set used by 226 MOBIKE (see [4]). These events can be issued by many different 227 protocols running in kernel or user space. Since the reaction (if 228 any) on a given event depends on the type of the event, a 229 classification of these events is necessary. 231 As an example, we define the following triggers in this document: 233 Trigger type Value Description 234 ---------------------------+-------+------------------------------- 235 TDB_TTYPE_IF_ADDED | 1 | New interface added 236 TDB_TTYPE_IF_REMOVED | 2 | Interface removed 237 TDB_TTYPE_IF_REMOVEDSOON | 3 | Interface is expected to be 238 | | removed soon 239 TDB_TTYPE_IF_ADDRADDED | 4 | New address added to interface 240 TDB_TTYPE_IF_ADDRREMOVED | 5 | Address removed from interface 241 TDB_TTYPE_IF_ADDRCHANGED | 6 | Interface has changed one of its 242 | | addresses (e.g. new DHCP lease) 243 TDB_TTYPE_TUNNEL_ADDED | 7 | IPSec tunnel was established 244 TDB_TTYPE_TUNNEL_CHANGED | 8 | IPSec tunnel conf. changed 245 TDB_TTYPE_TUNNEL_REMOVED | 9 | IPSec tunnel was removed 246 TDB_TTYPE_CONN_ESTABLISHED | 10 | e.g. dial-in network 247 | | has connected 248 TDB_TTYPE_CONN_LOST | 11 | connection to network lost 249 TDB_TTYPE_DEST_UNREACHABLE | 12 | e.g. ICMP packet received 250 TDB_TTYPE_MAX | 13 | Maximum value for trigger types 252 The types TDB_TTYPE_TUNNEL_ADDED, TDB_TTYPE_TUNNEL_CHANGED and 253 TDB_TTYPE_TUNNEL_REMOVED are inspired by [8]. Any listed trigger 254 types will be signalled using the "tdb_trigger" message structure 255 described in Section 7 257 Details about the supported message types and their formats can be 258 found below: 260 TDB_TTYPE_IF_ADDED: 262 This message is signalled if a new interface comes up and directly 263 refers to the "Link_Up.indication" event notification of the MIH 264 Function. 266 TDB_TTYPE_IF_REMOVED: 268 This message is signalled if an interface is going down and 269 directly refers to the "Link_Down.indication" event notification 270 of the MIH Function. 272 TDB_TTYPE_IF_REMOVEDSOON: 274 This message is signalled if an interface is expected (predicted) 275 to go down within a certain time interval and directly refers to 276 the "Link_Going_Down.indication" event notification of the MIH 277 Function. 279 A future version of this document will add more triggers and a more 280 detailed description of them. 282 5. API for the Trigger Database 284 To access the trigger database, an API is defined. For that purpose 285 the new network protocol family ID PF_TRIGGER has to be defined. The 286 operation of the API is analogue to the PF_KEY interface (see [2]). 288 To access the API, a socket of the family PF_TRIGGER has to be 289 created. To communicate with the Trigger Database, messages are sent 290 and received through the socket with the send() and recv() functions. 291 Any other functions like bind(), connect(), etc. are not supported 292 and MUST NOT have any effects on a socket of the PF_TRIGGER family. 294 The following exhibits a sample socket creation: 296 int s = socket(PF_TRIGGER, SOCK_RAW, PF_TRIGGER); 298 The format of the messages is the following: Each message starts with 299 a fixed header. Appended to this header, there are some payloads 300 depending on the type of the message. The available message types 301 are described in Section 6. 303 Each time when a message is sent to the Trigger Database, it will 304 respond with a message of the same type. This response contains the 305 same payloads as transmitted to the Trigger Database, only some 306 additional information MAY be included (e.g., the Trigger Database 307 assigns an id to each trigger). 309 The normal operation works in the following way: A MOBIKE 310 implementation, which wants to be informed about changes in the 311 Trigger Database, registers itself to the Trigger Database by sending 312 a TDB_REGISTER message. 314 If a protocol daemon wants to add, delete or modify an existing 315 trigger it sends a TDB_ADD, TDB_DELETE or TDB_MODIFY message 316 respectively to the Trigger Database including information that is 317 important to add, delete or modify the trigger. 319 The Trigger Database acknowledges this message with a TDB_ADD, 320 TDB_DELETE or TDB_MODIFY response to the network protocol and with a 321 TDB_NOTIFY message to the registered MOBIKE implementation. This 322 notify message contains information about the newly added, deleted or 323 modified trigger including its ID. All available information about a 324 trigger can be requested with a TDB_GET message. 326 If a MOBIKE implementation no longer wants to receive notifications 327 for changes to the Trigger Database, it sends a TDB_DEREGISTER 328 message. 330 In a future version of this document, we will try to add some 331 information about scenarios to better illustrate the interaction. 333 6. Supported Message Types 335 Several different message types can be sent to the Trigger Database 336 using a PF_TRIGGER socket. The message type is indicated by the 337 tdb_header_msgtype field that is part of the generic message header 338 (see Section 7) and can be one of the following values: 340 Message type Value Description 341 ------------------+---------+------------------------------ 342 TDB_ADD | 1 | Add a trigger to the 343 | | Trigger Database 344 TDB_GET | 2 | Get information about an 345 | | existing trigger. 346 TDB_DELETE | 3 | Delete a trigger from the 347 | | Trigger Database 348 TDB_REGISTER | 4 | Registers an application 349 | | to receive messages for 350 | | each new trigger added. 351 TDB_DEREGISTER | 5 | Deregisters an application 352 | | from receiving messages for 353 | | each new trigger added. 354 TDB_NOTIFY | 6 | A new trigger has been 355 | | added, deleted or updated. 356 TDB_MODIFY | 7 | Modify a trigger in the 357 | | Trigger Database 358 TDB_DUMP | 8 | Dump all Trigger Database 359 | | entries 360 TDB_FLUSH | 9 | Delete all Trigger Database 361 | | entries 362 TDB_MAX | 10 | Generic maximum for message 363 | | types 365 Each message type requires different payloads to be appended. Each 366 payload starts with a generic payload header followed by payload 367 specific data. The generic header has the following structure: 369 struct tdb_payload { 370 uint16_t tdb_payload_len; 371 uint16_t tdb_payload_type; 372 } __attribute__( ( packed ) ); 373 /* sizeof( struct tdb_payload ) == 4 */ 375 The tdb_payload_len field contains the length of the payload divided 376 by 8. The type of the payload is determined by the tdb_payload_type 377 field, which contains one of the following values: 379 Payload type Value Description 380 ---------------------------+---------+------------------------------- 381 TDB_PT_INTERFACE | 1 | Information about an interface 382 TDB_PT_ADDRESS | 2 | The IP address of an interface 383 TDB_PT_TRIGGER | 3 | Trigger id, type, etc. 385 Details about the supported message types and their formats can be 386 found below: 388 TDB_ADD: 390 If an application or network protocol wants to add a new trigger, 391 it sends a TDB_ADD message to the Trigger Database. The new 392 trigger is stored in the Trigger Database and a corresponding 393 TDB_NOTIFY message that indicates that a new trigger has been 394 added is sent to all registered applications. 396 The format of the message is: 398 400 The TRIGGER payload indicates the type of the trigger and also 401 includes some trigger specific data. The INTERFACE payload is 402 needed to select the appropriate physical interface, the new 403 trigger is related to. For many triggers, an additional address 404 payload is required. It contains, for example, the new address 405 for a TDB_TTYPE_IF_ADDRCHANGED trigger. 407 The response from the Trigger Database contains the same 408 information as the request: 410 412 TDB_DELETE: 414 A trigger, which is stored inside the Trigger Database, can be 415 deleted using the TDB_DELETE payload. In the request the only 416 information, which has to be specified is the id of the trigger, 417 which is stored in 'TRIGGER(*)'. A corresponding TDB_NOTIFY 418 message that indicates that a trigger has been deleted is sent to 419 all registered applications. 421 The format of the message is: 423 425 The Trigger Database responds with a message with the following 426 format: 428 430 In the response, the TRIGGER payload has all fields filled with 431 the correct values. 433 TDB_GET: 435 The TDB_GET message is used to request all available information 436 of a specified trigger. In the request the only information, 437 which has to be specified is the id of the trigger, which is 438 stored in 'TRIGGER(*)'. 440 The format of the message is: 442 444 The Trigger Database responds with a message of the following 445 format: 447 449 In the response a fully initialized TRIGGER payload is present. 450 Additionally, INTERFACE payload is present as well as and an 451 optional an ADDRESS payload, if an address is available for the 452 specified trigger. 454 TDB_REGISTER: 456 An application, which is interested in each new trigger, can 457 register itself to the Trigger Database. After the application 458 has registered, it receives a message each time a new trigger has 459 been added to the database. The format of the message is: 461
463 No additional payload has to be added. The Trigger Database 464 responds with a message of the same type and with the same 465 content, i.e. its format is: 467
469 TDB_DEREGISTER: 471 An application, which is no longer interested in receiving 472 notifications about trigger changes, can de-register itself from 473 the Trigger Database. The format of the message is: 475
477 No additional payload has to be added. The Trigger Database 478 responds with a message of the same type and with the same 479 content, i.e. its format is: 481
483 TDB_NOTIFY 485 An application that has registered itself to get informed about 486 the new triggers or updates to these triggers, receives a 487 TDB_NOTIFY message. The format of the message is the same as for 488 a TDB_ADD message. The only difference is that some field are 489 filled by the Trigger Database before sending the TDB_NOTIFY 490 message. 492 The format of the message is: 494 496 Since this message is sent by the Trigger Database itself, a 497 registered application MUST NOT respond to it. 499 TDB_MODIFY: 501 If an application or a network protocol wants to modify a trigger 502 (because its status has changed), it sends a TDB_MODIFY message to 503 the Trigger Database. The new trigger is stored and a 504 corresponding TDB_NOTIFY message that indicates that an existing 505 trigger has been modified is sent to all registered applications. 507 The format of the message is: 509 511 The TRIGGER payload indicates the type of the trigger and also 512 includes some trigger specific data. 514 The response from the Trigger Database contains the same 515 information as the request: 517 519 TDB_DUMP: 521 An application, that wants to learn all currently available 522 triggers should send a TDB_DUMP message. Since a TDB_GET message 523 requires a specific trigger id for retrieval, applications which 524 to not know all trigger IDs depend on this message class for 525 learning all unknown triggers. The format of the message is: 527
529 The Trigger Database will respond with all currently available 530 triggers entries by serially sending the following message: 532 534 TDB_FLUSH: 536 For deleting all entries in a Trigger Database, the TDB_FLUSH 537 message is used. Since the TDB_GET message requires a specific 538 trigger id for deletion, reliable cleaning of a Trigger Database 539 can be done with this message. The format of the message is: 541
543 The Trigger Database will respond with the following message: 545
547 7. Payload Format 549 HEADER: 551 Each message starts with the fixed header. It contains general 552 information about the message and determines, which payloads have 553 to be included in it. It has the following format: 555 struct tdb_header { 556 uint8_t tdb_header_version; 557 uint8_t tdb_header_msgtype; 558 uint8_t tdb_header_errno; 559 uint8_t tdb_header_reserved1; 560 uint16_t tdb_header_msglen; 561 uint16_t tdb_header_reserved2; 562 uint32_t tdb_header_seq; 563 uint32_t tdb_header_pid; 564 } __attribute__( ( packed ) ); 565 /* sizeof( struct tdb_header ) == 16 */ 567 The fields of this structure contain the following values: 569 tdb_header_version: The version of the used PF_TRIGGER interface. 570 This document specifies this API in version 1. 572 tdb_header_msgtype: This field contains the type of the message. 573 All possible values are listed in the table in Section 6. 575 tdb_header_errno: If an error occurred while processing a request, 576 the response will only include the message header without any 577 payloads. The type of the error is indicated by the value in 578 this field. The values are taken from the error number 579 specification of the operating system (e.g. the errno.h file). 581 tdb_header_msglen: The length of the message divided by 8 is 582 stored into this field. 584 tdb_header_seq: This field contains the number of the last message 585 sent incremented by 1. 587 tdb_header_pid: The process id of the program sending the message. 588 If the message is generated inside the kernel, this value is 589 set to zero. 591 INTERFACE: 593 The INTERFACE payload is used to provide all needed information 594 about an active network interface. 596 The format of the INTERFACE payload is the following: 598 struct tdb_interface { 599 uint16_t tdb_interface_len; 600 uint16_t tdb_interface_pltype; 601 uint32_t tdb_interface_selector; 602 uint32_t tdb_interface_type; 603 uint32_t tdb_interface_bandwidth; 604 uint32_t tdb_interface_quality; 605 uint32_t tdb_interface_reserved; 606 } __attribute__( ( packed ) ); 607 /* sizeof( struct tdb_interface ) == 16 */ 609 This fields contain the following values: 611 tdb_interface_len: This field contains the length of the payload 612 divided by 8. 614 tdb_interface_pltype: This field contains the value 615 TDB_PT_INTERFACE. 617 tdb_interface_selector: The tdb_interface_selector field stores 618 interface enumeration information for unique identification (IF 619 #0, #1, #2, ...). When a new interface comes up, this value 620 should be set by the kernel. 622 tdb_interface_type: Classification of an interface, for instance 623 fixed or wireless network link. The MIH Function provides this 624 information by issuing a "MIH_Poll.request" from the Trigger 625 Database, before creating any event notification destined for 626 the MOBIKE daemon. 628 tdb_interface_bandwidth: Information about the maximum bandwidth 629 of an interface. The MIH Function provides this information by 630 issuing a "MIH_Poll.request" from the Trigger Database, before 631 creating any event notification destined for the MOBIKE daemon. 633 tdb_interface_quality: Information about current connection 634 quality of an interface. The MIH Function provides this 635 information by issuing a "MIH_Poll.request" from the Trigger 636 Database, before creating any event notification destined for 637 the MOBIKE daemon. 639 tdb_interface_reserved: This field is reserved for future use and 640 MUST be set to zero. 642 Further information about an interface might be necessary. 643 Especially asymmetric link connectivity/availability in case of 644 wireless connections might be relevant. This is left for future 645 investigation. 647 ADDRESS: 649 The ADDRESS payload is used to provide the IP address of an 650 interface to the Trigger Database or registered application. This 651 information is important for most triggers. But it might be 652 possible that there are trigger types which do not need an ADDRESS 653 payload. 655 The format of the ADDRESS payload is: 657 struct tdb_address { 658 uint16_t tdb_address_len; 659 uint16_t tdb_address_pltype; 660 uint8_t tdb_address_proto; 661 uint8_t tdb_address_prefixlen; 662 uint16_t tdb_address_reserved; 663 } __attribute__( ( packed ) ); 664 /* sizeof( struct tdb_address ) == 8 */ 666 /* followed by some form of struct sockaddr */ 668 Information about IP address and probably ports is provided by a 669 sockaddr structure which is attached to the tdb_address structure. 670 A sockaddr structure is capable of storing both a IPv4 and IPv6 671 address. The fields of the tdb_address structure contains the 672 following values: 674 tdb_address_len: This field contains the length of the payload 675 including the sockaddr structure divided by 8. 677 tdb_address_pltype: The tdb_address_pltype field contains the 678 value TDB_PT_ADDRESS. 680 tdb_address_proto: The tdb_address_proto field is normally set to 681 zero. However, if is are set in the attached sockaddr needed, 682 then the field SHOULD be set to the protocol number of the 683 upper layer protocol. (e.g. TCP or UDP). This functionality 684 may become relevant for signalling IPSec related information 685 (e.g. tunnel changes) 687 tdb_address_prefixlen: This field contains the prefix length of 688 the address, which might be useful to key management 689 applications, which employ it in access control decisions. If 690 the tdb_address_prefixlen is non-zero the address has a prefix. 692 tdb_address_reserved: The tdb_address_reserved field is reserved 693 for future use and MUST be set to zero. 695 TRIGGER: 697 The TRIGGER payload is used to provide all needed information 698 about a trigger itself, e.g. the trigger type, an id, etc. The 699 notation TRIGGER(*) indicates that only the id field is used to 700 identify the trigger and all other fields SHOULD be set to zero. 702 The format of the TRIGGER payload is the following: 704 struct tdb_trigger { 705 uint16_t tdb_trigger_len; 706 uint16_t tdb_trigger_pltype; 707 uint16_t tdb_trigger_type; 708 uint16_t tdb_trigger_reserved1; 709 uint32_t tdb_trigger_id; 710 uint32_t tdb_trigger_reserved2; 711 } __attribute__( ( packed ) ); 712 /* sizeof( struct tdb_trigger ) == 16 */ 713 This fields contain the following values: 715 tdb_address_len: This field contains the length of the payload 716 divided by 8. 718 tdb_address_pltype: This field contains the value TDB_PT_TRIGGER. 720 tdb_address_type: The type of the trigger is stored into this 721 field. All possible values are listed in the table in section 722 Section 4. 724 tdb_address_id: The id of a trigger is assigned by the Trigger 725 Database itself. In the message sent by userspace programs, 726 which do not know this value (e.g. for TDB_ADD messages), this 727 value MUST be set to zero. 729 Further information about a trigger might be necessary. This is 730 left for future investigation. 732 8. Applicability 734 Even though this document is intended to give a solution for MOBIKE, 735 the API is generic enough to make information available for other 736 protocols as well. 738 The Next Step In Signaling (NSIS) protocol suite, for example, 739 requires access to up-to-date information about IP addresses, 740 interfaces and interactions with mobility protocols. In order to 741 react on mobility events some sort of interaction between the kernel, 742 various signalling protocols (including Mobile IP, IKE/IPsec, etc.) 743 and the NSIS daemon is required (see [9]). Hence, an NSIS daemon 744 supporting mobility could benefit from a generic interface to meet 745 it's requirements for fast and accurate detection of mobility events, 746 address and interface changes. GIMPS, for example, demands immediate 747 reaction in case of a mobility event (e.g., handover). Monitoring 748 procedures of mobility management protocols like Mobile IP are 749 required to react to these mobility events in an appropriate way. 751 The trigger database and it's API could provide necessary information 752 for detecting such a movement (new interface/IP address available, 753 expiring Mobile IP timers). 755 9. IANA Considerations 757 This document defines an IANA registry for the protocol family 758 PF_TRIGGER. 760 An IANA registry might be needed for the different trigger types (for 761 which examples are provided in Section 4). 763 10. Security Considerations 765 This document describes an API which allows information about IP 766 addresses to be obtained at a local host. A malicious application or 767 protocol daemon could disseminate wrong information. This would make 768 other protocols, such as MOBIKE, believe that the status of a 769 particular address has changed. This will likely lead to unexpected 770 protocol behaviour, such as switching between addresses back-and- 771 forth. Hence, a certain trust has to be placed into the applications 772 and protocol daemons that are allowed to access the database to 773 insert, modify or delete triggers. Access control mechanisms might 774 enforce certain rights to use the API or parts of it. 776 11. Acknowledgments 778 The authors would like to thank Murugaraj Shanmugam, Yu Xinwen, 779 Wolfgang Groeting and Stefan Berg for their comments. Furthermore, 780 the authors would like to thank Emanuel Corthay for pointing them to 781 the IEEE 802.21 draft. 783 12. References 785 12.1. Normative References 787 [1] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 788 draft-ietf-mobike-protocol-08 (work in progress), February 2006. 790 [2] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, 791 Version 2", RFC 2367, July 1998. 793 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 794 Levels", March 1997. 796 12.2. Informative References 798 [4] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", 799 draft-ietf-mobike-design-08 (work in progress), March 2006. 801 [5] Rajkumar, Ajay., Williams, Michael., Liu, Xiaoyu., and Vivek. 802 Gupta, "Media Independent Handover Services", IEEE-Draft Draft 803 IEEE Standard for Local and Metropolitan Area Networks / IEEE 804 P802.21/D00.01, July 2005. 806 [6] Sklower, K., "Tree-based Packet Routing Table for Berkeley 807 UNIXProceedings of the Winter 1991 USENIX Conference, Dallas, 808 TX, USENIX Association. 1991. pp. 93-103.", 1991. 810 [7] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, "Linux 811 Netlink as an IP Services Protocol", RFC 3549, July 2003. 813 [8] Sugimoto, S. and F. Dupont, "PF_KEY Extension as an Interface 814 between Mobile IPv6 and IPsec/IKE", 815 draft-sugimoto-mip6-pfkey-migrate-01 (work in progress), 816 August 2005. 818 [9] Lee, S., Jeong, S., Tschofenig, H., Fu, X., and J. Manner, 819 "Applicability Statement of NSIS Protocols in Mobile 820 Environments", 821 draft-ietf-nsis-applicability-mobility-signalling-02 (work in 822 progress), July 2005. 824 Authors' Addresses 826 Udo Schilcher 827 Universitaet Klagenfurt 828 Klagenfurt, Carinthia 9020 829 Austria 831 Email: udo.schilcher@edu.uni-klu.ac.at 833 Hannes Tschofenig 834 Siemens 835 Otto-Hahn-Ring 6 836 Munich, Bayern 81739 837 Germany 839 Email: Hannes.Tschofenig@siemens.com 841 Franz Muenz 842 Siemens AG 843 Otto-Hahn-Ring 6 844 Munich, Bayern 81739 845 Germany 847 Email: Franz.Muenz@thirdwave.de 849 Shinta Sugimoto 850 Ericsson Research Japan 851 Nippon Ericsson K.K. 852 Koraku Mori Building 853 1-4-14, Koraku, Bunkyo-ku 854 Tokyo 112-0004 855 Japan 857 Phone: +81 3 3830 2241 858 Email: shinta.sugimoto@ericsson.com 860 Intellectual Property Statement 862 The IETF takes no position regarding the validity or scope of any 863 Intellectual Property Rights or other rights that might be claimed to 864 pertain to the implementation or use of the technology described in 865 this document or the extent to which any license under such rights 866 might or might not be available; nor does it represent that it has 867 made any independent effort to identify any such rights. Information 868 on the procedures with respect to rights in RFC documents can be 869 found in BCP 78 and BCP 79. 871 Copies of IPR disclosures made to the IETF Secretariat and any 872 assurances of licenses to be made available, or the result of an 873 attempt made to obtain a general license or permission for the use of 874 such proprietary rights by implementers or users of this 875 specification can be obtained from the IETF on-line IPR repository at 876 http://www.ietf.org/ipr. 878 The IETF invites any interested party to bring to its attention any 879 copyrights, patents or patent applications, or other proprietary 880 rights that may cover technology that may be required to implement 881 this standard. Please address the information to the IETF at 882 ietf-ipr@ietf.org. 884 Disclaimer of Validity 886 This document and the information contained herein are provided on an 887 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 888 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 889 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 890 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 891 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 892 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 894 Copyright Statement 896 Copyright (C) The Internet Society (2006). This document is subject 897 to the rights, licenses and restrictions contained in BCP 78, and 898 except as set forth therein, the authors retain all their rights. 900 Acknowledgment 902 Funding for the RFC Editor function is currently provided by the 903 Internet Society.