[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-levkowetz-dhc-mip-fa) 00 01 02

DHC Working Group                                           H. Levkowetz
Internet-Draft                                               ipUnplugged
Expires: August 1, 2004                                         Feb 2004


               DHCP Option for Mobile IP Mobility Agents
                 <draft-ietf-dhc-mipadvert-opt-02.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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 August 1, 2004.

Copyright Notice

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

Abstract

   This document defines a Dynamic Host Configuration Protocol (DHCP)
   option with sub-options.  One sub-option is passed from the DHCP
   Server to the DHCP Client to announce the presence of one or more
   Mobile IP Mobility Agents.  For each announced Mobility Agent,
   information is provided which is the same as that of the Mobile IP
   Agent Advertisement extension to ICMP Router Advertisements.  There
   is also one sub-option which may be used by a DHCP client to provide
   identity information to the DHCP server.








Levkowetz                Expires August 1, 2004                 [Page 1]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
         2.1 Requirements Terminology . . . . . . . . . . . . . . . .  3
         2.2 Mobile IP Terminology  . . . . . . . . . . . . . . . . .  3
         2.3 DHCP Terminology . . . . . . . . . . . . . . . . . . . .  3

   3.  Mobility Agent Information Option  . . . . . . . . . . . . . .  3
         3.1 Mobility Agent Information Option Definition . . . . . .  3
         3.2 Network Access Identifier Sub-Option . . . . . . . . . .  5
         3.3 Mobility Agent Announcement (Dynamic) Sub-Option . . . .  6
         3.4 Mobility Agent Announcement (Static) Sub-Option  . . . .  8

   4.  Mobility Agent Option Usage  . . . . . . . . . . . . . . . . .  9
         4.1 DHCP Server - Mobility Agent Interaction . . . . . . . .  9
         4.2 Mobile Node Considerations . . . . . . . . . . . . . . . 10
         4.3 DHCP Server Considerations . . . . . . . . . . . . . . . 10

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11

       Normative References . . . . . . . . . . . . . . . . . . . . . 12

       Informative References . . . . . . . . . . . . . . . . . . . . 12

       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13

   A.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13

       Intellectual Property and Copyright Statements . . . . . . . . 14
















Levkowetz                Expires August 1, 2004                 [Page 2]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


1. Introduction

   There already exists a DHCP [RFC2131] option to announce Mobile IP v4
   Home Agent addresses, this is described in [RFC2132].  There is,
   however, no DHCP option available to announce Mobile IP v4 Foreign
   Agents.

   Announcement of available Mobile IP v4 Mobility Agents by means of
   DHCP provides possibilities for selective and individual assignment
   of Mobility Agents to Mobile Nodes.  This in turn makes load-sharing
   and selective service offerings easier.  This draft describes a DHCP
   option for announcing IPv4 Mobility Agents to DHCP Clients.

2. Terminology

2.1 Requirements Terminology

   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].

2.2 Mobile IP Terminology

   The Mobile IP related terminology used in this document is described
   in [RFC3344].

2.3 DHCP Terminology

   The DHCP related terminology used in this document is described in
   [RFC2131].

3. Mobility Agent Information Option

3.1 Mobility Agent Information Option Definition

   This document defines a new DHCP Option called the Mobility Agent
   Option.  It is a "container" option for specific agent- supplied
   sub-options.  The format of the Mobility Agent option is:



           Code     Len     Mobility Agent Information Field
         +-------+------+------+------+------+------+--...-+------+
         |  TBD  |   N  |  a1  |  a2  |  a3  |  a4  |      |  aN  |
         +-------+------+------+------+------+------+--...-+------+

   The length N gives the total number of octets in the Mobility Agent
   Field.  The Mobility Agent Information field consists of a sequence



Levkowetz                Expires August 1, 2004                 [Page 3]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


   of SubOpt/Length/Value tuples for each sub-option, encoded in the
   following manner:

















































