summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4332.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4332.txt')
-rw-r--r--doc/rfc/rfc4332.txt619
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]
+