Internet DRAFT - draft-momose-mip6-mipsock
draft-momose-mip6-mipsock
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 <sys/socket.h>. All
message structures used by the AF_MOBILITY socket are defined in
<net/mipsock.h>. The socket is created as follows:
#include <sys/types.h>
#include <sys/socket.h>
#include <net/mipsock.h>
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]
