Network Working Group                                             B. Koh
Internet-Draft                                                     C. Ng
Expires: November 30, 2004                      Panasonic Singapore Labs
                                                               J. Hirano
                                                               Panasonic
                                                               June 2004



                   Dynamic Inter Home Agent Protocol
                           draft-koh-dihap-00


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   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 November 30, 2004.


Copyright Notice


   Copyright (C) The Internet Society (2004). All Rights Reserved.


Abstract


   This draft describes a proposed Dynamic Inter Home Agent solution to
   provide redundancy and load balancing of Home Agents.  The proposed
   solution recommends additional communication between home agents that
   may be located far apart in terms of network topology but still
   belonging to or are trusted by the same administrative domains
   (service providers).  While the mobile node is roaming away from its
   home network, intervening home agents in the path of the
   bidirectional tunnel between the mobile node and its registered home




Koh, et al.            Expires November 30, 2004                [Page 1]
Internet-Draft                   DIHAP                         June 2004



   agent may detect its presence.  The intervening home agents that are
   affiliated to the current home agent of the mobile node then proceed
   to update it of their availability to serve as home agent for the
   mobile node.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of Dynamic Inter Home Agents Protocol . . . . . . . .  4
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1   Home Agent Change Message  . . . . . . . . . . . . . . . .  5
     4.2   Affiliated Home Agent Update Message . . . . . . . . . . .  6
     4.3   Home Interface List Update Message . . . . . . . . . . . .  7
   5.  Home Interface List  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . .  9
     6.1   Home Agent Notification  . . . . . . . . . . . . . . . . . 10
       6.1.1   Separate Anycast . . . . . . . . . . . . . . . . . . . 10
       6.1.2   Piggy-backed Anycast . . . . . . . . . . . . . . . . . 10
   7.  Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 10
     7.1   Original Home Agent  . . . . . . . . . . . . . . . . . . . 10
       7.1.1   Solo Operation . . . . . . . . . . . . . . . . . . . . 10
       7.1.2   Centralised Operation  . . . . . . . . . . . . . . . . 11
     7.2   Affiliated Home Agent  . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 15























Koh, et al.            Expires November 30, 2004                [Page 2]
Internet-Draft                   DIHAP                         June 2004



1.  Introduction


   For Mobile IPv6 [6], mobile nodes either tunnel its traffic through a
   bi-directional tunnel via its home agent or it may employ route
   optimisation with the correspondent node it is in communication with.
   For NEMO Basic Support [1], the default mode of operation is to
   tunnel all traffic meant for the mobile network through the home
   agent serving the mobile router.  As such, home agents may greatly
   affect the effectiveness and efficiency with respect to the terminals
   that deploy these two protocols.  With the widespread prolification
   of mobile terminals and supporting services, this may gain increasing
   importance as a influencing factor.  Sometimes, the mobile host and
   its network could be closer to the correspondent node than the Home
   Agent or the home agent becomes increasing congested and overloaded.
   By choosing a home closer to its current location, the network
   traffic could be significantly reduced as well as improving the
   overall performance of the mobile host or network.  One solution for
   solving this problem is described in [3], the Inter Home Agents
   Protocol proposes that the mobile node be provided with multiple home
   agents and any of the home agents can forward packets to and from the
   the mobile node.  However, the downside to the proposed solution is
   the constant updating between all of the home agents.  This is
   irregardless of whether or not the other home agents are useful to
   the mobile node.  There is hence a fixed increase in signalling
   overhead per number of home agents involved.


   This draft describes a proposed Dynamic Inter Home Agent solution to
   provide redundancy and load balancing of Home Agents.  The proposed
   solution recommends additional communication between home agents that
   may be located far apart in terms of network topology but still
   belonging to or are trusted by the same administrative domains
   (service providers).  While the mobile node is roaming away from its
   home network, intervening home agents in the path of the
   bidirectional tunnel between the mobile node and its registered home
   agent may detect its presence.  The intervening home agents that are
   affiliated to the current home agent of the mobile node then proceed
   to update it of their availability to serve as home agent for the
   mobile node.


   The proposed solution employs the use of an addition Home Interface
   List as a repository of the received updates from other home agents
   including local interfaces that are serving as home agents.  The
   location of the Home Interface List gives rise to the two operation
   modes of the solution.  When the list is located on the home agent
   itself, this is referred to as the solo mode of operation.  However,
   it is possible to locate the list on a topologically different
   location.  This is referred to as the centralised mode of operation.