Levkowetz                Expires August 1, 2004                 [Page 4]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


          SubOpt  Len     Sub-option Value
         +------+------+------+------+------+------+--...-+------+
         |  1   |   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |
         +------+------+------+------+------+------+--...-+------+
          SubOpt  Len     Sub-option Value
         +------+------+------+------+------+------+--...-+------+
         |  2   |   N  |  t1  |  t2  |  t3  |  t4  |      |  tN  |
         +------+------+------+------+------+------+--...-+------+

         ...

   The length N of the DHCP Mobility Agent Information Option shall
   include all bytes of the sub-option code/length/value tuples.  Since
   at least one sub-option must be included in the option, the minimum
   Mobility Agent Information length is two (2).  The length N of the
   sub-options shall be the number of octets in only that sub-option's
   value field.  A sub-option length may not be zero; if the only
   purpose of a sub-option is to signal a boolean value, a flag byte
   MUST be defined to carry that value.  The sub-options need not appear
   in any particular order.  There is no 255 (End) sub-option defined
   for this option, so the Mobility Agent Information field SHALL NOT be
   terminated with a 255 sub-option.

3.2 Network Access Identifier Sub-Option

   The Network Access Identifier (NAI) defined in [RFC2486] is already
   used in Mobile IP as an alternative to the home address as an
   identifier of a mobile node [RFC2794].

   o  The Network Access Identifier sub-option of the Mobility Agent
      Information Option MAY be used by the DHCP client to provide
      identifying information to the DHCP server, as part of the
      DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages.  The server MAY
      use this information in selecting mobility agent announcement
      parameters for the client.
   o  If the client requests the server to provide the Mobility Agent
      Option by including it in the Parameter Request List Option of a
      DHCPDISCOVER, DHCPREQUEST or DHCPINFORM message, the client also
      SHOULD include the Mobility Agent Option with the Network Access
      Identifier sub-option in the DHCPDISCOVER message.
   o  The server MAY include the Network Access Identifier sub-option
      from the client DHCPDISCOVER message in subsequent DHCPOFFER and
      DHCPACK messages if the server used this sub-option in selecting
      client parameters.
   o  The client MUST include the Network Access Identifier sub-option
      in a DHCPREQUEST message if it included it in the DHCPDISCOVER
      message.




Levkowetz                Expires August 1, 2004                 [Page 5]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


   The number of this sub-option is 1.

   The format of the Network Access Identifier sub-option is as follows:


     SubOpt   Len     Sub-option Value
    +------+-----+-----+-----+-----+-----+--...-+-----+
    |  1   |  N  |  Network Access Identifier         |
    +------+-----+-----+-----+-----+-----+--...-+-----+


