MIP6 WG S. Chakrabarti
Internet-Draft E. Nordmark
Expires: April 27, 2006 Sun Microsystems
October 24, 2005
Extension to Sockets API for Mobile IPv6
draft-ietf-mip6-mipext-advapi-05.txt
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 April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes data structures and API support for Mobile
IPv6 as an extension to the Advanced Socket API for IPv6.
Just the the Advanced Sockets API for IPv6 gives access to various
extension headers and the ICMPv6 protocol, this document specifies
the same level of access for Mobile IPv6 components. It specifies a
mechanism for applications to retrieve and set information for
Mobility Header messages, Home Address destination options and
Chakrabarti & Nordmark Expires April 27, 2006 [Page 1]
Internet-Draft Sockets API for Mobile IPv6 October 2005
Routing Header Type 2 extension headers. It also specifies the
common data structures and definitions that might be used by certain
advanced Mobile IPv6 socket applications.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Common Structures and Definitions . . . . . . . . . . . . . 6
4.1 The Mobility Header Data Structures . . . . . . . . . . . 6
4.1.1 The ip6_mh Structure . . . . . . . . . . . . . . . . . 6
4.1.2 Binding Refresh Request Mobility Message . . . . . . . 7
4.1.3 Home Address Test Init (HoTI) Message . . . . . . . . 7
4.1.4 Care-of Address Test Init (CoTI) Message . . . . . . . 7
4.1.5 Home Address Test (HOT) Message . . . . . . . . . . . 8
4.1.6 Care Of Address Test (COT) Message . . . . . . . . . . 8
4.1.7 Binding Update Mobility Message . . . . . . . . . . . 8
4.1.8 Binding Acknowledgment Mobility Message . . . . . . . 9
4.1.9 Binding Error Mobility Message . . . . . . . . . . . . 9
4.1.10 Mobility Option TLV data structure . . . . . . . . . 9
4.1.11 Mobility Option Data Structures . . . . . . . . . . 10
4.2 Mobility Header Constants . . . . . . . . . . . . . . . . 10
4.3 IPv6 Home Address Destination Option . . . . . . . . . . . 12
4.4 Type 2 Routing Header . . . . . . . . . . . . . . . . . . 13
4.5 New ICMP Messages for Mobile IPv6 . . . . . . . . . . . . 13
4.6 IPv6 Neighbor Discovery Changes . . . . . . . . . . . . . 15
5. Access to Home Address Destination Option and Routing
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Routing Header access functions . . . . . . . . . . . . . 18
5.2 Content of Type 2 Routing Header . . . . . . . . . . . . . 20
5.3 Order of extension headers for Home Address Destination
Options . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4 Home Address Destination Option access functions . . . . . 21
5.5 Content of Home Address Destination option . . . . . . . . 21
6. Mobility Protocol Headers . . . . . . . . . . . . . . . . . 23
6.1 Receiving and Sending Mobility Header Messages . . . . . . 23
7. Protocols File . . . . . . . . . . . . . . . . . . . . . . . 25
8. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
11. Changes from last revisions . . . . . . . . . . . . . . . . 29
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1 Normative References . . . . . . . . . . . . . . . . . . 31
13.2 Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . 33
Chakrabarti & Nordmark Expires April 27, 2006 [Page 2]
Internet-Draft Sockets API for Mobile IPv6 October 2005
1. Introduction
Mobility Support in IPv6 [2] defines a new Mobility Protocol header,
a Home Address destination option and a new Routing Header type. It
is expected that Mobile IPv6 user-level implementations and some
special applications will need to access and process these IPv6
extension headers. This document is an extension to the existing
Advanced Sockets API document [1]; it addresses the Advanced IPv6
Sockets API for these new protocol elements define by Mobile IPv6.
The applicability of this API is mainly targets user-level
applications. However, it has also shown to be useful within some
Mobile IPv6 implementations, for instance, where part of the Mobile
IPv6 protocol is implemented at user-level and part in the kernel.
It is up to any such implementations to architect which part of the
Mobile IPv6 and IPSec packet processing should be done at the user-
level in order to meet the design needs of the particular platform
and operating system.
The target user-level applications for this socket API are believed
to be the debugging and diagnostic applications as well as some
policy applications which would like to receive a copy of protocol
information at the application layer.
The packet information along with access to the extension headers
(Routing header and Destination options) are specified using the
"ancillary data" fields that were added to the 4.3BSD Reno sockets
API in 1990. The reason is that these ancillary data fields are part
of the Posix.1g standard and should therefore be adopted by most
vendors. This document is consistent with Advanced Sockets API for
IPv6 [1] in structure definitions, header files and function
definitions.
This document does not address application access to either the
authentication header or the encapsulating security payload header.
This document also does not address any API that might be necessary
for Mobile Network [4] specific needs. Furthermore, it should be
noted that this API document excludes discussion on application level
API. It assumes that address selection socket API [5] takes care of
selection of Care-of-address or home-address as the source address by
the application, when source address selection is required due to the
nature of the application.
Providing mobility "awareness" to applications, such as applications
being able to tell whether the host is at home or not, is out of
scope for this API.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 3]
Internet-Draft Sockets API for Mobile IPv6 October 2005
2. Applicability
This API document can be applied in the following cases:
1. User-level debugging and monitoring tools: This socket API is
useful for accessing Mobility Headers, Home-address options and
Type 2 Routing Headers . For example, mh-ping might be a
monitoring tool which can process mobility headers on the receive
side to check binding status.
2. Partial user-level implementation of Mobile IPv6: We assume that
some implementations may choose to do the Mobility header
processing at user level. In that case, this document recommends
implementing at least the handling of Home-address options and
Routing Header Type 2 in the main IP processing paths in the
kernel. The API can then be used to send and receive the
Mobility Header packets used for Mobile Ipv6 signalling.
3. Complete header processing at the kernel-level: Many
implementations of Mobile IPv6 [2] perform processing of Home
Address Option, Routing Headers and Mobility headers at the
kernel level. However, the kernel keeps a copy of the received
extension headers and passes them up to the API which is used by
the user-level applications purely for monitoring and debugging
Mobile IPv6 packets.
On an IPv6 host which does not implement Mobile IPv6, the IPv6
specification [3] requires that packets with the Home Address option
or Routing Header of type 2 (where segments left is non-zero) be
dropped on receipt. This means that it is not possible to implement
Mobile IPv6 as an application on such a system. Thus on such a
system, the applicability of this API is limited to the first case
above of debugging and monitoring applications (such as tcpdump)
being able to parse and interpret Mobile IPv6 packets.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 4]
Internet-Draft Sockets API for Mobile IPv6 October 2005
3. Overview
This document can be divided into the following parts.
1. Definitions of constants and structures for C programs that
capture the Mobile IPv6 packet formats on the wire. A common
definition of these is useful at least for packet snooping
applications. This is captured in Section 4. In addition
Section 4 also defines data structures for Home Address
destination option, Routing Header Type 2, new ICMPv6 messages
related to Mobile IPv6.
2. Notes on how to use the IPv6 Advanced API to access Home Address
options and type 2 Routing Headers. This is captured in
Section 5.
3. Notes on how user-level applications can observe MH (Mobility
Header) packets using raw sockets (in Section 6). The IPv6 RAW
socket interface described in this document, allows applications
to receive MH packets whether or not the systems MH processing
takes place in the "kernel" or at the "user space".
4. Suggested name for /etc/protocols (in Section 7).
All examples in this document omit error checking in the favor of
brevity, as it is following the same style as the Advanced Socket API
[1].
We note that many of the functions and socket options defined in this
document may have error returns that are not defined in this
document.
Data types in this document follow the Posix.1g format: intN_t means
a signed integer of exactly N bits (e.g., int16_t) and uintN_t means
an unsigned integer of exactly N bits (e.g., uint32_t).
Once the API specification becomes mature and is deployed, it may be
formally standardized by a more appropriate body, such as has been
done with the Basic API [6]. However, since this specification
largely builds upon the Advanced Socket API [1], such standardization
would make sense only if the Advanced Socket API [1] was also
standardized.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 5]
Internet-Draft Sockets API for Mobile IPv6 October 2005
4. Common Structures and Definitions
ANSI-C provides little guarantees about the size and alignment of
data structures, thus depending on the implementation of a compiler,
the structures below might, when compiled, not match the packet
formats defined in RFC 3775 [2]. However, the structures are
specified in a way to maximize the probability that compilers will
lay out the structure in a way that is identical to the packet
formats on the wire.
Thus the mobility header message data structures include the mobility
header fields such that they are consistent across different
compilers.
The structure definitions below are merely examples; the requirement
is that the structures contain the fields specified below. Depending
on the compiler used as well as the host byte order, the layout of
the structures might need to be different. But as long as they
provide the same fields as below we can ensure application
portability when using this API.
The constants shown below are in network byte order, thus an
application needs to perform the appropriate byte order conversion
(ntohs(), etc) when using the constants.
A structures and constants below should be included when including
the (new) header file : <netinet/ip6mh.h>
4.1 The Mobility Header Data Structures
4.1.1 The ip6_mh Structure
The following structure is defined as a result of including <netinet/
ip6mh.h>. This is the fixed part of the Mobility Header. Different
Mobility message types are defined Mobile IPv6 [2]. For portability
and alignment reasons, each mobility message type includes the
mobility header fields as opposed to including the ip6_mh structure
followed by the message specific fields.
struct ip6_mh {
uint8_t ip6mh_proto; /* NO_NXTHDR by default */
uint8_t ip6mh_hdrlen; /* Header Len in unit of 8 Octets
excluding the first 8 Octets */
uint8_t ip6mh_type; /* Type of Mobility Header */
uint8_t ip6mh_reserved; /* Reserved */
uint16_t ip6mh_cksum; /* Mobility Header Checksum */
/* Followed by type specific messages */
};
Chakrabarti & Nordmark Expires April 27, 2006 [Page 6]
Internet-Draft Sockets API for Mobile IPv6 October 2005
4.1.2 Binding Refresh Request Mobility Message
struct ip6_mh_binding_request {
uint8_t ip6mhbr_proto;
uint8_t ip6mhbr_hdrlen;
uint8_t ip6mhbr_type;
uint8_t ip6mhbr_reserved;
uint16_t ip6mhbr_cksum;
uint16_t ip6mhbr_reserved;
/* Followed by optional Mobility Options */
};
4.1.3 Home Address Test Init (HoTI) Message
struct ip6_mh_home_test_init {
uint8_t ip6mhhti_proto;
uint8_t ip6mhhti_hdrlen;
uint8_t ip6mhhti_type;
uint8_t ip6mhhti_reserved;
uint16_t ip6mhhti_cksum;
uint16_t ip6mhhti_reserved;
uint32_t ip6mhhti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
4.1.4 Care-of Address Test Init (CoTI) Message
struct ip6_mh_careof_test_init {
uint8_t ip6mhcti_proto;
uint8_t ip6mhcti_hdrlen;
uint8_t ip6mhcti_type;
uint8_t ip6mhcti_reserved;
uint16_t ip6mhcti_cksum;
uint16_t ip6mhcti_reserved;
uint32_t ip6mhcti_cookie[2]; /* 64 bit Cookie by MN */
/* Followed by optional Mobility Options */
};
Chakrabarti & Nordmark Expires April 27, 2006 [Page 7]
Internet-Draft Sockets API for Mobile IPv6 October 2005
4.1.5 Home Address Test (HOT) Message
struct ip6_mh_home_test {
uint8_t ip6mhht_proto;
uint8_t ip6mhht_hdrlen;
uint8_t ip6mhht_type;
uint8_t ip6mhht_reserved;
uint16_t ip6mhht_cksum;
uint16_t ip6mhht_nonce_index;
uint32_t ip6mhht_cookie[2]; /* Cookie from HOTI msg */
uint32_t ip6mhht_keygen[2]; /* 64 Bit Key by CN */
/* Followed by optional Mobility Options */
};
4.1.6 Care Of Address Test (COT) Message
struct ip6_mh_careof_test {
uint8_t ip6mhct_proto;
uint8_t ip6mhct_hdrlen;
uint8_t ip6mhct_type;
uint8_t ip6mhct_reserved;
uint16_t ip6mhct_cksum;
uint16_t ip6mhct_nonce_index;
uint32_t ip6mhct_cookie[2]; /* Cookie from COTI message */
uint32_t ip6mhct_keygen[2]; /* 64bit key by CN */
/* Followed by optional Mobility Options */
};
4.1.7 Binding Update Mobility Message
struct ip6_mh_binding_update {
uint8_t ip6mhbu_proto;
uint8_t ip6mhbu_hdrlen;
uint8_t ip6mhbu_type;
uint8_t ip6mhbu_reserved;
uint16_t ip6mhbu_cksum;
uint16_t ip6mhbu_seqno; /* Sequence Number */
uint16_t ip6mhbu_flags;
uint16_t ip6mhbu_lifetime; /* Time in unit of 4 sec */
/* Followed by optional Mobility Options */
};
/* Binding Update Flags, in network byte-order */
#define IP6_MH_BU_ACK 0x8000 /* Request a binding ack */
#define IP6_MH_BU_HOME 0x4000 /* Home Registration */
#define IP6_MH_BU_LLOCAL 0x2000 /* Link-local compatibility */
Chakrabarti & Nordmark Expires April 27, 2006 [Page 8]
Internet-Draft Sockets API for Mobile IPv6 October 2005
#define IP6_MH_BU_KEYM 0x1000 /* Key management mobility */
4.1.8 Binding Acknowledgment Mobility Message
struct ip6_mh_binding_ack {
uint8_t ip6mhba_proto;
uint8_t ip6mhba_hdrlen;
uint8_t ip6mhba_type;
uint8_t ip6mhba_reserved;
uint16_t ip6mhba_cksum;
uint8_t ip6mhba_status; /* Status code */
uint8_t ip6mhba_flags;
uint16_t ip6mhba_seqno;
uint16_t ip6mhba_lifetime;
/* Followed by optional Mobility Options */
};
/* Binding Acknowledgement Flags */
#define IP6_MH_BA_KEYM 0x80 /* Key management mobility */
4.1.9 Binding Error Mobility Message
struct ip6_mh_binding_error {
uint8_t ip6mhbe_proto;
uint8_t ip6mhbe_hdrlen;
uint8_t ip6mhbe_type;
uint8_t ip6mhbe_reserved;
uint16_t ip6mhbe_cksum;
uint8_t ip6mhbe_status; /* Error Status */
uint8_t ip6mhbe_reserved;
struct in6_addr ip6mhbe_homeaddr;
/* Followed by optional Mobility Options */
};
4.1.10 Mobility Option TLV data structure
struct ip6_mh_opt {
uint8_t ip6mhopt_type; /* Option Type */
uint8_t ip6mhopt_len; /* Option Length */
/* Followed by variable length Option Data in bytes */
};
Chakrabarti & Nordmark Expires April 27, 2006 [Page 9]
Internet-Draft Sockets API for Mobile IPv6 October 2005
4.1.11 Mobility Option Data Structures
4.1.11.1 Binding Refresh Advice
struct ip6_mh_opt_refresh_advice {
uint8_t ip6mora_type;
uint8_t ip6mora_len;
uint16_t ip6mora_interval; /* Refresh interval in 4 sec */
};
4.1.11.2 Alternate Care-of Address
struct ip6_mh_opt_altcoa {
uint8_t ip6moa_type;
uint8_t ip6moa_len;
struct in6_addr ip6moa_addr; /* Alternate CoA */
};
4.1.11.3 Nonce Indices
struct ip6_mh_opt_nonce_index {
uint8_t ip6moni_type;
uint8_t ip6moni_len;
uint16_t ip6moni_home_nonce;
uint16_t ip6moni_coa_nonce;
};
4.1.11.4 Binding Authorization Data
struct ip6_mh_opt_auth_data {
uint8_t ip6moad_type;
uint8_t ip6moad_len;
uint8_t ip6moad_data[12];
};
4.2 Mobility Header Constants
IPv6 Next Header Value for Mobility:
<netinet/in.h>
#define IPPROTO_MH 135 /* IPv6 Mobility Header: IANA */
Chakrabarti & Nordmark Expires April 27, 2006 [Page 10]
Internet-Draft Sockets API for Mobile IPv6 October 2005
Mobility Header Message Types:
<netinet/ip6mh.h>
#define IP6_MH_TYPE_BRR 0 /* Binding Refresh Request */
#define IP6_MH_TYPE_HOTI 1 /* HOTI Message */
#define IP6_MH_TYPE_COTI 2 /* COTI Message */
#define IP6_MH_TYPE_HOT 3 /* HOT Message */
#define IP6_MH_TYPE_COT 4 /* COT Message */
#define IP6_MH_TYPE_BU 5 /* Binding Update */
#define IP6_MH_TYPE_BACK 6 /* Binding ACK */
#define IP6_MH_TYPE_BERROR 7 /* Binding Error */
Mobility Header Message Option Types:
<netinet/ip6mh.h>
#define IP6_MHOPT_PAD1 0x00 /* PAD1 */
#define IP6_MHOPT_PADN 0x01 /* PADN */
#define IP6_MHOPT_BREFRESH 0x02 /* Binding Refresh */
#define IP6_MHOPT_ALTCOA 0x03 /* Alternate COA */
#define IP6_MHOPT_NONCEID 0x04 /* Nonce Index */
#define IP6_MHOPT_BAUTH 0x05 /* Binding Auth Data */
Status values accompanied with Mobility Binding Acknowledgement:
<netinet/ip6mh.h>
Chakrabarti & Nordmark Expires April 27, 2006 [Page 11]
Internet-Draft Sockets API for Mobile IPv6 October 2005
#define IP6_MH_BAS_ACCEPTED 0 /* BU accepted */
#define IP6_MH_BAS_PRFX_DISCOV 1 /* Accepted, but prefix
discovery Required */
#define IP6_MH_BAS_UNSPECIFIED 128 /* Reason unspecified */
#define IP6_MH_BAS_PROHIBIT 129 /* Administratively
prohibited */
#define IP6_MH_BAS_INSUFFICIENT 130 /* Insufficient
resources */
#define IP6_MH_BAS_HA_NOT_SUPPORTED 131 /* HA registration not
supported */
#define IP6_MH_BAS_NOT_HOME_SUBNET 132 /* Not Home subnet */
#define IP6_MH_BAS_NOT_HA 133 /* Not HA for this
mobile node */
#define IP6_MH_BAS_DAD_FAILED 134 /* DAD failed */
#define IP6_MH_BAS_SEQNO_BAD 135 /* Sequence number out
of range */
#define IP6_MH_BAS_HOME_NI_EXPIRED 136 /* Expired Home nonce
index */
#define IP6_MH_BAS_COA_NI_EXPIRED 137 /* Expired Care-of
nonce index */
#define IP6_MH_BAS_NI_EXPIRED 138 /* Expired Nonce
Indices */
#define IP6_MH_BAS_REG_NOT_ALLOWED 139 /* Registration type
change disallowed */
Status values for the Binding Error mobility messages:
<netinet/ip6mh.h>
#define IP6_MH_BES_UNKNOWN_HAO 1 /* Unknown binding for HOA */
#define IP6_MH_BES_UNKNOWN_MH 2 /* Unknown MH Type */
4.3 IPv6 Home Address Destination Option
Due to alignment issues in the compiler, and the alignment
requirements for this option, the included IPv6 address must be
specified as an array of 16 octets.
<netinet/ip6.h>
Chakrabarti & Nordmark Expires April 27, 2006 [Page 12]
Internet-Draft Sockets API for Mobile IPv6 October 2005
/* Home Address Destination Option */
struct ip6_opt_home_address {
uint8_t ip6oha_type;
uint8_t ip6oha_len;
uint8_t ip6oha_addr[16]; /* Home Address */
};
Option Type Definition:
#define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */
4.4 Type 2 Routing Header
<netinet/ip6.h>
/* Type 2 Routing header for Mobile IPv6 */
struct ip6_rthdr2 {
uint8_t ip6r2_nxt; /* next header */
uint8_t ip6r2_len; /* length : always 2 */
uint8_t ip6r2_type; /* always 2 */
uint8_t ip6r2_segleft; /* segments left: always 1 */
uint32_t ip6r2_reserved; /* reserved field */
struct in6_addr ip6r2_homeaddr; /* Home Address */
};
4.5 New ICMP Messages for Mobile IPv6
ICMP message types and definitions for Mobile IPv6 are defined in
<netinet/icmp6.h>
#define MIP6_HA_DISCOVERY_REQUEST 144
#define MIP6_HA_DISCOVERY_REPLY 145
#define MIP6_PREFIX_SOLICIT 146
#define MIP6_PREFIX_ADVERT 147
The following data structures can be used for the ICMP message types
discussed in Section 6.5 through 6.8 in the base Mobile IPv6 [2]
specification.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 13]
Internet-Draft Sockets API for Mobile IPv6 October 2005
struct mip6_dhaad_req { /* Dynamic HA Address Discovery */
struct icmp6_hdr mip6_dhreq_hdr;
};
#define mip6_dhreq_type mip6_dhreq_hdr.icmp6_type
#define mip6_dhreq_code mip6_dhreq_hdr.icmp6_code
#define mip6_dhreq_cksum mip6_dhreq_hdr.icmp6_cksum
#define mip6_dhreq_id mip6_dhreq_hdr.icmp6_data16[0]
#define mip6_dhreq_reserved mip6_dhreq_hdr.icmp6_data16[1]
struct mip6_dhaad_rep { /* HA Address Discovery Reply */
struct icmp6_hdr mip6_dhrep_hdr;
/* Followed by Home Agent IPv6 addresses */
};
#define mip6_dhrep_type mip6_dhrep_hdr.icmp6_type
#define mip6_dhrep_code mip6_dhrep_hdr.icmp6_code
#define mip6_dhrep_cksum mip6_dhrep_hdr.icmp6_cksum
#define mip6_dhrep_id mip6_dhrep_hdr.icmp6_data16[0]
#define mip6_dhrep_reserved mip6_dhrep_hdr.icmp6_data16[1]
struct mip6_prefix_solicit { /* Mobile Prefix Solicitation */
struct icmp6_hdr mip6_ps_hdr;
};
#define mip6_ps_type mip6_ps_hdr.icmp6_type
#define mip6_ps_code mip6_ps_hdr.icmp6_code
#define mip6_ps_cksum mip6_ps_hdr.icmp6_cksum
#define mip6_ps_id mip6_ps_hdr.icmp6_data16[0]
#define mip6_ps_reserved mip6_ps_hdr.icmp6_data16[1]
struct mip6_prefix_advert { /* Mobile Prefix Advertisements */
struct icmp6_hdr mip6_pa_hdr;
/* Followed by one or more PI options */
};
#define mip6_pa_type mip6_pa_hdr.icmp6_type
#define mip6_pa_code mip6_pa_hdr.icmp6_code
#define mip6_pa_cksum mip6_pa_hdr.icmp6_cksum
#define mip6_pa_id mip6_pa_hdr.icmp6_data16[0]
#define mip6_pa_flags_reserved mip6_pa_hdr.icmp6_data16[1]
/* Mobile Prefix Advertisement Flags in network-byte order */
#define MIP6_PA_FLAG_MANAGED 0x8000
#define MIP6_PA_FLAG_OTHER 0x4000
Chakrabarti & Nordmark Expires April 27, 2006 [Page 14]
Internet-Draft Sockets API for Mobile IPv6 October 2005
Prefix options are defined in IPv6 Advanced Socket API [1]. Mobile
IPv6 Base specification [2] describes the modified behavior in
'Modifications to IPv6 Neighbor Discovery' Section. Prefix Options
for Mobile IP are defined in the following Section.
4.6 IPv6 Neighbor Discovery Changes
IPv6 Neighbor Discovery changes are also defined in <netinet/icmp6.h>
New 'Home Agent' flag in router advertisement:
#define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */
New Router flag with prefix information of the home agent:
#define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */
As per Mobile IPv6 specification [2] Section 7.2, a Home Agent MUST
include at least one prefix option with the Router Address (R) bit
set. Advanced Socket API [1] defines data structure for prefix
option as follows:
struct nd_opt_prefix_info { /* prefix information */
uint8_t nd_opt_pi_type;
uint8_t nd_opt_pi_len;
uint8_t nd_opt_pi_prefix_len;
uint8_t nd_opt_pi_flags_reserved;
uint32_t nd_opt_pi_valid_time;
uint32_t nd_opt_pi_preferred_time;
uint32_t nd_opt_pi_reserved2;
struct in6_addr nd_opt_pi_prefix;
};
New advertisement interval option and home agent information options
are defined in Mobile IPv6 [2] base specification.
struct nd_opt_adv_interval { /* Advertisement interval option */
uint8_t nd_opt_ai_type;
uint8_t nd_opt_ai_len;
uint16_t nd_opt_ai_reserved;
uint32_t nd_opt_ai_interval;
};
The option types for the new Mobile IPv6 specific options:
Chakrabarti & Nordmark Expires April 27, 2006 [Page 15]
Internet-Draft Sockets API for Mobile IPv6 October 2005
#define ND_OPT_ADV_INTERVAL 7 /* Adv Interval Option */
#define ND_OPT_HA_INFORMATION 8 /* HA Information option */
struct nd_opt_homeagent_info { /* Home Agent information */
uint8_t nd_opt_hai_type;
uint8_t nd_opt_hai_len;
uint16_t nd_opt_hai_reserved;
uint16_t nd_opt_hai_preference;
uint16_t nd_opt_hai_lifetime;
};
Chakrabarti & Nordmark Expires April 27, 2006 [Page 16]
Internet-Draft Sockets API for Mobile IPv6 October 2005
5. Access to Home Address Destination Option and Routing Headers
Applications that need to be able to access home address destination
option and routing header type 2 information, can do so by setting
the appropriate setsockopt option and using ancillary data objects.
The order of extension headers are defined in Mobile IPv6 [2] when
sending a IPv6 packet with a Home Address Destination Option with
other possible extension headers. Section 5.3 elaborates the
extension header order when all the possible cases are present. This
document does not recommend the user-level program to set Home
Address destination option or Routing Header Type 2 option, however
for clarity it defines the order of extension headers. See the
Section 2 of this document for appropriate usage of sending and
receiving of Home Address destination option and Routing Header Type
2 extension headers.
This document defines a new set of socket options, IPV6_MIPDSTOPTS
and IPV6_RECVMIPDSTOPTS for sending and receiving Home Address
destination options. In order to receive Home Address destination
option or Route Header Type 2 extension header, application must call
setsockopt() to turn on the corresponding flag (error checking is not
performed in the example for brevity):
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVMIPDSTOPTS,
&on, sizeof(on));
When any of these options are enabled, the corresponding data is
returned as control information by recvmsg(), as one or more
ancillary data objects. Receiving the above information for TCP
applications is not defined in this document (see Section 4.1 of
Advanced Sockets API for IPv6 [1]).
Note that if the IP implementation on the host does not implement the
handling of type 2 routing headers or Home Address options, then per
RFC 2460 [3], the IP is required to drop the packet. Hence the
applications using this mechanism only work on hosts where at least
those pieces of RFC 3775 [2] are implemented in the IP layer.
For receiving the Home Address destination option header, the Mobile
IPv6 implementation follows the initial processing of the Home
Address destination option (Section 9.3.1 of Mobile IPv6 [2]) before
passing the information to the API level. This includes initial
processing of IPSec authentication data in a packet when it exists.
For sending Home Address destination option, ancillary data can be
Chakrabarti & Nordmark Expires April 27, 2006 [Page 17]
Internet-Draft Sockets API for Mobile IPv6 October 2005
used to specify the option content for a single datagram. This only
applies to datagram and raw sockets; not to TCP sockets. Advanced
API [1] document restricts one IPV6_xxx ancillary data object for a
particular extension header in the control buffer. Thus there would
be a single ancillary data object for Home address destination option
in a ancillary data buffer. If multiple destination options are
present then the header order should be in compliance with Section
6.3 and 9.3.2 of Mobile IPv6 [2] base specification.
For TCP data packets with Home Address destination option may be used
with "sticky" option for all transmitted packets. The application
can remove the sticky Home Destination option header by calling
setsockopt() for IPV6_MIPSTOPTS with a zero option length.
Note that Section 2 of this document does not encourage setting Home
Address destination option at the user-level.
However, the following socket option parameters and cmsghdr fields
may be used for sending.
opt level/ optname/ optval/
cmsg_level cmsg_type cmsg_data[]
------------ ------------ ------------------------
IPPROTO_IPV6 IPV6_MIPDSTOPTS ip6_dest structure
IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
Some IPv6 implementations may support "sticky" options [1] for IPv6
destination option for datagram and RAW sockets.
Behavior of legacy IPv6 socket applications:
Legacy IPv6 applications/implementations using the Advanced Socket
API [1] mechanisms, upon receiving Home Address destination options
or Routing headers(Type 2), will discard the packet as per Section
4.2 and 4.4 of IPV6 Protocol [3] specification respectively;
otherwise they should properly handle the Home Address destination
option and the Routing Header Type 2 specified in this document.
5.1 Routing Header access functions
IPV6 Protocol [3] defines Routing header extension header for Type 0.
Thus, in order to access the IPv6 Routing header Type 2 extension
header, one MUST use type = 2 and segment = 1. The following
existing functions defined in Advanced API for IPv6 Sockets [1] are
supported for Mobile IPv6 applications for sending and receiving
Routing Header Type 2 headers:
For sending:
Chakrabarti & Nordmark Expires April 27, 2006 [Page 18]
Internet-Draft Sockets API for Mobile IPv6 October 2005
size_t inet6_rth_space(int type, int segments);
void *inet6_rth_init(void *bp, int bp_len, int type, int segments);
int inet6_rth_add(void *bp, const struct in6_addr *addr);
For receiving:
int inet6_rth_segments(const void *bp);
struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
NOTE: Reversing operation is not possible using Route Header Type 2
extension header. Thus inet6_rth_reverse() is not used.
Detailed descriptions and examples of accessing an IPv6 Routing
Header are discussed in the Advanced Sockets API for IPv6 [1].
However, Section 7 of Advanced API for IPv6 Sockets [1] indicates
that multiple types of routing headers can be received as multiple
ancillary data objects to the application (with cmsg_type set to
IPV6_RTHDR). Currently there is no API functions defined to return
the routing header type, however this document does not define a
helper function since it is easy to access the Routing Header Type
field just as easily as ip6r_segleft field. An excerpt of a code
sample is provided for extracting the type of the received routing
header.
if (msg.msg_controllen != 0 &&
cmsgptr->cmsg_level == IPPROTO_IPV6 &&
cmsgptr->cmsg_type == IPV6_RTHDR) {
struct in6_addr *in6;
char asciiname[INET6_ADDRSTRLEN];
struct ip6_rthdr *rthdr;
int segments, route_type;
rthdr = (struct ip6_rthdr *)extptr;
segments = inet6_rth_segments(extptr);
printf("route (%d segments, %d left): ",
segments, rthdr->ip6r_segleft);
route_type = rthdr->ip6r_type;
if (route_type == 2) {
printf ("Routing header Type 2 present\n");
}
}
The function inet6_rth_gettype() returns the routing header type on
success. It returns -1 on error.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 19]
Internet-Draft Sockets API for Mobile IPv6 October 2005
5.2 Content of Type 2 Routing Header
It is recommended that no portable applications will send Routing
Header Type 2 ancillary data from application layer, since many
implementations take care of that at the kernel layer and may not
support the API for sending routing header type 2.
For user-level applications that receive Routing Header Type 2,
inet6_rth_getaddr() returns the Care-Of-Address or the original
destination address of the received packet. This is in compliance
with the existing Routing header Type=0 processing for IPv6 [1].
Thus on the receive side, the socket application will always receive
data packets at its original home-address. The implementations are
responsible for processing the routing header type 2 packet as per
Mobile IPv6 RFC [2], before passing the routing header type 2
information to the Socket API.
If a pure IPv6 [3] system receives the Routing Header Type 2 packets,
it will follow the process described in Section 4.4 of IPv6 [3] base
specification.
5.3 Order of extension headers for Home Address Destination Options
Section 6.3 of Mobile IPV6 [2] defines the extension header order for
Home address destination option.
Routing Header
Home Address Destination Option
Fragment Header
AH/ESP Header
IPv6 [3] specifies that the destination header can be either before
Routing header or after AH/ESP header if they are all present.
Thus, when Home Address destination option is present along with
other extension headers, the order will be:
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Destination Options [Home Address Option]
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Chakrabarti & Nordmark Expires April 27, 2006 [Page 20]
Internet-Draft Sockets API for Mobile IPv6 October 2005
Destination Options header (note 3)
upper-layer header
Any user-level implementation or application that sends Home address
destination option through ancillary data objects should follow the
order extension header defined in this document when using
IPV6_MIPDSTOPTS socket options.
5.4 Home Address Destination Option access functions
The application must enable the IPV6_RECVMIPDSTOPTS socket option in
order to receive the Home Address destination option (error checking
is not performed in the example for brevity):
int on = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVMIPDSTOPTS, &on, sizeof(on));
Each Destination option header is returned as one ancillary data
object described by a cmsghdr structure with cmsg_level set to
IPPROTO_IPV6 and cmsg_type set to IPV6_MIPDSTOPTS.
The receive side Home Address destination option is further processed
by calling the inet6_opt_next(), inet6_opt_find(), and
inet6_opt_get_value() functions as defined in Advanced API for IPv6
sockets [1].
This document assumes that portable Mobile IPv6 applications will not
send a Home Address Destination Option from the application level, as
the Mobile IPv6 implementation underneath takes care of sending the
Home Address option and the routing header type 2 at the kernel.
However, some embedded software implementations may implement the
IPv6 packet processing/sending at the user-level; those
implementations may choose to provide the API support for sending a
home-address option at the application layer. In this case, the Home
Address destination options are normally constructed by using the
inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and
inet6_opt_set_val() functions, described in Section 10 of Advanced
sockets API for IPv6 [1].
5.5 Content of Home Address Destination option
The received ancillary data object for Home Address destination
option SHOULD contain the Care-Of-Address of the mobile node. It is
assumed that the initial processing of the Home Address destination
option will verify the validity of home-address as described in 6.3
and 9.5 of Mobile IPv6 Specification [2] and swap the source address
Chakrabarti & Nordmark Expires April 27, 2006 [Page 21]
Internet-Draft Sockets API for Mobile IPv6 October 2005
of the packet (COA) with the content of Home Address destination
option.
Note that whether or not these new APIs are used, the sender's home
address is contained in the source address (which is passed to the
application using the socket-level functions recvfrom(), recvmsg(),
accept() and getpeername()). This is necessary for:
maintaining consistency between simple user-level applications
running between mobile nodes and the diagnostic applications on
home-agent or on correspondent node, which use this API.
obtaining the COA address of the mobile node when Home Address
destination option is used.
maintaining consistency of existing IPv6 Socket APIs and
processing of Home Address destination option.
If an implementation supports send-side Home Address destination API,
then it must follow the same rule for data content as specified in
Mobile IPv6 RFC [2] for sending home-address option. Thus the home-
address option will contain the home-address and the implementation
will use the care-of-address as the source address of the outgoing
packet.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 22]
Internet-Draft Sockets API for Mobile IPv6 October 2005
6. Mobility Protocol Headers
Mobile IPv6 [2] defines a new IPv6 protocol header to carry mobility
messages between Mobile Nodes, Home Agents and Correspondent Nodes.
These protocol headers carry Mobile IPv6 Binding messages as well as
Return Routability [2] messages. Currently the specification [2]
does not allow transport packets (piggybacking) along with the
mobility messages. Thus the mobility protocol header can be accessed
through an IPv6 RAW socket. An IPv6 RAW socket that is opened for
protocol IPPROTO_MH should always be able to see all the MH (Mobility
Header) packets. It is possible that future applications may
implement part of Mobile IPv6 signal processing at the application
level. Having a RAW socket interface may also enable an application
to execute the Return Routability protocol or other future
authentication protocol involving mobility header at the user level.
6.1 Receiving and Sending Mobility Header Messages
This specification recommends IPv6 RAW sockets mechanism to send and
receive Mobility Header (MH) packets. The behavior is similar to
ICMPV6 processing, where kernel passes a copy of the mobility header
packet to the receiving socket. Depending on the implementation, the
kernel may process the mobility header as well in addition to passing
the mobility header to the application. In order to comply with the
restriction in Advanced Sockets API for IPv6 [1], applications should
set IPV6_CHECKSUM socket option with IPPROTO_MH protocol RAW Sockets.
A Mobile IPv6 implementation that supports Mobile IPv6 API, must
implement Mobility Header API checksum calculation by default at the
kernel for both incoming and outbound path. A Mobile IPv6
implementation must not return error on IPV6_CHECKSUM socket option
setting, even if the socket option is a NO-OP function for that
implementation because it verifies the checksum at the kernel level.
Mobility Header checksum procedure is described in Mobile IPv6
Protocol [2] specification. Again, it is recommended that the
applications set the IPV6_CHECKSUM socket option along with the RAW
sockets for IPPROTO_MH protocol, for application portability.
As an example, a program that wants to send or receive mobility
header protocol(MH), could open a socket as following (error checking
is not performed in the example for brevity):
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_MH);
int offset = 4;
setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset,
sizeof(offset));
For example, if an implementation likes to handle HOTI/HOT and COTI/
Chakrabarti & Nordmark Expires April 27, 2006 [Page 23]
Internet-Draft Sockets API for Mobile IPv6 October 2005
COT message processing, it can do so by using IPv6 RAW Sockets for
IPPROTO_MH at the application layer. The same application may also
set IPV6_RECVDSTOPTS socket option for receiving home-address option
in a binding update [2] from the mobile node.
IPv6 RAW sockets are described in Section 3 of IPv6 Advanced Socket
API [1] specification. All data sent and received via raw sockets
must be in network byte order. The data structures that are defined
in this document are in network byte order and they are believed to
be supported by most compilers to directly hold packet-formats for
the wire transmission.
The usual send/recv functions for datagram should be used for the
Mobile IPv6 RAW sockets in order to send and receive data
respectively.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 24]
Internet-Draft Sockets API for Mobile IPv6 October 2005
7. Protocols File
Many hosts provide the file /etc/protocols that contains the names of
the various IP protocols and their protocol numbers. The protocol
numbers are obtained through function getprotoXXX() functions.
The following addition should be made to the /etc/protocols file, in
addition to what is defined in Section 2.4 of Advanced Sockets API
for IPv6 [1].
The protocol number for Mobility Header:
(http://www.iana.org/assignments/protocol-numbers)
ipv6-mh 135 # Mobility Protocol Header
Chakrabarti & Nordmark Expires April 27, 2006 [Page 25]
Internet-Draft Sockets API for Mobile IPv6 October 2005
8. IPv4-Mapped IPv6 Addresses
The various socket options and ancillary data specifications defined
in this document apply only to true IPv6 sockets. It is possible to
create an IPv6 socket that actually sends and receives IPv4 packets,
using IPv4-mapped IPv6 addresses, but the mapping of the options
defined in this document to an IPv4 datagram is beyond the scope of
this document. The above statement is in compliance with Section 13
of IPv6 Socket API [1].
Chakrabarti & Nordmark Expires April 27, 2006 [Page 26]
Internet-Draft Sockets API for Mobile IPv6 October 2005
9. Security Considerations
The setting of Home Address Destination option and Route Header Type
2 IPV6_RTHDR socket option may not be allowed at the application
level in order to prevent denial-of-service attacks or man-in-the-
middle attacks by hackers. Sending and receiving of mobility header
messages are possible by IPv6 RAW sockets. Thus it is assumed that
this operation is only possible by privileged users. However, this
API does not prevent the existing security threat from a hacker by
sending bogus mobility header or other IPv6 packets using Home
Address option and Type 2 Routing Header extension.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 27]
Internet-Draft Sockets API for Mobile IPv6 October 2005
10. IANA Considerations
This document does not define a new protocol. However, it uses
Mobility Header Protocol for IPv6 to define an API for /etc/protocols
file. (ref: http://www.iana.org/assignments/protocol-numbers)
Chakrabarti & Nordmark Expires April 27, 2006 [Page 28]
Internet-Draft Sockets API for Mobile IPv6 October 2005
11. Changes from last revisions
[ TO BE DELETED BY THE RFC EDITOR BEFORE PUBLISHING AS A RFC]
Version 05 changes:
* Addressed IESG review comments.
Version 04 changes:
* Addressed Last call comment remaining issues and Area Director
review comments
Version 03 changes:
* Modified new ICMPv6 type definition values to match RFC3775.
Version 02 changes:
* Added section 3.1.1 and 3.2.1 to clarify content of routing
header type 2 and destination options.
* Clarified existing socket application behavior in section 3.
* Updated introduction to clarify scope of the applications wrt
this API
* Added IANA section and Full Copyright statement and internet
draft boiler plate
* Updated acknowledgement section and fixed typo etc.
The following changes were made in 01 version per feedback from
the implementors at Connectathon 2004.
* Section 2.1.11.2 now defines alternate COA address data
structure as struct in6_addr for consistency. It was defined as
16 unit of bytes.
* Added Binding Update Authdata of 12 bytes in the
struct ip6_mh_opt_auth_data
* Added a new function inet6_rth_gettype() in section 3.1 in order
to distinguish routing header type 2 ancillary data items from
type 0 routing header ancillary data items on the receive side.
* Updated the Acknowledgement and Authors' address section
Chakrabarti & Nordmark Expires April 27, 2006 [Page 29]
Internet-Draft Sockets API for Mobile IPv6 October 2005
12. Acknowledgement
Thanks to Brian Haley for the thorough review of this draft and many
helpful comments. Keiichi Shima, Alexandru Petrescu, Ryuji Wakikawa,
Vijay Devarapalli, Jim Bound, Suvidh Mathur, Karen Nielsen, Mark
Borst, Vladislav Yasevich and other mobile-ip working group members
provided valuable input. Antti Tuominen suggested the routing header
type function for this API document. During IESG review, Bill Fenner
suggested accessing routing header type directly for being consistent
with RFC3542. A new socket option for Home Address Destination
Option is added as per Bill Fenner's suggestion for clarity of
extension header orders. Thanks to Thomas Narten and Jari Arkko for
the review of this document.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 30]
Internet-Draft Sockets API for Mobile IPv6 October 2005
13. References
13.1 Normative References
[1] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6", RFC 3542,
May 2003.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
13.2 Informative References
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5] Nordmark, E., "IPv6 Socket API for source address selection",
draft-chakrabarti-ipv6-addrselect-api-03 (work in progress),
July 2005.
[6] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
February 2003.
Authors' Addresses
Samita Chakrabarti
Sun Microsystems
16 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 5068
Email: samita.chakrabarti@sun.com
Chakrabarti & Nordmark Expires April 27, 2006 [Page 31]
Internet-Draft Sockets API for Mobile IPv6 October 2005
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Chakrabarti & Nordmark Expires April 27, 2006 [Page 32]
Internet-Draft Sockets API for Mobile IPv6 October 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.
Chakrabarti & Nordmark Expires April 27, 2006 [Page 33]
