idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 599. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE802.21], [MSFD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 17, 2008) is 5663 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 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Proposed Standard Subir Das 5 Expires: April 17, 2009 Telcordia 6 October 17, 2008 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Mobility Server (MoS) discovery 10 draft-ietf-mipshop-mos-dhcp-options-06 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document defines a number of Dynamic Host Configuration Protocol 44 (DHCPv4 and DHCPv6) options that contain a list of domain names 45 or IP addresses that can be mapped to servers providing IEEE 802.21 46 type of Mobility Services [MSFD]. These Mobility Services are used 47 to assist an MN in handover preparation (network discovery) and 48 handover decision (network selection). The services addressed 49 in this document are the Media Independent Handover Services 50 defined in [IEEE802.21]. 52 Mobility Services DHCP Options October 2008 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC-2119. 60 Terminology and abbreviations used in this document 62 Mobility Services: comprises of a set of different services provided 63 by the network to mobile nodes to facilitate handover preparation 64 and handover decision. 66 Mobility Server: a network node providing Mobility Support Services. 68 MIH: Media Independent Handover, as defined in [IEEE802.21]. 70 MIH Service: IS, ES or CS type of service, as defined in 71 [IEEE802.21]. 73 Table of Content 75 1. Introduction .................................................2 76 2. DHCPv4 Options for MoS Discovery..............................3 77 2.1 Domain Name List........................................5 78 2.2 IPv4 Address List.......................................6 79 3. DHCPv6 Options for MoS Discovery..............................6 80 4. Option Usage..................................................8 81 4.1 Usage of DHCPv4 Options for MoS Discovery...............8 82 4.2 Usage of DHCPv6 Options for MoS Discovery...............9 83 5. Security Considerations .....................................10 84 6. IANA Considerations .........................................10 85 7. Acknowledgements ............................................11 86 8. References ..................................................11 87 8.1 Normative References ...................................11 88 8.2 Informative References .................................11 89 Author's Addresses .............................................11 90 Intellectual Property and Copyright Statements .................12 92 1. Introduction 94 IEEE 802.21 [IEEE802.21] defines three distinct service types to 95 facilitate link layer handovers across heterogeneous technologies: 97 a) Information Services (IS) 98 IS provides a unified framework to the higher layer entities 99 across the heterogeneous network environment to facilitate discovery 100 and selection of multiple types of networks existing within a 101 geographical area, with the objective to help the higher layer 103 Mobility Services DHCP Options September 2008 105 mobility protocols to acquire a global view of the heterogeneous 106 networks and perform seamless handover across these networks. 108 b) Event Services (ES) 109 Events may indicate changes in state and transmission behavior 110 of the physical, data link and logical link layers, or predict state 111 changes of these layers. The Event Service may also be used to 112 indicate management actions or command status on the part of the 113 network or some management entity. 115 c) Command Services (CS) 116 The command service enables higher layers to control the 117 physical, data link, and logical link layers. The higher layers may 118 control the reconfiguration or selection of an appropriate link 119 through a set of handover commands. 121 In IEEE terminology these services are called Media Independent 122 Handover (MIH) services. While these services may be co-located, 123 the different pattern and type of information they provide does not 124 necessitate the co-location. 126 An MN may make use of any of these MIH service types separately or 127 any combination of them [MSFD]. In practice a Mobility Server may 128 not necessarily host all three of these MIH services together, thus 129 there is a need to discover the MIH services types separately. 131 This document defines a new dhcpv4 option called MoS option, which 132 allows the MN to locate a Mobility Server which hosts the desired 133 service type (i.e. IS, ES or CS)as defined in [IEEE802.21]. The MoS 134 information type defines sub-options for different services. The 135 document also defines DHCPv6 options that allow the MN to 136 discover Mobility Servers hosting MIH services in different 137 deployment scenarios. Apart from manual configuration, this is one 138 of the possible solutions for locating a server providing Mobility 139 Services. 141 2. DHCPv4 Option for MoS Discovery 143 This section describes the MoS option for DHCPv4. 144 The MoS option begins with a option code followed by a length and 145 sub-options. The value of the length octet does not include itself 146 or the option code. The option layout is depicted below: 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Option Code | length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Sub-Option 1 | 153 . . 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Mobility Services DHCP Options October 2008 158 | ... | 159 . . 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Sub-Option n | 162 . . 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Option Code 167 OPTION-IPv4-MoS (TBD) - 1 byte 169 Length 171 1 byte 173 Sub-options 175 A series of DHCPv4 sub-options. 177 When the total length of a MoS option exceeds 254 octets, the 178 Procedure outlined in [RFC3396] MUST be employed to split the 179 option into multiple, smaller options. 181 A sub-option begins with a sub-option Type followed by a length 182 and a `enc` field. The value of the length octet does not include 183 itself or the option code. There are two types of encodings, 184 specified by the encoding byte ('enc') that follows the code byte. 185 If the encoding byte has the value 0, it is followed by a list of 186 domain names, as described below (Section 2.1). If the encoding byte 187 has the value 1, it is followed by one or more IPv4 addresses 188 (Section 2.2). 190 All implementations MUST support both encodings. A DHCP server MUST 191 NOT mix the two encodings in the same DHCP message, even if it sends 192 two different instances of the same option. Attempts to do so would 193 result in incorrect client behavior as DHCP processing rules call 194 for the concatenation of multiple instances of an option into a 195 single option prior to processing the option [RFC3396]. 197 The sub-option layout is depicted below: 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Sub-opt Type | length | enc | FQDN or . 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Mobility Services DHCP Options October 2008 206 +---------------------------------------------------------------+ 207 . IP Address . 208 . | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 The sub-option Types are summarized below. 212 +--------------+---------------+ 213 | Sub-opt | Service | 214 | Type* | Name | 215 +==============+===============+ 216 | 1 | IS | 217 +--------------+---------------+ 218 | 2 | ES | 219 +--------------+---------------+ 220 | 3 | IS and ES | 221 +--------------+---------------+ 222 | 4 | CS | 223 +--------------+---------------+ 224 | 5 | IS and CS | 225 +--------------+---------------+ 226 | 6 | ES and CS | 227 +--------------+---------------+ 228 | 7 | IS, CS and ES | 229 +--------------+---------------+ 231 *Note: The values `0` '8' to '255' are reserved and MUST NOT be used. 232 Future sub-options may or may not use the above format. 234 2.1 Domain Name List 236 If the 'enc' byte has a value of 0, the encoding byte is followed by 237 a sequence of labels, encoded according to Section 8 of [RFC3315], 238 quoted below: 240 So that domain names may be encoded uniformly, a domain name 241 or a list of domain names is encoded using the technique 242 described in section 3.1 of [RFC1035]. A domain name, or list 243 of domain names, in DHCP MUST NOT be stored in compressed form, 244 as described in section 4.1.4 of [RFC1035]. 246 [RFC1035] encoding was chosen to accommodate future international- 247 lized domain name mechanisms. The minimum length for this encoding 248 is 3. 250 The option MAY contain multiple domain names, but these SHOULD refer 251 to different NAPTR records, rather than different A records. The 252 client MUST try the records in the order listed, applying the 253 mechanism described in [MoS-DNS] for each. The client only resolves 255 Mobility Services DHCP Options October 2008 257 the subsequent domain names if attempts to contact the first one 258 failed or yielded no common transport protocols between the MN and 259 the server. 261 Use of multiple domain names is not meant to replace NAPTR and SRV 262 records, but rather to allow a single DHCP server to indicate MIH 263 servers operated by multiple providers. 265 The sub-option for this encoding has the following format: 267 Type Len enc DNS name of MoS server 268 +-----+---+---+-----+-----+-----+-----+-----+-- 269 |1..7 | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 270 +-----+---+---+-----+-----+-----+-----+-----+-- 272 As an example, consider the case where the server wants to offer 273 two MIH IS servers, "example.com" and "example.net". These would 274 be encoded as follows: 275 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 276 |1..7|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 277 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 278 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 279 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 280 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 282 2.2 IPv4 Address List 284 If the 'enc' byte has a value of 1, the encoding byte is followed by 285 a list of IPv4 addresses indicating appropriate MIH servers 286 available to the MN. Servers MUST be listed in order of preference. 288 Its minimum length is 5, and the length MUST be a multiple of 4 plus 289 one. The sub-option for this encoding has the following format: 291 Code Len enc IPv4 Address 1 IPv4 Address 2 292 +-----+---+---+-----+----+---+----+----+-- 293 |1..7 | n | 1 | a1 | a2 |a3 | a4 | a1 | ... 294 +-----+---+---+-----+----+---+----+----+-- 296 3. DHCPv6 Option for MoS discovery 298 This section introduces new DHCPv6 option used for MoS discovery. 300 Whether the MN receives an MoS address from local or home network 301 will depend on the actual network deployment [MSFD]. 303 Mobility Services DHCP Options October 2008 305 The MoS option begins with a option code followed by a length and 306 sub-options. The value of the length octet does not include itself 307 or the option code. The option layout is depicted below: 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Option Code | length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sub-Option 1 | 314 . . 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | ... | 317 . . 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Sub-Option n | 320 . . 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Option Code 325 OPTION-IPv6-MoS (TBD) - 2 bytes 327 Length 329 2 bytes 331 Sub-options 333 A series of DHCPv6 sub-options. 335 The sub-options follow the same format (except the length value) and 336 'enc' rules as described in Section 2. The sub-option layout is 337 Depicted below: 339 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | sub-opt Type | Length | enc | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 . FQDN or IP Address . 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Mobility Services DHCP Options October 2008 350 The sub-option Types are summarized below. 351 +--------------+---------------+ 352 | Sub-opt | Service | 353 | Type* | Name | 354 +==============+===============+ 355 | 1 | IS | 356 +--------------+---------------+ 357 | 2 | ES | 358 +--------------+---------------+ 359 | 3 | IS and ES | 360 +--------------+---------------+ 361 | 4 | CS | 362 +--------------+---------------+ 363 | 5 | IS and CS | 364 +--------------+---------------+ 365 | 6 | ES and CS | 366 +--------------+---------------+ 367 | 7 | IS, CS and ES | 368 +--------------+---------------+ 370 *Note: The values `0` '8' to '255' are reserved and MUST NOT be used. 371 Future sub-options may or may not use the above format. 373 4. Option Usage 375 4.1 Usage of DHCPv4 Options for MoS Discovery 377 The requesting and sending of the proposed DHCPv4 option follow the 378 rules for DHCP options in [RFC2131]. 380 4.1.1 Mobile Node behavior 382 The mobile node may perform the MoS information discovery procedure 383 either during initial association with a network or when the 384 mobility service is required. It may also try to perform the MoS 385 information discovery when it lacks the network information for MoS 386 or needs to change the MoS for some reasons, for instance, to 387 recover from the single point of failure of the existing MoS. 389 In order to acquire the MoS information, the mobile node MUST send 390 either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or 391 a unicast server address, respectively. In this message the mobile 392 node (DHCP client) MUST include the sub-opt Type for the MoS 393 Discovery in the sub-options field. 395 Mobility Services DHCP Options October 2009 397 4.1.2 DHCP Server behavior 399 When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message 400 with the MoS Discovery option in the options field, the DHCP server 401 MUST follow the [RFC2131] logic to construct either a DHCPOFFER or 402 DHCPACK message including the MoS Discovery option. The reply 403 message may contain the IP address or the FQDN of the MoS Server. 405 The DHCP server MUST always construct the response according to 406 the Sub-opt Type requested by the DHCP client. 408 In case that the server cannot find any MoS information for a 409 specific MoS sub-opt Type, it MUST return the MoS option with a 410 sub-option by setting the sub-opt Type to the requested 411 sub-opt Type and the length of the sub-option to 1. 413 4.2 DHCPv6 Options for MoS discovery 415 The requesting and sending of the proposed DHCPv6 options follow the 416 rules for DHCP options in [RFC3315]. 418 4.2.1 Mobile node behavior 420 The mobile node may perform the MoS information discovery procedure 421 either during initial association with a network or when the 422 mobility service is required. It may also try to perform the MoS 423 information discovery when it lacks the network information for MoS 424 or needs to change the MoS for some reasons, for instance, to 425 recover from the single point of failure of the existing MoS 427 In order to acquire the MoS address, the mobile node MUST send either 428 a REQUEST or INFORMATION_REQUEST message to the All_DHCP_Servers 429 multicast address. In this message the mobile node (DHCP client) 430 MUST include the Option Code for the MoS Discovery option in the 431 option_code. 433 4.2.2 DHCP Server behavior 435 When the DHCP Server receives either REQUEST or INFORMATION-REQUEST 436 message the DHCP server MUST follow the following logic to construct 437 a REPLY message with the MoS Information option. 439 If the DHCP server has the requested MoS information, it MUST 440 include the information in the MoS Information option. The server 441 may provide the matching information from the preconfigured 442 information available locally. 444 Mobility Services DHCP Options September 2008 446 The DHCP server MUST always construct the response 447 according to the Sub-Opt Type requested by the DHCP client. 449 In case that the server cannot find any MoS information for a 450 specific MoS type, it MUST return the MoS option with 451 a sub-option by setting the Sub-opt Type to the requested Sub-opt 452 Type and the length of the sub-option to 1. 454 5. Security Considerations 456 The security considerations in [RFC2131] apply. If an adversary 457 manages to modify the response from a DHCP server or insert its own 458 response, an MN could be led to contact a rogue Mobility Server, 459 possibly one that then would provide wrong information, event or 460 command for handover. 462 It is recommended to use either DHCP authentication option described 463 in [RFC3118] where available, or rely upon link layer security. 465 This will also protect the denial of service attacks to DHCP 466 servers. [RFC3118] provides mechanisms for both entity authentication 467 and message authentication. 469 6. IANA Considerations 471 This document defines one new DHCPv4 option as described in section 472 2. 474 MoS Option for DHCPv4 (OPTION-IPv4-MoS) TBD 476 This document creates a new registry for the Sub-Option field in the 477 MoS DHCPv4 option called the "MoS Service Type" (Section 2). 478 IS 1 479 ES 2 480 IS and ES 3 481 CS 4 482 IS and CS 5 483 ES and CS 6 484 IS, CS and ES 7 486 The values '0', '8' to '255' are reserved and MUST NOT be used. New 487 values can be allocated by Standards Action or IESG approval. 489 This document also defines new DHCPv6 options as described in 490 section 3 492 Mobility Services DHCP Options October 2008 494 MoS Option for DHCPv6 (OPTION-IPv6-MoS) TBD 496 This document creates a new registry for the sub-option field in 497 the MoS DHCPv6 option called the ?MoS Service Type?(section 3). 499 IS 1 500 ES 2 501 IS and ES 3 502 CS 4 503 IS and CS 5 504 ES and CS 6 505 IS, CS and ES 7 507 The values '0', '8' to '255' are reserved and MUST NOT be used. New 508 Values can be allocated by Standards Action or IESG approval. 510 7. Acknowledgements 512 Authors would like to acknowledge the following individuals for 513 their valuable comments. 514 Vijay Devarapalli, Telemaco Melia, and Yoshihiro Ohba 516 8. References 518 8.1 Normative References 520 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 521 2131, March 1997. 523 [RFC1035] Mockapetris, P., "Domain names - implementation and 524 specification", STD 13, RFC 1035, November 1987. 526 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 527 RFC3396, November 2002. 529 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 531 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 532 Droms et al, July 2003 534 8.2 Informative References 536 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 537 Networks: Media Independent Handover Services 539 Mobility Services DHCP Options October 2008 541 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 542 draft-ietf-mipshop-mos-dns-discovery, (Work in Progress), 543 May 2008. 545 [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)", 546 draft-ietf-mipshop-mstp-solution, (Work in Progress) 548 Authors' Addresses 550 Gabor Bajko 551 Nokia 552 e-mail: gabor.bajko@nokia.com 554 Subir Das 555 Telcordia Technologies Inc. 556 e-mail: subir@research.telcordia.com 558 Full Copyright Statement 560 Copyright (C) The IETF Trust (2008). 562 This document is subject to the rights, licenses and restrictions 563 contained in BCP 78, and except as set forth therein, the authors 564 retain all their rights. 566 This document and the information contained herein are provided on 567 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 568 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 569 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 570 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 571 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 572 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 573 FOR A PARTICULAR PURPOSE. 575 Intellectual Property 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed 579 to pertain to the implementation or use of the technology described 580 in this document or the extent to which any license under such 581 rights might or might not be available; nor does it represent that 582 it has made any independent effort to identify any such rights. 583 Information on the procedures with respect to rights in RFC 584 documents can be found in BCP 78 and BCP 79. 586 Mobility Services DHCP Options October 2008 588 Copies of IPR disclosures made to the IETF Secretariat and any 589 assurances of licenses to be made available, or the result of an 590 attempt made to obtain a general license or permission for the use 591 of such proprietary rights by implementers or users of this 592 specification can be obtained from the IETF on-line IPR repository 593 at http://www.ietf.org/ipr. 595 The IETF invites any interested party to bring to its attention any 596 copyrights, patents or patent applications, or other proprietary 597 rights that may cover technology that may be required to implement 598 this standard. Please address the information to the IETF at ietf- 599 ipr@ietf.org. 601 Acknowledgment 603 Funding for the RFC Editor function is provided by the IETF 604 Administrative Support Activity (IASA).