Internet DRAFT - draft-ogawa-mobopts-dhcpv4-fho
draft-ogawa-mobopts-dhcpv4-fho
MobOpts WG
Internet Draft T. Ogawa
Document: draft-ogawa-mobopts-dhcpv4-fho-00.txt NTT
Expires: Jan. 2006 July 2005
DHCPv4 Extensions and Option for Fast Handovers
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
When a standard IPv4 node (mobile node: MN) changes its wireless
network attachment point (performs a handover), it gets new IP layer
configuration information (e.g., its new IP address and the addresses
of new routers) from a DHCP server and changes its IP layer
configuration. During such a handover process, it cannot send or
receive IP packets to/from its corresponding node (CN), so a service
disruption is caused. In this document, we introduce new DHCPv4
extensions and an option (Fast Handover Option) for fast handovers.
This protocol is ported from "DHCPv6 options for Fast Handovers" [6].
It enables DHCP servers to send new configuration information to MNs
before a handover to be used after the handover, so MNs can have
shorter handover processing times. It is noted that DHCP servers and
MNs implementing this protocol can achieve fast handovers with
standard IPv4 routers without any other micro-mobility management
protocols.
Ogawa Expires - January 2006 [Page 1]
DHCPv6 Options for Fast Handovers July 2005
Conventions used in this document
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 RFC2119 [1]. Most
terms used in this draft are defined in RFC2131 [2] and RFC2132 [3].
This document uses the following terms.
o MN
Mobile Node. MN is the same as a DHCP client in this document.
o CN
Corresponding Node. A node with which an MN is communicating.
o DHCP-domain
A group of subnets that a DHCP server can manage, and for which
an MN can use the same configuration except for subnet mask,
router address, MN's IP address, and some subnet-specific
options.
o Previous domain
The DHCP-domain to which the MN was attached before a handover.
o New domain
The DHCP-domain to which the MN is attached after a handover.
o D-LABEL
Unique number of a DHCP-domain in a DHCP server.
o AP
Attachment point of the network. If the network interface is a
wireless LAN, it is the same as an access point.
o AP-ID
Unique ID of an AP.
o AP-LABEL
Unique number of an AP in a DHCP server.
o Domain-Aps
APs in a DHCP-domain.
o Neighbor-Aps
Ogawa Expires - January 2006 [Page 2]
DHCPv6 Options for Fast Handovers July 2005
APs physically neighboring an AP.
o L-LABEL
A unique number of a link (subnet) in a DHCP server that is used
to associate an AP Information Sub-option and a Link Information
Sub-option.
o Original DHCP server
A DHCP server that sent the fast handover options that the MN
is using.
Table of Contents
1. Introduction..................................................3
2. New Functions.................................................4
3. Protocol Details..............................................5
3.1 DHCPv4 Fast Handover Extensions..............................5
3.2 Format of DHCP Fast Handover Option..........................9
4. Security Considerations......................................14
5. IANA Considerations..........................................14
6. References...................................................14
1. Introduction
When a standard IPv4 node (mobile node: MN) changes its wireless
network attachment point (AP) (performs a handover), it cannot send
and receive IP packets to/from its corresponding node (CN) during the
handover process. Typically, a handover process consists of the
following processes [2] and takes more than ten seconds.
(1) The MN detects a Layer-2 disconnection between itself and the
current (AP), searches for other APs, and sets up a new Layer-2
connection between itself and a new AP.
(2) The MN detects a link-up and waits for a random time between one
and ten seconds and then sends a DHCPREQUEST message that
includes the previously allocated IP address to all DHCP servers.
(3) The DHCP servers respond to the DHCPNACK message by rejecting the
address (in this case, the MN is assumed to have moved to another
subnet).
(4) The MN waits for more than ten seconds and sends a DHCPDISCOVER
message.
(5) The DHCP servers respond with DHCPOFFER messages.
(6) The MN receives one or more DHCPOFFER messages from the DHCP
servers including offers of new IP addresses and it selects one
server.
Ogawa Expires - January 2006 [Page 3]
DHCPv6 Options for Fast Handovers July 2005
(7) The MN sends a DHCPREQUEST message to the selected server, and
the server replies with a DHCPACK message including other
configuration information.
(8) The MN sends an ARP message for duplicated address detection
(DAD) of new IP addresses.
In IETF, Fast Handovers for Mobile IPv6 (FMIPv6)[4] are to be
standardized soon as an experimental RFC, and the Fast Handovers for
Mobile IPv4 (FMIPv4)[5] protocol ported from FMIPv6 has been proposed
as an individual draft. It reduces the handover time from steps (2)
to (6) above by sending new configuration information to an MN from a
previous access router (AR) before a handover. However, with FMIPv4,
all ARs must be equipped with the FMIP function, and every AR must be
able to exchange FMIPv4 messages with neighboring ARs.
In this document, new DHCPv4 extensions and an option (Fast Handover
Option) are defined for fast handovers. This protocol is ported from
"DHCPv6 options for Fast Handovers" [6]. It is noted that DHCP
servers and MNs implementing this protocol can reduce the process
time of steps (1) to (7) with standard IPv4 routers without any other
micro-mobility management protocols. Step (8) needs to be reduced,
but that is out of the scope of this document. One idea is to apply
Opt-DAD [7] for IPv6. There are many user authentication methods, for
example, we think that 802.1X, pana, and how to reduce the user
authentication time during a handover are worth standardizing, but
these are also out of the scope of this document. To enable an MN to
continue communication with its corresponding nodes (CNs) after a
handover, some kind of macro-mobility management protocol, for
example, mobile IP v4 [8] or SIP [9] is required.
2. New Functions
This document introduces four new functions.
(1) AP information distribution function
The Fast Handover Option carries AP information about the new link.
For example, if the candidate new APs use a wireless LAN, MNs can
know the channel numbers used by the APs before the handover.
During a handover, MNs only need to search for the notified
channels instead of all channels, which can reduce the layer-2
handover time.
Ogawa Expires - January 2006 [Page 4]
DHCPv6 Options for Fast Handovers July 2005
(2) Fast network movement detection function
The Fast Handover Option also carries lists of the IDs of
candidate new APs (e.g., BSSID) and corresponding new access
router's (NAR's) IP address to the MN on the old link. When the MN
connects to one of the APs, it searches for its ID in the list and
discovers to which subnet it has moved.
(3) Fast IP address assigning function
The Fast Handover Option also carries the candidate new DHCP
server's server identifier (IP address). When the MN moves to a
new link, it sends a DHCPREQUEST message including the
corresponding DHCP server identifier via the corresponding NAR as
soon as it detects the link-up. The DHCP server replies with a
DHCPACK message including the MN's new IP address and other
configuration information.
(4) DHCP proxying function
If the IP address-pool of the new DHCP server is large and the
original DHCP server can assign candidate new IP addresses to the
MNs before the handover, this DHCP proxying function is useful to
reduce the number of DHCP messages during a handover.
This function also enables the Fast Handover Option to carry an
MN's candidate new IP addresses and unique numbers for DHCP-
domains (see "Conventions used in this document"), and an MN can
know whether it has entered a new DHCP-domain upon link-up. If the
DHCP proxying function is used and the MN is still in the same
DHCP-domain, it does not need to send DHCP messages to the new
DHCP server.
3. Protocol Details
3.1 DHCPv4 Fast Handover Extensions
This section defines DHCPv4 extensions for fast handovers. They are
based on DHCP [2] and differences are noted below.
DHCPREQUEST, DHCPLELEASE, and DHCPACK messages may include the Fast
Handover Option, but other messages MUST NOT include the Fast
Handover Option.
Ogawa Expires - January 2006 [Page 5]
DHCPv6 Options for Fast Handovers July 2005
Table 4 of [2] MUST be changed to the following Tables 1 and 2.
+--------------+------------+-------------+-------------+------------+
| |INIT-REBOOT |SELECTING |BOUND to | RENEWING to|
| | | | RENEWING | REBINDING |
+--------------+------------+-------------+-------------+------------+
|broad/unicast |broadcast |broadcast |unicast |broadcast |
|server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
|requested-ip |MUST |MUST |MUST NOT |MUST NOT |
|ciaddr |zero |zero |IP address |IP address |
+--------------+------------+-------------+-------------+------------+
Table 1: Client messages from different states
+-------------------------------------------+
| | BOUND, RENEWING and REBIND |
| | to REQUESTING |
+--------------+----------------------------+
|broad/unicast |unicast |
|server-ip |MUST |
|requested-ip |MAY |
|ciaddr |zero |
+--------------+----------------------------+
Table 2: Client messages from different states
3.1.1 Initial exchange of DHCPREQUEST and DHCPACK
If an MN detects a link-up for the first time (when it is booted,
rebooted, or attached to a network for the first time), it enters the
INIT state or SELECTING state [2], and it MUST send a DHCPREQUEST
message including a First Handover option, and it enters the
REBOOTING state or REQUESTING state, respectively. The Fast Handover
option MUST include the Previous AP-ID. If the MN knows the new AP's
ID before handover, it MAY add the New AP-ID in the First Handover
option.
Ogawa Expires - January 2006 [Page 6]
DHCPv6 Options for Fast Handovers July 2005
If a DHCP server receives a DHCPREQUEST message that includes a
Previous AP-ID, it replies with DHCPACK messages including Fast
Handover options. Information carried in the options depend on the
new AP-ID in the DHCPREQUEST message.
o If the DHCPREQUEST message includes new AP-ID, the DHCPACK message
includes two AP Information Sub-options, and one or two Link
Information Sub-options corresponding to the APs specified by the
Previous AP-ID and new AP-ID.
o If the DHCPREQUEST message does not include new AP-ID, the DHCPACK
message includes as many AP Information Sub-options as the number
of APs in the DHCP-domain to which the MN is attached and as many
Link Information Sub-options as the number of subnets in the
DHCP-domain.
An AP Information Sub-option MUST include an AP's Layer-2 protocol
code and Layer-2-dependent information (e.g., channel number) and the
AP's neighbor-AP's AP-LABEL, and an unique number of a subnet (L-
LABEL) to which the AP is attached.
A Link Information Sub-option MUST include the following information
about a subnet: an L-LABEL, an unique number of a DHCP-domain (D-
LABEL) that includes the subnet, new DHCP server's identifier, yiaddr
(clients IP address), a subnet mask, and the routers' IP addresses.
The Sub-option MAY encapsulate subnet specific other options defined
[3] requested by the MN.
If the DHCP server cannot offer the new DHCP server's IP address to
the MN, the new DHCP server's identifier MUST be set to "0xffffffff".
If the DHCP server cannot assign an IP address to the MN, the yiaddr
MUST be set to "0".
If an MN in the REBOOTING or REQUESTING state accepts the DHCPACK, it
records the leases of all IP addresses offered by the DHCPACK, sets
their timers T1 and T2, and enters the BOUND state.
3.1.2 Handover
In the BOUND, RENEWING, and REBINDING states, MNs MUST watch the
Layer-2 state, and if the MN decides to perform a handover, it looks
up the AP Information Sub-option corresponding to the current AP and
get information about the AP's neighboring APs. If the neighboring
APs use a wireless LAN, the MN searches for only the notified channel
instead of for all channels. The interface between Layer 2 and DHCP
in the MN is out of the scope of this document.
Ogawa Expires - January 2006 [Page 7]
DHCPv6 Options for Fast Handovers July 2005
If the MN detects a Layer-2 handover, it gets the AP-ID of the AP to
which the MN is attached from its Layer 2.
The MN searches the AP Information Sub-options received before the
handover, gets the L-LABEL corresponding to the AP-ID, looks up the
Link Information Sub-option corresponding to the L-LABEL, and gets
the new DHCP server's identifier and its new configuration.
If the new DHCP server's identifier is "ffffffff", the MN MUST enter
the INIT state immediately.
If the new DHCP server's identifier is not "ffffffff", it MUST do one
of following process.
o If the L-LABEL is the same as the previous L-LABEL, this means
that the MN is still in the same subnet, so it MUST NOT change
the configuration.
o If the L-LABEL is not the same as the previous L-LABEL and the
yiaddr in the sub-option is not "0" and the D-LABEL in the sub-
option is the same as the previous D-LABEL, the MN checks on the
yiaddr (e.g., ARP for allocated IP address) offered by the
original DHCP server. If the yiaddr is invalid in the new subnet,
the MN MUST send a DHCPDECLINE Message to the original DHCP server
and enter the INIT state. If the address is valid, it MUST use the
configuration information in the Fast Handover Option (yiaddr,
subnet mask, routers address and some configuration information
specific to the subnet).
o Otherwise, the MN MUST send a DHCPREQUEST unicast message
including siaddr (server identifier) notified by the Link
Information Sub-option and a Fast Handover option including the
Previous AP-ID (ID of the AP to which the MN is now attached). The
message MAY include the requested IP address option notified by
the Link Information Sub-option as yiaddr. Then, the MN enters
the REQUESTING state.
It is defined in [2] that: "(If the MN is in the INIT-REBOOT state),
the client (MN) SHOULD wait (sending a DHCPREQUEST message) for a
random time between one and ten seconds to desynchronize the use of
DHCP at startup". However, in this case, if the MN is sure that the
link-up was not caused by the failure of the previous AP, or by the
power-on operation of the new AP, and the probability of message
synchronization is small, then the MN SHOULD send the DHCPREQUEST
message immediately.
Ogawa Expires - January 2006 [Page 8]
DHCPv6 Options for Fast Handovers July 2005
3.1.3 Releasing and renewing
To release or renew addresses offered by the Fast Handover Option
from a server, the MN MUST send DHCPRELEASE or DHCPRENEW unicast
messages including a Fast Handover Information Request Option to the
original DHCP server.
3.1.4 Rebinding
To Rebind addresses offered by the Fast Handover Option, the MN sends
a DHCPREBIND broadcast message including a Fast Handover Information
Option. The option MUST include the Previous AP-ID and MAY include
the New AP-ID.
3.2 Format of DHCP Fast Handover Option
This section defines the format of the DHCP Fast Handover Option and
its sub-options. The format is based on DHCPv4 [2], [3] and
differences are clearly noted below.
3.2.1 Fast Handover Option
A Fast Handover Option sent by an MN MUST encapsulate one Previous AP
ID Sub-option and may encapsulate a New AP ID Sub-option.
A Fast Handover Option sent by a server MUST encapsulate an AP
Information Sub-option or a Link Information Sub-option.
Code Len Sub-options
+-----+-----+-----+-----+-----+-----+
| tbd | n | ...
+-----+-----+-----+-----+-----+-----+
Ogawa Expires - January 2006 [Page 9]
DHCPv6 Options for Fast Handovers July 2005
3.2.2 Previous AP ID Sub-option (FHO-Previous_AP-ID)
The Previous AP ID Sub-option is used in the Fast Handover Option.
Sub-code Len Value AP-ID
+-----+-----+-----+-----+-----+-----+
| tbd | n | a | ...
+-----+-----+-----+-----+-----+-----+
Value a 1. Wireless LAN 802.11b
2. Wireless LAN 802.11g
3. Wireless LAN 802.11a
(1 octet)
AP-ID If the Value a is 1, 2, or 3, BSSID is used.
(variable length)
3.2.3 New AP ID Sub-option (FHO-New_AP-ID)
The New AP ID Sub-option is used in the Fast Handover option.
Sub-code Len Value AP-ID
+-----+-----+-----+-----+-----+-----+
| tbd | n | a | ...
+-----+-----+-----+-----+-----+-----+
Value a 1. Wireless LAN 802.11b
2. Wireless LAN 802.11g
3. Wireless LAN 802.11a
(1 octet)
AP-ID If the Value a is 1, 2, or 3, BSSID is used.
(variable length)
Ogawa Expires - January 2006 [Page 10]
DHCPv6 Options for Fast Handovers July 2005
3.2.4 AP Information Sub-option
The AP Information Sub-option carries AP Information associated
with an AP and is used in the Fast Handover Option.
Sub-code Len AP-LABEL L-LABEL Value neighbor-AP-LABEL Value info
+-----+-----+--------+--------+-----+-----+-----+-----+-----+----
| tbd | n |AP-LABEL|L-LABEL | b | L1 | L2 | ... | a |...
+-----+-----+--------+--------+-----+-----+-----+-----+-----+----
AP-LABEL Unique number in a DHCP-domain of the AP. "0" is
reserved.
(1 octet)
L-LABEL This number indicates associated Layer-3
Information Sub-option. The same number is also
set in the associated Link Information Sub-
option.
If the DHCP does not know Link Information
about the AP, "(0x00)" is set.
(1 octet)
Value b (neighbor-AP-number)
Number of neighbor-APs of the AP.
(1 octet)
Neighbor- AP-LABEL AP-LABELs of the neighbor-APs.
(as many as the number of neighbor-APs).
(1 octet)
Value a 1. Wireless LAN 802.11b
2. Wireless LAN 802.11g
3. Wireless LAN 802.11a
(1 octet)
info AP-ID and other information associated with the
"Value a".
(variable length)
Ogawa Expires - January 2006 [Page 11]
DHCPv6 Options for Fast Handovers July 2005
If the "Value a" is 1, 2, or 3, the info field is defined as below.
Authentication algorithms other than open system ones are to be
discussed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ch | ESSID-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESSID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth-algorithm-number | auth-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth-data(variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BSSID BSSID of the AP. (AP-ID)
(6 octets)
ch channel number.
(1 octet)
ESSID-Length Length of ESSID (octets)
ESSID See section 7.3.2.1 "Service Set Identity
(SSID) element" of 802.11.
(variable length)
auth-algorithm-number
See section 7.3.1.1 Authentication Algorithm
Number field of 802.11.
0: open system authentication.
(2 octets)
auth-len Length of auth-data associated with
authentication-algorithm-number (octets).
If authentication-algorithm-number is 0,
then auth-len is 0.
(2 octets)
Ogawa Expires - January 2006 [Page 12]
DHCPv6 Options for Fast Handovers July 2005
auth-data Authentication data associated with
authentication-algorithm-number.
If authentication-algorithm-number is 0,
auth-data does not exist.
(variable length)
3.2.5 Link Information Sub-option
The Link Information Sub-option carries Link Information associated
with a link and is used in the Fast Handover Option.
It MUST encapsulate the subnet mask option and the router option in
[3]. It MAY encapsulate other subnet-specific options defined in [3]
requested by MN.
Sub-code Len L-LABEL D-LABEL siaddr yiaddr options
+----+-----+--------+--------+---+---+---+---+---+---+---+---+-----+--
|tbd | n | L-LABEL|D-LABEL | a1| a2| a3| a4| a1| a2| a3| a4|...
+----+-----+--------+--------+---+---+---+---+---+---+---+---+-----+--
L-LABEL This number associates the AP Information
Sub-option with the Link Information Sub-option.
The same number is also set in the associated
Layer-2 Information Sub-option. "(0x00)" is
reserved in this field.
(1 octet)
D-LABEL Unique number of the DHCP-domain to which the AP
belongs.
"0" is reserved. If the DHCP-domain is not
managed by the DHCP server, then "(0xff)" is
set.
(1 octet)
siaddr New server IP address on this link.
If the original DHCP server cannot offer the
address, then "(0xffffffff)" is
set.
(4 octets)
Ogawa Expires - January 2006 [Page 13]
DHCPv6 Options for Fast Handovers July 2005
yiaddr client IP address on this link.
If the DHCP server cannot offer the address,
then "0" is set.
(1 octet)
4. Security Considerations
Secure delivery of Fast Handover information from a DHCP
server to a (DHCP client) relies on overall DHCP
security. The option defined in this draft does not have
an additional impact on DHCP security. The DHCP authentication
mechanism shall be used when the operator seeks authentication of the
requestor and the information source (DHCP server).
There are many user authentication methods, for example, 802.1x, pana,
and how to reduce the user authentication time during a handover are
to be standardized, but these are also out of the scope of this
document.
5. IANA Considerations
This document introduces a new DHCPv4 option and some sub-options.
The type numbers for these new options are currently TBD.
An appropriate request will be made to IANA if this Internet draft
gets accepted as an RFC.
6. References
Normative References
[1] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.
[2] Droms R., "Dynamic Host Configuration Protocol," RFC 2131, Mar.
1997.
[3] Alexander S., et al., "DHCP Options and BOOTP Vendor Extensions,"
RFC 2132,
Mar. 1997.
Ogawa Expires - January 2006 [Page 14]
DHCPv6 Options for Fast Handovers July 2005
Informative References
[4] Koodli R., Editor, "Fast Handovers for Mobile IPv6," draft-ietf-
mipshop-fast-mipv6-03.txt, Oct. 2004.
[5] Koodli R., et. al., "Adapting Mobile IPv6 Fast Handovers for
IPv4," draft-koodli-fmipv4-00.txt, Oct. 2004.
[6] Ogawa T., et. al., "DHCPv6 Options for Fast Handovers,"
draft-ogawa-fhopt-00.txt, Feb. 2005.
[7] N. Moore, et al., "Optimistic Duplicate Address Detection for
IPv6," draft-ietf-ipv6-optimistic-dad-03.txt, December 2004.
[8] C. Perkins, et al., "IP Mobility Support for IPv4," RFC 3344,
August 2002.
[9] M. Handley, et al., "SIP: Session Initiation Protocol," IETF RFC
3261, June 2002.
Author's Addresses
Takeshi Ogawa
NTT Network Systems Laboratories, NTT Corporation
9-11 Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585, Japan
Phone: +81 422 59 4053
Email: ogawa.takeshi@lab.ntt.co.jp
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
Ogawa Expires - January 2006 [Page 15]
DHCPv6 Options for Fast Handovers July 2005
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full 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.
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.
Ogawa Expires - January 2006 [Page 16]