Koh, et al.            Expires November 30, 2004                [Page 3]
Internet-Draft                   DIHAP                         June 2004



2.  Terminology


   There are separate documents regarding Mobility terminology [5] as
   well as Nemo terminology [2], which defines the terms related to
   Network Mobility used in the document.  This document in addition
   defines the following term.


      Affiliated Home Agent


         A home agent that is known and trusted by a singular or group
         of home agents.



3.  Overview of Dynamic Inter Home Agents Protocol


   When a home agent is deployed, each home agent should be configured
   with the prefixes of other affiliated home agents.


   A Home Interface List comprising of information such as interface and
   mobile node addresses should be available to the home agent.  The
   list may be located on the home agent or at a remote location (e.g.
   some other home agent) that is preconfigured in the home agent.  This
   information is different from the Binding Cache of the home agent as
   its entries comprises of all the available interfaces able to serve
   as a home agent. Each entry should preferably have a metric to
   indicate preference for use as a home agent interface.  The
   preference metric should be updated as the situation requires it.
   Each entry may optionally have a corresponding mobile node address to
   indicate that the interface should only be considered for the
   indicated mobile node.  For each such mobile node entry, there should
   also be a corresponding selection metric.


   The home agent should first register all of its interfaces available
   to serve as home agent interfaces with the Home Interface List.  When
   a registered interface is no longer available, it should be
   deregistered from the List.  Unavailability may be due possibly to
   the link going down or congestion.


   When choosing an interface to serve as the home agent for the mobile
   node, the home agent may choose from its available local interfaces
   or it may alternatively consult the Home Interface List.











Koh, et al.            Expires November 30, 2004                [Page 4]
Internet-Draft                   DIHAP                         June 2004



   +-----------------------------------------------------+
   |                                                     |
   |   Internet                             HA4          |
   |                                                     |
   |                  HA2                                |
   |                                                     |      +-------+
   |                                                 /---|==HA==| Home  |
   |                                          /-----/    |      |Network|
   |                                  /------/           |      +-------+
   |                   /-----HA3-----/ Packet Path       |
   |    MN-----HA1----/                                  |
   |                                                     |
   +-----------------------------------------------------+


   During normal operation, the home agent (HA1, HA3) may detect or be
   informed of the presence of mobile nodes (MN) registered with an
   affiliated home agent (HA) roaming in their vicinity.  Upon such
   occasion, the home agent (HA1, HA3) may choose to inform the
   destination affiliated home agent (HA)of its availability to serve as
   a home agent for the mobile node (MN).  The Home Interface List of
   the destination affiliated home agent (HA) is updated accordingly.


   The home agent (HA) may choose to actively inform a registered mobile
   node (MN) to switch to another home agent interface.  In this case, a
   Home Agent Change message may be sent to the mobile node (MN) with
   the address of the new home agent interface address (HA1).  The
   mobile node (MN) should then proceed to register itself with the
   given home agent interface (HA1).


   The Home Interface List may be shared amongst several home agents.
   In this scenario, the list may be hosted on one of the home agents or
   at another remote location.


4.  Message Formats


4.1  Home Agent Change Message


   The Home Agent Change message is used by a home agent to request a
   mobile node to perform a home registration with a specific home
   agent.


   The Home Agent Change message uses the MH Type value 8.  When this
   value is indicated in the MH Type field, the format of the Message
   Data field in the Mobility Header is as follows:








