idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 25, 2009) is 5510 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) == Missing Reference: 'RFC 2131' is mentioned on line 464, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: September 24, 2009 Telcordia Technologies 6 March 25, 2009 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 IEEE 802.21 Mobility Services (MoS) Discovery 10 draft-ietf-mipshop-mos-dhcp-options-12 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 24, 2009. 35 Copyright and License Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines new Dynamic Host Configuration Protocol 49 (DHCPv4 and DHCPv6) options that contain a list IP addresses and a 50 list of domain names that can be mapped to servers providing IEEE 51 802.21 type of Mobility Service (MoS)[MSFD]. These Mobility 52 Services are used to assist an MN in handover preparation (network 53 discovery) and handover decision (network selection). The services 54 addressed in this document are the Media Independent Handover 55 Services defined in [IEEE802.21]. 57 (1) Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 61 this document are to be interpreted as described in RFC-2119. 63 (2) Terminology and abbreviations used in this document 65 Mobility Services: a set of different services provided by the 66 network to mobile nodes to facilitate handover preparation 67 and handover decision. In this document, Mobility Services refer to 68 the services defined in IEEE 802.21 specifications [IEEE802.21] 70 Mobility Server: a network node providing Mobility Support Services. 72 MIH: Media Independent Handover, as defined in [IEEE802.21]. 74 MIH Service: IS, ES or CS type of service, as defined in 75 [IEEE802.21] 77 Table of Contents 79 1. Introduction .................................................2 80 2. MoS IPv4 address option for DHCPv4............................3 81 3. MoS Domain Name List option for DHCPv4........................5 82 4. MoS IPv6 address option for DHCPv6............................7 83 5. MoS Domain Name List option for DHCPv6........................9 84 6. Option Usage.................................................10 85 6.1 Usage of MoS Options for DHCPv4........................10 86 6.2 Usage of MoS Options for DHCPv6........................11 87 7. Security Considerations .....................................12 88 8. IANA Considerations .........................................12 89 9. Acknowledgements ............................................13 90 10. References .................................................13 91 10.1 Normative References ..................................13 92 10.2 Informative References ................................13 93 Author's Addresses .............................................13 95 Mobility Services DHCP Options March 2009 97 1. Introduction 99 IEEE 802.21 [IEEE802.21] defines three distinct service types to 100 facilitate link layer handovers across heterogeneous technologies: 102 a) Information Services (IS) 103 IS provides a unified framework to the higher layer entities 104 across the heterogeneous network environment to facilitate 105 discovery and selection of multiple types of networks existing 106 within a geographical area, with the objective to help the higher 107 layer mobility protocols to acquire a global view of heterogeneous 108 networks and perform seamless handover across these networks. 110 b) Event Services (ES) 111 Events may indicate changes in state and transmission behavior 112 of the physical, data link and logical link layers, or predict state 113 changes of these layers. The Event Service may also be used to 114 indicate management actions or command status on the part of the 115 network or some management entity. 117 c) Command Services (CS) 118 The command service enables higher layers to control the 119 physical, data link, and logical link layers. The higher layers may 120 control the reconfiguration or selection of an appropriate link 121 through a set of handover commands. 123 In IEEE terminology these services are called Media Independent 124 Handover (MIH) services. While these services may be co-located, 125 the different pattern and type of information they provide does not 126 necessitate the co-location. 128 An MN may make use of any of these MIH service types separately or 129 any combination of them [MSFD]. In practice a Mobility Server may 130 not necessarily host all three of these MIH services together, thus 131 there is a need to discover the MIH services types separately. 133 This document defines new DHCPv4 and DHCPv6 options and sub-options 134 called the MoS IP Address and Domain Name List Options, which allow 135 the MN to locate a Mobility Server which hosts the desired service 136 type (i.e. IS, ES or CS) as defined in [IEEE802.21]. Apart from 137 manual configuration, this is one of the possible solutions for 138 locating a server providing Mobility Services. 140 2. MoS IPv4 Address Option for DHCPv4 142 This section describes the MoS IPv4 Address Option for DHCPv4. 143 Whether the MN receives an MoS address from local or home network 144 will depend on the actual network deployment [MSFD]. The MoS IPv4 145 Address Option begins with a option code followed by a length and 146 sub-options. The value of the length octet does not include itself 147 or the option code. The option layout is depicted below: 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Option Code | Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Sub-Option 1 | 154 . . 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | ... | 157 . . 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Sub-Option n | 160 . . 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Option Code 165 OPTION-IPv4_Address-MoS (To Be Assigned) - 1 byte 167 Length 169 An 8-bit field indicating the length of the option 170 excluding the 'Option Code' and the 'Length' fields 172 Sub-options 174 A series of DHCPv4 sub-options 176 When the total length of a MoS IPv4 Address Option exceeds 254 177 octets, the procedure outlined in [RFC3396] MUST be employed to 178 split the option into multiple, smaller options. 180 A sub-option begins with a sub-option code followed by a length 181 and one or more IPv4 addresses. The sub-option layout is 182 depicted below: 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Sub-opt Code | Length | IP Address . . . . . 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 . . 189 . | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 The sub-option Codes are summarized below. 193 +--------------+---------------+ 194 | Sub-opt | Service | 195 | Code* | Name | 196 +==============+===============+ 197 | 1 | IS | 198 +--------------+---------------+ 199 | 2 | CS | 200 +--------------+---------------+ 201 | 3 | ES | 202 +--------------+---------------+ 204 *Note: The values `0` '4' to '255' are reserved and MUST NOT be used. 206 If the length is followed by a list of IPv4 addresses indicating 207 appropriate MIH servers available to the MN, servers MUST be listed in 208 order of preference. Its minimum length is 4, and the length MUST be a 209 multiple of 4. The sub-option has the following format: 211 Code Len IPv4 Address 1 IPv4 Address 2 212 +-----+---+---+----+----+----+----+----+--- 213 |1..3 | n |a1 | a2 |a3 | a4 | a1 | ... 214 +-----+---+---+----+----+----+-----+----+-- 216 3. MoS Domain Name List Option for DHCPv4 218 This section describes the MoS Domain Name List Option for DHCPv4. 219 The general format of this option is depicted below: 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Option Code | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Sub-Option 1 | 226 . . 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ... | 229 . . 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Sub-Option n | 232 . . 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Option Code 237 OPTION-IPv4_FQDN-MoS (To Be Assigned) - 1 byte 239 Length 240 An 8-bit field indicating the length of the option 241 excluding the 'Option Code' and the 'Length' fields 243 Sub-options 245 A series of DHCPv4 sub-options. 247 When the total length of a MoS Domain Name List Option exceeds 254 248 octets, the procedure outlined in [RFC3396] MUST be employed to 249 split the option into multiple, smaller options. 251 A sub-option begins with a sub-option Code followed by a length 252 and one or more FQDNs. The sub-option layout is depicted below: 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Sub-opt Code | Length | FQDN(s) . . . . . . 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 . . 259 . | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 The sub-option Codes are summarized below. 263 +--------------+---------------+ 264 | Sub-opt | Service | 265 | Code* | Name | 266 +==============+===============+ 267 | 1 | IS | 268 +--------------+---------------+ 269 | 2 | CS | 270 +--------------+---------------+ 271 | 3 | ES | 272 +--------------+---------------+ 274 *Note: The values `0` '4' to '255' are reserved and MUST NOT be used. 276 Thus the sub-option for this encoding has the following format: 278 Code Len DNS name of MoS server 279 +-----+----+----+-----+-----+-----+-----+-- 280 |1..3 | n | s1 | s2 | s3 | s4 | s5 | ... 281 +-----+----+----+-----+-----+-----+-----+-- 283 The Sub-option begins with a sub-option code followed by a length 284 and a sequence of labels that are encoded according to Section 8 of 285 [RFC3315]. 287 The Sub-option MAY contain multiple domain names, but these should 288 Refer to the NAPTR records of different providers, rather than 289 different A records within the same provider. That is, the use of 290 multiple domain names is not meant to replace NAPTR and SRV records, 291 but rather to allow a single DHCP server to indicate MIH servers 292 operated by multiple providers. 294 The client MUST try the records in the order listed, applying the 295 mechanism described in [MoS-DNS] for each. The client only resolves 296 the subsequent domain names if attempts to contact the first one 297 failed or yielded no common transport protocols between the MN and 298 the server. 300 As an example, consider the case where the server wants to offer 301 two MIH IS servers, "example.com" and "example.net". These would 302 be encoded as follows: 303 +-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 304 |1..3 |26 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 305 +-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 306 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 307 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 308 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 310 4. MoS IPv6 Address Option for DHCPv6 312 This section describes the MoS IPv6 Address Option for DHCPv6. 313 Whether the MN receives an MoS address from local or home network 314 will depend on the actual network deployment [MSFD]. The MoS 315 Discovery Option begins with a option code followed by a length 316 and sub-options. The value of the length octet does not include 317 itself or the option code. The option layout is depicted below: 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Option Code | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Sub-Option 1 | 324 . . 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | ... | 327 . . 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Sub-Option n | 330 . . 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Option Code 334 OPTION-IPv6_Address-MoS (To Be Assigned) - 2 bytes 336 Length 338 A 16-bit field indicating the length of the option 339 excluding the 'Option Code' and the 'Length' fields. 341 Sub-options 343 A series of DHCPv6 sub-options 345 The sub-options follow the same format (except the Sub-opt Code and 346 Length value) as described in Section 2. The value of the Sub-opt 347 Code and Length are 2-octets and the Length does not include itself 348 or the Sub-opt Code field. The sub-option layout is depicted below: 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | sub-opt Code | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | IP Address | 355 . . 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 The sub-option Codes are summarized below. 359 +----------------+---------------+ 360 | Sub-opt Code* | Service Name | 361 +================+===============+ 362 | 1 | IS | 363 +----------------+---------------+ 364 | 2 | CS | 365 +----------------+---------------+ 366 | 3 | ES | 367 +----------------+---------------+ 368 *Note: The values `0` '4' to '65535' are reserved and MUST NOT be 369 used. 371 5. MoS Domain Name List option for DHCPv6 373 This section describes the MoS Domain List Option for DHCPv6. The 374 general format of this option for is depicted below: 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Option Code | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Sub-Option 1 | 381 . . 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | ... | 384 . . 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Sub-Option n | 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Option Code 392 OPTION-IPv6_FQDN-MoS (To Be Assigned) - 2 bytes 394 Length 396 A 16-bit field indicating the length of the option 397 excluding the 'Option Code' and the 'Length' fields. 399 Sub-options 401 A series of DHCPv6 sub-options 403 The Sub-options follow the same format (except the Sub-opt Code and 404 Length value) as described in Section 3. The value of the Sub-opt 405 Code and Length are 2-octets and the Length does not include itself 406 or the Sub-opt Code field. The sub-option layout is depicted below: 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | sub-opt Code | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | FQDN(s) | 413 . . 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 +----------------+---------------+ 417 | Sub-opt Code* | Service Name | 418 +================+===============+ 419 | 1 | IS | 420 +----------------+---------------+ 421 | 2 | CS | 422 +----------------+---------------+ 423 | 3 | ES | 424 +----------------+---------------+ 426 Mobility Services DHCP Options March 2009 428 *Note: The values `0` '4' to '65535' are reserved and MUST NOT be 429 used. 431 The sub-option Codes are summarized below. 433 The semantics and content of the DHCPv6 encoding of this option are 434 exactly the same as the encoding described in Section 3, except the 435 Option Code and Length value. 437 6. Option Usage 439 6.1 Usage of MoS Options for DHCPv4 441 The requesting and sending of the proposed DHCPv4 options follow 442 the rules for DHCP options in [RFC2131]. 444 6.1.1 Mobile Node behavior 446 The mobile node may perform a MoS discovery either during initial 447 association with a network or when the mobility service is required. 448 It may also try to perform the MoS discovery when it lacks the 449 network information for MoS or needs to change the MoS for some 450 reasons, for instance, to recover from the single point of failure 451 of the existing MoS. 453 In order to discover the IP address or domain name of a MoS Server, 454 the mobile node(DHCP client) MUST include either a MoS IPv4 Address 455 Option or a MoS Domain Name List Option in the respective DHCP 456 messages as defined in [RFC2131]. The requested options MUST 457 include one or more sub-option(s) with the Sub-opt Code(s) that 458 represents the service(s)the mobile node is interested in. 460 6.1.2 DHCP Server behavior 462 When the DHCP server receives either a MoS IPv4 Address Option or a 463 MoS Domain Name List Option, the DHCP server MUST always construct 464 the response messages (as defined in [RFC 2131]) according to the 465 sub-option code(s) representing the service(s) desired by the mobile 466 node in the Sub-option Code field(s). Each sub-option in a response 467 message may contain a list of one or more IP addresses or a list of 468 one or more FQDNs of the MoS server hosting the desired service. 470 In case that the server cannot find any Mobility Server satisfying 471 the requested Sub-opt Code, the server MUST return the MoS Option 472 with a sub-option by setting the Sub-opt Code to the requested 473 Sub-opt Code. 475 6.2 Usage of MoS Options for DHCPv6 477 The requesting and sending of the proposed DHCPv6 options follow 478 the rules for DHCP options in [RFC3315]. 480 6.2.1 Mobile node behavior 482 The mobile node may perform the MoS discovery either during initial 483 association with a network or when the mobility service is required. 484 It may also try to perform the MoS discovery when it lacks the 485 network information for MoS or needs to change the MoS for some 486 reasons, for instance, to recover from the single point of failure 487 of the existing MoS. 489 In order to discover the IP address or FQDN of a MoS, the mobile 490 node(DHCP client) MUST include either a MoS IPv6 Address Option 491 or a MoS Domain Name List Option in the respective DHCP messages 492 as defined in [RFC3315]. The requested MoS Option MUST 493 include one or more sub-option(s) with the Sub-opt Code(s) that 494 represents the service(s) the mobile node is interested in. 496 6.2.2 DHCP Server behavior 498 When the DHCP Server receives either a MoS IPv6 Address Option or 499 a MoS Domain Name List Option, the DHCP server MUST always construct 500 the response messages (as defined in RFC3315]), according to the sub- 501 option code(s) representing the service(s) desired by the mobile node 502 in the Sub-option code field(s). Each Sub-option in a response 503 message may contain a list of one or more IP addresses or a list of 504 one or more FQDNs of the MoS server hosting the desired service. 506 In case that the server cannot find any Mobility Server satisfying 507 the requested Sub-opt Code, the server MUST return the MoS Option 508 with a sub-option by setting the Sub-opt Code to the requested 509 Sub-opt Code. 511 7. Security Considerations 513 The security considerations in [RFC2131] apply. If an adversary 514 manages to modify the response from a DHCP server or insert its own 515 response, an MN could be led to contact a rogue Mobility Server, 516 possibly one that then would provide wrong information, event or 517 command for handover. 519 It is recommended to use either DHCP authentication option described 520 in [RFC3118] where available, or rely upon link layer security. 522 This will also protect the denial of service attacks to DHCP 523 servers. [RFC3118] provides mechanisms for both entity 524 authentication and message authentication. 526 8. IANA Considerations 528 This document defines two new DHCPv4 options as described in Sections 529 2 and 3. 531 MoS IPv4 Address Option for DHCPv4 (OPTION-IPv4_Address-MoS) TBA 533 MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS) TBA 535 This document creates a new registry for the Sub-Option fields in 536 the MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 537 Service Type" (Section 2 and 3). 539 IS 1 540 CS 2 541 ES 3 543 The values '0', '4' to '255' are reserved and MUST NOT be used. New 544 values can be allocated by Standards Action or IESG approval. 546 This document also defines two DHCPv6 options as described in 547 sections 4 and 5. 549 MoS IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-MoS) TBA 551 MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS) TBA 553 This document creates a new registry for the sub-option field in 554 the MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 555 Service Type" (Section 4 and 5). 557 IS 1 558 CS 2 559 ES 3 561 The values '0', '4' to '65535' are reserved and MUST NOT be used. 562 New Values can be allocated via Standards Action as defined 563 in [RFC5226]. 565 9. Acknowledgements 567 Authors would like to acknowledge the following individuals for 568 their valuable comments. 569 Alfred Hoenes, Bernie Volz, , David W. Hankins, Jari Arkko, 570 Telemaco Melia, Ralph Droms Ted Lemon Vijay Devarapalli, and 571 Yoshihiro Ohba 573 10. References 575 10.1 Normative References 577 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 578 2131, March 1997. 580 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 581 Droms et al, July 2003 583 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 585 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 586 RFC3396, November 2002. 588 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 589 IANA Considerations Section in RFCs" , May 2008. 591 [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)", 592 draft-ietf-mipshop-mstp-solution-12.txt (Work in Progress). 594 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 595 draft-ietf-mipshop-mos-dns-discovery-04.txt (Work in Progress), 597 10.2 Informative References 599 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 600 Networks: Media Independent Handover Services 602 Authors' Addresses 604 Gabor Bajko 605 Nokia 606 e-mail: gabor.bajko@nokia.com 608 Subir Das 609 Telcordia Technologies Inc. 610 e-mail: subir@research.telcordia.com