DHC Working Group H. Levkowetz Internet-Draft ipUnplugged Expires: August 1, 2004 Feb 2004 DHCP Option for Mobile IP Mobility Agents 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]