idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-14.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 14 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 (May 01, 2009) is 5473 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-04 -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: October 31, 2009 Telcordia Technologies 6 May 01, 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-14 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 October 31, 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 of IP addresses and 50 a 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 a mobile node (MN) in handover 53 preparation (network discovery) and handover decision (network 54 selection). The services addressed in this document are the Media 55 Independent Handover Services defined in [IEEE802.21]. 57 Table of Contents 59 1. Introduction ................................................2 60 2. MoS IPv4 address option for DHCPv4............................3 61 3. MoS Domain Name List option for DHCPv4........................5 62 4. MoS IPv6 address option for DHCPv6............................7 63 5. MoS Domain Name List option for DHCPv6........................9 64 6. Option Usage.................................................10 65 6.1 Usage of MoS Options for DHCPv4........................10 66 6.2 Usage of MoS Options for DHCPv6........................11 67 7. Security Considerations .....................................12 68 8. IANA Considerations .........................................12 69 9. Acknowledgements ............................................13 70 10. References .................................................13 71 10.1 Normative References ..................................13 72 10.2 Informative References ................................14 73 Author's Addresses .............................................14 75 (1) Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in RFC-2119. 81 (2) Terminology and abbreviations used in this document 83 Mobility Services: a set of services provided by the network to 84 mobile nodes to facilitate handover preparation and handover 85 decision. In this document, Mobility Services refer to 86 the services defined in IEEE 802.21 specifications [IEEE802.21] 88 Mobility Server: a network node providing Mobility Services. 90 MIH: Media Independent Handover, as defined in [IEEE802.21]. 92 MIH Service: IS, ES or CS type of service, as defined in 93 [IEEE802.21] 95 Mobility Services DHCP Options May 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 mobile node (MN) may make use of any of these MIH service types 129 separately or any combination of them [MSFD]. In practice a Mobility 130 Server may not necessarily host all three of these MIH services 131 together, thus there is a need to discover the MIH services types 132 separately. 134 This document defines new DHCPv4 and DHCPv6 options and sub-options 135 called the MoS IP Address and Domain Name List Options, which allow 136 the MN to locate a Mobility Server which hosts the 137 desired service type (i.e. IS, ES or CS) as defined in [IEEE802.21]. 138 Apart from manual configuration, this is one of the possible 139 solutions for locating a server providing Mobility Services. 141 2. MoS IPv4 Address Option for DHCPv4 143 This section describes the MoS IPv4 Address Option for DHCPv4. 144 Whether the MN receives an MoS address from local or home network 145 will depend on the actual network deployment [MSFD]. The MoS IPv4 146 Address Option begins with a option code followed by a length and 147 sub-options. The value of the length octet does not include itself 148 or the option code. The option layout is depicted below: 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Option Code | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Sub-Option 1 | 155 . . 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ... | 158 . . 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Sub-Option n | 161 . . 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Option Code 166 OPTION-IPv4_Address-MoS (To Be Assigned) - 1 byte 168 Length 170 An 8-bit field indicating the length of the option 171 excluding the 'Option Code' and the 'Length' fields 173 Sub-options 175 A series of DHCPv4 sub-options 177 When the total length of a MoS IPv4 Address Option exceeds 254 178 octets, the procedure outlined in [RFC3396] MUST be employed to 179 split the option into multiple, smaller options. 181 A sub-option begins with a sub-option code followed by a length 182 and one or more IPv4 addresses. The sub-option layout is 183 depicted below: 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Sub-opt Code | Length | IP Address . . . . . 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 . . 190 . | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 The sub-option Codes are summarized below. 194 +--------------+---------------+ 195 | Sub-opt | Service | 196 | Code* | Name | 197 +==============+===============+ 198 | 1 | IS | 199 +--------------+---------------+ 200 | 2 | CS | 201 +--------------+---------------+ 202 | 3 | ES | 203 +--------------+---------------+ 205 *Note: The values `0` and '4' to '255' are reserved. 207 If the length is followed by a list of IPv4 addresses indicating 208 appropriate MIH servers available to the MN for a requested option, 209 servers MUST be listed in order of preference and the client should 210 process them in decreasing order of preference. In case there is no 211 MIH server available, the length is set to 0, otherwise it is a 212 multiple of 4. 214 The sub-option has the following format: 216 Code Len IPv4 Address 1 IPv4 Address 2 217 +-----+---+---+----+----+----+----+----+--- 218 |1..3 | n |a1 | a2 |a3 | a4 | a1 | ... 219 +-----+---+---+----+----+----+-----+----+-- 221 3. MoS Domain Name List Option for DHCPv4 223 This section describes the MoS Domain Name List Option for DHCPv4. 224 The general format of this option is depicted below: 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Option Code | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Sub-Option 1 | 231 . . 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ... | 234 . . 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Sub-Option n | 237 . . 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Option Code 242 OPTION-IPv4_FQDN-MoS (To Be Assigned) - 1 byte 244 Length 245 An 8-bit field indicating the length of the option 246 excluding the 'Option Code' and the 'Length' fields 248 Sub-options 250 A series of DHCPv4 sub-options. 252 When the total length of a MoS Domain Name List Option exceeds 254 253 octets, the procedure outlined in [RFC3396] MUST be employed to 254 split the option into multiple, smaller options. 256 A sub-option begins with a sub-option Code followed by a length 257 and one or more FQDNs. The sub-option layout is depicted below: 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Sub-opt Code | Length | FQDN(s) . . . . . . 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 . . 264 . | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 The sub-option Codes are summarized below. 268 +--------------+---------------+ 269 | Sub-opt | Service | 270 | Code* | Name | 271 +==============+===============+ 272 | 1 | IS | 273 +--------------+---------------+ 274 | 2 | CS | 275 +--------------+---------------+ 276 | 3 | ES | 277 +--------------+---------------+ 279 *Note: The values `0` and '4' to '255' are reserved. 281 Thus the sub-option for this encoding has the following format: 283 Code Len DNS name of MoS server 284 +-----+----+----+-----+-----+-----+-----+-- 285 |1..3 | n | s1 | s2 | s3 | s4 | s5 | ... 286 +-----+----+----+-----+-----+-----+-----+-- 288 The Sub-option begins with a sub-option code followed by a length 289 and a sequence of labels that are encoded according to Section 8 of 290 [RFC3315]. 292 The Sub-option MAY contain multiple domain names, but these should 293 Refer to the NAPTR records of different providers, rather than 294 different A records within the same provider. That is, the use of 295 multiple domain names is not meant to replace NAPTR and SRV records, 296 but rather to allow a single DHCP server to indicate MIH servers 297 operated by multiple providers. 299 The client MUST try the records in the order listed, applying the 300 mechanism described in [MoS-DNS] for each. The client only resolves 301 the subsequent domain names if attempts to contact the first one 302 failed or yielded no common transport protocols between the MN and 303 the server. 305 As an example, consider the case where the server wants to offer 306 two MIH IS servers, "example.com" and "example.net". These would 307 be encoded as follows: 308 +-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 309 |1..3 |26 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 310 +-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 311 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 312 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 313 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 315 4. MoS IPv6 Address Option for DHCPv6 317 This section describes the MoS IPv6 Address Option for DHCPv6. 318 Whether the MN receives an MoS address from local or home network 319 will depend on the actual network deployment [MSFD]. The MoS 320 Discovery Option begins with a option code followed by a length 321 and sub-options. The value of the length octet does not include 322 itself or the option code. The option layout is depicted below: 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Option Code | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Sub-Option 1 | 329 . . 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | ... | 333 . . 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Sub-Option n | 336 . . 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Option Code 340 OPTION-IPv6_Address-MoS (To Be Assigned) - 2 bytes 342 Length 344 A 16-bit field indicating the length of the option 345 excluding the 'Option Code' and the 'Length' fields. 347 Sub-options 349 A series of DHCPv6 sub-options 351 The sub-options follow the same format (except the Sub-opt Code and 352 Length value) as described in Section 2. The value of the Sub-opt 353 Code and Length are 2-octets and the Length does not include itself 354 or the Sub-opt Code field. The sub-option layout is depicted below: 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | sub-opt Code | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | IP Address | 361 . . 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 The sub-option Codes are summarized below. 365 +----------------+---------------+ 366 | Sub-opt Code* | Service Name | 367 +================+===============+ 368 | 1 | IS | 369 +----------------+---------------+ 370 | 2 | CS | 371 +----------------+---------------+ 372 | 3 | ES | 373 +----------------+---------------+ 374 *Note: The values `0` and '4' to '65535' are reserved. 376 If the length is followed by a list of IPv6 addresses indicating 377 appropriate MIH servers available to the MN for a requested option, 378 servers MUST be listed in order of preference and the client should 379 process them in decreasing order of preference. In case there is no MIH 380 server available, the length is set to 0, otherwise it is a multiple of 381 16. 383 5. MoS Domain Name List option for DHCPv6 385 This section describes the MoS Domain List Option for DHCPv6. The 386 general format of this option for is depicted below: 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Option Code | Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Sub-Option 1 | 393 . . 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | ... | 396 . . 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Sub-Option n | 399 . . 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Option Code 404 OPTION-IPv6_FQDN-MoS (To Be Assigned) - 2 bytes 406 Length 408 A 16-bit field indicating the length of the option 409 excluding the 'Option Code' and the 'Length' fields. 411 Sub-options 413 A series of DHCPv6 sub-options 415 The Sub-options follow the same format (except the Sub-opt Code and 416 Length value) as described in Section 3. The value of the Sub-opt 417 Code and Length are 2-octets and the Length does not include itself 418 or the Sub-opt Code field. The sub-option layout is depicted below: 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | sub-opt Code | Length | 424 Mobility Services DHCP Options May 2009 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | FQDN(s) | 428 . . 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 The sub-option Codes are summarized below. 432 +----------------+---------------+ 433 | Sub-opt Code* | Service Name | 434 +================+===============+ 435 | 1 | IS | 436 +----------------+---------------+ 437 | 2 | CS | 438 +----------------+---------------+ 439 | 3 | ES | 440 +----------------+---------------+ 442 *Note: The values `0` and '4' to '65535' are reserved. 444 The semantics and content of the DHCPv6 encoding of this option are 445 exactly the same as the encoding described in Section 3, except the 446 Option Code and Length value. 448 6. Option Usage 450 6.1 Usage of MoS Options for DHCPv4 452 The requesting and sending of the proposed DHCPv4 options follow 453 the rules for DHCP options in [RFC2131]. 455 6.1.1 Mobile Node behavior 457 The mobile node may perform a MoS discovery either during initial 458 association with a network or when the mobility service is required. 459 It may also try to perform the MoS discovery when it lacks the 460 network information for MoS or needs to change the MoS for some 461 reasons, for instance, to recover from the single point of failure 462 of the existing MoS. 464 In order to discover the IP address or FQDN of a MoS, the mobile 465 node (DHCP client) MUST include either a MoS IPv4 Address Option 466 or a MoS Domain Name List Option in the Parameter Request List 467 (PRL) in the respective DHCP messages as defined in [RFC2131]. 469 The client MAY include a MoS IPv4 Address Option or a MoS Domain 470 Name List Option that includes one or more sub-option(s) with the 472 Sub-opt Code(s) that represents the service(s) the mobile node is 473 interested in. However, a client SHOULD be prepared to accept a 474 response from a server that includes other sub-option(s) or does 475 not include the requested sub-option(s). 477 6.1.2 DHCP Server behavior 479 When the DHCP Server receives either a MoS IPv4 Address Option or 480 a MoS Domain Name List Option in the PRL, the DHCP server MUST 481 include the option in its response message as defined in [RFC2131]. 483 A server MAY use the sub-options in the received MoS IPv4 Address 484 Option or MoS Domain Name List Option from the client's message 485 to restrict its response to the client requested sub-options. In 486 the case when the server cannot find any Mobility Server satisfying 487 a requested sub-option, the server SHOULD return the MoS Option 488 with that sub-option and the length of the sub-option set to 0. 490 6.2 Usage of MoS Options for DHCPv6 492 The requesting and sending of the proposed DHCPv6 options follow 493 the rules for DHCP options in [RFC3315]. 495 6.2.1 Mobile node behavior 497 The mobile node may perform the MoS discovery either during initial 498 association with a network or when the mobility service is required. 499 It may also try to perform the MoS discovery when it lacks the 500 network information for MoS or needs to change the MoS for some 501 reasons, for instance, to recover from the single point of failure 502 of the existing MoS. 504 In order to discover the IP address or FQDN of a MoS, the mobile 505 node (DHCP client) MUST include either a MoS IPv6 Address Option 506 or a MoS Domain Name List Option in the Option Request Option (ORO) 507 in the respective DHCP messages as defined in [RFC3315]. 509 The client MAY include a MoS IPv6 Address Option or a MoS Domain 510 Name List Option that includes one or more sub-option(s) with the 511 Sub-opt Code(s) that represents the service(s) the mobile node is 512 interested in. However, a client SHOULD be prepared to accept a 513 response from a server that includes other sub-option(s) or does 514 not include the requested sub-option(s). 516 6.2.2 DHCP Server behavior 518 When the DHCP Server receives either a MoS IPv6 Address Option or 519 a MoS Domain Name List Option in the ORO, the DHCP server MUST 520 include the option in its response message as defined in [RFC3315]. 522 A server MAY use the sub-options in the received MoS IPv6 Address 523 Option or MoS Domain Name List Option from the client's message 524 to restrict its response to the client requested sub-options. In 525 the case when the server cannot find any Mobility Server satisfying 526 a requested sub-option, the server SHOULD return the MoS Option 527 with that sub-option and the length of the sub-option set to 0. 529 7. Security Considerations 531 The security considerations in [RFC2131] apply. If an adversary 532 manages to modify the response from a DHCP server or insert its own 533 response, an MN could be led to contact a rogue Mobility Server, 534 possibly one that then would provide wrong information, event or 535 command for handover. 537 It is recommended to use either DHCP authentication option described 538 in [RFC3118] where available. This will also protect the denial of 539 service attacks to DHCP servers. [RFC3118] provides mechanisms for 540 both entity authentication and message authentication. 542 In deployments where DHCP authentication is not available, lower 543 layer security services may be sufficient to protect DHCP messages. 545 Regarding domain name resolution, it is recommended to consider the 546 usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational 547 Practices [RFC4641]. Security considerations described in [MoS-DNS] 548 also apply. 550 8. IANA Considerations 552 This document defines two new DHCPv4 options as described in Sections 553 2 and 3. 555 MoS IPv4 Address Option for DHCPv4 (OPTION-IPv4_Address-MoS) TBA 557 MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS) TBA 559 This document creates a new registry for the Sub-Option fields in 560 the MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 561 Service Type" (Section 2 and 3). 562 IS 1 563 CS 2 564 ES 3 566 The values '0', and '4' to '255' are reserved. New Values can be 567 allocated via Standards Action as defined in [RFC5226]. 569 This document also defines two DHCPv6 options as described in 570 sections 4 and 5. 572 MoS IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-MoS) TBA 574 MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS) TBA 576 This document creates a new registry for the sub-option field in 577 the MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 578 Service Type" (Section 4 and 5). 579 IS 1 580 CS 2 581 ES 3 583 The values '0', and '4' to '65535' are reserved. New Values can be 584 allocated via Standards Action as defined in [RFC5226]. 586 9. Acknowledgements 588 Authors would like to acknowledge the following individuals for 589 their valuable comments. 590 Alfred Hoenes, Bernie Volz, David W. Hankins, Jari Arkko, 591 Telemaco Melia, Ralph Droms Ted Lemon, Vijay Devarapalli, and 592 Yoshihiro Ohba 594 10. References 596 10.1 Normative References 598 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 599 2131, March 1997. 601 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 602 Droms et al, July 2003 604 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 606 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 607 RFC3396, November 2002. 609 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 610 Rose, "DNS Security Introduction and Requirements", RFC 4033, 611 March 2005. 613 [RFC5226] T. Narten and H. Alvestrand, "Guidelines for Writing an 614 IANA Considerations Section in RFCs" , May 2008. 616 [MSFD] T Melia, Ed., "Mobility Services Framework Design (MSFD)", 617 draft-ietf-mipshop-mstp-solution-12.txt (Work in Progress). 619 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 620 draft-ietf-mipshop-mos-dns-discovery-04.txt (Work in Progress), 622 10.2 Informative References 624 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 625 RFC 4641, September 2006. 627 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 628 Networks: Media Independent Handover Services. 630 Authors' Addresses 632 Gabor Bajko 633 Nokia 634 e-mail: gabor.bajko@nokia.com 636 Subir Das 637 Telcordia Technologies Inc. 638 e-mail: subir@research.telcordia.com