Koh, et al.            Expires November 30, 2004                [Page 5]
Internet-Draft                   DIHAP                         June 2004



    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +               Alternate Home Agent Address                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Reserved


         16-bit field reserved for future use.  The value MUST be
         initialized to zero by the sender, and MUST be ignored by the
         receiver.


      Alternate Home Agent Address


         The address of the new home agent with which the mobile node
         should initiate a home registration.



4.2  Affiliated Home Agent Update Message


   The Affiliated Home Agent Update message is used by an affiliated
   home agent to inform a home agent of its availability and suitability
   to act as a home agent for the detected mobile node in question.


   The Affiliated Home Agent Update message uses the MH Type value 9.
   When this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:



    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |Hop Limit Count|   Lifetime    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +            Detected Mobile Node Care-of-Address               +
   |                                                               |
   +                                                               +




Koh, et al.            Expires November 30, 2004                [Page 6]
Internet-Draft                   DIHAP                         June 2004



   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Hop Limit Count


         8-bit field specify the initial Hop Count of the IPv6 header.
         By subtracting Hop Limit Count from the Hop Count, it is
         possible to estimate the distance (in hops) of the affiliated
         home agent from the registered home agent.  This value may then
         be used as the metric value in the Home Interface List Update
         message.


      Lifetime


         8-bit unsigned integer.  The number of time units remaining
         before the information contained within this update MUST be
         considered expired.  One time unit is 4 seconds.


      Detected Mobile Node Care-of-Address


         The current Care-of-Address of the mobile node that was
         detected by the affiliated home agent.



4.3  Home Interface List Update Message


   The Home Interface List Update message is used by a home agent to
   update the Home Interface List when the home agent is operating in
   centralised mode.  This means that the Home Interface List is
   actually hosted on an entity at a remote location and the home agent
   itself.


   The Home Interface List Update message uses the MH Type value 10.
   When this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:

















Koh, et al.            Expires November 30, 2004                [Page 7]
Internet-Draft                   DIHAP                         June 2004



    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    Metric     |   Lifetime    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +               Home Agent Interface Address                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                 Mobile Node Home Address                      .
   .                                                               .
   |                                                               |


      Metric


         8-bit unsigned integer.  The number reflections the
         desirability of using the interface specified in the message as
         a home agent. Metric values for entries of local interfaces
         should not used to compare with the metric values for entries
         created for affiliated home agents as their derivation may
         differ.


      Lifetime


         8-bit unsigned integer.  The number of time units remaining
         before the information contained within this update MUST be
         considered expired.  One time unit is 4 seconds.


      Home Agent Interface Address


         The address of the interface that is available to serve as a
         home agent. If the Mobile Node Home Address field exists, the
         interface will only serve as home agent for that mobile node.


      Mobile Node Home Address


         Only found for messages corresponding to Affiliated Home Agent
         Update messages.  This field may be left out if not applicable.
         The existence of this field may be deduced from the Header Len
         field of the Mobility Header.






Koh, et al.            Expires November 30, 2004                [Page 8]
Internet-Draft                   DIHAP                         June 2004



5.  Home Interface List


   The Home Interface List maintains a record of available interfaces
   for which may serve as home agents for mobile nodes.  A Home
   Interface List may either be maintained by each home agent node or
   else at a known location.  The Home Interface List may be implemented
   in any manner consistent with the external behavior described in this
   document, for example by being combined with the node's Binding Cache
   as maintained by Mobile IP.  When responding to a home registration
   request or performing load balancing for congested interfaces, the
   home agent may choose to utilise local interfaces or else the Home
   Interface List should be searched.


   Each Home Interface List entry conceptually contains the following
   fields:


   o  The address of the interface to serve as a home agent


   o  The address of the specific mobile node for which the interface is
      willing to serve as a home agent.  This value may be left blank.
      Entries with a value in this field should be given higher priority
      when a request is made for the mobile node in question.


   o  A metric value.  This may be a preference value for using this
      interface.  When there is a valid value in the mobile node address
      field however, this metric may be used to signify the proximity of
      the interface to the mobile node in question.


   o  A lifetime value, indicating the remaining lifetime for this Home
      Interface List entry.  This may be mandatory for all entries in a
      remotely located Home Interface List, else required only for
      entries with a valid mobile node address field value.


   The Home Interface List should be updated when interfaces come out or
   are taken off due to congestion or otherwise.