3.3 Mobility Agent Announcement (Dynamic) Sub-Option

   The Mobility Agent Announcement (Dynamic) sub-option announces the
   address of one or more mobility agents, together with all the
   information about the mobility agent which is normally found in a
   Mobile IP Agent Advertisement extension to ICMP Router Advertisements
   as described in [RFC3344].

   All fields are defined so as to correspond to fields of the same name
   in a Mobility Agent Advertisement Extension as described in
   [RFC3344], and if in the future additional bits are allocated from
   the 'reserved' field for the Mobility Agent Advertisement Extension,
   they should be equally valid in a DHCP Mobility Agent option.
   However, if RFC 3344 is revised and additional fields are defined for
   the Mobility Agent Advertisement Extension, a new sub-option SHOULD
   be defined to carry such a new format Mobility Agent Announcement.

   This option may contain announcements of one Mobility Agents.  If it
   is desired to announce more than one Mobility Agent, multiple
   instances of this sub-option may occur within the Mobility Agent
   Information Option.

   The number of this sub-option is 2.


     SubOpt   Len     Sub-option Value (Announcements)
    +------+-----+-----+-----+--...-+-----+
    |  2   |  N  |  Announcement          |
    +------+-----+-----+-----+--...-+-----+

   The format of one Mobility Agent Announcement 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Mobility Agent IP Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Levkowetz                Expires August 1, 2004                 [Page 6]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


    |     Type      |  Adv-Length   |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Registration Lifetime      |R|B|H|F|M|G|r|T|   reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  zero or more care-of addresses               |
    |                              ...                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Agent IP Address
      The address through which the Mobile Node may reach the announced
      Mobility Agent in order to do a Mobile IP registration.
   Type
      16.  This is the same value as for the type field in a Mobility
      Agent Advertisement Extension as described in [RFC3344].  If other
      Mobility Agent Advertisement Extensions are defined in the future,
      this field will make it possible to differentiate between them
      without using new DHCP option numbers.
   Adv-Length
      (6 + 4*N), where 6 accounts for the number of bytes in the
      Sequence Number, Registration Lifetime, flags, and reserved
      fields, and N is the number of care-of addresses advertised for
      the Mobility Agent.
   Sequence Number
      The count of Mobility Agent DHCP announcements made since the DHCP
      server was initialised or the Mobility Agent was re-booted,
      starting at zero.  This is a total count, not a per-client count.
      If this count rolls over, it continues with the value 256
      following the value 0xffff, to be able to distinguish a roll-over
      from a Mobility Agent re-boot, (see Section 2.3.2 of [RFC3344]).
      Note that this requires the DHCP server to have knowledge of part
      of the state of the Mobility Agent; if the DHCP server does not
      have this capability, the sub-option described in Section 3.4
      should be used instead of the Mobility Agent Announcement
      (Dynamic) sub-option.
   Registration Lifetime
      The longest lifetime (measured in seconds) that this agent is
      willing to accept in any Registration Request. A value of 0xffff
      indicates infinity.
   R
      Registration required.  Registration with this foreign agent (or
      another foreign agent listed in this DHCP option) is required even
      when using a co-located care-of address.
   B
      Busy.  The foreign agent will not accept registrations from
      additional mobile nodes.
      Note that this requires the DHCP server to have knowledge of part
      of the state of the Mobility Agent; if the DHCP server does not
      have this capability, the sub-option described in Section 3.4



Levkowetz                Expires August 1, 2004                 [Page 7]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


      should be used instead of the Mobility Agent Announcement
      (Dynamic) sub-option.
   H
      Home agent.  This agent offers service as a home agent with the IP
      address given in the announcement.
   F
      Foreign agent.  This agent offers service as a foreign agent with
      the IP address given in the announcement.
   M
      Minimal encapsulation.  This agent implements receiving tunnelled
      datagrams that use minimal encapsulation [RFC2004].
   G
      GRE encapsulation.  This agent implements receiving tunnelled
      datagrams that use GRE encapsulation [RFC1701].
   r
      Sent as zero; ignored on reception.  SHOULD NOT be allocated for
      any other uses.
   T
      Foreign agent supports reverse tunnelling [RFC3024].
   reserved
      Sent as zero; ignored on reception.
   Care-of Address(es)
      The foreign agent care-of address(es) provided by this foreign
      agent.  An DHCP Mobility Agent Announcement MUST include at least
      one care-of address if the 'F' bit is set.  The number of care-of
      addresses present is determined by the Length field in the
      Extension.

3.4 Mobility Agent Announcement (Static) Sub-Option

   In the Mobility Agent Announcement (Dynamic) Sub-Option described
   above, the 'B' bit and the 'Sequence Number' field is expected to
   faithfully reflect the state of the Mobility Agent announced.  This
   requires continuous state information update between Mobility Agent
   and DHCP Server, which will normally not be available to a
   stand-alone DHCP Server.

   The Mobility Agent Announcement (Static) Sub-Option is adapted to
   this case.  In format it is identical to the Mobility Agent
   Announcement (Dynamic) Sub-Option, but it always has the 'B' bit and
   the 'Sequence Number' field set to zero.  Mobile Nodes which receive
   this sub-option should be aware of this, and in particular should be
   prepared to handle the case where a Mobility Agent is announced by
   this DHCP Option and sub-option, but is found to be busy and not able
   to handle new registrations when a registration attempt is made.

   This sub-option may contain announcements of one Mobility Agent.  If
   it is desired to announce more than one Mobility Agent, multiple



