diff options
Diffstat (limited to 'doc/rfc/rfc4332.txt')
-rw-r--r-- | doc/rfc/rfc4332.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4332.txt b/doc/rfc/rfc4332.txt new file mode 100644 index 0000000..c6a83d8 --- /dev/null +++ b/doc/rfc/rfc4332.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group K. Leung +Request for Comments: 4332 A. Patel +Category: Informational Cisco Systems + G. Tsirtsis + Flarion Technologies + E. Klovning + Birdstep Technology ASA + December 2005 + + + Cisco's Mobile IPv4 Host Configuration Extensions + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. The + IETF disclaims any knowledge of the fitness of this RFC for any + purpose and in particular notes that the decision to publish is not + based on IETF review for such things as security, congestion control, + or inappropriate interaction with deployed protocols. The RFC Editor + has chosen to publish this document at its discretion. Readers of + this document should exercise caution in evaluating its value for + implementation and deployment. See RFC 3932 for more information. + + This RFC does not offer any security mechanisms to provide data + origin authentication and integrity, yet these security services are + vitally important in this context. + +Abstract + + An IP device requires basic host configuration to be able to + communicate. For example, it will typically require an IP address + and the address of a DNS server. This information is configured + statically or obtained dynamically using Dynamic Host Configuration + Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol + (PPP/IPCP). However, both DHCP and PPP/IPCP provide host + configuration based on the access network. In Mobile IPv4, the + registration process boots up a Mobile Node at an access network, + also known as a foreign network. The information to configure the + + + +Leung, et al. Informational [Page 1] + +RFC 4332 Host Config December 2005 + + + host needs to be based on the home network. This document describes + the Cisco vendor-specific extensions to Mobile IPv4 to provide the + base host configuration in Registration Request and Reply messages. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Host Configuration Extensions Summary ...........................3 + 3. Host Configuration Extensions ...................................4 + 3.1. Host Configuration Request Extension .......................5 + 3.2. Home Network Length Prefix Extension .......................5 + 3.3. DNS Server Extension .......................................6 + 3.4. DHCP Server Extension ......................................6 + 3.5. DHCP Client ID Extension ...................................7 + 3.6. Default Gateway Extension ..................................7 + 3.7. DNS Suffix Extension .......................................8 + 3.8. Configuration URL Extension ................................8 + 4. Security Considerations .........................................9 + 5. Acknowledgements ................................................9 + 6. Informative References ..........................................9 + +1. Introduction + + An IPv4 device requires some basic configuration to communicate with + other nodes. Typically, it has an IP address for an interface and + DNS server's IP address to resolve the peer's hostname to an IP + address. DHCP [RFC2131] and PPP/IPCP [RFC1332] provide host + configuration information on the access network interface, but this + is inadequate in a Mobile IPv4 environment. In Mobile IPv4 + [RFC3344], a Mobile Node has a virtual network interface on the home + network, anchored by the Home Agent. The IP address, home subnet + prefix, default gateway, and home network's DNS servers are essential + in the boot up of a network interface. In some cases, these are the + only pieces of information needed by the Mobile Node. + + The Mobile IPv4 registration process provides the mechanism for a + Mobile Node to boot up on a foreign network. Upon the successful + registration, the Mobile Node can communicate with the Correspondent + Node. The need to provide an efficient method to obtain the host + configuration exists. If the Mobile Node is a DHCP client, it can + obtain configuration parameters from the DHCP server in the home + network after the initial registration. + + This document introduces the Cisco vendor-specific extensions (VSEs) + [RFC3115] to provide the means for a Mobile Node to download some + fundamental configuration associated with the home network via the + + + + + +Leung, et al. Informational [Page 2] + +RFC 4332 Host Config December 2005 + + + Home Agent. These extensions provide information for home subnet + prefix, DNS server, DHCP server, DHCP client identifier, default + gateway, DNS suffix, and configuration URL. + +2. Host Configuration Extensions Summary + + The following Cisco vendor-specific extensions provide the host + configuration for a Mobile Node. The "Host Configuration Request" + extension is allowed only in the Registration Request. The rest of + the extensions are appended in the Registration Reply. + + o Host Configuration Request + + * Request for host configuration information from the Mobile Node + to the Home Agent. + + o Home Network Prefix Length + + * The length of the subnet prefix on the home network. + + o Default Gateway + + * The default gateway's IP address on the home network. + + o DNS Server + + * The DNS server's IP address in the home network. + + o DNS Suffix + + * The DNS suffix for hostname resolution in the home network. + + o DHCP Client ID + + * The DHCP Client ID used to obtain the IP address. When the + Mobile Node returns home and is responsible for managing its + own address, this information maps to the client identifier + option as defined in section 9.14 of [RFC2132] and referenced + in [RFC2131]. + + o DHCP Server + + * The DHCP server's IP address in the home network. + + o Configuration URL + + * The URL for the Mobile Node to download configuration + parameters from a server. + + + +Leung, et al. Informational [Page 3] + +RFC 4332 Host Config December 2005 + + + When the Mobile Node needs to obtain its host configuration, the Host + Configuration Request VSE is appended to the Registration Request. + This VSE indicates to the Home Agent that either all or selected host + configuration VSEs need to be appended to the Registration Reply. If + the Home Agent retrieved the information from a DHCP server (in Proxy + DHCP mode), then the DHCP Client ID and DHCP Server extensions are + appended in the Registration Reply. These DHCP-related extensions + are populated with values that had been used in the DHCP messages + exchanged between the Home Agent and the DHCP server. + + The VSEs are authenticated as part of the registration message using + any of the authentication mechanism defined for Mobile IP ([RFC3344], + [RFC3012]). + + This message MAY contain extensions defined in Mobile IP, including + vendor-specific extensions [RFC3115]. + +3. Host Configuration Extensions + + Cisco's host configuration extensions to Mobile IPv4 are based on the + vendor-specific extensions defined in [RFC3115]. The format of the + VSE TLV (Type-Length-Value) 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor/Org-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-NVSE-Type | Vendor-NVSE-Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: 134 + + Length: + + Indicates the length (in bytes) of the data field within this + extension, excluding the Type and Length fields. + + Reserved: + + Reserved for future use. To be set to 0 while sending, ignored + on reception. + + Vendor/Org-ID: + + 9 (Cisco Systems) + + + +Leung, et al. Informational [Page 4] + +RFC 4332 Host Config December 2005 + + + Vendor-NVSE-Type: + + 14 (Host Configuration) + + Vendor-NVSE-Value: + + Format is shown below for each subtype. The Sub-Type field is + an integer from 0 to 255. + +3.1. Host Configuration Request Extension + + This format of the Host Configuration Request extension is shown + below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | Selector | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 0 + + Selector: + + 0 indicates all host configuration available to the Home + Agent (HA) is requested by the Mobile Node. + +3.2. Home Network Length Prefix Extension + + This format of the Home Network Prefix Length extension is shown + below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | Prefix Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 1 + + Prefix Length: + + The number of bits in the home subnet prefix. + + + + +Leung, et al. Informational [Page 5] + +RFC 4332 Host Config December 2005 + + +3.3. DNS Server Extension + + This format of the DNS Server extension is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | Primary DNS Server + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . | Secondary DNS Server + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 2 + + Primary DNS Server: + + The IP address of the primary DNS server. + + Secondary DNS Server: + + The IP address of the secondary DNS server. + +3.4. DHCP Server Extension + + This format of the DHCP Server extension is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | DHCP Server + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 3 + + DHCP Server: + + The IP address of the DHCP server. + + + + + + +Leung, et al. Informational [Page 6] + +RFC 4332 Host Config December 2005 + + +3.5. DHCP Client ID Extension + + This format of the DHCP Client ID extension is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | Client ID . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 4 + + Client ID: + + DHCP servers use this value to index their database of address + bindings. This value is expected to be unique for all clients + in an administrative domain. The size of field is between 2 + and 255 octets. + +3.6. Default Gateway Extension + + This format of the Default Gateway extension is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | Default Gateway + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 5 + + Default Gateway: + + The IP address of the default gateway for the Mobile Node on + the home network. + + + + + + + + + + +Leung, et al. Informational [Page 7] + +RFC 4332 Host Config December 2005 + + +3.7. DNS Suffix Extension + + This format of the DNS Suffix extension is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | DNS Suffix . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 6 + + DNS Suffix: + + The DNS suffix to be appended to the name of Mobile Node when + completing its fully qualified domain name (FQDN). The size of + field is between 1 and 246 octets. + +3.8. Configuration URL Extension + + This format of the Configuration URL extension is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Type | URL String . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sub-Type: + + 7 + + URL String: + + The Mobile Node can retrieve configuration parameters via the + URL. The URL is at most 246 bytes in length. + + + + + + + + + + + + + +Leung, et al. Informational [Page 8] + +RFC 4332 Host Config December 2005 + + +4. Security Considerations + + The host configuration extensions follow the same rules for Mobile IP + extensions in registration messages. See the Security Considerations + section in RFC 3344. + + The Configuration URL extension may trigger the Mobile Node to + download the configuration parameters from a server. The protection + of the data transfer is outside the scope of this document. Possible + options include encryption of data before transfer or using HTTPS. + +5. Acknowledgements + + The authors would like to acknowledge Jayshree Bharatia, Kuntal + Chowdhury, Avi Lior, and Lila Madour for their contributions to the + work in progress titled "Mobile IPv4 Extension for Configuration + Options Exchange". + +6. Informative References + + [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [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. + + [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ + Response Extensions", RFC 3012, November 2000. + + [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ + Organization-Specific Extensions", RFC 3115, April 2001. + + [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, + August 2002. + + + + + + + + + + + + + + +Leung, et al. Informational [Page 9] + +RFC 4332 Host Config December 2005 + + +Authors' Addresses + + Kent Leung + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + US + + Phone: +1 408-526-5030 + EMail: kleung@cisco.com + + + Alpesh Patel + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + US + + Phone: +1 408-853-9580 + EMail: alpesh@cisco.com + + + George Tsirtsis + Flarion Technologies + Bedminster One + 135 Route 202/206 South + Bedminster, NJ 07921 + US + + Phone: +1 908-947-7059 + EMail: g.tsirtsis@flarion.com + + + Espen Klovning + Birdstep Technology ASA + Bryggegata 7 + Oslo, 0250 + Norway + + Phone: +47 95 20 26 29 + EMail: espen@birdstep.com + + + + + + + + + + +Leung, et al. Informational [Page 10] + +RFC 4332 Host Config December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Leung, et al. Informational [Page 11] + |