idnits 2.17.1 draft-levkowetz-dhc-mip-fa-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 27, 2002) is 7946 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: 3 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: December 26, 2002 June 27, 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 December 26, 2002. 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 sub-options. One sub-option may be used by a DHCP 40 client to provide mobile IP related identity information to the DHCP 41 server. Another sub-option may be passed from the DHCP Server to the 42 DHCP Client to announce the presence of one or more mobile IP 43 Mobility Agents. For each announced Mobility Agent, information is 44 provided which is the same as that of the classical Mobile IP Agent 45 Advertisement extension to ICMP Router Advertisements. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements terminology . . . . . . . . . . . . . . . . . . . 3 53 3. Mobility Agent Information Option . . . . . . . . . . . . . . 3 54 3.1 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 63 Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Informative References . . . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 There exists a DHCP option to announce mobile IP home agent 71 addresses, described in RFC 2132 [2]. There is however no option 72 available to announce Mobile IP Foreign Agents. Furthermore, the 73 existing home agent option provides home agent addresses, but no 74 other pertinent information about the home agent. 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 Agent information. 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 Option Definition 95 This document defines a new DHCP Option called the Mobility Agent 96 Information Option. It is a "container" option for specific agent- 97 supplied sub-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 option code TDB indicates that this is a Mobility Agent 105 Information option. The length N gives the total number of octets in 106 the Mobility Agent Information Field. The Mobility Agent Information 107 field consists of a sequence of SubOpt/Length/Value tuples for each 108 sub-option, encoded in the following manner: 110 SubOpt Len Sub-option Value 111 +------+------+------+------+------+------+--...-+------+ 112 | n | N | s1 | s2 | s3 | s4 | | sN | 113 +------+------+------+------+------+------+--...-+------+ 114 SubOpt Len Sub-option Value 115 +------+------+------+------+------+------+--...-+------+ 116 | m | N | t1 | t2 | t3 | t4 | | tN | 117 +------+------+------+------+------+------+--...-+------+ 119 The Mobility Agent Information field shall NOT be terminated with a 120 255 sub-option. The length N of the DHCP Mobility Agent Information 121 Option shall include all bytes of the sub-option code/length/value 122 tuples. Since at least one sub-option must be defined, the minimum 123 Mobility Agent Information length is two (2). The length N of the 124 sub-options shall be the number of octets in only that sub-option's 125 value field. A sub-option length may be zero. The sub-options need 126 not appear in sub-option code order. 128 3.2 Network Access Identifier Sub-Option 130 The Network Access Identifier (NAI) defined in RFC 2486 [3] is 131 already used in Mobile IP as an alternative to the home address as an 132 identifier of a mobile node [9]. 134 The Network Access Identifier sub-option of the Mobility Agent 135 Information Option MAY be used by the DHCP client to provide 136 identifying information to the DHCP server, as part of the 137 DHCPDISCOVER message. The server may then use this information in 138 selecting mobility agent announcement parameters for the client. 140 The format of the Network Access Identifier sub-option is as follows: 142 SubOpt Len Sub-option Value 143 +------+-----+-----+-----+-----+-----+--...-+-----+ 144 | 1 | N | Network Access Identifier | 145 +------+-----+-----+-----+-----+-----+--...-+-----+ 147 The Network Access Identifier SHALL NOT contain a terminating zero 148 octet. 150 3.3 Mobility Agent Announcement Sub-Option 152 The Mobility Agent Announcement sub-option announces the address of 153 one or more mobility agents, together with all the information about 154 the mobility agent which is normally found in a Mobile IP Agent 155 Advertisement extension to ICMP Router Advertisements as described in 156 RFC 3220 [5]. 158 All fields are defined so as to correspond to fields of the same name 159 in a Mobility Agent Advertisement Extension as described in RFC 3220 160 [5], and if in the future additional bits are allocated from the 161 'reserved' field for the Mobility Agent Advertisement Extension, they 162 should be equally valid in a DHCP Mobility Agent option. 164 This option may contain announcements of one or more Mobility Agents, 165 in sequence. The length of each individual Mobility Agent 166 Announcement is determined from the Adv-Length field of the 167 announcement. 169 SubOpt Len Sub-option Values (Announcements) 170 +------+-----+-----+-----+--...-+-----+-----+-----+--...-+-----+... 171 | 2 | N | Announcement 1 | Announcement 2 | 172 +------+-----+-----+-----+--...-+-----+-----+-----+--...-+-----+... 174 The format of one Mobility Agent Announcement is as follows [5]. 175 (Note that no particular alignment is guaranteed for this sub-option 176 value): 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Mobility Agent IP Address | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Adv-Length | Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | zero or more care-of addresses | 188 | ... | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Agent IP Address 192 The address trough which the Mobile Node may reach the 193 announced Mobility Agent in order to do a Mobile IP 194 registration. 196 Type 197 16. This is the same value as for the type field in a Mobility 198 Agent Advertisement Extension as described in RFC 3220 [5]. If 199 other Mobility Agent Advertisement Extensions are defined in 200 the future, this field will make it possible to differentiate 201 between them without using new DHCP option numbers. 203 Adv-Length 204 (6 + 4*N), where 6 accounts for the number of bytes in the 205 Sequence Number, Registration Lifetime, flags, and reserved 206 fields, and N is the number of care-of addresses advertised for 207 the Mobility Agent. 209 Sequence Number 210 The count of Mobility Agent DHCP announcements made since the 211 DHCP server was initialized (RFC 3220, Section 2.3.2 [5]). 213 Registration Lifetime 214 The longest lifetime (measured in seconds) that this agent is 215 willing to accept in any Registration Request. A value of 216 0xffff indicates infinity. 218 R 219 Registration required. Registration with this foreign agent 220 (or another foreign agent listed in this DHCP option) is 221 required even when using a co-located care-of address. 223 B 224 Busy. The foreign agent will not accept registrations from 225 additional mobile nodes. 227 H 228 Home agent. This agent offers service as a home agent on the 229 link on which this mobility agent announcement is sent. 231 F 232 Foreign agent. This agent offers service as a foreign agent on 233 the link on which this mobility agent announcement is sent. 235 M 236 Minimal encapsulation. This agent implements receiving 237 tunneled datagrams that use minimal encapsulation [7]. 239 G 240 GRE encapsulation. This agent implements receiving tunneled 241 datagrams that use GRE encapsulation [6]. 243 r 244 Sent as zero; ignored on reception. SHOULD NOT be allocated 245 for any other uses. 247 T 248 Foreign agent supports reverse tunneling [11]. 250 reserved 251 Sent as zero; ignored on reception. 253 Care-of Address(es) 254 The foreign agent care-of address(es) provided by this foreign 255 agent. An DHCP Mobility Agent Announcement MUST include at 256 least one care-of address if the 'F' bit is set. The number of 257 care-of addresses present is determined by the Length field in 258 the Extension. 260 4. Mobility Agent Option Usage 262 The requesting and sending of this option follows the rules for DHCP 263 options in RFC 2131 [1] 265 5. Security Considerations 267 DHCP provides an authentication mechanism, as described in RFC 3118 268 [4], which may be used if authentication is required before offering 269 the Mobility Agent option described here. On the other hand, Mobile 270 IP Agent Advertisements as described in RFC 3220 [5] requires no 271 authentication for Agent Advertisement and Agent Solicitation 272 messages. 274 By providing Agent Advertisements by means of DHCP as an alternative 275 to extended ICMP Router Advertisement messages it is possible to do 276 so more selectively, and it does not offer any new threat to the 277 internet. 279 6. IANA Considerations 281 The value for the DHCP Mobility Agent Information option code defined 282 in Section 3 must be assigned from the numbering space defined for 283 public DHCP Options in RFC 2939 [10]. 285 This document defines a new numbering space for the sub-options of 286 the DHCP_MIP_OPTION option, and defines sub-options 1 and 2 of this 287 numbering space, according to Section 3.2 and Section 3.3. 289 Normative References 291 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 292 March 1997. 294 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 295 Extensions", RFC 2132, March 1997. 297 [3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 298 2486, January 1999. 300 [4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 301 RFC 3118, June 2001. 303 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 304 2002. 306 Informative References 308 [6] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 309 Routing Encapsulation (GRE)", RFC 1701, October 1994. 311 [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 312 October 1996. 314 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 315 Levels", BCP 14, RFC 2119, March 1997. 317 [9] Calhoun, P. and C. Perkins, "Mobile IP Network Access 318 Identifier Extension for IPv4", RFC 2794, March 2000. 320 [10] Droms, R., "Procedures and IANA Guidelines for Definition of 321 New DHCP Options and Message Types", BCP 43, RFC 2939, 322 September 2000. 324 [11] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 325 3024, January 2001. 327 Author's Address 329 Henrik Levkowetz 330 ipUnplugged AB 331 Arenavagen 33 332 Stockholm S-121 28 333 SWEDEN 335 Phone: +46 8 725 9513 336 EMail: henrik@levkowetz.com 338 Full Copyright Statement 340 Copyright (C) The Internet Society (2002). All Rights Reserved. 342 This document and translations of it may be copied and furnished to 343 others, and derivative works that comment on or otherwise explain it 344 or assist in its implementation may be prepared, copied, published 345 and distributed, in whole or in part, without restriction of any 346 kind, provided that the above copyright notice and this paragraph are 347 included on all such copies and derivative works. However, this 348 document itself may not be modified in any way, such as by removing 349 the copyright notice or references to the Internet Society or other 350 Internet organizations, except as needed for the purpose of 351 developing Internet standards in which case the procedures for 352 copyrights defined in the Internet Standards process must be 353 followed, or as required to translate it into languages other than 354 English. 356 The limited permissions granted above are perpetual and will not be 357 revoked by the Internet Society or its successors or assigns. 359 This document and the information contained herein is provided on an 360 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 361 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 362 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 363 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 364 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 366 Acknowledgement 368 Funding for the RFC Editor function is currently provided by the 369 Internet Society.