6.  Mobile Node Operation


   The mobile node MUST be able to interpret the new Home Agent Change
   message in order for the Dynamic Inter Home Agent Protocol to
   function. Upon the receipt of the option, the mobile node should
   perform the following actions:


   o  Check that there is a corresponding home registration entry for
      the source address given in the packet containing the option. If a
      corresponding entry is not found, the packet MUST be silently
      discarded.





Koh, et al.            Expires November 30, 2004                [Page 9]
Internet-Draft                   DIHAP                         June 2004



   o  If a corresponding home registration entry was found, the
      Alternate Home Agent Address should be retrieved from the option
      and the Home Registration process started with the new Home Agent.


   o  The mobile node MAY choose to expire the home registration with
      its old home agent, it may otherwise allow it to expire normally.



6.1  Home Agent Notification


   The mobile MAY choose to take no specific action to notify any nearby
   home agents.  However, this may be the least effective method of
   implementing the solution.  Better alternatives involving the use of
   anycasting are given below.


6.1.1  Separate Anycast


   For a mobile node that implements the Separate Anycast, whenever the
   mobile node sends a Binding Update to its registered home agent, a
   separate packet with the destination address set to the value of
   Mobile IPv6 Home-Agents anycast address [4] is sent. The source
   address of the packet should be set to the mobile node's current
   Care-of-Address. The packet should contain the address of the mobile
   node's current home agent.


6.1.2  Piggy-backed Anycast


   For a mobile node that implements the Piggy-backed Anycast, the
   mobile node should encapsulate the Binding Update to its registered
   home agent. The new IPv6 header should have the source address set to
   the mobile node's current Care-of-address and the destination address
   as the Mobile IPv6 Home-Agents anycast address.


7.  Home Agent Operation


7.1  Original Home Agent


   The original home agent is the home agent with which the mobile node
   currently has a home registration.  When the Home Interface List is
   located on the home agent itself, it is described as performing in
   solo mode.  Locating the Home Interface List on a remote interface or
   on another home agent is called the centralised operation mode.


7.1.1  Solo Operation


   The home agent operates as per Mobile IP [6] and NEMO [1], however,
   it should also register the interfaces on which it is serving as a
   home agent with the Home Interface List.  Home registration requests




Koh, et al.            Expires November 30, 2004               [Page 10]
Internet-Draft                   DIHAP                         June 2004



   are handled normally. However, if and when it decides to do load
   balancing either due to traffic congestion or impending link going
   down, it MAY arbitrarily choose a local interface or else query the
   Home Interface List. It MAY then send a message with the Home Agent
   Change message to the affected mobile node(s) requesting that the
   mobile node register itself with the new home agent.


   When the home agent receives an Affiliated Home Agent Update message
   addressed to itself, it should perform the following actions:


   o  Check that the source address of the packet contains the address
      belonging to an affiliated home agent or group of home agents. The
      packet should be silently discarded otherwise.


   o  Check that the Detected Mobile Node Care-of-Address field has a
      corresponding Care-of-Address entry in the Binding Cache and that
      it is a Home Registration.


   o  Update the Home Interface List with the address of the affiliated
      home agent interface, the specified mobile node's home address,
      the lifetime for which the entry is valid and the metric.  The
      metric described here is calculated by deducting the Hop Limit
      Count field in the Affiliated Home Agent Update message from the
      current Hop Limit value in the IPv6 header field.  This should
      yield the approximate distance (in hops) to the affiliated home
      agent.



