idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-04.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 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 913. 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 (July 11, 2008) is 5762 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP WG Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Proposed Standard Subir Das 5 Expires: January 11, 2009 Telcordia 6 July 11, 2008 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Mobility Server (MoS) discovery 10 draft-ietf-mipshop-mos-dhcp-options-04 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 January 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. DHCPv6 Options for MoS Discovery..............................6 80 3.1 IPv6 MoS Identifier Option..............................6 81 3.2 IPv6 MoS Information Option.............................7 82 4. Option Usage..................................................9 83 4.1 Usage of DHCPv4 Options for MoS Discovery...............9 84 4.2 Usage of DHCPv6 Options for MoS Discovery..............10 85 5. Security Considerations .....................................11 86 6. IANA Considerations .........................................11 87 7. Acknowledgements ............................................12 88 8. Appendix A: Relay Agent Option ..............................12 89 8.1 DHCPv4 Relay Agent MoS Option.........................12 90 8.2 IPv6 Relay Agent MoS Option...........................14 91 9. References ..................................................17 92 9.1 Normative References ...................................17 93 9.2 Informative References .................................17 94 Author's Addresses .............................................17 95 Intellectual Property and Copyright Statements .................18 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 discovery 105 and selection of multiple types of networks existing within a 106 geographical area, with the objective to help the higher layer 107 mobility protocols to acquire a global view of the heterogeneous 108 networks and perform seamless handover across these networks. 110 Mobility Services DHCP Options January 2009 112 b) Event Services (ES) 113 Events may indicate changes in state and transmission behavior 114 of the physical, data link and logical link layers, or predict state 115 changes of these layers. The Event Service may also be used to 116 indicate management actions or command status on the part of the 117 network or some management entity. 119 c) Command Services (CS) 120 The command service enables higher layers to control the 121 physical, data link, and logical link layers. The higher layers may 122 control the reconfiguration or selection of an appropriate link 123 through a set of handover commands. 125 In IEEE terminology these services are called Media Independent 126 Handover (MIH) services. While these services may be co-located, 127 the different pattern and type of information they provide does not 128 necessitate the co-location. 130 An MN may make use of any of these MIH service types separately or 131 any combination of them. In practice a Mobility Server may not 132 necessarily host all three of these MIH services together, thus there 133 is a need to discover the MIH services types separately. 135 This document defines a new dhcpv4 option called MoS option, which 136 allows the MN to locate a Mobility Server which hosts the desired 137 service type (i.e. IS, ES or CS)as defined in [IEEE802.21]. The MoS 138 information type defines sub-options for different services. The 139 document also defines DHCPv6 options which allow the MN to 140 discover Mobility Servers hosting MIH services in different 141 deployment scenarios. Apart from manual configuration, this is one 142 of the possible solutions for locating a server providing Mobility 143 Services. 145 2. DHCPv4 Option for MoS Discovery 147 This section describes the MoS option for DHCPv4. 148 The MoS option begins with a option code followed by a length and 149 sub-options. The value of the length octet does not include itself 150 or the option code. The option layout is depicted below: 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Option Code | length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Sub-Option 1 | 157 . . 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | ... | 160 . . 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Sub-Option n | 163 . . 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Mobility Services DHCP Options January 2009 168 Option Code 170 OPTION-IPv4-MoS (TBD) - 2 bytes 172 Length 174 2 bytes 175 Sub-options 177 A series of DHCPv4 sub-options. 179 When the total length of a MoS option exceeds 255 octets, the 180 Procedure outlined in [RFC3396] MUST be employed to split the 181 option into multiple, smaller options. 183 A sub-option begins with a sub-option Type followed by a length 184 and a `enc` field. The value of the length octet does not include 185 itself or the option code. There are two types of encodings, 186 specified by the encoding byte ('enc') that follows the code byte. 187 If the encoding byte has the value 0, it is followed by a list of 188 domain names, as described below (Section 2.1). If the encoding byte 189 has the value 1, it is followed by one or more IPv4 addresses 190 (Section 2.2). 192 All implementations MUST support both encodings. A DHCP server MUST 193 NOT mix the two encodings in the same DHCP message, even if it sends 194 two different instances of the same option. Attempts to do so would 195 result in incorrect client behavior as DHCP processing rules call 196 for the concatenation of multiple instances of an option into a 197 single option prior to processing the option [RFC3396]. 199 The sub-option layout is depicted below: 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Sub-opt Type | length | enc | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | FQDN or IP Address | 206 . . 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 The sub-option Types are summarized below. 210 +--------------+---------------+ 211 | Sub-opt | Service | 212 | Type* | Name | 213 +==============+===============+ 214 | 1 | IS | 215 +--------------+---------------+ 216 | 2 | ES | 217 +--------------+---------------+ 219 Mobility Services DHCP Options January 2009 221 +--------------+---------------+ 222 | 3 | IS and ES | 223 +--------------+---------------+ 224 | 4 | CS | 225 +--------------+---------------+ 226 | 5 | IS and CS | 227 +--------------+---------------+ 228 | 6 | ES and CS | 229 +--------------+---------------+ 230 | 7 | IS, CS and ES | 231 +--------------+---------------+ 233 *Note: The values `0` '8' to '255' are reserved and MUST NOT be 234 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 3.1 of [RFC1035], 240 quoted below: 242 Domain names in messages are expressed in terms of a sequence 243 of labels. Each label is represented as a one octet length 244 field followed by that number of octets. Since every domain 245 name ends with the null label of the root, a domain name is 246 terminated by a length byte of zero. The high order two bits of 247 every length octet must be zero, and the remaining six bits of 248 the length field limits the label to 63 octets or less. To 249 simplify implementations, the total length of a domain name 250 (i.e., label octets and label length octets) is restricted to 251 255 octets or less. 253 [RFC1035] encoding was chosen to accommodate future international- 254 lized domain name mechanisms. The minimum length for this encoding 255 is 3. 257 The option MAY contain multiple domain names, but these SHOULD refer 258 to different NAPTR records, rather than different A records. The 259 client MUST try the records in the order listed, applying the 260 mechanism described in [MoS-DNS] for each. The client only resolves 261 the subsequent domain names if attempts to contact the first one 262 failed or yielded no common transport protocols between the MN and 263 the server. 265 Use of multiple domain names is not meant to replace NAPTR and SRV 266 records, but rather to allow a single DHCP server to indicate MIH 267 servers operated by multiple providers. 269 The sub-option for this encoding has the following format: 271 Mobility Services DHCP Options January 2009 273 Type Len enc DNS name of MoS server 274 +-----+---+---+-----+-----+-----+-----+-----+-- 275 |1..7 | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 276 +-----+---+---+-----+-----+-----+-----+-----+-- 278 As an example, consider the case where the server wants to offer 279 two MIH IS servers, "example.com" and "example.net". These would 280 be encoded as follows: 281 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 282 |1..7|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 283 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 284 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 285 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 286 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 288 2.2 IPv4 Address List 290 If the 'enc' byte has a value of 1, the encoding byte is followed by 291 a list of IPv4 addresses indicating appropriate MIH servers 292 available to the MN. Servers MUST be listed in order of preference. 294 Its minimum length is 5, and the length MUST be a multiple of 4 plus 295 one. The sub-option for this encoding has the following format: 297 Code Len enc IPv4 Address 1 IPv4 Address 2 298 +-----+---+---+-----+----+---+----+----+-- 299 |1..7 | n | 1 | a1 | a2 |a3 | a4 | a1 | ... 300 +-----+---+---+-----+----+---+----+----+-- 302 3. DHCPv6 Options for MoS discovery 304 This section introduces new DHCPv6 options used for MoS discovery. 306 Whether the MN receives an MoS address from local or home network 307 will depend on the actual network deployment. 309 3.1 IPv6 MoS Identifier Option 311 This option is included in the Information-request message and used 312 to request the address of a specific (e.g., IS, ES, CS or any 313 combination) MoS-type from a DHCP server. 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Option Code | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | MoS-type | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Mobility Services DHCP Options January 2009 324 Option Code 326 OPTION-IPv6-MoS (TBD) - 2 bytes 328 Length 330 2 bytes 332 MoS-Type* 334 1 byte 336 The type of Mobility Services the MN is looking for, 337 i.e., IS, ES or CS or a combination of these: 339 +--------------+-------------- + 340 | MoS-type | MoS Name | 341 | value | | 342 +==============+===============+ 343 | 1 | IS | 344 +--------------+---------------+ 345 | 2 | ES | 346 +--------------+---------------+ 347 | 3 | IS and ES | 348 +--------------+---------------+ 349 | 4 | CS | 350 +--------------+---------------+ 351 | 5 | IS and CS | 352 +--------------+---------------+ 353 | 6 | ES and CS | 354 +--------------+---------------+ 355 | 7 | IS, CS and ES | 356 +--------------+---------------+ 357 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 358 used. 360 3.2 IPv6 MoS Information Option 362 This option is included in the Reply message and used to carry MoS 363 information to the mobile node in the form of one or more of MoS IP 364 address(es) or MoS FQDN(s). 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Option Code | Length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 . Sub-options . 371 . . 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Mobility Services DHCP Options January 2009 376 Option Code 377 OPTION-IPv6-MoSINF (TBD)- 2 bytes 379 Length 381 The length of sub-options 383 sub-options 385 A series of MoS Information sub-options. 387 3.2.1 MoS Information Sub-option 389 This sub-option carries the assigned MoS information to the DHCP 390 client. 392 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | sub-opt Code | Length | MoS Type | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 . MoS Information . 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Sub-opt Code 403 An 8-bit unsigned integer for the type of the following 404 MoS Information field. Possible values are: 406 1 MoS IP address 408 2 MoS FQDN 410 Length 412 1 + length of MoS Information field. 414 MoS-Type* 415 1 byte 417 The type of Mobility Services the MN is looking for, 418 i.e., IS, ES or CS or a combination of these: 420 +--------------+-------------- + 421 | MoS Type | MoS Name | 422 | value | | 423 +==============+===============+ 424 | 1 | IS | 425 +--------------+---------------+ 426 | 2 | ES | 427 +--------------+---------------+ 429 Mobility Services DHCP Options January 2009 431 +--------------+---------------+ 432 | 3 | IS and ES | 433 +--------------+---------------+ 434 | 4 | CS | 435 +--------------+---------------+ 436 | 5 | IS and CS | 437 +--------------+---------------+ 438 | 6 | ES and CS | 439 +--------------+---------------+ 440 | 7 | IS, CS and ES | 441 +--------------+---------------+ 443 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 444 used. 446 MoS Information 448 An MoS IP address or MoS FQDN to be provided to a mobile 449 node as indicated in the sub-opt-code. 451 When the sub-opt-code is set to 1, the MoS Information field MUST 452 contain the 128-bit IPv6 address of the MoS. 454 When the sub-opt-code is set to 2, the MoS Information field MUST 455 contain the FQDN of the MoS as described in Section 8 of [RFC3315]. 457 4. Option Usage 459 4.1 Usage of DHCPv4 Options for MoS Discovery 461 The requesting and sending of the proposed DHCPv4 option follow the 462 rules for DHCP options in [RFC2131]. 464 4.1.1 Mobile Node behavior 466 The mobile node may perform the MoS information discovery procedure 467 either during initial association with a network or when the 468 mobility service is required. It may also try to perform the MoS 469 information discovery when it lacks the network information for MoS 470 or needs to change the MoS for some reasons, for instance, to 471 recover from the single point of failure of the existing MoS. 473 In order to acquire the MoS information, the mobile node MUST send 474 either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or 475 a unicast server address, respectively. In this message the mobile 476 node (DHCP client) MUST include the sub-opt Type for the MoS 477 Discovery in the sub-options field. 479 Mobility Services DHCP Options January 2009 481 4.1.2 DHCP Server behavior 483 When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message 484 with the MoS Discovery option in the options field, the DHCP server 485 MUST follow the [RFC2131] logic to construct either a DHCPOFFER or 486 DHCPACK message including the MoS Discovery option. The reply 487 message may contain the IP address or the FQDN of the MoS Server. 489 The DHCP server MUST always construct the response according to 490 the Sub-opt Type requested by the DHCP client. 492 In case that the server cannot find any MoS information for a 493 specific MoS sub-opt Type, it MUST return the MoS option with a 494 sub-option by setting the sub-opt Type to the requested 495 sub-opt Type and the length of the sub-option to 1. 497 4.2 DHCPv6 Options for MoS discovery 499 The requesting and sending of the proposed DHCPv6 options follow the 500 rules for DHCP options in [RFC3315]. 502 4.2.1 Mobile node behavior 504 The mobile node may perform the MoS information discovery procedure 505 either during initial association with a network or when the 506 mobility service is required. It may also try to perform the MoS 507 information discovery when it lacks the network information for MoS 508 or needs to change the MoS for some reasons, for instance, to 509 recover from the single point of failure of the existing MoS 511 In order to acquire the MoS address, the mobile node MUST send an 512 Information-request message to the All_DHCP_Relay_Agents_and_Servers 513 multicast address. In this message the mobile node (DHCP client) 514 MUST include the Option Code for the MoS Discovery option in the 515 option_code. 517 4.2.3 DHCP Server behavior 519 When the DHCP Server receives the Information-request message the 520 DHCP server MUST follow the following logic to construct a Reply 521 message with the MoS Information option. 523 If the DHCP server has the requested MoS information, it MUST 524 include the information in the MoS Information option. The server 525 may provide the matching information from the preconfigured 526 information available locally. 528 Mobility Services DHCP Options January 2009 530 The DHCP server MUST always construct the response 531 according to the MoS Type requested by the DHCP client. 533 In case that the server cannot find any MoS information for a 534 specific MoS type, it MUST return the MoS Information option with 535 a sub-option by setting the MoS type to the requested MoS Type 536 and the length of the sub-option to 4. 538 5. Security Considerations 540 The security considerations in [RFC2131] apply. If an adversary 541 manages to modify the response from a DHCP server or insert its own 542 response, an MN could be led to contact a rogue Mobility Server, 543 possibly one that then would provide wrong information, event or 544 command for handover. 546 It is recommended to use either DHCP authentication option described 547 in [RFC3118] where available, or rely upon link layer security. 549 This will also protect the denial of service attacks to DHCP 550 servers.[RFC3118] provides mechanisms for both entity authentication 551 and message authentication. 553 6. IANA Considerations 555 This document defines one new DHCPv4 option as described in section 556 2. 558 MoS Option for DHCPv4 (OPTION-IPv4-MoS) TBD 560 This document creates a new registry for the Sub-Option field in the 561 MoS DHCPv4 option called the "MoS Service Type". 562 IS 1 563 ES 2 564 IS and ES 3 565 CS 4 566 IS and CS 5 567 ES and CS 6 568 IS, CS and ES 7 570 The values '0', '8' to '255' are reserved and MUST NOT be used. New 571 values can be allocated by Standards Action or IESG approval. 573 This document also defines new DHCPv6 options as described in 574 sections 3.1 and 3.2 576 IPv6-MoSINF (IPv6 MoS Information Option) TBD 577 IPv6-MoS (IPv6 MoS Identifier Option) TBD 579 Mobility Services DHCP Options January 2009 581 This document creates a new registry for the "MoS Type" field in 582 the IPv6 MoS Relay Agent Sub-option (section 3.2.1) and the MoS 583 Information Sub-option (section 3.3.1). 584 IS 1 585 ES 2 586 IS and ES 3 587 CS 4 588 IS and CS 5 589 ES and CS 6 590 IS, CS and ES 7 592 The values '0', '8' to '255' are reserved and MUST NOT be used. New 593 Values can be allocated by Standards Action or IESG approval. 595 7. Acknowledgements 597 Authors would like to acknowledge the following individuals for 598 their valuable comments. 599 Vijay Devarapalli, Telemaco Melia, and Yoshihiro Ohba 601 8. Appendix A 603 In case any network provider wants to provision the MOS address 604 during network access authentication it could do so if it defines 605 the required DHCP options and required DHCP-AAA interface. This 606 appendix is provided at assist any future standardization work if 607 need arises. The deployment scenario is presented in the appendix 608 of [MSFD]. The DHCP-based discovery in this scenario requires an 609 interaction between the DHCP and the AAA infrastructure. 611 8.1 DHCPv4 Relay Agent MoS Option 613 This option carries the home network MoS information which was 614 transferred to the NAS from AAAH. The DHCP relay agent inserts 615 this option when forwarding client-originated DHCP packets to 616 a DHCP server. 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Option Code | Length | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Sub-options | 623 . . 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Option-code 628 Mobility Services DHCP Options January 2009 630 OPTION-IPv4-MoS-RELAY (TBD) - 2 bytes 632 Length 634 The length of sub-options 636 Sub-options 638 A series of IPv4 Relay Agent sub-options. 640 When the total length of a Relay Agent MoS option exceeds 255 641 octets, the procedure outlined in [RFC3396] MUST be employed to 642 split the option into multiple, smaller options. 644 A sub-option begins with a sub-option Type followed by a length(N) 645 and sub-option value. The value of the length octet does not include 646 itself or the option code. Sub-option value has two encodings, 647 specified by the encoding byte ('enc')as described in Section 2.1 648 and Section 2.2. 650 8.1.1. IPv4 MoS Relay Agent Sub-option 652 The sub-option layout is depicted below: 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Sub-opt Type | length | enc | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | FQDN or IP Address | 659 . . 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 The sub-option Types are summarized below. 663 +--------------+---------------+ 664 | Sub-opt | Service | 665 | Type* | Name | 666 +==============+===============+ 667 | 1 | IS | 668 +--------------+---------------+ 669 | 2 | ES | 670 +--------------+---------------+ 671 | 3 | IS and ES | 672 +--------------+---------------+ 673 | 4 | CS | 674 +--------------+---------------+ 675 | 5 | IS and CS | 676 +--------------+---------------+ 677 | 6 | ES and CS | 678 +--------------+---------------+ 679 | 7 | IS, CS and ES | 680 +--------------+---------------+ 682 Mobility Services DHCP Options January 2009 684 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 685 used. 687 If the 'enc' byte has a value of 0, the encoding byte is followed by 688 a sequence of labels, encoded according to Section 3.1 of [RFC1035] 689 as described in Section 2.1. 691 If the 'enc' byte has a value of 1, the encoding byte is followed by 692 a list of IPv4 addresses indicating appropriate MIH servers 693 available to the MN as described in Section 2.2. 695 8.1.2 DHCPv4 Relay Agent behavior 697 Upon receiving the DHCP-REQUEST from the mobile node, the 698 DHCP relay agent MUST forward the message to the DHCP server as per 699 [RFC2131]. If the relay agent determines that the AAAV/NAS has 700 passed MoS information for this mobile node and has available MoS 701 information for it, the relay agent MUST include the MoS information 702 in the IPv4 Relay Agent MoS option, and insert this option in 703 client-originated DHCP packets to a DHCP server. In case the relay 704 agent does not maintain any MoS information for the requesting 705 mobile node, it simply forwards the received message 706 to the DHCP server according to the [RFC2131]. 708 The DHCP Server echoes the option back verbatim to the relay agent 709 in server-to-client replies, and the relay agent strips the option 710 before forwarding the reply to the client according to the [RFC2131]. 712 8.2 DHCPv6 Relay Agent MoS Option 714 This option carries the home network information which was 715 transferred to the NAS from AAAH. The DHCP relay agent sends this 716 option to the DHCP server in the Relay-forward Message. 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Option Code | Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Sub-options | 723 . . 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Option-code 728 OPTION-IPv6-MoS-RELAY (TBD) - 2 bytes 730 Mobility Services DHCP Options January 2009 732 Length 734 The length of sub-options 736 Sub-options 738 A series of IPv6 Relay Agent sub-options. 740 8.2.1. IPv6 MoS Relay Agent Sub-option 742 This sub-option carries the MoS information to the DHCP server. 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Sub-opt Code | Length | MoS Type | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 . MoS Information . 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Sub-opt-code 754 An 8-bit unsigned integer for the type of the following 755 MoS Information field. Possible values are: 757 1 MoS IP address list 759 2 MoS FQDN list 761 Length 763 1 + the length of MoS Information field. 765 MoS-Type* 766 1 byte 768 The type of Mobility Services the MN is looking for, 769 i.e., IS, ES or CS or a combination of these: 771 +--------------+-------------- + 772 | MoS Type | MoS Name | 773 | value | | 774 +==============+===============+ 775 | 1 | IS | 776 +--------------+---------------+ 777 | 2 | ES | 778 +--------------+---------------+ 779 | 3 | IS and ES | 780 +--------------+---------------+ 782 Mobility Services DHCP Options January 2009 784 +--------------+---------------+ 785 | 4 | CS | 786 +--------------+---------------+ 787 | 5 | IS and CS | 788 +--------------+---------------+ 789 | 6 | ES and CS | 790 +--------------+---------------+ 791 | 7 | IS, CS and ES | 792 +--------------+---------------+ 794 *Note: The values '0', '8' to '255' are reserved and MUST NOT be 795 used. 797 MoS Information 799 An MoS IP address or MoS FQDN. 801 When the sub-opt-code is set to 1, the MoS Information field MUST 802 contain the 128-bit IPv6 address of the MoS. 804 When the sub-opt-code is set to 2, the MoS Information field MUST 805 contain the FQDN of the MoS as described in Section 8 of [RFC3315]. 807 Multiple sub-options may exist in a IPv6 Relay Agent option to carry 808 more than one MoS Information (IPv6 address or FQDN). 810 The DHCP server MUST always construct the response according to 811 the Sub-opt Type requested by the DHCP client and not based upon 812 the Sub-opt Type that is inserted by the relay agent. 814 8.2.2 DHCP Relay Agent behavior 816 Upon receiving the Information-request from the mobile node, the 817 DHCP relay agent MUST forward the message to the DHCP server as per 818 [RFC3315]. 820 If the relay agent determines that the AAAV/NAS has passed MoS 821 information for this mobile node and has available MoS information 822 for it, the relay agent MUST include the MoS information in the IPv6 823 Relay Agent option, and attach this option in the Relay-forward 824 message. 826 In case the relay agent does not maintain any MoS information for 827 the requesting mobile node, it simply forwards the received message 828 to the DHCP server according to the [RFC3315]. 830 Mobility Services DHCP Options January 2009 832 9. References 834 9.1 Normative References 836 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 837 2131, March 1997. 839 [RFC1035] Mockapetris, P., "Domain names - implementation and 840 specification", STD 13, RFC 1035, November 1987. 842 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 843 RFC3396, November 2002. 845 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 847 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 848 Droms et al, July 2003 850 9.2 Informative References 852 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 853 Networks: Media Independent Handover Services 855 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 856 draft-ietf-mipshop-mos-dns-discovery, (Work in Progress), 857 May 2008. 859 [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)", 860 draft-ietf-mipshop-mstp-solution, (Work in Progress) 862 Authors' Addresses 864 Gabor Bajko 865 Nokia 866 e-mail: gabor.bajko@nokia.com 868 Subir Das 869 Telcordia Technologies Inc. 870 e-mail: subir@research.telcordia.com 872 Full Copyright Statement 874 Copyright (C) The IETF Trust (2008). 876 This document is subject to the rights, licenses and restrictions 877 contained in BCP 78, and except as set forth therein, the authors 878 retain all their rights. 880 Mobility Services DHCP Options January 2009 882 This document and the information contained herein are provided on 883 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 884 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 885 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 886 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 887 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 888 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 889 FOR A PARTICULAR PURPOSE. 891 Intellectual Property 893 The IETF takes no position regarding the validity or scope of any 894 Intellectual Property Rights or other rights that might be claimed 895 to pertain to the implementation or use of the technology described 896 in this document or the extent to which any license under such 897 rights might or might not be available; nor does it represent that 898 it has made any independent effort to identify any such rights. 899 Information on the procedures with respect to rights in RFC 900 documents can be found in BCP 78 and BCP 79. 902 Copies of IPR disclosures made to the IETF Secretariat and any 903 assurances of licenses to be made available, or the result of an 904 attempt made to obtain a general license or permission for the use 905 of such proprietary rights by implementers or users of this 906 specification can be obtained from the IETF on-line IPR repository 907 at http://www.ietf.org/ipr. 909 The IETF invites any interested party to bring to its attention any 910 copyrights, patents or patent applications, or other proprietary 911 rights that may cover technology that may be required to implement 912 this standard. Please address the information to the IETF at ietf- 913 ipr@ietf.org. 915 Acknowledgment 917 Funding for the RFC Editor function is provided by the IETF 918 Administrative Support Activity (IASA).