Levkowetz                Expires August 1, 2004                 [Page 8]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


   instances of this sub-option may occur within the Mobility Agent
   Information Option.

   The number of this sub-option is 3.

     SubOpt   Len     Sub-option Value (Announcements)
    +------+-----+-----+-----+--...-+-----+
    |  3   |  N  |  Announcement          |
    +------+-----+-----+-----+--...-+-----+

   For both the Static and the Dynamic Mobility Agent Announcement
   sub-option the following applies:
   o  The Mobility Agent Announcement sub-options of the Mobility Agent
      Information Option MAY be used by the DHCP server to provide
      Mobility Agent information to the DHCP client, as part of a
      DHCPOFFER or DHCPACK message.  If a Network Access Identifier
      sub-option was provided by the client, it SHOULD be used to choose
      the particular Mobility Agent or Agents to announce if the server
      has more than one Mobility Agent to offer.
   o  If the server provides the Mobility Agent Option with a Mobility
      Agent Announcement sub-option in a DHCPOFFER message, it also MUST
      include the same Mobility Agent Option and sub-options in a
      subsequent corresponding DHCPACK message.

4. Mobility Agent Option Usage

   The requesting and sending of this option follows the rules for DHCP
   options in [RFC2131].

4.1 DHCP Server - Mobility Agent Interaction

   A stand-alone DHCP server providing the Mobility Agent Announcement
   Sub-Option will normally not have any knowledge of the state of the
   mobility agent which the sub-option refers to.  This means that some
   of the information in the announcement (such as the 'B' bit in
   particular) cannot be dynamically updated.  In this case, the
   Mobility Agent Announcement (Static) Sub-Option SHOULD be used.

   A DHCP server co-located with a Mobility Agent may have more
   information about the dynamic state of the Mobility agent, and may
   therefore be able to provide reliable state information in the
   announcement.  In this case, the Mobility Agent Announcement
   (Dynamic) Sub-Option MAY be used.  Mechanisms to provide state
   information transfer between the Mobility Agent and the DHCP server
   are not in the scope of this document.






Levkowetz                Expires August 1, 2004                 [Page 9]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


4.2 Mobile Node Considerations

   A Mobile IP v4 Mobile Node may request the Mobility Agent Information
   option at it's discretion.  This may be done before, concurrently
   with, or after doing an ICMP Mobility Agent Solicitation according to
   [RFC3344], or without doing such an ICMP solicitation at all.  It is
   however expected that a common usage would be for a mobile node which
   connects to a new access node to acquire a DHCP address and solicit
   for FAs in parallel.  To differentiate between possible services, the
   Mobility Agents could be announced solely through DHCP by use of the
   Mobility Agent Information Option with one of the Mobility Agent
   Announcement sub-options, not by responding to router solicitations;
   this way the Mobility Agent and service level offered could be
   dependent on the NAI provided by the MN in the Network Access
   Identifier sub-option.

   When a Mobility Agent is announced by means of an ICMP Mobility Agent
   Advertisement according to [RFC3344], the listening Mobile Node is
   able to directly acquire the link-layer address of the Mobility Agent
   from the advertisement message.  If however the Mobility Agent is
   advertised through the DHCP Mobility Agent Information Option, the
   link-layer address will not be part of the advertisement, and it is
   necessary for the Mobile Node to issue an ARP request for the
   link-layer address corresponding to the Mobility Agent's IP address.

   Further, when a Mobility Agent is announced by means of an ICMP
   Mobility Agent Advertisement, the advertisement may also contain
   information about the available on-link routers.  When the Mobility
   Agent announcement is done through the DHCP Mobility Agent
   Information Option, the information about available routers SHOULD
   instead be provided through the DHCP Router Option.