7.1.2  Centralised Operation


   The home agent in centralised operation is essentially similar to
   solo operation.  The key difference being that all updates to the
   Home Interface List should be forwarded to the entity hosting the
   list. Additionally, the home agent should update its local interfaces
   that are serving as home agents with the remote Home Interface List
   together with a lifetime entry and should periodically do so before
   the lifetime expires.


   When the home agent receives an Affiliated Home Agent Update message
   from a intermediate home agent, it should as per Solo operation check
   that the source home agent of the the message is valid.  The Detected
   Mobile Node Care-of-Address field is then checked with the Binding
   Cache for a match. Assuming a match is found, the Home Interface List
   Update message is created and sent to be updated at the remote Home
   Interface List.


   The remote Home Interface List may be queried for a home agent
   address by the home agent by sending a Query message with a payload




Koh, et al.            Expires November 30, 2004               [Page 11]
Internet-Draft                   DIHAP                         June 2004



   consisting of a magic number and the home address of the mobile node.
   The Reply message from the Home Interface List should have a payload
   consisting of the same magic number contained in the Query message as
   well as the selected home agent interface address.


   It is assumed that the home agents and the entity hosting the Home
   Interface List are known to each other.


7.2  Affiliated Home Agent


   Affiliated home agents MAY actively scan forwarded packets for the
   existence of a mobility header and an affiliated home agent address
   in the destination address field. They then send a Alternate Home
   Agent Update to the destination address of the intercepted packet.
   This assumes that the home agent is also a operating as a router.
   The more efficient and effective method would be for the mobile node
   to use anycasting.  In any case, the affiliated home agent would take
   the following actions:


   o  Detect presence of Binding Updates to a home agent.


   o  Check that destination home agent belongs to list of affiliated
      home agents (e.g. by checking the network prefix).  Perform
      relevant packet processing.  Forwarding the packet if it was
      intercepted, Decapsulating and forwarding a piggy-backed anycast
      or discarding a separate anycast notification packet.


   o  Check Home Interface List to look for available interface to serve
      as the home agent for the mobile node.


   o  Create and send the Affiliated Home Agent Update message and send
      it to the home agent specified in the destination address.



8.  IANA Considerations


   This document defines three new Mobility Header messages


   o  Home Agent Change Message


   o  Affiliated Home Agent Update Message


   o  Home Interface List Update Message



9.  Security Considerations


   A home agent MUST know whether the other home agent is an affiliated




Koh, et al.            Expires November 30, 2004               [Page 12]
Internet-Draft                   DIHAP                         June 2004



   home agent.  Affiliated home agents SHOULD establish secure
   associations with each other before sending Affiliated Home Agent
   Updates.  All signaling messages between the home agents SHOULD be
   authenticated and encrypted (e.g. by using IPsec ESP)


   Please refer to the Mobile IPv6 specification [6] and the NEMO Basic
   Support protocol specification [1] for security considerations.


10  References


   [1]  Devarapalli, V., "Network Mobility (NEMO) Basic Support
        Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
        June 2004.


   [2]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
        draft-ietf-nemo-terminology-00 (work in progress), May 2003.


   [3]  Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents
        Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in
        progress), February 2004.


   [4]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
        Addresses", IETF RFC 2526, March 1999.


   [5]  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
        3753, June 2004.


   [6]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.



Authors' Addresses


   Benjamin Koh
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG


   EMail: benjamin@psl.com.sg











Koh, et al.            Expires November 30, 2004               [Page 13]
Internet-Draft                   DIHAP                         June 2004



   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG


   Phone: +65 65505420
   EMail: cwng@psl.com.sg



   Jun Hirano
   Matsushita Electric Industrial Co., Ltd. (Panasonic)
   5-3 Hikarino-oka
   Yokosuka, Kanagawa  239-0847
   JP


   Phone: +81 46 840 5123
   EMail: hirano.jun@jp.panasonic.com

































Koh, et al.            Expires November 30, 2004               [Page 14]
Internet-Draft                   DIHAP                         June 2004



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 IETF's procedures with respect to rights in IETF 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 (2004). 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.




Koh, et al.            Expires November 30, 2004               [Page 15]