idnits 2.17.1 draft-ietf-dhc-mipadvert-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 24, 2002) is 7854 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) ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3220 (ref. '5') (Obsoleted by RFC 3344) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Levkowetz 3 Internet-Draft ipUnplugged 4 Expires: April 24, 2003 October 24, 2002 6 DHCP Option for Mobile IP Mobility Agents 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 24, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document defines a new Dynamic Host Configuration Protocol 39 (DHCP) option with suboptions. One suboption is passed from the DHCP 40 Server to the DHCP Client to announce the presence of one or more 41 Mobile IP Mobility Agents. For each announced Mobility Agent, 42 information is provided which is the same as that of the Mobile IP 43 Agent Advertisement extension to ICMP Router Advertisements. There 44 is also one suboption which may be used by a DHCP client to provide 45 identity information to the DHCP server. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3 53 3. Mobility Agent Information Option . . . . . . . . . . . . . . 3 54 3.1 Mobility Agent Information Option Definition . . . . . . . . . 3 55 3.2 Network Access Identifier Sub-Option . . . . . . . . . . . . . 4 56 3.3 Mobility Agent Announcement Sub-Option . . . . . . . . . . . . 4 58 4. Mobility Agent Option Usage . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 Normative References . . . . . . . . . . . . . . . . . . . . . 7 66 Informative References . . . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 There already exists a DHCP option to announce Mobile IP Home Agent 73 addresses, described in RFC 2132 [2]. There is, however, no option 74 available to announce Mobile IP Foreign Agents. 76 Announcement of available Mobile IP Mobility Agents by means of DHCP 77 provides possibilities for selective and individual assignment of 78 Mobility Agents to Mobile Nodes. This in turn makes load-sharing and 79 selective service offerings easier. This draft describes a DHCP 80 option for announcing Mobility Agents to DHCP Clients. 82 2. Requirements terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [8]. 88 The Mobile IP related terminology used in this document is described 89 in RFC 3220 [5]. 91 3. Mobility Agent Information Option 93 3.1 Mobility Agent Information Option Definition 95 This document defines a new DHCP Option called the Mobility Agent 96 Option. It is a "container" option for specific agent- supplied sub- 97 options. The format of the Mobility Agent option is: 99 Code Len Mobility Agent Information Field 100 +-------+------+------+------+------+------+--...-+------+ 101 | TBD | N | a1 | a2 | a3 | a4 | | aN | 102 +-------+------+------+------+------+------+--...-+------+ 104 The length N gives the total number of octets in the Mobility Agent 105 Field. The Mobility Agent Information field consists of a sequence 106 of SubOpt/Length/Value tuples for each sub-option, encoded in the 107 following manner: 109 SubOpt Len Sub-option Value 110 +------+------+------+------+------+------+--...-+------+ 111 | 1 | N | s1 | s2 | s3 | s4 | | sN | 112 +------+------+------+------+------+------+--...-+------+ 113 SubOpt Len Sub-option Value 114 +------+------+------+------+------+------+--...-+------+ 115 | 2 | N | t1 | t2 | t3 | t4 | | tN | 116 +------+------+------+------+------+------+--...-+------+ 118 The Mobility Agent Information field shall NOT be terminated with a 119 255 sub-option. The length N of the DHCP Mobility Agent Information 120 Option shall include all bytes of the sub-option code/length/value 121 tuples. Since at least one sub-option must be defined, the minimum 122 Mobility Agent Information length is two (2). The length N of the 123 sub-options shall be the number of octets in only that sub-option's 124 value field. A sub-option length may be zero. The sub-options need 125 not appear in sub-option code order. 127 3.2 Network Access Identifier Sub-Option 129 The Network Access Identifier (NAI) defined in RFC 2486 [3] is 130 already used in Mobile IP as an alternative to the home address as an 131 identifier of a mobile node [9]. 133 The Network Access Identifier sub-option of the Mobility Agent 134 Information Option MAY be used by the DHCP client to provide 135 identifying information to the DHCP server, as part of the 136 DHCPDISCOVER message. The server may then use this information in 137 selecting mobility agent announcement parameters for the client. 139 The format of the Network Access Identifier sub-option is as follows: 141 SubOpt Len Sub-option Value 142 +------+-----+-----+-----+-----+-----+--...-+-----+ 143 | 1 | N | Network Access Identifier | 144 +------+-----+-----+-----+-----+-----+--...-+-----+ 146 3.3 Mobility Agent Announcement Sub-Option 148 The Mobility Agent Announcement sub-option announces the address of 149 one or more mobility agents, together with all the information about 150 the mobility agent which is normally found in a Mobile IP Agent 151 Advertisement extension to ICMP Router Advertisements as described in 152 RFC 3220 [5]. 154 All fields are defined so as to correspond to fields of the same name 155 in a Mobility Agent Advertisement Extension as described in RFC 3220 156 [5], and if in the future additional bits are allocated from the 157 'reserved' field for the Mobility Agent Advertisement Extension, they 158 should be equally valid in a DHCP Mobility Agent option. 160 This option may contain announcements of one or more Mobility Agents, 161 in sequence. The length of each individual Mobility Agent 162 Announcement is determined from the Adv-Length field of the 163 announcement. 165 SubOpt Len Sub-option Value (Announcements) 166 +------+-----+-----+-----+--...-+-----+-----+-----+--...-+-----+... 167 | 2 | N | Announcement 1 | Announcement 2 | 168 +------+-----+-----+-----+--...-+-----+-----+-----+--...-+-----+... 170 The format of one Mobility Agent Announcement is as follows: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Mobility Agent IP Address | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type | Adv-Length | Sequence Number | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | zero or more care-of addresses | 182 | ... | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Option code 186 DHCP_MIP_OPTION (to be assigned by IANA) 188 Length 189 Length in bytes of this option, not including the Option code 190 and Length bytes. 192 Agent IP Address 193 The address trough which the Mobile Node may reach the 194 announced Mobility Agent in order to do a Mobile IP 195 registration. 197 Type 198 16. This is the same value as for the type field in a Mobility 199 Agent Advertisement Extension as described in RFC 3220 [5]. If 200 other Mobility Agent Advertisement Extensions are defined in 201 the future, this field will make it possible to differentiate 202 between them without using new DHCP option numbers. 204 Reserved-0 205 Sent as zero; required to be zero on reception for the option 206 described in this document. 208 Adv-Length 209 (6 + 4*N), where 6 accounts for the number of bytes in the 210 Sequence Number, Registration Lifetime, flags, and reserved 211 fields, and N is the number of care-of addresses advertised for 212 the Mobility Agent. 214 Sequence Number 215 The count of Mobility Agent DHCP announcements made since the 216 DHCP server was initialized (RFC 3220, Section 2.3.2 [5]). 218 Registration Lifetime 219 The longest lifetime (measured in seconds) that this agent is 220 willing to accept in any Registration Request. A value of 221 0xffff indicates infinity. 223 R 224 Registration required. Registration with this foreign agent 225 (or another foreign agent listed in this DHCP option) is 226 required even when using a co-located care-of address. 228 B 229 Busy. The foreign agent will not accept registrations from 230 additional mobile nodes. 232 H 233 Home agent. This agent offers service as a home agent on the 234 link on which this mobility agent announcement is sent. 236 F 237 Foreign agent. This agent offers service as a foreign agent on 238 the link on which this mobility agent announcement is sent. 240 M 241 Minimal encapsulation. This agent implements receiving 242 tunneled datagrams that use minimal encapsulation [7]. 244 G 245 GRE encapsulation. This agent implements receiving tunneled 246 datagrams that use GRE encapsulation [6]. 248 r 249 Sent as zero; ignored on reception. SHOULD NOT be allocated 250 for any other uses. 252 T 253 Foreign agent supports reverse tunneling [11]. 255 reserved 256 Sent as zero; ignored on reception. 258 Care-of Address(es) 259 The foreign agent care-of address(es) provided by this foreign 260 agent. An DHCP Mobility Agent Announcement MUST include at 261 least one care-of address if the 'F' bit is set. The number of 262 care-of addresses present is determined by the Length field in 263 the Extension. 265 4. Mobility Agent Option Usage 267 The requesting and sending of this option follows the rules for DHCP 268 options in RFC 2131 [1] 270 5. Security Considerations 272 DHCP provides an authentication mechanism, as described in RFC 3118 273 [4], which may be used if authentication is required before offering 274 the Mobility Agent option described here. On the other hand, Mobile 275 IP Agent Advertisements as described in RFC 3220 [5] requires no 276 authentication for Agent Advertisement and Agent Solicitation 277 messages. 279 By providing Agent Advertisements by means of DHCP as an alternative 280 to extended ICMP Router Advertisement messages it is possible to do 281 so more selectively, and it does not offer any new threat to the 282 internet. 284 6. IANA Considerations 286 The value for the DHCP_MIP_OPTION code must be assigned from the 287 numbering space defined for public DHCP Options in RFC 2939 [10]. 289 7. Acknowledgements 291 Normative References 293 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 294 March 1997. 296 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 297 Extensions", RFC 2132, March 1997. 299 [3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 300 2486, January 1999. 302 [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 303 RFC 3118, June 2001. 305 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 306 2002. 308 Informative References 310 [6] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 311 Routing Encapsulation (GRE)", RFC 1701, October 1994. 313 [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 314 October 1996. 316 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 317 Levels", BCP 14, RFC 2119, March 1997. 319 [9] Calhoun, P. and C. Perkins, "Mobile IP Network Access 320 Identifier Extension for IPv4", RFC 2794, March 2000. 322 [10] Droms, R., "Procedures and IANA Guidelines for Definition of 323 New DHCP Options and Message Types", BCP 43, RFC 2939, 324 September 2000. 326 [11] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 327 3024, January 2001. 329 Author's Address 331 Henrik Levkowetz 332 ipUnplugged AB 333 Arenavagen 33 334 Stockholm S-121 28 335 SWEDEN 337 Phone: +46 8 725 9513 338 EMail: henrik@levkowetz.com 340 Full Copyright Statement 342 Copyright (C) The Internet Society (2002). All Rights Reserved. 344 This document and translations of it may be copied and furnished to 345 others, and derivative works that comment on or otherwise explain it 346 or assist in its implementation may be prepared, copied, published 347 and distributed, in whole or in part, without restriction of any 348 kind, provided that the above copyright notice and this paragraph are 349 included on all such copies and derivative works. However, this 350 document itself may not be modified in any way, such as by removing 351 the copyright notice or references to the Internet Society or other 352 Internet organizations, except as needed for the purpose of 353 developing Internet standards in which case the procedures for 354 copyrights defined in the Internet Standards process must be 355 followed, or as required to translate it into languages other than 356 English. 358 The limited permissions granted above are perpetual and will not be 359 revoked by the Internet Society or its successors or assigns. 361 This document and the information contained herein is provided on an 362 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 363 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 364 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 365 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 366 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Acknowledgement 370 Funding for the RFC Editor function is currently provided by the 371 Internet Society.