idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-03.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 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 932. 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 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE802.21]), 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 (June 22, 2008) is 5786 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 (-07) exists of draft-ietf-mipshop-mos-dns-discovery-01 Summary: 3 errors (**), 0 flaws (~~), 3 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: December 22, 2008 Telcordia 6 June 22, 2008 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Mobility Server (MoS) discovery 10 draft-ietf-mipshop-mos-dhcp-options-03 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 44 Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a 45 list of domain names or IP addresses that can be mapped to servers 46 providing IEEE 802.21 type of Mobility Services. These Mobility 47 Services are used to assist an MN in handover preparation (network 48 discovery) and handover decision (network selection). The services 49 addressed by this document are the Media Independent Handover 50 Services defined in [IEEE802.21]. 52 Conventions used in this document 54 Mobility Services DHCP Options December 2008 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. DHCPv4 Relay Agent MoS Option.................................6 80 3.2.1. IPv4 MoS Relay Agent Sub-option......................7 81 4. DHCPv6 Options for MoS Discovery..............................6 82 4.1 IPv6 MoS Identifier Option..............................6 83 4.2 IPv6 Relay Agent MoS Option.............................9 84 4.3 IPv6 MoS Information Option............................11 85 5. Option Usage.................................................13 86 5.1 Usage of DHCPv4 Options for MoS Discovery..............13 87 5.2 Usage of DHCPv6 Options for MoS Discovery..............14 88 6. Security Considerations .....................................15 89 7. IANA Considerations .........................................15 90 8. Acknowledgements ............................................16 91 9. Normative References ........................................16 92 10. Informative References .....................................17 93 11. Author's Addresses .........................................17 95 1. Introduction 97 IEEE 802.21 [IEEE802.21] defines three distinct service types to 98 facilitate link layer handovers across heterogeneous technologies: 100 a) Information Services (IS) 101 IS provides a unified framework to the higher layer entities 102 across the heterogeneous network environment to facilitate discovery 103 and selection of multiple types of networks existing within a 104 geographical area, with the objective to help the higher layer 105 mobility protocols to acquire a global view of the heterogeneous 106 networks and perform seamless handover across these networks. 108 Mobility Services DHCP Options December 2008 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. In practice a Mobility Server may not 130 necessarily host all three of these MIH services together, thus there 131 is a need to discover the MIH services types separately. 133 This document defines a new dhcpv4 option called MoS option, which 134 allows the MN to locate a Mobility Server which hosts the desired 135 service type (i.e. IS, ES or CS)as defined in [IEEE802.21]. The MoS 136 information type defines sub-options for different services. The 137 document also defines three DHCPv6 options which allow the MN to 138 discover Mobility Servers hosting MIH services in different 139 deployment scenarios. Apart from manual configuration, this is one 140 of the possible solutions for locating a server providing Mobility 141 Services. 143 2. DHCPv4 Option for MoS Discovery 145 This section describes the MoS option for DHCPv4. 146 The MoS 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 Mobility Services DHCP Options December 2008 166 Option Code 168 OPTION-IPv4-MoS (TBD) - 2 bytes 170 Length 172 2 bytes 173 Sub-options 175 A series of DHCPv4 sub-options. 177 When the total length of a MoS option exceeds 255 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(N) 182 and sub-option value. The value of the length octet does not include 183 itself or the option code. Sub-option value has two 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 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | FQDN or IP Address | 204 . . 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 The sub-option Types are summarized below. 208 +--------------+---------------+ 209 | Sub-opt | Service | 210 | Type* | Name | 211 +==============+===============+ 212 | 1 | IS | 213 +--------------+---------------+ 214 | 2 | ES | 215 +--------------+---------------+ 217 Mobility Services DHCP Options December 2008 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 232 used. 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 3.1 of [RFC1035], 238 quoted below: 240 Domain names in messages are expressed in terms of a sequence 241 of labels. Each label is represented as a one octet length 242 field followed by that number of octets. Since every domain 243 name ends with the null label of the root, a domain name is 244 terminated by a length byte of zero. The high order two bits of 245 every length octet must be zero, and the remaining six bits of 246 the length field limits the label to 63 octets or less. To 247 simplify implementations, the total length of a domain name 248 (i.e., label octets and label length octets) is restricted to 249 255 octets or less. 251 [RFC1035] encoding was chosen to accommodate future international- 252 lized domain name mechanisms. The minimum length for this encoding 253 is 3. 255 The option MAY contain multiple domain names, but these SHOULD refer 256 to different NAPTR records, rather than different A records. The 257 client MUST try the records in the order listed, applying the 258 mechanism described in [MoS-DNS] for each. The client only resolves 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 Mobility Services DHCP Options December 2008 271 Type Len enc DNS name of MoS server 272 +-----+---+---+-----+-----+-----+-----+-----+-- 273 |1..7 | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 274 +-----+---+---+-----+-----+-----+-----+-----+-- 276 As an example, consider the case where the server wants to offer 277 two MIH IS servers, "example.com" and "example.net". These would 278 be encoded as follows: 279 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 280 |1..7|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 281 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 282 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 283 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 284 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 286 2.2 IPv4 Address List 288 If the 'enc' byte has a value of 1, the encoding byte is followed by 289 a list of IPv4 addresses indicating appropriate MIH servers 290 available to the MN. Servers MUST be listed in order of preference. 292 Its minimum length is 5, and the length MUST be a multiple of 4 plus 293 one. The sub-option for this encoding has the following format: 295 Code Len enc IPv4 Address 1 IPv4 Address 2 296 +-----+---+---+-----+----+---+----+----+-- 297 |1..7 | n | 1 | a1 | a2 |a3 | a4 | a1 | ... 298 +-----+---+---+-----+----+---+----+----+-- 300 3. IPv4 Relay Agent MoS Option 302 This option carries the home network MoS information which was 303 transferred to the NAS from AAAH by using [MoS-AAA]. The DHCP 304 relay agent insert this option when forwarding client-originated 305 DHCP packets to a DHCP server. 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Option Code | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sub-options | 312 . . 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Option-code 317 OPTION-IPv4-MoS-RELAY (TBD) - 2 bytes 319 Mobility Services DHCP Options December 2008 321 Length 323 The length of sub-options 325 Sub-options 327 A series of IPv4 Relay Agent sub-options. 329 When the total length of a Relay Agent MoS option exceeds 255 330 octets, the procedure outlined in [RFC3396] MUST be employed to 331 split the option into multiple, smaller options. 333 A sub-option begins with a sub-option Type followed by a length(N) 334 and sub-option value. The value of the length octet does not include 335 itself or the option code. Sub-option value has two encodings, 336 specified by the encoding byte ('enc')as described in Section 2.1 337 and Section 2.2. 339 3.2.1. IPv4 MoS Relay Agent Sub-option 341 The 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Sub-opt Type | length | enc | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | FQDN or IP Address | 348 . . 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 The sub-option Types are summarized below. 352 +--------------+---------------+ 353 | Sub-opt | Service | 354 | Type* | Name | 355 +==============+===============+ 356 | 1 | IS | 357 +--------------+---------------+ 358 | 2 | ES | 359 +--------------+---------------+ 360 | 3 | IS and ES | 361 +--------------+---------------+ 362 | 4 | CS | 363 +--------------+---------------+ 364 | 5 | IS and CS | 365 +--------------+---------------+ 366 | 6 | ES and CS | 367 +--------------+---------------+ 368 | 7 | IS, CS and ES | 369 +--------------+---------------+ 371 Mobility Services DHCP Options December 2008 373 *Note: The values ?0?, '8' to '255' are reserved and MUST NOT be 374 used. 376 If the 'enc' byte has a value of 0, the encoding byte is followed by 377 a sequence of labels, encoded according to Section 3.1 of [RFC1035] 378 as described in Section 2.1. 380 If the 'enc' byte has a value of 1, the encoding byte is followed by 381 a list of IPv4 addresses indicating appropriate MIH servers 382 available to the MN as described in Section 2.2. 384 4. DHCPv6 Options for MoS discovery 386 This section introduces new DHCPv6 options used for MoS discovery. 388 Whether the MN receives an MoS address from local or home network 389 will depend on the actual network deployment. In general, following 390 rules apply to discovery rules: 391 a) In a split scenario, where the network access authentication is 392 independent of the home network authentication, the MN will discover 393 the MoS in the local (visited) network. 395 b) In an integrated scenario, where the network access 396 authentication is performed by the home network, the MN will 397 discover the MoS as per the home network policy, usually stored in 398 the subscription profile. When the policy dictates that an MoS 399 located in the home network has to be used, the address of the MoS 400 from the home network may be sent to a NAS (via AAA protocols) to 401 the visited network during the authentication procedure. A DHCP 402 relay agent may be provisioned accordingly to forward the MOS 403 address to the DHCP Server. 405 The DHCPv6 options defined in this section together with the 406 procedures defined in section 4 can support both scenarios. 408 4.1 IPv6 MoS Identifier Option 410 This option is included in the Information-request message and used 411 to request the address of a specific (e.g., IS, ES, CS or any 412 combination) MoS-type from a DHCP server. 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Option Code | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | MoS-type | Reserved | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Option Code 423 OPTION-IPv6-MoS (TBD) - 2 bytes 425 Mobility Services DHCP Options December 2008 427 Length 429 2 bytes 431 MoS-Type* 432 1 byte 434 The type of Mobility Services the MN is looking for, 435 i.e., IS, ES or CS or a combination of these: 437 +--------------+-------------- + 438 | MoS-type | MoS Name | 439 | value | | 440 +==============+===============+ 441 | 1 | IS | 442 +--------------+---------------+ 443 | 2 | ES | 444 +--------------+---------------+ 445 | 3 | IS and ES | 446 +--------------+---------------+ 447 | 4 | CS | 448 +--------------+---------------+ 449 | 5 | IS and CS | 450 +--------------+---------------+ 451 | 6 | ES and CS | 452 +--------------+---------------+ 453 | 7 | IS, CS and ES | 454 +--------------+---------------+ 455 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 456 used. 458 4.2 IPv6 Relay Agent MoS Option 460 This option carries the home network information which was 461 transferred to the NAS from AAAH by using [MoS-AAA]. The DHCP 462 relay agent sends this option to the DHCP server in the 463 Relay-forward Message. 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Option Code | Length | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Sub-options | 470 . . 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Mobility Services DHCP Options December 2008 475 Option-code 477 OPTION-IPv6-MoS-RELAY (TBD) - 2 bytes 479 Length 481 The length of sub-options 483 Sub-options 485 A series of IPv6 Relay Agent sub-options. 487 4.2.1. IPv6 MoS Relay Agent Sub-option 489 This sub-option carries the MoS information to the DHCP server. 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Sub-opt Code | Length | MoS Type | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 . MoS Information . 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Sub-opt-code 501 An 8-bit unsigned integer for the type of the following 502 MoS Information field. Possible values are: 504 1 MoS IP address list 506 2 MoS FQDN list 508 Length 510 1 + the length of MoS Information field. 512 MoS-Type* 513 1 byte 515 The type of Mobility Services the MN is looking for, 516 i.e., IS, ES or CS or a combination of these: 518 +--------------+-------------- + 519 | MoS Type | MoS Name | 520 | value | | 521 +==============+===============+ 522 | 1 | IS | 523 +--------------+---------------+ 524 | 2 | ES | 525 +--------------+---------------+ 526 | 3 | IS and ES | 527 +--------------+---------------+ 529 Mobility Services DHCP Options December 2008 531 +--------------+---------------+ 532 | 4 | CS | 533 +--------------+---------------+ 534 | 5 | IS and CS | 535 +--------------+---------------+ 536 | 6 | ES and CS | 537 +--------------+---------------+ 538 | 7 | IS, CS and ES | 539 +--------------+---------------+ 541 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 542 used. 544 MoS Information 546 An MoS IP address or MoS FQDN. 548 When the sub-opt-code is set to 1, the MoS Information field MUST 549 contain the 128-bit IPv6 address of the MoS. 551 When the sub-opt-code is set to 2, the MoS Information field MUST 552 contain the FQDN of the MoS as described in Section 8 of [RFC3315]. 554 Multiple sub-options may exist in a IPv6 Relay Agent option to carry 555 more than one MoS Information (IPv6 address or FQDN). 557 4.3 IPv6 MoS Information Option 559 This option is included in the Reply message and used to carry MoS 560 information to the mobile node in the form of one or more of MoS IP 561 address(es) or MoS FQDN(s). 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Option Code | Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 . Sub-options . 568 . . 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Option Code 573 OPTION-IPv6-MoSINF (TBD)- 2 bytes 575 Length 577 The length of sub-options 579 sub-options 581 A series of MoS Information sub-options. 583 Mobility Services DHCP Options December 2008 585 4.3.1 MoS Information Sub-option 587 This sub-option carries the assigned MoS information to the DHCP 588 client. 590 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | sub-opt Code | Length | MoS Type | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | | 596 . MoS Information . 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Sub-opt Code 601 An 8-bit unsigned integer for the type of the following 602 MoS Information field. Possible values are: 604 1 MoS IP address 606 2 MoS FQDN 608 Length 610 1 + length of MoS Information field. 612 MoS-Type* 613 1 byte 615 The type of Mobility Services the MN is looking for, 616 i.e., IS, ES or CS or a combination of these: 618 +--------------+-------------- + 619 | MoS Type | MoS Name | 620 | value | | 621 +==============+===============+ 622 | 1 | IS | 623 +--------------+---------------+ 624 | 2 | ES | 625 +--------------+---------------+ 626 | 3 | IS and ES | 627 +--------------+---------------+ 628 | 4 | CS | 629 +--------------+---------------+ 630 | 5 | IS and CS | 631 +--------------+---------------+ 632 | 6 | ES and CS | 633 +--------------+---------------+ 634 | 7 | IS, CS and ES | 635 +--------------+---------------+ 637 Mobility Services DHCP Options December 2008 639 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 640 used. 642 MoS Information 644 An MoS IP address or MoS FQDN to be provided to a mobile 645 node as indicated in the sub-opt-code. 647 The sub-opt-code, sub-opt-len and MoS Information fields are set in 648 the same manner as those of an IPv6 MoS Relay Agent sub-option. 650 5. Option Usage 652 5.1 Usage of DHCPv4 Options for MoS Discovery 654 The requesting and sending of the proposed DHCPv4 options follow the 655 rules for DHCP options in [RFC2131]. 657 5.1.1 Mobile Node behavior 659 The mobile node may perform the MoS information discovery procedure 660 either during initial association with a network or when the 661 mobility service is required. It may also try to perform the MoS 662 information discovery when it lacks the network information for MoS 663 or needs to change the MoS for some reasons, for instance, to 664 recover from the single point of failure of the existing MoS. 666 In order to acquire the MoS information, the mobile node MUST send 667 either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or 668 a unicast server address, respectively. In this message the mobile 669 node (DHCP client) MUST include the sub-opt Type for the MoS 670 Discovery in the sub-options field. 672 5.1.2 DHCP Server behavior 674 When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message 675 with the MoS Discovery option in the options field, the DHCP server 676 MUST follow the [RFC2131] logic to construct either a DHCPOFFER or 677 DHCPACK message including the MoS Discovery option. The reply 678 message may contain the IP address or the FQDN of the MoS Server. 680 The DHCP server MUST always construct the response according to 681 the Sub-opt Type requested by the DHCP client and not based upon 682 the Sub-opt Type that is inserted by the relay agent. 684 Mobility Services DHCP Options December 2008 686 In case that the server cannot find any MoS information for a 687 specific MoS sub-opt Type, it MUST return the MoS option with a 688 sub-option by setting the sub-opt Type to the requested 689 sub-opt Type and the length of the sub-option to 1. 691 5.1.3 DHCP Relay Agent behavior 693 Upon receiving the DHCP-REQUEST from the mobile node, the 695 DHCP relay agent MUST forward the message to the DHCP server as per 696 [RFC2131]. If the relay agent determines that the AAAV/NAS has 697 passed MoS information for this mobile node and has available MoS 698 information for it, the relay agent MUST include the MoS information 699 in the IPv4 Relay Agent MoS option, and insert this option in 700 client-originated DHCP packets to a DHCP server. In case the relay 701 agent does not maintain any MoS information for the requesting 702 mobile node, it simply forwards the received message 703 to the DHCP server according to the [RFC2131]. 705 Servers recognizing the IPv4 Agent MoS option may use the 706 information to implement MoS IP address or other parameter 707 assignment policies. The DHCP Server echoes the 708 option back verbatim to the relay agent in server-to-client replies, 709 and the relay agent strips the option before forwarding the reply to 710 the client according to the [RFC2131]. 712 5.2 DHCPv6 Options for MoS discovery 714 The requesting and sending of the proposed DHCPv6 options follow the 715 rules for DHCP options in [RFC3315]. 717 5.2.1 Mobile node behavior 719 The mobile node may perform the MoS information discovery procedure 720 either during initial association with a network or when the 721 mobility service is required. It may also try to perform the MoS 722 information discovery when it lacks the network information for MoS 723 or needs to change the MoS for some reasons, for instance, to 724 recover from the single point of failure of the existing MoS 726 In order to acquire the MoS address, the mobile node MUST send an 727 Information-request message to the All_DHCP_Relay_Agents_and_Servers 728 multicast address. In this message the mobile node (DHCP client) 729 MUST include the Option Code for the MoS Discovery option in the 730 option_code. 732 5.2.2 DHCP Relay Agent behavior 734 Upon receiving the Information-request from the mobile node, the 735 DHCP relay agent MUST forward the message to the DHCP server as per 736 [RFC3315]. 738 Mobility Services DHCP Options December 2008 740 If the relay agent determines that the AAAV/NAS has passed MoS 741 information for this mobile node and has available MoS information 742 for it, the relay agent MUST include the MoS information in the IPv6 743 Relay Agent option, and attach this option in the Relay-forward 744 message. 746 In case the relay agent does not maintain any MoS information for 747 the requesting mobile node, it simply forwards the received message 748 to the DHCP server according to the [RFC3315]. 750 Upon receiving a Relay-reply message from the DHCPv6 server, the 751 relay agent MUST follow the guidelines defined in [RFC3315]. The 752 relay agent extracts the Reply message from the Relay Message option 753 in the Relay-reply message and relays it to the mobile node. 755 5.2.3 DHCP Server behavior 757 When the DHCP Server receives the Information-request message with 758 the MoS Identifier option in the Relay-forward message, it looks for 759 a MIP6 Relay Agent Option containing MoS Information. The 760 Information-request message may not include the MIP6 Relay Agent 761 option in case there was no MoS information available at the NAS / 762 DHCP Relay Agent for a mobile node. 764 The DHCP server MUST follow the following logic to construct a Reply 765 message with the MoS Information option, and include the Reply 766 message in the payload of a Relay Message option of Relay-reply 767 message. 769 If the DHCP server has the requested MoS information, it MUST 770 include the information in the MoS Information option. The server 771 may provide the matching information either extracted from the IPv6 772 MOS Relay Agent option or from the preconfigured information 773 available locally. 775 The DHCP server MUST always construct the response 776 according to the MoS Type requested by the DHCP client and not 777 based upon the MoS Type that is inserted by the relay agent. 779 In case that the server cannot find any MoS information for a 780 specific MoS type, it MUST return the MoS Information option with 781 a sub-option by setting the MoS type to the requested MoS Type 782 and the length of the sub-option is to 4. 784 6. Security Considerations 786 The security considerations in [RFC2131] apply. If an adversary 787 manages to modify the response from a DHCP server or insert its own 788 response, an MN could be led to contact a rogue Mobility Server, 790 Mobility Services DHCP Options December 2008 792 possibly one that then would provide wrong information, event or 793 command for handover. 795 It is recommended to use either DHCP authentication option described 796 in [RFC3118] where available, or rely upon link layer security. 798 This will also protect the denial of service attacks to DHCP 799 servers.[RFC3118] provides mechanisms for both entity authentication 800 and message authentication. 802 7. IANA Considerations 804 This document defines one new DHCPv4 option as described in section 805 2. 807 MoS Option for DHCPv4 (OPTION-IPv4-MoS) TBD 808 Mos Option for DHCPv4 Relay (OPTION-IPV4-MoS-RELAY) TBD 810 This document creates a new registry for the Sub-Option field in the 811 MoS DHCPv4 option called the "MoS Service Type". 812 IS 1 813 ES 2 814 IS and ES 3 815 CS 4 816 IS and CS 5 817 ES and CS 6 818 IS, CS and ES 7 820 The values '0', '8' to '255' are reserved and MUST NOT be used. New 821 values can be allocated by Standards Action or IESG approval. 823 This document also defines three new DHCPv6 options as described in 824 sections 3.1 and 3.2 826 IPv6-MoSINF (IPv6 MoS Information Option) TBD 827 IPv6-MoS (IPv6 MoS Identifier Option) TBD 828 IPv6-MoS-RELAY (IPv6 Relay Agent MoS Option) TBD 830 This document creates a new registry for the "MoS Type" field in 831 the IPv6 MoS Relay Agent Sub-option (section 3.2.1) and the MoS 832 Information Sub-option (section 3.3.1). 833 IS 1 834 ES 2 835 IS and ES 3 836 CS 4 837 IS and CS 5 838 ES and CS 6 839 IS, CS and ES 7 841 The values '0', '8' to '255' are reserved and MUST NOT be used. New 842 Values can be allocated by Standards Action or IESG approval. 844 Mobility Services DHCP Options December 2008 846 8. Acknowledgements 848 Authors would like to acknowledge the following individuals for 849 their valuable comments. 850 Vijay Devarapalli, Telemaco Melia, and Yoshihiro Ohba 852 9. Normative References 854 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 855 2131, March 1997. 857 [RFC1035] Mockapetris, P., "Domain names - implementation and 858 specification", STD 13, RFC 1035, November 1987. 860 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 861 RFC3396, November 2002. 863 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 865 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 866 Droms et al, July 2003 868 10. Informative References 870 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 871 Networks: Media Independent Handover Services 873 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 874 draft-ietf-mipshop-mos-dns-discovery-01, (Work in Progress), 875 May 2008. 877 [MoS-AAA] Stuper, Patrick et.al, ?Diameter extensions for MoS 878 Discovery? draft-stupar-dime-mos-options-00? 879 (Work in progress), February, 2008 881 11. Authors' Addresses 883 Gabor Bajko 884 Nokia 885 e-mail: gabor.bajko@nokia.com 887 Subir Das 888 Telcordia Technologies Inc. 889 e-mail: subir@research.telcordia.com 891 Mobility Services DHCP Options December 2008 893 Full Copyright Statement 895 Copyright (C) The IETF Trust (2008). 897 This document is subject to the rights, licenses and restrictions 898 contained in BCP 78, and except as set forth therein, the authors 899 retain all their rights. 901 This document and the information contained herein are provided on 902 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 903 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 904 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 905 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 906 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 907 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 908 FOR A PARTICULAR PURPOSE. 910 Intellectual Property 912 The IETF takes no position regarding the validity or scope of any 913 Intellectual Property Rights or other rights that might be claimed 914 to pertain to the implementation or use of the technology described 915 in this document or the extent to which any license under such 916 rights might or might not be available; nor does it represent that 917 it has made any independent effort to identify any such rights. 918 Information on the procedures with respect to rights in RFC 919 documents can be found in BCP 78 and BCP 79. 921 Copies of IPR disclosures made to the IETF Secretariat and any 922 assurances of licenses to be made available, or the result of an 923 attempt made to obtain a general license or permission for the use 924 of such proprietary rights by implementers or users of this 925 specification can be obtained from the IETF on-line IPR repository 926 at http://www.ietf.org/ipr. 928 The IETF invites any interested party to bring to its attention any 929 copyrights, patents or patent applications, or other proprietary 930 rights that may cover technology that may be required to implement 931 this standard. Please address the information to the IETF at ietf- 932 ipr@ietf.org. 934 Acknowledgment 936 Funding for the RFC Editor function is provided by the IETF 937 Administrative Support Activity (IASA).