idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-07.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 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 606. 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 13 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 27, 2008) is 5659 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) == Outdated reference: A later version (-12) exists of draft-ietf-mipshop-mstp-solution-08 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-04 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task force Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Proposed Standard Subir Das 5 Expires: April 27, 2009 Telcordia Technologies 6 October 27, 2008 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 IEEE 802.21 Mobility Server (MoS) discovery 10 draft-ietf-mipshop-mos-dhcp-options-07 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 (1) 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 (2) Terminology and abbreviations used in this document 62 Mobility Services: a set of different services provided by the 63 network to mobile nodes to facilitate handover preparation 64 and handover decision. In this document, Mobility Services refer to 65 the services defined in IEEE 802.21 specifications [IEEE802.21] 67 Mobility Server: a network node providing Mobility Support Services. 69 MIH: Media Independent Handover, as defined in [IEEE802.21]. 71 MIH Service: IS, ES or CS type of service, as defined in 72 [IEEE802.21] 74 Table of Contents 76 1. Introduction .................................................2 77 2. DHCPv4 Options for MoS Discovery..............................3 78 2.1 Domain Name List........................................5 79 2.2 IPv4 Address List.......................................6 80 3. DHCPv6 Options for MoS Discovery..............................6 81 4. Option Usage..................................................8 82 4.1 Usage of DHCPv4 Options for MoS Discovery...............8 83 4.2 Usage of DHCPv6 Options for MoS Discovery...............9 84 5. Security Considerations .....................................10 85 6. IANA Considerations .........................................10 86 7. Acknowledgements ............................................11 87 8. References ..................................................11 88 8.1 Normative References ...................................11 89 8.2 Informative References .................................12 90 Author's Addresses .............................................12 91 Intellectual Property and Copyright Statements .................13 93 1. Introduction 95 IEEE 802.21 [IEEE802.21] defines three distinct service types to 96 facilitate link layer handovers across heterogeneous technologies: 98 a) Information Services (IS) 99 IS provides a unified framework to the higher layer entities 100 across the heterogeneous network environment to facilitate discovery 101 and selection of multiple types of networks existing within a 102 geographical area, with the objective to help the higher layer 104 Mobility Services DHCP Options September 2008 106 mobility protocols to acquire a global view of heterogeneous 107 networks and perform seamless handover across these networks. 109 b) Event Services (ES) 110 Events may indicate changes in state and transmission behavior 111 of the physical, data link and logical link layers, or predict state 112 changes of these layers. The Event Service may also be used to 113 indicate management actions or command status on the part of the 114 network or some management entity. 116 c) Command Services (CS) 117 The command service enables higher layers to control the 118 physical, data link, and logical link layers. The higher layers may 119 control the reconfiguration or selection of an appropriate link 120 through a set of handover commands. 122 In IEEE terminology these services are called Media Independent 123 Handover (MIH) services. While these services may be co-located, 124 the different pattern and type of information they provide does not 125 necessitate the co-location. 127 An MN may make use of any of these MIH service types separately or 128 any combination of them [MSFD]. In practice a Mobility Server may 129 not necessarily host all three of these MIH services together, thus 130 there is a need to discover the MIH services types separately. 132 This document defines a new DHCPv4 option called the MoS option, 133 which allows the MN to locate a Mobility Server which hosts the 134 desired service type (i.e. IS, ES or CS) as defined in [IEEE802.21]. 135 The MoS information type defines sub-options for different services. 136 This document also defines DHCPv6 options that allow the MN to 137 discover Mobility Servers hosting MIH services in different 138 deployment scenarios. Apart from manual configuration, this is one 139 of the possible solutions for locating a server providing Mobility 140 Services. 142 2. DHCPv4 Option for MoS Discovery 144 This section describes the MoS option for DHCPv4. Whether the MN 145 receives an MoS address from local or home network will depend on 146 the actual network deployment [MSFD]. The MoS option begins with a 147 option code followed by a length and sub-options. The value of the 148 length octet does not include itself or the option code. The option 149 layout is depicted below: 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Option Code | length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Sub-Option 1 | 157 Mobility Services DHCP Options October 2008 158 . . 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | ... | 161 . . 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Sub-Option n | 164 . . 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Option Code 169 OPTION-IPv4-MoS (To Be Assigned) - 1 byte 171 Length 173 An 8-bit field indicating the length of the option 174 excluding the 'Option Code' and the 'Length' fields 176 Sub-options 178 A series of DHCPv4 sub-options. 180 When the total length of a MoS option exceeds 254 octets, the 181 procedure outlined in [RFC3396] MUST be employed to split the 182 option into multiple, smaller options. 184 A sub-option begins with a sub-option Type followed by a length 185 and a `enc` field. The value of the length octet does not include 186 itself or the Sub-opt Type field. There are two types of encodings, 187 specified by the encoding byte ('enc') that follows the code byte. 188 If the encoding byte has the value 0, it is followed by a list of 189 domain names, as described below (Section 2.1). If the encoding byte 190 has the value 1, it is followed by one or more IPv4 addresses 191 (Section 2.2). 193 All implementations MUST support both encodings. A DHCP server MUST 194 NOT mix the two encodings in the same DHCP message, even if it sends 195 two different instances of the same option. Attempts to do so would 196 result in incorrect client behavior as DHCP processing rules call 197 for the concatenation of multiple instances of an option into a 198 single option prior to processing the option [RFC3396]. 200 The sub-option layout is depicted below: 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Sub-opt Type | length | enc | FQDN or . 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Mobility Services DHCP Options October 2008 209 +---------------------------------------------------------------+ 210 . IP Address . 211 . | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 The sub-option Types are summarized below. 215 +--------------+---------------+ 216 | Sub-opt | Service | 217 | Type* | Name | 218 +==============+===============+ 219 | 1 | IS | 220 +--------------+---------------+ 221 | 2 | ES | 222 +--------------+---------------+ 223 | 3 | IS and ES | 224 +--------------+---------------+ 225 | 4 | CS | 226 +--------------+---------------+ 227 | 5 | IS and CS | 228 +--------------+---------------+ 229 | 6 | ES and CS | 230 +--------------+---------------+ 231 | 7 | IS, CS and ES | 232 +--------------+---------------+ 234 *Note: The values `0` '8' to '255' are reserved and MUST NOT be used. 236 2.1 Domain Name List 238 If the 'enc' byte has a value of 0, the encoding byte is followed by 239 a sequence of labels, encoded according to Section 8 of [RFC3315], 240 quoted below: 242 So that domain names may be encoded uniformly, a domain name 243 or a list of domain names is encoded using the technique 244 described in section 3.1 of [RFC1035]. A domain name, or list 245 of domain names, in DHCP MUST NOT be stored in compressed form, 246 as described in section 4.1.4 of [RFC1035]. 248 [RFC1035] encoding was chosen to accommodate future international- 249 lized domain name mechanisms. The minimum length for this encoding 250 is 3. 252 The option MAY contain multiple domain names, but these SHOULD refer 253 to different NAPTR records, rather than different A records. The 254 client MUST try the records in the order listed, applying the 255 mechanism described in [MoS-DNS] for each. The client only resolves 257 Mobility Services DHCP Options October 2008 259 the subsequent domain names if attempts to contact the first one 260 failed or yielded no common transport protocols between the MN and 261 the server. 263 Use of multiple domain names is not meant to replace NAPTR and SRV 264 records, but rather to allow a single DHCP server to indicate MIH 265 servers operated by multiple providers. 267 The sub-option for this encoding has the following format: 269 Type Len enc DNS name of MoS server 270 +-----+---+---+-----+-----+-----+-----+-----+-- 271 |1..7 | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 272 +-----+---+---+-----+-----+-----+-----+-----+-- 274 As an example, consider the case where the server wants to offer 275 two MIH IS servers, "example.com" and "example.net". These would 276 be encoded as follows: 277 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 278 |1..7|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 279 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 280 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 281 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 282 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 284 2.2 IPv4 Address List 286 If the 'enc' byte has a value of 1, the encoding byte is followed by 287 a list of IPv4 addresses indicating appropriate MIH servers 288 available to the MN. Servers MUST be listed in order of preference. 290 Its minimum length is 5, and the length MUST be a multiple of 4 plus 291 one. The sub-option for this encoding has the following format: 293 Code Len enc IPv4 Address 1 IPv4 Address 2 294 +-----+---+---+-----+----+---+----+----+-- 295 |1..7 | n | 1 | a1 | a2 |a3 | a4 | a1 | ... 296 +-----+---+---+-----+----+---+----+----+-- 298 3. DHCPv6 Option for MoS discovery 300 This section introduces new DHCPv6 option used for MoS discovery. 302 Whether the MN receives an MoS address from local or home network 303 will depend on the actual network deployment [MSFD]. 305 Mobility Services DHCP Options October 2008 307 The MoS option begins with a option code followed by a length and 308 sub-options. The value of the length octet does not include itself 309 or the option code. The option layout is depicted below: 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Option Code | length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Sub-Option 1 | 316 . . 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | ... | 319 . . 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Sub-Option n | 322 . . 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Option Code 327 OPTION-IPv6-MoS (To Be Assigned) - 2 bytes 329 Length 331 A 16-bit field indicating the length of the option 332 excluding the 'Option Code' and the 'Length' fields. 334 Sub-options 336 A series of DHCPv6 sub-options. 338 The sub-options follow the same format (except the length value) and 339 'enc' rules as described in Section 2. The value of the length is 2- 340 octets and does not include itself or the Sub-opt Type field. The 341 sub-option layout is depicted below: 343 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | sub-opt Type | Length | enc | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 . FQDN or IP Address . 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Mobility Services DHCP Options October 2008 354 The sub-option Types are summarized below. 355 +--------------+---------------+ 356 | Sub-opt | Service | 357 | Type* | Name | 358 +==============+===============+ 359 | 1 | IS | 360 +--------------+---------------+ 361 | 2 | ES | 362 +--------------+---------------+ 363 | 3 | IS and ES | 364 +--------------+---------------+ 365 | 4 | CS | 366 +--------------+---------------+ 367 | 5 | IS and CS | 368 +--------------+---------------+ 369 | 6 | ES and CS | 370 +--------------+---------------+ 371 | 7 | IS, CS and ES | 372 +--------------+---------------+ 374 *Note: The values `0` '8' to '255' are reserved and MUST NOT be used. 376 4. Option Usage 378 4.1 Usage of DHCPv4 Options for MoS Discovery 380 The requesting and sending of the proposed DHCPv4 option follow the 381 rules for DHCP options in [RFC2131]. 383 4.1.1 Mobile Node behavior 385 The mobile node may perform the MoS information discovery procedure 386 either during initial association with a network or when the 387 mobility service is required. It may also try to perform the MoS 388 information discovery when it lacks the network information for MoS 389 or needs to change the MoS for some reasons, for instance, to 390 recover from the single point of failure of the existing MoS. 392 In order to acquire the MoS information, the mobile node MUST send 393 either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or 394 a unicast server address, respectively. In this message the mobile 395 node (DHCP client) MUST include the sub-opt Type for the MoS 396 Discovery in the sub-options field. 398 Mobility Services DHCP Options October 2009 400 4.1.2 DHCP Server behavior 402 When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message 403 with the MoS Discovery option in the options field, the DHCP server 404 MUST follow the [RFC2131] logic to construct either a DHCPOFFER or 405 DHCPACK message including the MoS Discovery option. The reply 406 message may contain the IP address or the FQDN of the MoS Server. 408 The DHCP server MUST always construct the response according to 409 the Sub-opt Type requested by the DHCP client. If set of FQDNs 410 in the response message turns out to be more than 256 bytes, 411 the DHCP server should send a reduced list of FQDNs so that they 412 fit into one sub option. 414 In case that the server cannot find any MoS information for a 415 specific MoS sub-opt Type, it MUST return the MoS option with a 416 sub-option by setting the sub-opt Type to the requested 417 sub-opt Type and the length of the sub-option to 1. 419 4.2 DHCPv6 Options for MoS discovery 421 The requesting and sending of the proposed DHCPv6 options follow the 422 rules for DHCP options in [RFC3315]. 424 4.2.1 Mobile node behavior 426 The mobile node may perform the MoS information discovery procedure 427 either during initial association with a network or when the 428 mobility service is required. It may also try to perform the MoS 429 information discovery when it lacks the network information for MoS 430 or needs to change the MoS for some reasons, for instance, to 431 recover from the single point of failure of the existing MoS 433 In order to acquire the MoS address, the mobile node MUST send either 434 a REQUEST or INFORMATION_REQUEST message to the All_DHCP_Servers 435 multicast address. In this message the mobile node (DHCP client) 436 MUST include the Option Code for the MoS Discovery option in the 437 option_code. 439 4.2.2 DHCP Server behavior 441 When the DHCP Server receives either REQUEST or INFORMATION-REQUEST 442 message the DHCP server MUST follow the following logic to construct 443 a REPLY message with the MoS Information option. 445 If the DHCP server has the requested MoS information, it MUST 446 include the information in the MoS Information option. The server 448 Mobility Services DHCP Options September 2008 450 may provide the matching information from the preconfigured 451 information available locally. The DHCP server MUST always 452 construct the response according to the Sub-Opt Type requested 453 by the DHCP client. 455 In case that the server cannot find any MoS information for a 456 specific MoS type, it MUST return the MoS option with 457 a sub-option by setting the Sub-opt Type to the requested Sub-opt 458 Type and the length of the sub-option to 1. 460 5. Security Considerations 462 The security considerations in [RFC2131] apply. If an adversary 463 manages to modify the response from a DHCP server or insert its own 464 response, an MN could be led to contact a rogue Mobility Server, 465 possibly one that then would provide wrong information, event or 466 command for handover. 468 It is recommended to use either DHCP authentication option described 469 in [RFC3118] where available, or rely upon link layer security. 471 This will also protect the denial of service attacks to DHCP 472 servers. [RFC3118] provides mechanisms for both entity authentication 473 and message authentication. 475 6. IANA Considerations 477 This document defines one new DHCPv4 option as described in section 478 2. 480 MoS Option for DHCPv4 (OPTION-IPv4-MoS) To Be Assigned 482 This document creates a new registry for the Sub-Option field in the 483 MoS DHCPv4 option called the "IEEE 802.21 Service Type" (Section 2). 484 IS 1 485 ES 2 486 IS and ES 3 487 CS 4 488 IS and CS 5 489 ES and CS 6 490 IS, CS and ES 7 492 The values '0', '8' to '255' are reserved and MUST NOT be used. New 493 values can be allocated by Standards Action or IESG approval. 495 This document also defines new DHCPv6 options as described in 496 section 3 498 Mobility Services DHCP Options October 2008 500 MoS Option for DHCPv6 (OPTION-IPv6-MoS) To Be Assigned 502 This document creates a new registry for the sub-option field in 503 the MoS DHCPv6 option called the "IEEE 802.21 Service Type" 504 (section 3). 506 IS 1 507 ES 2 508 IS and ES 3 509 CS 4 510 IS and CS 5 511 ES and CS 6 512 IS, CS and ES 7 514 The values '0', '8' to '255' are reserved and MUST NOT be used. New 515 Values can be allocated by Standards Action or IESG approval. 517 7. Acknowledgements 519 Authors would like to acknowledge the following individuals for 520 their valuable comments. 521 Bernie Volz, Vijay Devarapalli, Alfred Hoenes, Telemaco Melia, and 522 Yoshihiro Ohba 524 8. References 526 8.1 Normative References 528 [RFC1035] Mockapetris, P., "Domain names - implementation and 529 specification", STD 13, RFC 1035, November 1987. 531 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 532 2131, March 1997. 534 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 535 Droms et al, July 2003 537 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 539 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 540 RFC3396, November 2002. 542 [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)", 543 draft-ietf-mipshop-mstp-solution-08.txt (Work in Progress). 545 Mobility Services DHCP Options October 2008 547 8.2 Informative References 549 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 550 Networks: Media Independent Handover Services 552 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 553 draft-ietf-mipshop-mos-dns-discovery-04.txt (Work in Progress), 555 Authors' Addresses 557 Gabor Bajko 558 Nokia 559 e-mail: gabor.bajko@nokia.com 561 Subir Das 562 Telcordia Technologies Inc. 563 e-mail: subir@research.telcordia.com 565 Full Copyright Statement 567 Copyright (C) The IETF Trust (2008). 569 This document is subject to the rights, licenses and restrictions 570 contained in BCP 78, and except as set forth therein, the authors 571 retain all their rights. 573 This document and the information contained herein are provided on 574 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 575 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 576 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 577 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 578 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 579 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 580 FOR A PARTICULAR PURPOSE. 582 Mobility Services DHCP Options October 2008 584 Intellectual Property 586 The IETF takes no position regarding the validity or scope of any 587 Intellectual Property Rights or other rights that might be claimed 588 to pertain to the implementation or use of the technology described 589 in this document or the extent to which any license under such 590 rights might or might not be available; nor does it represent that 591 it has made any independent effort to identify any such rights. 592 Information on the procedures with respect to rights in RFC 593 documents can be found in BCP 78 and BCP 79. 595 Copies of IPR disclosures made to the IETF Secretariat and any 596 assurances of licenses to be made available, or the result of an 597 attempt made to obtain a general license or permission for the use 598 of such proprietary rights by implementers or users of this 599 specification can be obtained from the IETF on-line IPR repository 600 at http://www.ietf.org/ipr. 602 The IETF invites any interested party to bring to its attention any 603 copyrights, patents or patent applications, or other proprietary 604 rights that may cover technology that may be required to implement 605 this standard. Please address the information to the IETF at ietf- 606 ipr@ietf.org. 608 Acknowledgment 610 Funding for the RFC Editor function is provided by the IETF 611 Administrative Support Activity (IASA).