Network Working Group T. Momose Internet-Draft NEC Expires: December 3, 2005 K. Shima IIJ A. Tuominen HUT June 2005 The application interface to exchange mobility information with Mobility subsystem (Mobility Socket, AF_MOBILITY) draft-momose-mip6-mipsock-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes the interface to exchange mobility related information between processes or between processes and a kernel, using a socket interface. A new address family is defined for the purpose. Momose, et al. Expires December 3, 2005 [Page 1] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 1. Introduction We sometimes need to implement applications which need to be aware of the status of mobility protocols such as Mobile IPv6 and NEMO. A user space Mobile IPv6/NEMO protocol stack is one of such applications. Another example is a program to synchronize binding information between home agents for redundancy, such as HA-HA protocol implementation. When implementing those applications, we need an interface to get/set such information from/to the module which implements the mobility functions. We call the module a mobility subsystem. We define Mipsock (mobility socket) as a new socket to exchange mobility related informations between a mobility subsystem and other applications. Mipsock uses a new address family (AF_MOBILITY) that is a variation of raw sockets and acts like the PF_ROUTE socket mechanism. A message sent to an AF_MOBILITY socket is delivered to a mobility subsystem and all other applications which listen an AF_MOBILITY socket. In addition to the broadcasting mechanism, an unicast mechanism to deriver messages to a specific process is also designed. Applications can get/set mobility related informations by simply reading/writing an AF_MOBILITY socket and can also be notified as soon as the information is updated thanks to the asynchronous nature of the socket mechanism. Momose, et al. Expires December 3, 2005 [Page 2] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 2. Related works Draft-yokote-mobileip-api [5] is a proposal which defines an API to get mobility information. The API defined in the draft consists of functions to get the information and the callback mechanism to receive any asynchronous events from a mobility subsystem. The proposal provides more abstract interface compared to our Mipsock API, which may be easier to use for application programmer. On the other hand, the proposal does not mention the mechanism of message exchange between mobility entities. Our proposal can fill the gap between such an abstract API set and the lower layer message exchange. Momose, et al. Expires December 3, 2005 [Page 3] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 3. AF_MOBILITY Address Family 3.1 Conceptual Model This section provides the conceptual description of the AF_MOBILITY socket mechanism. The AF_MOBILITY is an application interface to exchange mobility related information used in Mobile IPv6 [1] and NEMO [2]. AF_MOBILITY is located between the mobility subsystem and the application layer and provides a socket interface to both layers. Figure 1 shows the concept of AF_MOBILITY. The similar concept is also adopted by PF_ROUTE and PF_KEY [3]. +--------------+ +---------------+ | |---[ AF_MOBILITY ]---| | | | | |----+ | Mobility | <---- set ----- | Application | | | Subsystem | | | |----+ | | --- notify ---> | | | | | | +---------------+ | | +--------------+ <---- get -----> | | | +--------------+ | | | +-------------+ Figure 1 The implementation of a mobility subsystem can be done both in a kernel or in a user space. It depends on the design of the implementation of the system. The important point is that all mobility related entities can exchange information using a common interface as long as the design chooses the AF_MOBILITY mechanism as the interface between them. 3.2 AF_MOBILITY Socket The AF_MOBILITY address family is defined in . All message structures used by the AF_MOBILITY socket are defined in . The socket is created as follows: #include #include #include int s; s = socket(AF_MOBILITY, SOCK_RAW, 0); Momose, et al. Expires December 3, 2005 [Page 4] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 The AF_MOBILITY socket only supports the SOCK_RAW socket type. The protocol parameter does not have any meaning. It should be 0 currently. The AF_MOBILITY socket can be created and operated by a privileged process, since the socket will insert or delete binding information stored in a mobility subsystem which affects the routing behavior of the node. 3.3 Mipsock message The following messages are defined in this document. Actual parameters used in each messages are different by each message type. #define MIPM_NODETYPE_INFO 1 #define MIPM_BC_ADD 2 #define MIPM_BC_UPDATE 3 #define MIPM_BC_REMOVE 4 #define MIPM_BC_FLUSH 5 #define MIPM_BC_GET 6 #define MIPM_BUL_ADD 7 #define MIPM_BUL_UPDATE 8 #define MIPM_BUL_REMOVE 9 #define MIPM_BUL_FLUSH 10 #define MIPM_BUL_GET 11 #define MIPM_MD_INFO 12 #define MIPM_HOME_HINT 13 #define MIPM_RR_HINT 14 #define MIPM_BE_HINT 15 3.3.1 MIPM_NODETYPE_INFO MIPM_NODETYPE_INFO set or get of the current node type. mipm_nodetype_info structure is used as a parameter. This message is delivered to all processes which listen to a AF_MOBILITY socket. Any process which need to change its behavior based on the mobility functions can use this message to get the node type. A special process, which handles mobility protocol signaling messages, may change the node type by issuing this message. For example, a user space Mobile IPv6 or NEMO protocol stack will use this message to enable or disable mobility functions. 3.3.2 MIPM_BC_ADD [Do we need MIPM_BC_ADD, in addition to MIPM_BC_UPDATE??] MIPM_BC_ADD message is sent when a new binding cache entry is Momose, et al. Expires December 3, 2005 [Page 5] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 created. mipm_bc_info structure is used as a parameter. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is issued by a user space mobility protocol subsystem, which provides a correspondent node or a home agent function including a home agent. Such a mobility program may add a new binding cache entry for route optimization after the program completes some kind of authorization procedure to confirm the binding information between the home address and the care-of address of the mobile node, which the correspondent node is now communicating, is valid. 3.3.3 MIPM_BC_UPDATE MIPM_BC_UPDATE message is sent when existing binding cache entry is updated. mipm_bc_info structure is used as a parameter. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is issued by a user space mobility protocol subsystem, which provides a correspondent node or a home agent function including a home agent. Such a mobility program may update an existing binding cache entry for route optimization after the program completes some kind of authorization procedure to confirm the binding information between the home address and the care-of address of the mobile node, which the correspondent node is now communicating, is valid. 3.3.4 MIPM_BC_REMOVE MIPM_BC_REMOVE deletes a binding cache entry and is sent when an existing binding cache entry need to be deleted. mipm_bc_info structure is used as a parameter. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is issued by a user space mobility protocol subsystem, which provides a correspondent node or a home agent function including a home agent. Such a mobility program may remove an existing binding cache entry, when the lifetime of the entry expires or when some kind of error condition which need to remove the binding information occurs. 3.3.5 MIPM_BC_FLUSH MIPM_BC_FLUSH deletes all of binding cache entries. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is used by a user space mobility protocol subsystem, which provides a correspondent node function including a home agent. Momose, et al. Expires December 3, 2005 [Page 6] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 The typical usage of this message is to clear all binding cache information in a kernel when stopping a correspondent node or a home agent function. 3.3.6 MIPM_BC_GET MIPM_BC_GET requests an information os a specified binding cache entry. The result will be send back in the same MIPM_BC_GET message. This message is delivered to all processes which listen to an AF_MOBILITY socket. This message is issued by a user space program which need to know the information of a binding cache entry. A program issues the message with mip_bc_info structure filled with the address of the binding cache entry which the program need to know. The message will be resent again by kernel or other responsible mobility programs with all information filled. 3.3.7 MIPM_BUL_ADD [Do we need MIPM_BUL_ADD, in addition to MIPM_BUL_UPDATE??] MIPM_BUL_ADD message is sent when a new binding update list entry is created. mipm_bul_info structure is used as a parameter. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is issued by a user space mobility protocol subsystem, which provides a mobile host or a mobile router function. Such a mobility program may add a binding update list entry to register its binding information to its home agent, or to perform route optimization with correspondent nodes. 3.3.8 MIPM_BUL_UPDATE MIPM_BUL_UPDATE message is sent when existing binding update list entry is updated. mipm_bul_info structure is used as a parameter. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is issued by a user space mobility protocol subsystem, which provides a mobile host or a mobile router function. Such a mobility program may update an existing binding update list entry. 3.3.9 MIPM_BUL_REMOVE MIPM_BUL_REMOVE deletes a binding cache entry. mipm_bul_info structure is used as a parameter. This message is delivered to all Momose, et al. Expires December 3, 2005 [Page 7] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 processes which listen to a AF_MOBILITY socket. This message is issued by a user space mobility protocol subsystem, which provides a mobile host or a mobile router function. Such a mobility program may delete a binding update list entry when its lifetime expires. 3.3.10 MIPM_BUL_FLUSH MIPM_BUL_FLUSH deletes all of binding cache entries. This message is delivered to all processes which listen to a AF_MOBILITY socket. This message is used by a user space mobility protocol subsystem, which provides a mobile node function. The typical usage of this message is to clear all binding information in a kernel when stopping a mobile node function. 3.3.11 MIPM_BUL_GET MIPM_BUL_GET requests an information os a specified binding update list entry. The result will be send back in the same MIPM_BUL_GET message. This message is delivered to all processes which listen to an AF_MOBILITY socket. This message is issued by a user space program which need to know the information of a binding update list entry. A program issues the message with mip_bul_info structure filled with the address of the binding update list entry which the program need to know. The message will be resent again by kernel or other responsible mobility programs with all information filled. 3.3.12 Should we consider these messages ? These messages are very Shisa [6] dependent. I don't think it should be on standardization track. #define MIPM_MD_INFO 10 #define MIPM_HOME_HINT 11 #define MIPM_RR_HINT 12 #define MIPM_BE_HINT 13 3.4 AF_MOBILITY Operation 3.5 AF_MOBILITY Message Filtering AF_MOBILITY socket will generate a lot of messages related to mobility activities on a node. For some programs, not all messages Momose, et al. Expires December 3, 2005 [Page 8] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 are necessary to receive. To reduce the number of messages which need to be processed by a program, the following filter mechanism is provided. struct mip_filter; void MIP_FILTER_SETPASSALL(struct mip_filter *); void MIP_FILTER_SETBLOCKALL(struct mip_filter *); void MIP_FILTER_SETPASS(int, struct mip_filter *); void MIP_FILTER_SETBLOCK(int, struct mip_filter *); int MIP_FILTER_WILLPASS(int, struct mip_filter *); int MIP_FILTER_WILLBLOCK(int, struct mip_filter *); The filter is set by the setsockopt() system call. The current value can be get by the getsockopt() system call. Momose, et al. Expires December 3, 2005 [Page 9] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 4. AF_MOBILITY Message Format An AF_MOBILITY message consisits of two parts. One is common header as mip_msghdr. The common header part is commonly used for all messages. Message type specific part is followed. 4.1 mip_msghdr mip_msghdr structure is a common header part of all AF_MOBILITY messages. struct mip_msghdr { uint16_t mipm_msglen; /* message length */ uint8_t mipm_version; /* version number */ uint8_t mipm_type; /* message type */ uint32_t mipm_flags; /* flags, e.g. MIPF_DONE */ uint32_t mipm_pid; /* identify sender */ uint32_t mipm_seq; /* identifier of each message */ uint32_t mipm_errno; /* why failed */ }; #define MIPF_DONE 0x01 /* message confirmed */ mipm_msglen: The length of the entire message. The length of a message varies depend on the message type and its optional parameters. mipm_version: A version number of the message set. Currently, all messages must specify 1 as a version number. mipm_type: The type number of a message. mipm_flags: The flags associated to the message contents. mipm_seq: A sequence number to identify a particular message. mipm_pid: A unique identifier of each message. This field used to be identified which process originated this message. When kernel issued a message, this field should be 0. mipm_errno: An error number which indicates why the request failed. 4.2 mip_bc_info mip_bc_info structure is used to inject a binding cache entry to kernel. This structure is used with MIPM_BC_ADD, MIPM_BC_UPDATE, MIPM_BC_REMOVE messages. Momose, et al. Expires December 3, 2005 [Page 10] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 struct mip_bc_info { struct mip_msghdr mipmci_hdr; uint16_t mipmci_seqno; uint16_t mipmci_flags; uint32_t mipmci_lifetime; struct sockaddr mipmci_addr[0]; }; #define mipmci_msglen mipmci_hdr.mipm_msglen #define mipmci_version mipmci_hdr.mipm_version #define mipmci_type mipmci_hdr.mipm_type #define mipmci_flags mipmci_hdr.mipm_flags #define mipmci_pid mipmci_hdr.mipm_pid #define mipmci_seq mipmci_hdr.mipm_seq #define mipmci_errno mipmci_hdr.mipm_errno #define MIPMCI_HOA(mipmci) (&(mipmci)->mipmci_addr[0]) #define MIPMCI_COA(mipmci) \ ((struct sockaddr *)((caddr_t)(MIPMCI_HOA(mipmci)) \ + (MIPMCI_HOA(mipmci))->sa_len)) #define MIPMCI_CNADDR(mipmci) \ ((struct sockaddr *)((caddr_t)(MIPMCI_COA(mipmci)) \ + (MIPMCI_COA(mipmci))->sa_len)) mipmci_msglen: The length of the entire message. mipmci_version: 1 mipmci_type: MIPM_BC_ADD, MIPM_BC_UPDATE or MIPM_BC_REMOVE mipmci_seqno: The sequence number value in the binding update message sent from a mobile node. mipmci_flags: The flag value in the binding update message sent from a mobile node. mipmci_lifetime: The lifetime of this binding cache entry. The unit is second, not same as the value in the binding update message. MIPMCI_HOA: The position where the home address of a peer mobile node is stored. MIPMCI_COA: The position where the care-of address of a peer mobile node is stored. MIPMCI_CNADDR: The position where the local address of the node is stored. TODO: include prefix information when a node is acting as a NEMO node. Momose, et al. Expires December 3, 2005 [Page 11] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 4.3 mip_bul_info mip_bul_info structure is used to inject a binding update list to kernel. This structure is used with MIPM_BUL_ADD, MIPM_BUL_UPDATE, MIPM_BUL_REMOVE messages. struct mip_bul_info { struct mip_msghdr mipmui_hdr; uint16_t mipmui_flags; uint16_t mipmui_hoa_ifindex; uint8_t mipmui_coa_ifname[IFNAMSIZ]; uint8_t mipmui_state; struct sockaddr mipmui_addr[0]; }; #define mipmui_msglen mipmui_hdr.mipm_msglen #define mipmui_version mipmui_hdr.mipm_version #define mipmui_type mipmui_hdr.mipm_type #define mipmui_flags mipmui_hdr.mipm_flags #define mipmui_seq mipmui_hdr.mipm_seq #define mipmui_pid mipmui_hdr.mipm_pid #define mipmui_errno mipmui_hdr.mipm_errno #define MIPMUI_HOA(mipmui) (&(mipmui)->mipmui_addr[0]) #define MIPMUI_COA(mipmui) \ ((struct sockaddr *)((caddr_t)(MIPMUI_HOA(mipmui)) \ + (MIPMUI_HOA(mipmui))->sa_len)) #define MIPMUI_PEERADDR(mipmui) \ ((struct sockaddr *)((caddr_t)(MIPMUI_COA(mipmui)) \ + (MIPMUI_COA(mipmui))->sa_len)) mipmui_msglen: The length of the entire message. mipmui_version: 1 mipmui_type: MIPM_BUL_ADD, MIPM_BUL_UPDATE or MIPM_BUL_REMOVE mipmui_flags: The flag in a binding update message mipmui_hoa_ifindex The interface index assigned home address mipmui_coa_ifname The interface name assigned a care-of address mipmui_state The state of the binding update list entry. Currently, this is shisa specific use. MIPMUI_HOA: The position where the home address of a node is stored. Momose, et al. Expires December 3, 2005 [Page 12] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 MIPMUI_COA: The position where the care-of address of a node is stored. MIPMUI_PEERADDR: The position where the address of a peer node is stored. TODO: include prefix information when a node is acting as a NEMO node. 4.4 mip_nodetype_info mip_nodetype_info structure is used to set or get the type of a node. This structure is used with MIPM_NODETYPE_INFO message. struct mipm_nodetype_info { struct mip_msghdr mipmni_hdr; uint8_t mipmni_nodetype; uint8_t mipmni_enable; /* set 1 to enable, 0 to disable */ }; #define mipmni_msglen mipmni_hdr.mipm_msglen #define mipmni_version mipmni_hdr.mipm_version #define mipmni_type mipmni_hdr.mipm_type #define mipmni_flags mipmni_hdr.mipm_flags #define mipmni_pid mipmni_hdr.mipm_pid #define mipmni_seq mipmni_hdr.mipm_seq #define mipmni_errno mipmni_hdr.mipm_errno mipmni_msglen: The length of the entire message. mipmni_version: 1 mipmni_type: MIPM_NODETYPE_INFO mipmni_nodetype: Type of node as listed bellow. #define MIPMNI_NONE 0x00 #define MIPMNI_MIP6_CORRESPONDENT_NODE 0x01 #define MIPMNI_MIP6_HOME_AGENT 0x02 #define MIPMNI_MIP6_MOBILE_NODE 0x04 #define MIPMNI_MIP6_MOBILE_ROUTER 0x08 mipmni_enable: Set 1 when enabling the feature of the specified node type. Set 0 when disabling the feature. 4.5 mip_home_hint mipm_home_hint structure is used to notify returning home event Momose, et al. Expires December 3, 2005 [Page 13] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 detected inside kernel to movement detection programs. This structure is used with MIPM_HOME_HINT message. struct mip_home_hint { struct mip_msghdr mipmhh_hdr; uint16_t mipmhh_ifindex; /* ifindex of interface which received RA */ uint16_t mipmhh_prefixlen; /* Prefix Length */ struct sockaddr mipmhh_prefix[0]; /* received prefix */ }; #define mipmhh_msglen mipmhh_hdr.mipm_msglen #define mipmhh_version mipmhh_hdr.mipm_version #define mipmhh_type mipmhh_hdr.mipm_type #define mipmhh_flags mipmhh_hdr.mipm_flags #define mipmhh_pid mipmhh_hdr.mipm_pid #define mipmhh_seq mipmhh_hdr.mipm_seq #define mipmhh_errno mipmhh_hdr.mipm_errno mipmhh_msglen: The length of the entire message. mipmhh_version: 1 mipmhh_type: MIPM_HOME_HINT mipmhh_ifindex: The interface index number of the network interface which is considered to be the home network of a mobile node. mipmhh_prefixlen: The prefix length of the mipmhh_prefix member variable. mipmhh_prefix: The prefix value which is considered to be one of home prefixes, received from the network interface specified by the mipmhh_ifindex member variable. 4.6 mip_md_info mipm_mdinfo structure is used to notify movement info from movement detection programs to mobile node or mobile router programs. This structure is used with MIPM_MD_INFO message. Momose, et al. Expires December 3, 2005 [Page 14] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 struct mip_md_info { struct mip_msghdr mipmmi_hdr; uint8_t mipmmi_command; uint8_t mipmmi_hint; uint16_t mipmmi_ifindex; struct sockaddr mipm_md_addr[0]; }; #define mipmmi_msglen mipmmi_hdr.mipm_msglen #define mipmmi_version mipmmi_hdr.mipm_version #define mipmmi_type mipmmi_hdr.mipm_type #define mipmmi_flags mipmmi_hdr.mipm_flags #define mipmmi_pid mipmmi_hdr.mipm_pid #define mipmmi_seq mipmmi_hdr.mipm_seq #define mipmmi_errno mipmmi_hdr.mipm_errno #define MIPMMI_HOA(mipmmi) (&(mipmmi)->mipmmi_addr[0]) #define MIPMMI_COA(mipmmi) \ ((struct sockaddr *)((caddr_t)(MIPMMI_HOA(mipmmi)) \ + (MIPMMI_HOA(mipmmi))->sa_len)) #define MIPMMI_COA2(mipmmi) \ ((struct sockaddr *)((caddr_t)(MIPMMI_COA(mipmmi)) \ + (MIPMMI_COA(mipmmi))->sa_len)) #define MIPMMI_CMD_REREG 0x01 #define MIPMMI_CMD_DEREGHOME 0x02 #define MIPMMI_CMD_DEREGFOREIGN 0x03 #define MIPMMI_CMD_SCAN 0x04 #define MIPMMI_HINT_INDEX 0x01 #define MIPMMI_HINT_ADDR 0x02 #define MIPMMI_HINT_HOME 0x03 mipmmi_msglen: The length of the entire message. mipmmi_version: 1 mipmmi_type: MIPM_MD_INFO mipmmi_command: The supplemental command number. MIPM_CMD_REREG: set when the message implies attachment to a foreign network. MIPM_CMD_DEREGHOME: set when the message implies returning home. MIPM_CMD_DEREGFOREIGN: set when the message implies a mobile node stops its function and trying to deregister from a foreign network. Momose, et al. Expires December 3, 2005 [Page 15] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 MIPM_CMD_SCAN: TBD XXX mipmmi_hint MIPMMI_HINT_INDEX: MIPMMI_HINT_ADDR: MIPMMI_HINT_HOME: mipmmi_ifindex: TBD XXX MIPMMI_HOA: The position where the home address of a mobile node is stored. MIPMMI_COA: The position where the new care-of address of a mobile node is stored. MIPMMI_COA2: The position where the additional new care-of address of a mobile node is stored. This value exists only the multiple care-of address registration mechanism described in [4] is used. 4.7 mip_rr_hint mipm_rr_hint structure is used to notify mobile node or mobile router programs that they should initiate the return routability procedure. This structure is used with MIPM_RR_HINT message. struct mip_rr_hint { struct mip_msghdr mipmrh_hdr; struct sockaddr mipmrh_addr[0]; }; #define mipmrh_msglen mipmrh_hdr.miph_msglen #define mipmrh_version mipmrh_hdr.miph_version #define mipmrh_type mipmrh_hdr.miph_type #define mipmrh_flags mipmrh_hdr.miph_flags #define mipmrh_pid mipmrh_hdr.miph_pid #define mipmrh_seq mipmrh_hdr.miph_seq #define mipmrh_errno mipmrh_hdr.miph_errno #define MIPMRH_HOA(mipmrh) ((mipmrh)->mipmrh_addr) #define MIPMRH_PEERADDR(mipmrh) \ ((struct sockaddr *)((caddr_t)(MIPMRH_HOA(mipmrh)) \ + (MIPMRH_HOA(mipmrh))->sa_len)) Momose, et al. Expires December 3, 2005 [Page 16] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 mipmrh_msglen: The length of the entire message. mipmrh_version: 1 mipmrh_type: MIPM_RR_HINT MIPMRH_HOA: The position where the address of the home address is stored. MIPMRH_PEERADDR: The position where the peer address which caused this hint message is stored. Typically, when a mobile node sends(or receives) a packet to(or from) a correspondent node via a bi-directional tunnel between the mobile node and its home agent, this message is generated. 4.8 mip_be_hint mipm_be_hint structure is used to notify mobility programs that they should send a Binding Error message. This structure is used with MIPM_BE_HINT message. struct mip_be_hint { struct mip_msghdr mipmbeh_hdr; u_int8_t mipmbeh_status; struct sockaddr mipmbeh_addr[0]; }; #define mipmbeh_msglen mipmbeh_hdr.miph_msglen #define mipmbeh_version mipmbeh_hdr.miph_version #define mipmbeh_type mipmbeh_hdr.miph_type #define mipmbeh_flags mipmbeh_hdr.miph_flags #define mipmbeh_seq mipmbeh_hdr.miph_pid #define mipmbeh_seq mipmbeh_hdr.miph_seq #define mipmbeh_errno mipmbeh_hdr.miph_errno #define MIPMBEH_PEERADDR(mipmbeh) ((mipmbeh)->mipmbeh_addr) #define MIPMBEH_COA(mipmbeh) \ ((struct sockaddr *)((caddr_t)(MIPMBEH_PEERADDR(mipmbeh)) \ + (MIPMBEH_PEERADDR(mipmbeh))->sa_len)) #define MIPMBEH_HOA(mipmbeh) \ ((struct sockaddr *)((caddr_t)(MIPMBEH_COA(mipmbeh)) \ + (MIPMBEH_COA(mipmbeh))->sa_len)) mipmbeh_msglen: The length of the entire message. mipmbeh_version: 1 Momose, et al. Expires December 3, 2005 [Page 17] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 mipmbeh_type: MIPM_BE_HINT mipmbeh_status: The status value which should be included in the status field of a Binding Error message. MIPMBEH_PEERADDR: The position where the address which should be the source address of a Binding Error message is stored. MIPMBEH_COA: The position where the care-of address of the peer mobile node which should be the destination address of a Binding Error message is stored. MIPMBEH_HOA: The position where the home address of the peer mobile which should be included in a Binding Error message is stored. Momose, et al. Expires December 3, 2005 [Page 18] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 5. Constants #define MIP_VERSION 1 #define MIPM_NODETYPE_INFO 1 #define MIPM_BC_ADD 2 #define MIPM_BC_UPDATE 3 #define MIPM_BC_REMOVE 4 #define MIPM_BC_FLUSH 5 #define MIPM_BUL_ADD 6 #define MIPM_BUL_UPDATE 7 #define MIPM_BUL_REMOVE 8 #define MIPM_BUL_FLUSH 9 #define MIPM_MD_INFO 10 #define MIPM_HOME_HINT 11 #define MIPM_RR_HINT 12 #define MIPM_BE_HINT 13 Momose, et al. Expires December 3, 2005 [Page 19] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 6. Security Considerations The mobility socket framework enables applications to create, modify, remove and get mobility related informations. Some messages issued by applications such as creating, modifying and removing would affect the behavior of mobility protocol subsystem. And it could cause serious problems. Thus, such operation should be restricted to only trusted and privileged users and processes. The getting method might be restricted to trusted and privileged users and processes as well if there are concerns of privacy. Momose, et al. Expires December 3, 2005 [Page 20] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 7. Acknowledgements The authors would like to thank Ryuji Wakikawa, Romain Kuntz and Thierry Ernst for their input. 8. References [1] Johnson, Perkins, and Arkko, "Mobility Support in IPv6", RFC 3775. [2] Devarapalli, Wakikawa, Petrescu, and Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963. [3] McDonald, Metz, and Phan, "PF_KEY Key Management API, Version 2", RFC 2367. [4] Wakikawa, Uehara, Ernst, and Nagami, "Multiple Care-of Address Registration", draft-wakikawa-mobileip-multiplecoa-04 (work in progress). [5] Yegin, Muhammad, Yokote, Fu, Williams, and Takeshita, "Mobile IP API", draft-yokote-mobileip-api-02 (work in progress). [6] Shisa Development Team, "SHISA:A Mobile IPv6/NEMO Stack implementation on BSD". Authors' Addresses Tsuyoshi Momose NEC Corporation 7-1, Shiba 5-chome Minato-ku, Tokyo 108-8001 Japan Phone: +81 3 3454 1111 Email: momose@az.jp.nec.com URI: http://www.nec.com/ Momose, et al. Expires December 3, 2005 [Page 21] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 Keiichi Shima Internet Initiative Japan Inc. Jinbo-cho Mitsui Bldg. 1-105 Kanda, Jinbo-cho Chiyoda-ku, Tokyo 101-0051 Japan Phone: +81 3 5205 6500 Email: keiichi@iijlab.net URI: http://www.iij.ad.jp/en/ Antti Tuominen Helsinki University of Technology Computer Science Building Konemiehentie 2 Espoo FI-02150 Finland Phone: +358 9 451 5136 Email: anttit@tcs.hut.fi URI: http://www.tcs.hut.fi/ Momose, et al. Expires December 3, 2005 [Page 22] Internet-Draft Mobility Socket, AF_MOBILITY June 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Momose, et al. Expires December 3, 2005 [Page 23]