idnits 2.17.1 draft-ietf-dhc-mipadvert-opt-02.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 13 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 (Feb 2004) is 7376 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: A later version (-08) exists of draft-ietf-dhc-agentopt-radius-03 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group H. Levkowetz 2 Internet-Draft ipUnplugged 3 Expires: August 1, 2004 Feb 2004 5 DHCP Option for Mobile IP Mobility Agents 6 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt . 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html . 28 This Internet-Draft will expire on August 1, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This document defines a Dynamic Host Configuration Protocol (DHCP) 37 option with sub-options. One sub-option is passed from the DHCP 38 Server to the DHCP Client to announce the presence of one or more 39 Mobile IP Mobility Agents. For each announced Mobility Agent, 40 information is provided which is the same as that of the Mobile IP 41 Agent Advertisement extension to ICMP Router Advertisements. There 42 is also one sub-option which may be used by a DHCP client to provide 43 identity information to the DHCP server. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1 Requirements Terminology . . . . . . . . . . . . . . . . 3 51 2.2 Mobile IP Terminology . . . . . . . . . . . . . . . . . 3 52 2.3 DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3 54 3. Mobility Agent Information Option . . . . . . . . . . . . . . 3 55 3.1 Mobility Agent Information Option Definition . . . . . . 3 56 3.2 Network Access Identifier Sub-Option . . . . . . . . . . 5 57 3.3 Mobility Agent Announcement (Dynamic) Sub-Option . . . . 6 58 3.4 Mobility Agent Announcement (Static) Sub-Option . . . . 8 60 4. Mobility Agent Option Usage . . . . . . . . . . . . . . . . . 9 61 4.1 DHCP Server - Mobility Agent Interaction . . . . . . . . 9 62 4.2 Mobile Node Considerations . . . . . . . . . . . . . . . 10 63 4.3 DHCP Server Considerations . . . . . . . . . . . . . . . 10 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 Normative References . . . . . . . . . . . . . . . . . . . . . 12 73 Informative References . . . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 77 A. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . 14 81 1. Introduction 83 There already exists a DHCP [RFC2131] option to announce Mobile IP v4 84 Home Agent addresses, this is described in [RFC2132]. There is, 85 however, no DHCP option available to announce Mobile IP v4 Foreign 86 Agents. 88 Announcement of available Mobile IP v4 Mobility Agents by means of 89 DHCP provides possibilities for selective and individual assignment 90 of Mobility Agents to Mobile Nodes. This in turn makes load-sharing 91 and selective service offerings easier. This draft describes a DHCP 92 option for announcing IPv4 Mobility Agents to DHCP Clients. 94 2. Terminology 96 2.1 Requirements Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2.2 Mobile IP Terminology 104 The Mobile IP related terminology used in this document is described 105 in [RFC3344]. 107 2.3 DHCP Terminology 109 The DHCP related terminology used in this document is described in 110 [RFC2131]. 112 3. Mobility Agent Information Option 114 3.1 Mobility Agent Information Option Definition 116 This document defines a new DHCP Option called the Mobility Agent 117 Option. It is a "container" option for specific agent- supplied 118 sub-options. The format of the Mobility Agent option is: 120 Code Len Mobility Agent Information Field 121 +-------+------+------+------+------+------+--...-+------+ 122 | TBD | N | a1 | a2 | a3 | a4 | | aN | 123 +-------+------+------+------+------+------+--...-+------+ 125 The length N gives the total number of octets in the Mobility Agent 126 Field. The Mobility Agent Information field consists of a sequence 127 of SubOpt/Length/Value tuples for each sub-option, encoded in the 128 following manner: 130 SubOpt Len Sub-option Value 131 +------+------+------+------+------+------+--...-+------+ 132 | 1 | N | s1 | s2 | s3 | s4 | | sN | 133 +------+------+------+------+------+------+--...-+------+ 134 SubOpt Len Sub-option Value 135 +------+------+------+------+------+------+--...-+------+ 136 | 2 | N | t1 | t2 | t3 | t4 | | tN | 137 +------+------+------+------+------+------+--...-+------+ 139 ... 141 The length N of the DHCP Mobility Agent Information Option shall 142 include all bytes of the sub-option code/length/value tuples. Since 143 at least one sub-option must be included in the option, the minimum 144 Mobility Agent Information length is two (2). The length N of the 145 sub-options shall be the number of octets in only that sub-option's 146 value field. A sub-option length may not be zero; if the only 147 purpose of a sub-option is to signal a boolean value, a flag byte 148 MUST be defined to carry that value. The sub-options need not appear 149 in any particular order. There is no 255 (End) sub-option defined 150 for this option, so the Mobility Agent Information field SHALL NOT be 151 terminated with a 255 sub-option. 153 3.2 Network Access Identifier Sub-Option 155 The Network Access Identifier (NAI) defined in [RFC2486] is already 156 used in Mobile IP as an alternative to the home address as an 157 identifier of a mobile node [RFC2794]. 159 o The Network Access Identifier sub-option of the Mobility Agent 160 Information Option MAY be used by the DHCP client to provide 161 identifying information to the DHCP server, as part of the 162 DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages. The server MAY 163 use this information in selecting mobility agent announcement 164 parameters for the client. 165 o If the client requests the server to provide the Mobility Agent 166 Option by including it in the Parameter Request List Option of a 167 DHCPDISCOVER, DHCPREQUEST or DHCPINFORM message, the client also 168 SHOULD include the Mobility Agent Option with the Network Access 169 Identifier sub-option in the DHCPDISCOVER message. 170 o The server MAY include the Network Access Identifier sub-option 171 from the client DHCPDISCOVER message in subsequent DHCPOFFER and 172 DHCPACK messages if the server used this sub-option in selecting 173 client parameters. 174 o The client MUST include the Network Access Identifier sub-option 175 in a DHCPREQUEST message if it included it in the DHCPDISCOVER 176 message. 178 The number of this sub-option is 1. 180 The format of the Network Access Identifier sub-option is as follows: 182 SubOpt Len Sub-option Value 183 +------+-----+-----+-----+-----+-----+--...-+-----+ 184 | 1 | N | Network Access Identifier | 185 +------+-----+-----+-----+-----+-----+--...-+-----+ 187 3.3 Mobility Agent Announcement (Dynamic) Sub-Option 189 The Mobility Agent Announcement (Dynamic) sub-option announces the 190 address of one or more mobility agents, together with all the 191 information about the mobility agent which is normally found in a 192 Mobile IP Agent Advertisement extension to ICMP Router Advertisements 193 as described in [RFC3344]. 195 All fields are defined so as to correspond to fields of the same name 196 in a Mobility Agent Advertisement Extension as described in 197 [RFC3344], and if in the future additional bits are allocated from 198 the 'reserved' field for the Mobility Agent Advertisement Extension, 199 they should be equally valid in a DHCP Mobility Agent option. 200 However, if RFC 3344 is revised and additional fields are defined for 201 the Mobility Agent Advertisement Extension, a new sub-option SHOULD 202 be defined to carry such a new format Mobility Agent Announcement. 204 This option may contain announcements of one Mobility Agents. If it 205 is desired to announce more than one Mobility Agent, multiple 206 instances of this sub-option may occur within the Mobility Agent 207 Information Option. 209 The number of this sub-option is 2. 211 SubOpt Len Sub-option Value (Announcements) 212 +------+-----+-----+-----+--...-+-----+ 213 | 2 | N | Announcement | 214 +------+-----+-----+-----+--...-+-----+ 216 The format of one Mobility Agent Announcement is as follows: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Mobility Agent IP Address | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type | Adv-Length | Sequence Number | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | zero or more care-of addresses | 228 | ... | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Agent IP Address 232 The address through which the Mobile Node may reach the announced 233 Mobility Agent in order to do a Mobile IP registration. 234 Type 235 16. This is the same value as for the type field in a Mobility 236 Agent Advertisement Extension as described in [RFC3344]. If other 237 Mobility Agent Advertisement Extensions are defined in the future, 238 this field will make it possible to differentiate between them 239 without using new DHCP option numbers. 240 Adv-Length 241 (6 + 4*N), where 6 accounts for the number of bytes in the 242 Sequence Number, Registration Lifetime, flags, and reserved 243 fields, and N is the number of care-of addresses advertised for 244 the Mobility Agent. 245 Sequence Number 246 The count of Mobility Agent DHCP announcements made since the DHCP 247 server was initialised or the Mobility Agent was re-booted, 248 starting at zero. This is a total count, not a per-client count. 249 If this count rolls over, it continues with the value 256 250 following the value 0xffff, to be able to distinguish a roll-over 251 from a Mobility Agent re-boot, (see Section 2.3.2 of [RFC3344]). 252 Note that this requires the DHCP server to have knowledge of part 253 of the state of the Mobility Agent; if the DHCP server does not 254 have this capability, the sub-option described in Section 3.4 255 should be used instead of the Mobility Agent Announcement 256 (Dynamic) sub-option. 257 Registration Lifetime 258 The longest lifetime (measured in seconds) that this agent is 259 willing to accept in any Registration Request. A value of 0xffff 260 indicates infinity. 261 R 262 Registration required. Registration with this foreign agent (or 263 another foreign agent listed in this DHCP option) is required even 264 when using a co-located care-of address. 265 B 266 Busy. The foreign agent will not accept registrations from 267 additional mobile nodes. 268 Note that this requires the DHCP server to have knowledge of part 269 of the state of the Mobility Agent; if the DHCP server does not 270 have this capability, the sub-option described in Section 3.4 271 should be used instead of the Mobility Agent Announcement 272 (Dynamic) sub-option. 273 H 274 Home agent. This agent offers service as a home agent with the IP 275 address given in the announcement. 276 F 277 Foreign agent. This agent offers service as a foreign agent with 278 the IP address given in the announcement. 279 M 280 Minimal encapsulation. This agent implements receiving tunnelled 281 datagrams that use minimal encapsulation [RFC2004]. 282 G 283 GRE encapsulation. This agent implements receiving tunnelled 284 datagrams that use GRE encapsulation [RFC1701]. 285 r 286 Sent as zero; ignored on reception. SHOULD NOT be allocated for 287 any other uses. 288 T 289 Foreign agent supports reverse tunnelling [RFC3024]. 290 reserved 291 Sent as zero; ignored on reception. 292 Care-of Address(es) 293 The foreign agent care-of address(es) provided by this foreign 294 agent. An DHCP Mobility Agent Announcement MUST include at least 295 one care-of address if the 'F' bit is set. The number of care-of 296 addresses present is determined by the Length field in the 297 Extension. 299 3.4 Mobility Agent Announcement (Static) Sub-Option 301 In the Mobility Agent Announcement (Dynamic) Sub-Option described 302 above, the 'B' bit and the 'Sequence Number' field is expected to 303 faithfully reflect the state of the Mobility Agent announced. This 304 requires continuous state information update between Mobility Agent 305 and DHCP Server, which will normally not be available to a 306 stand-alone DHCP Server. 308 The Mobility Agent Announcement (Static) Sub-Option is adapted to 309 this case. In format it is identical to the Mobility Agent 310 Announcement (Dynamic) Sub-Option, but it always has the 'B' bit and 311 the 'Sequence Number' field set to zero. Mobile Nodes which receive 312 this sub-option should be aware of this, and in particular should be 313 prepared to handle the case where a Mobility Agent is announced by 314 this DHCP Option and sub-option, but is found to be busy and not able 315 to handle new registrations when a registration attempt is made. 317 This sub-option may contain announcements of one Mobility Agent. If 318 it is desired to announce more than one Mobility Agent, multiple 319 instances of this sub-option may occur within the Mobility Agent 320 Information Option. 322 The number of this sub-option is 3. 324 SubOpt Len Sub-option Value (Announcements) 325 +------+-----+-----+-----+--...-+-----+ 326 | 3 | N | Announcement | 327 +------+-----+-----+-----+--...-+-----+ 329 For both the Static and the Dynamic Mobility Agent Announcement 330 sub-option the following applies: 331 o The Mobility Agent Announcement sub-options of the Mobility Agent 332 Information Option MAY be used by the DHCP server to provide 333 Mobility Agent information to the DHCP client, as part of a 334 DHCPOFFER or DHCPACK message. If a Network Access Identifier 335 sub-option was provided by the client, it SHOULD be used to choose 336 the particular Mobility Agent or Agents to announce if the server 337 has more than one Mobility Agent to offer. 338 o If the server provides the Mobility Agent Option with a Mobility 339 Agent Announcement sub-option in a DHCPOFFER message, it also MUST 340 include the same Mobility Agent Option and sub-options in a 341 subsequent corresponding DHCPACK message. 343 4. Mobility Agent Option Usage 345 The requesting and sending of this option follows the rules for DHCP 346 options in [RFC2131]. 348 4.1 DHCP Server - Mobility Agent Interaction 350 A stand-alone DHCP server providing the Mobility Agent Announcement 351 Sub-Option will normally not have any knowledge of the state of the 352 mobility agent which the sub-option refers to. This means that some 353 of the information in the announcement (such as the 'B' bit in 354 particular) cannot be dynamically updated. In this case, the 355 Mobility Agent Announcement (Static) Sub-Option SHOULD be used. 357 A DHCP server co-located with a Mobility Agent may have more 358 information about the dynamic state of the Mobility agent, and may 359 therefore be able to provide reliable state information in the 360 announcement. In this case, the Mobility Agent Announcement 361 (Dynamic) Sub-Option MAY be used. Mechanisms to provide state 362 information transfer between the Mobility Agent and the DHCP server 363 are not in the scope of this document. 365 4.2 Mobile Node Considerations 367 A Mobile IP v4 Mobile Node may request the Mobility Agent Information 368 option at it's discretion. This may be done before, concurrently 369 with, or after doing an ICMP Mobility Agent Solicitation according to 370 [RFC3344], or without doing such an ICMP solicitation at all. It is 371 however expected that a common usage would be for a mobile node which 372 connects to a new access node to acquire a DHCP address and solicit 373 for FAs in parallel. To differentiate between possible services, the 374 Mobility Agents could be announced solely through DHCP by use of the 375 Mobility Agent Information Option with one of the Mobility Agent 376 Announcement sub-options, not by responding to router solicitations; 377 this way the Mobility Agent and service level offered could be 378 dependent on the NAI provided by the MN in the Network Access 379 Identifier sub-option. 381 When a Mobility Agent is announced by means of an ICMP Mobility Agent 382 Advertisement according to [RFC3344], the listening Mobile Node is 383 able to directly acquire the link-layer address of the Mobility Agent 384 from the advertisement message. If however the Mobility Agent is 385 advertised through the DHCP Mobility Agent Information Option, the 386 link-layer address will not be part of the advertisement, and it is 387 necessary for the Mobile Node to issue an ARP request for the 388 link-layer address corresponding to the Mobility Agent's IP address. 390 Further, when a Mobility Agent is announced by means of an ICMP 391 Mobility Agent Advertisement, the advertisement may also contain 392 information about the available on-link routers. When the Mobility 393 Agent announcement is done through the DHCP Mobility Agent 394 Information Option, the information about available routers SHOULD 395 instead be provided through the DHCP Router Option. 397 4.3 DHCP Server Considerations 399 By providing a NAI to the DHCP server (through use of the Network 400 Access Identifier Sub-Option), the Mobile Node makes it possible for 401 the server to match the realm of the NAI to a realm which is known to 402 the server through static configuration or possibly through a AAA 403 infrastructure. The exact mechanism used is however out of scope for 404 this specification. 406 If the DHCP server does not have the capability to match the realm of 407 the NAI provided by the Mobile Node against known realms, or if it 408 finds no matching realm, it MUST fall back to the method of matching 409 client to configuration parameters described in [RFC2131] (See 410 especially Section 2.1 of RFC 2131). It is for instance completely 411 acceptable to select parameter values for the Mobility Agent 412 Information Option Sub-Options based on the hardware address or 413 client-identifier of the client. 415 An alternative to providing the NAI to the DHCP server for use in 416 selecting Mobility Agent parameters could be to use a mechanism such 417 as the one described in [RADIUS-SUBOPT] to provide Mobility Agent 418 information obtained through AAA authentication to the DHCP server 419 for subsequent delivery to a client using the Mobility Agent 420 Information Option. 422 5. Security Considerations 424 Mobile IP Agent Advertisements as described in [RFC3344] requires no 425 authentication for Agent Advertisement and Agent Solicitation 426 messages. 428 DHCP provides an authentication mechanism, as described in [RFC3118], 429 which may be used if authentication is required before offering the 430 Mobility Agent option described here. Because it may be cumbersome 431 or practically impossible to distribute keys to foreign networks a 432 Mobile Node may visit, the ability to use the DHCP authentication 433 mechanism is not viewed as a major advantage of distributing Mobility 434 Agent Announcements through DHCP rather than through regular ICMP 435 Mobile IP Agent Advertisements. 437 By providing Agent Advertisements by means of DHCP as an alternative 438 to extended ICMP Router Advertisement messages it is possible to do 439 so more selectively, and it does not offer any new threat to the 440 internet. 442 6. IANA Considerations 444 This document defines one new DHCP v4 option value, and one new 445 sub-type numbering space to be managed by IANA. 447 Section 3.1 defines a new DHCP v4 option value, the Mobility Agent 448 Information Option. The type number for this option is [TBD, 449 assigned by IANA]. This option introduces a new sub-type numbering 450 space where the values 1, 2 and 3 has been assigned values in this 451 document. Approval of new Mobility Agent Information Option sub-type 452 numbers is subject to Expert Review, and a specification is required 453 [RFC2434]. 455 The value for the DHCP_MIP_OPTION code must be assigned from the 456 numbering space defined for public DHCP Options in [RFC2939]. 458 7. Acknowledgements 460 Normative References 462 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 463 2131, March 1997. 465 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 466 Extensions", RFC 2132, March 1997. 468 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 469 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 470 October 1998. 472 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 473 RFC 2486, January 1999. 475 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 476 Messages", RFC 3118, June 2001. 478 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 479 August 2002. 481 Informative References 483 [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 484 Routing Encapsulation (GRE)", RFC 1701, October 1994. 486 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 487 October 1996. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 493 Identifier Extension for IPv4", RFC 2794, March 2000. 495 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 496 of New DHCP Options and Message Types", BCP 43, RFC 2939, 497 September 2000. 499 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 500 revised", RFC 3024, January 2001. 502 [RADIUS-SUBOPT] 503 Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option 504 for the DHCP Relay Agent Information Option", 505 draft-ietf-dhc-agentopt-radius-03 (work in progress), 506 November 2003. 508 Author's Address 510 Henrik Levkowetz 511 ipUnplugged AB 512 Arenavagen 33 513 Stockholm S-121 28 514 SWEDEN 516 Phone: +46 8 725 9513 517 EMail: henrik@levkowetz.com 519 Appendix A. Open issues 521 (This section should be removed by the RFC editor before publication) 523 Discussion about this draft should be sent to dhcwg@ietf.org. 525 Open issues relating to this specification are tracked on the 526 following web site: http://www.mip4.org/issues/tracker/mip4/ 528 The current working documents for this draft are available at this 529 web site: http://ietf.levkowetz.com/drafts/dhc/mipadvert/ 531 Intellectual Property Statement 533 The IETF takes no position regarding the validity or scope of any 534 intellectual property or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; neither does it represent that it 538 has made any effort to identify any such rights. Information on the 539 IETF's procedures with respect to rights in standards-track and 540 standards-related documentation can be found in BCP-11. Copies of 541 claims of rights made available for publication and any assurances of 542 licenses to be made available, or the result of an attempt made to 543 obtain a general license or permission for the use of such 544 proprietary rights by implementors or users of this specification can 545 be obtained from the IETF Secretariat. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights which may cover technology that may be required to practice 550 this standard. Please address the information to the IETF Executive 551 Director. 553 Full Copyright Statement 555 Copyright (C) The Internet Society (2004). All Rights Reserved. 557 This document and translations of it may be copied and furnished to 558 others, and derivative works that comment on or otherwise explain it 559 or assist in its implementation may be prepared, copied, published 560 and distributed, in whole or in part, without restriction of any 561 kind, provided that the above copyright notice and this paragraph are 562 included on all such copies and derivative works. However, this 563 document itself may not be modified in any way, such as by removing 564 the copyright notice or references to the Internet Society or other 565 Internet organizations, except as needed for the purpose of 566 developing Internet standards in which case the procedures for 567 copyrights defined in the Internet Standards process must be 568 followed, or as required to translate it into languages other than 569 English. 571 The limited permissions granted above are perpetual and will not be 572 revoked by the Internet Society or its successors or assignees. 574 This document and the information contained herein is provided on an 575 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 576 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 577 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 578 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 579 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.