idnits 2.17.1 draft-ietf-mip4-gen-ext-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 346. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jul 07, 2007) is 6135 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 J. Bharatia 3 Internet-Draft Nortel Networks 4 Intended status: Standards Track K. Chowdhury 5 Expires: January 8, 2008 Starent Networks 6 A. Lior 7 Bridgewater Systems 8 K. Leung 9 Cisco Systems 10 Jul 07, 2007 12 Mobile IPv4 Extension for Configuration Options Exchange 13 draft-ietf-mip4-gen-ext-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 8, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes the mechanism for providing the host 47 configuration information during Mobile IP registration. One or more 48 Configuration Options Exchange Extensions may be included in the 49 registration message to provide the Mobile Node the configuration 50 parameters needed for network service (e.g. DNS). 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Glossary of Terms . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Conventions used in this document . . . . . . . . . . . . 3 57 2. Configuration Options Exchange Extension . . . . . . . . . . . 4 58 3. Processing of Configuration Options Exchange Extension . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 62 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . . . 13 66 1. Introduction 68 Mobile IPv4 lacks the capability to dynamically configure the 69 interface parameters (e.g. home subnet mask) and network service 70 elements (e.g. DNS servers) on the Mobile Node. This information 71 are required to be manually configured today. There are mechanisms 72 such as DHCP for the mobile node to configure information from the 73 foreign network, but not from the home network when the mobile node 74 is not attached to the home network. 76 This document defines a new extension that can be used to carry 77 configuration parameters from the Foreign Agent and/or Home Agent 78 during Mobile IPv4 registration. This configuration parameters 79 include DHCP option (Parameter Request List) defined in [RFC2132]. 81 1.1. Glossary of Terms 83 DNS - Domain Name System [RFC1035] 85 DHCP - Dynamic Host Configuration Protocol [RFC2131] 87 1.2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Configuration Options Exchange Extension 95 The Mobile IPv4 extension has the format shown in this section to 96 carry configuration information. This extension MAY be included as a 97 part of Mobile IP Registration Request or Registration Reply. 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Type | Length | Entity-Type | Sub-Type | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Config-Data 105 +-+-+-+-+-+-... 107 Figure 1: Configuration Options Exchange Extension 109 Type 111 Configuration Options Exchange Extension 113 Length 115 Indicates the length (in bytes) of the data field within this 116 Extension. The length does NOT include the Type and Length 117 bytes. This field MUST be set to 2 plus the total length of 118 the Config-Data field. 120 Entity-Type 122 This field indicates which Mobility Agent is requested to 123 provide configuration information when the extension is present 124 in a Registration Request and which Mobility Agent inserted the 125 extension in a Registration Reply. The Home Agent or Foreign 126 Agent may include the extension in the Registration Reply, 127 whereas the Mobile Node may append the extension in the 128 Registration Request to ask the Home Agent and/or Foreign Agent 129 for configuration information. Currently the following types 130 are defined: 132 0: Reserved. 134 1: Home Agent. 136 2: Foreign Agent. 138 Sub-Type 140 At this time the following values are defined: 142 0: Reserved. 144 1: DHCP Options. 146 All other values reserved for future use. 148 Config-Data 150 The configuration parameters are packed in DHCP-based formats 151 in the Config-Data field. Since the size of the Config-Data 152 field is limited to 253 bytes, the Mobility Agent needs to add 153 multiple extensions with this subtype when the configuration 154 information exceeds the boundary. The DHCP option must be 155 contained within one extension and never split up across 156 multiple extensions. 158 3. Processing of Configuration Options Exchange Extension 160 The Mobile Node may request values for specific configuration 161 parameters from the Home Agent and/or Foreign Agent by including the 162 'Parameter Request List' option (defined in [RFC2132]) in the 163 Registration Request. The list of requested parameters is specified 164 as a string of octets, where each octet is a valid DHCP option code 165 as defined in [RFC2132]. If this extension is included in the 166 Registration Request, the Home Agent or Foreign Agent (indicated in 167 the Entity-Type field) should provide requested information in the 168 Registration Reply. The Configuration Options Exchange extension 169 should be repeated in the Registration Request for parameter(s) 170 request based on the Entity-Type. If there are no Configuration 171 Options Exchange Extension in the Registration Request, it's up to 172 the Home Agent or Foreign Agent to decide which configuration 173 parameter to include in the Configuration Options Exchange extension. 174 The configuration parameter(s) should not be overwritten by the 175 Foreign Agent if the Home Agent has included them in the 176 Configuration Options Exchange extension. The Entity-Type field is 177 set to the Mobility Agent that appended the extension in the 178 Registration Reply. 180 When a Mobile IP entity (i.e. Mobile Node, Mobility Agent) adds a 181 Configuration Options Exchange Extension to a Registration Request or 182 Registration Reply message, this extension MUST appear prior to any 183 authentication extensions added by that entity. 185 Example: 187 Mobile Node wants to obtain the home network prefix mask and DNS 188 servers' IP addresses from its Home Agent during registration. The 189 Registration Request would contain the following values in the 190 Configuration Options Exchange Extension. The OpCode is set to 191 Parameter Request List (55) used to obtain the Subnet Mask (1) and 192 Domain Name Server (6); see [RFC2132]. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | =6 | =1 | =1 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | =55 | =2 | =1 | =6 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: Requested Configuration Parameters 204 Home Agent sends a Registration Reply that contains the following 205 values in the Configuration Options Exchange Extension. The Subnet 206 Mask (1) and Domain Name Server (6) options are embedded in the 207 extension. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | =18 | =1 | =0 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | =1 | =4 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 ... | =6 | =8 | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 3: Configuration Values in Response 225 4. IANA Considerations 227 This draft defines new Mobile IPv4 extension, the Configuration 228 Options Exchange Extension, as defined in Section 2 of this document. 229 This value MUST be assigned by IANA from the Mobile IP numbering 230 space for skippable extensions. 232 A new number space is to be created for enumerating Sub-Type of the 233 Configuration Options Exchange Extension defined in Section 2. For 234 Sub-Type, IANA should assign value 0 as Reserved and value 1 for the 235 DHCP Options. New values of Sub-Type of the Configuration Options 236 Exchange Extension, other than values 0-1 must be approved by 237 Designated Expert. 239 A new number space is to be created for enumerating Entity-Type of 240 the Configuration Options Exchange Extension defined in Section 2. 241 For Entity-Type, IANA should assign value 0 as Reserved, value 1 for 242 the Home Agent and value 2 for the Foreign Agent. New values of 243 Entity-Type of the Configuration Options Exchange Extension, other 244 than values 0-2 must be approved by Designated Expert. 246 5. Security Considerations 248 There is no confidentiality provided for this extension. The 249 information carried in the Configuration Options Exchange Extension 250 is from the Home Agent and/or Foreign Agent and is transferred 251 unencrypted. If sensitive information is sent for host configuration 252 purposes, it may need to be protected by other means outside the 253 scope of this document. 255 6. Acknowledgments 257 Authors like to thank Curtis Provost, Tom Hiller, and Vijay 258 Devarapalli for their valuable input to this document. 260 7. Normative References 262 [RFC1035] Mockapetris, P., "Domain names - implementation and 263 specification", STD 13, RFC 1035, November 1987. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 269 RFC 2131, March 1997. 271 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 272 Extensions", RFC 2132, March 1997. 274 Authors' Addresses 276 Jayshree Bharatia 277 Nortel Networks 278 2221, Lakeside Blvd 279 Richardson, TX 75082 281 Phone: +1 972-684-5767 282 Email: jayshree@nortel.com 284 Kuntal Chowdhury 285 Starent Networks 286 30 International Place 287 Tewksbury, MA 01876 289 Phone: +1 214-550-1416 290 Email: kchowdhury@starentnetworks.com 292 Avi Lior 293 Bridgewater Systems 294 303 Terry Fox Drive, Suite 100 295 Ottawa, Ontario, Canada K2K 3J1 297 Phone: +1 613-591-6655 298 Email: avi@bridgewatersystems.com 300 Kent Leung 301 Cisco Systems 302 170 West Tasman Drive 303 San Jose, CA 95134 305 Phone: +1 408-526-5030 306 Email: kleung@cisco.com 308 Full Copyright Statement 310 Copyright (C) The IETF Trust (2007). 312 This document is subject to the rights, licenses and restrictions 313 contained in BCP 78, and except as set forth therein, the authors 314 retain all their rights. 316 This document and the information contained herein are provided on an 317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 319 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 320 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 321 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 Intellectual Property 326 The IETF takes no position regarding the validity or scope of any 327 Intellectual Property Rights or other rights that might be claimed to 328 pertain to the implementation or use of the technology described in 329 this document or the extent to which any license under such rights 330 might or might not be available; nor does it represent that it has 331 made any independent effort to identify any such rights. Information 332 on the procedures with respect to rights in RFC documents can be 333 found in BCP 78 and BCP 79. 335 Copies of IPR disclosures made to the IETF Secretariat and any 336 assurances of licenses to be made available, or the result of an 337 attempt made to obtain a general license or permission for the use of 338 such proprietary rights by implementers or users of this 339 specification can be obtained from the IETF on-line IPR repository at 340 http://www.ietf.org/ipr. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights that may cover technology that may be required to implement 345 this standard. Please address the information to the IETF at 346 ietf-ipr@ietf.org. 348 Acknowledgment 350 Funding for the RFC Editor function is provided by the IETF 351 Administrative Support Activity (IASA).