4.3 DHCP Server Considerations

   By providing a NAI to the DHCP server (through use of the Network
   Access Identifier Sub-Option), the Mobile Node makes it possible for
   the server to match the realm of the NAI to a realm which is known to
   the server through static configuration or possibly through a AAA
   infrastructure.  The exact mechanism used is however out of scope for
   this specification.

   If the DHCP server does not have the capability to match the realm of
   the NAI provided by the Mobile Node against known realms, or if it
   finds no matching realm, it MUST fall back to the method of matching
   client to configuration parameters described in [RFC2131] (See
   especially Section 2.1 of RFC 2131).  It is for instance completely
   acceptable to select parameter values for the Mobility Agent
   Information Option Sub-Options based on the hardware address or



Levkowetz                Expires August 1, 2004                [Page 10]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


   client-identifier of the client.

   An alternative to providing the NAI to the DHCP server for use in
   selecting Mobility Agent parameters could be to use a mechanism such
   as the one described in [RADIUS-SUBOPT] to provide Mobility Agent
   information obtained through AAA authentication to the DHCP server
   for subsequent delivery to a client using the Mobility Agent
   Information Option.

5. Security Considerations

   Mobile IP Agent Advertisements as described in [RFC3344] requires no
   authentication for Agent Advertisement and Agent Solicitation
   messages.

   DHCP provides an authentication mechanism, as described in [RFC3118],
   which may be used if authentication is required before offering the
   Mobility Agent option described here.  Because it may be cumbersome
   or practically impossible to distribute keys to foreign networks a
   Mobile Node may visit, the ability to use the DHCP authentication
   mechanism is not viewed as a major advantage of distributing Mobility
   Agent Announcements through DHCP rather than through regular ICMP
   Mobile IP Agent Advertisements.

   By providing Agent Advertisements by means of DHCP as an alternative
   to extended ICMP Router Advertisement messages it is possible to do
   so more selectively, and it does not offer any new threat to the
   internet.

6. IANA Considerations

   This document defines one new DHCP v4 option value, and one new
   sub-type numbering space to be managed by IANA.

   Section 3.1 defines a new DHCP v4 option value, the Mobility Agent
   Information Option.  The type number for this option is [TBD,
   assigned by IANA].  This option introduces a new sub-type numbering
   space where the values 1, 2 and 3 has been assigned values in this
   document.  Approval of new Mobility Agent Information Option sub-type
   numbers is subject to Expert Review, and a specification is required
   [RFC2434].

   The value for the DHCP_MIP_OPTION code must be assigned from the
   numbering space defined for public DHCP Options in [RFC2939].

7. Acknowledgements

Normative References



Levkowetz                Expires August 1, 2004                [Page 11]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

Informative References

   [RFC1701]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701, October 1994.

   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
              October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2794]  Calhoun, P. and C. Perkins, "Mobile IP Network Access
              Identifier Extension for IPv4", RFC 2794, March 2000.

   [RFC2939]  Droms, R., "Procedures and IANA Guidelines for Definition
              of New DHCP Options and Message Types", BCP 43, RFC 2939,
              September 2000.

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RADIUS-SUBOPT]
              Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option
              for the DHCP Relay Agent Information Option",
              draft-ietf-dhc-agentopt-radius-03 (work in progress),
              November 2003.






Levkowetz                Expires August 1, 2004                [Page 12]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


Author's Address

   Henrik Levkowetz
   ipUnplugged AB
   Arenavagen 33
   Stockholm  S-121 28
   SWEDEN

   Phone: +46 8 725 9513
   EMail: henrik@levkowetz.com

Appendix A. Open issues

   (This section should be removed by the RFC editor before publication)

   Discussion about this draft should be sent to dhcwg@ietf.org.

   Open issues relating to this specification are tracked on the
   following web site: http://www.mip4.org/issues/tracker/mip4/

   The current working documents for this draft are available at this
   web site: http://ietf.levkowetz.com/drafts/dhc/mipadvert/





























Levkowetz                Expires August 1, 2004                [Page 13]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


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.

   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 (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Levkowetz                Expires August 1, 2004                [Page 14]


Internet-Draft      DHCP Option for Mobility Agents             Feb 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Levkowetz                Expires August 1, 2004                [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/