idnits 2.17.1 draft-bajko-mos-dhcp-options-02.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 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 688. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 == Line 220 has weird spacing: '...de Len enc ...' == Line 245 has weird spacing: '...e Len enc ...' == Line 569 has weird spacing: '... may provid...' -- 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 (February 8, 2008) is 5921 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 (~~), 4 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: Standards Track Subir Das 5 Expires: August 8, 2008 Telcordia 6 February 8, 2008 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Mobility Server (MoS) discovery 10 draft-bajko-mos-dhcp-options-02 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 August 8, 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 53 Mobility Services DHCP Options August 2007 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 57 this document are to be interpreted as described in RFC-2119. 59 Terminology and abbreviations used in this document 61 Mobility Services: comprises of a set of different services provided 62 by the network to mobile nodes to facilitate handover preparation 63 and handover decision. 65 Mobility Server: a network node providing Mobility Support Services. 67 MIH: Media Independent Handover, as defined in [IEEE802.21]. 69 MIH Service: IS, ES or CS type of service, as defined in 70 [IEEE802.21]. 72 Table of Content 74 1. Introduction ...................................................2 75 2. DHCPv4 Options for MoS Discovery................................3 76 2.1 Domain Name List .........................................4 77 2.2 IPv4 Address List ........................................5 78 3. DHCPv6 Options for MoS Discovery................................5 79 3.1 MoS Identifier Option.....................................6 80 3.2 IPv6 Relay Agent MoS Option...............................7 81 3.3 MoS Information Option....................................8 82 4. Option Usage...................................................10 83 4.1 Usage of DHCPv4 Options for MoS Discovery................10 84 4.2 Usage of DHCPv6 Options for MoS Discovery................11 85 5. Security Considerations .......................................11 86 6. IANA Considerations ...........................................11 87 7. Acknowledgements ..............................................12 88 8. Normative References ..........................................12 89 9. Informative References ........................................12 90 10. Author's Addresses ...........................................12 92 1. Introduction 94 IEEE 802.21 [IEEE802.21] defines three distinct service types to 95 facilitate link layer handovers across heterogeneous technologies: 97 a) Information Services (IS) 98 IS provides a unified framework to the higher layer entities 99 across the heterogeneous network environment to facilitate discovery 100 and selection of multiple types of networks existing within a 101 geographical area, with the objective to help the higher layer 102 mobility protocols to acquire a global view of the heterogeneous 103 networks and perform seamless handover across these networks. 105 b) Event Services (ES) 107 Mobility Services DHCP Options August 2007 109 Events may indicate changes in state and transmission behavior 110 of the physical, data link and logical link layers, or predict state 111 changes of these layers. The Event Service may also be used to 112 indicate management actions or command status on the part of the 113 network or some management entity. 115 c) Command Services (CS) 116 The command service enables higher layers to control the 117 physical, data link, and logical link layers. The higher layers may 118 control the reconfiguration or selection of an appropriate link 119 through a set of handover commands. 121 In IEEE terminology these services are called Media Independent 122 Handover (MIH) services. 123 While these services may be co-located, the different pattern and 124 type of information they provide does not necessitate the co- 125 location. 127 An MN may make use of any of these MIH service types separately or 128 any combination of them. 130 In practice a Mobility Server may not necessarily host all three of 131 these MIH services together, thus there is a need to discover the 132 MIH services types separately. 134 This document defines three dhcpv4 options, one for each of the 135 services defined in [IEEE802.21], which allow the MN to locate a 136 Mobility Server which hosts the desired service type (i.e. IS, ES or 137 CS). The document also defines three DHCPv6 options which allow the 138 MN to 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 Options for MoS Discovery 145 This section describes the three options for DHCPv4. 147 The DHCPv4 options for MoS discovery carry either a 32-bit (binary) 148 IPv4 address or, preferably, a DNS [RFC1035] fully-qualified domain 149 name (FQDN) to be used by the MN to locate a server hosting either 150 an IS, an ES or a CS MIH service. 152 The options have two encodings, specified by the encoding byte 153 ('enc') that follows the code byte. If the encoding byte has the 154 value 0, it is followed by a list of domain names, as described 155 below (Section 2.1). If the encoding byte has the value 1, it is 156 followed by one or more IPv4 addresses (Section 2.2). All 157 implementations MUST support both encodings. 158 A DHCP server MUST NOT mix the two encodings in the same DHCP 159 message, even if it sends two different instances of the same 160 option. Attempts to do so would result in incorrect client behavior 162 Mobility Services DHCP Options August 2007 164 as DHCP processing rules call for the concatenation of multiple 165 instances of an option into a single option prior to processing the 166 option [RFC3396]. 168 The code for the MIH IS option is XXX (to be assigned by IANA, TBD). 169 The code for the MIH ES option is YYY (to be assigned by IANA, TBD). 170 The code for the MIH CS option is ZZZ (to be assigned by IANA, TBD). 172 2.1 Domain Name List 174 If the 'enc' byte has a value of 0, the encoding byte is followed by 175 a sequence of labels, encoded according to Section 3.1 of [RFC1035], 176 quoted below: 178 Domain names in messages are expressed in terms of a sequence 179 of labels. Each label is represented as a one octet length 180 field followed by that number of octets. Since every domain 181 name ends with the null label of the root, a domain name is 182 terminated by a length byte of zero. The high order two bits of 183 every length octet must be zero, and the remaining six bits of 184 the length field limit the label to 63 octets or less. To 185 simplify implementations, the total length of a domain name 186 (i.e., label octets and label length octets) is restricted to 187 255 octets or less. 189 [RFC1035] encoding was chosen to accommodate future international- 190 lized domain name mechanisms. The minimum length for this encoding 191 is 3. 193 The option MAY contain multiple domain names, but these SHOULD refer 194 to different NAPTR records, rather than different A records. The 195 client MUST try the records in the order listed, applying the 196 mechanism described in [MoS-DNS] for each. The client only resolves 197 the subsequent domain names if attempts to contact the first one 198 failed or yielded no common transport protocols between the MN and 199 the server. 201 Use of multiple domain names is not meant to replace NAPTR and SRV 202 records, but rather to allow a single DHCP server to indicate MIH 203 servers operated by multiple providers. 205 Clients MUST support compression according to the encoding in 206 Section 4.1.4 of "Domain Names - Implementation And Specification" 207 [RFC1035]. 209 Since the domain names are supposed to be different domains, 210 compression will likely have little effect, however. 212 If the length of the domain list exceeds the maximum permissible 213 within a single option (254 octets), then the domain list MUST be 214 represented in the DHCP message as specified in [RFC3396]. 216 Mobility Services DHCP Options August 2007 218 The DHCP option for this encoding has the following format: 220 Code Len enc DNS name of MoS server 221 +-----+-----+-----+-----+-----+-----+-----+-----+-- 222 | XXX | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 223 +-----+-----+-----+-----+-----+-----+-----+-----+-- 225 As an example, consider the case where the server wants to offer two 226 MIH IS servers, "example.com" and "example.net". These would be 227 encoded as follows: 229 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 230 |XXX|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 231 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 233 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 234 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 236 2.2 IPv4 Address List 238 If the 'enc' byte has a value of 1, the encoding byte is followed by 239 a list of IPv4 addresses indicating appropriate MIH servers 240 available to the MN. Servers MUST be listed in order of preference. 242 Its minimum length is 5, and the length MUST be a multiple of 4 plus 243 one. The DHCP option for this encoding has the following format: 245 Code Len enc IPv4 Address 1 IPv4 Address 2 246 +-----+-----+-----+-----+-----+-----+-----+-----+-- 247 | XXX | n | 1 | a1 | a2 | a3 | a4 | a1 | ... 248 +-----+-----+-----+-----+-----+-----+-----+-----+-- 250 3. DHCPv6 Options for MoS discovery 252 This section introduces new DHCPv6 options used for MoS discovery. 254 Whether the MN receives an MoS address from local or home network 255 will depend on the actual network deployment. In general, following 256 rules apply to discovery rules: 258 a) In a split scenario, where the network access authentication is 259 independent of the home network authentication, the MN will discover 260 the MoS in the local (visited) network. 262 b) In an integrated scenario, where the network access 263 authentication is performed by the home network, the MN will 264 discover the MoS as per the home network policy, usually stored in 265 the subscription profile. When the policy dictates that an MoS 266 located in the home network has to be used, the address of the MoS 267 from the home network may be sent to a NAS (via AAA protocols) to 268 the visited network during the authentication procedure.DHCP relay 270 Mobility Services DHCP Options August 2007 272 agent may be provisioned accordingly to foward the MOS address to 273 the DHCP Server. 275 The DHCPv6 options defined in this section together with the 276 procedures defined in section 4 can support both scenarios. 278 3.1 MoS Identifier Option 280 This option is included in the Information-request message and used 281 to request the address of a specific (e.g., IS, ES, CS or its 282 combination) MoS-type from a DHCP server. 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | OPTION IPv6-MoS | option-len | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | MoS-type | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 option-code 293 OPTION_IPv6-MoS (TBD) - 2 bytes 295 option-len 297 2 bytes 299 MoS-Type 301 The type of Mobility Services the MN is looking for, 302 i.e. IS, ES or CS or a combination of these: 303 1 IS service 304 2 ES service 305 3 both IS and ES services 306 4 CS service 307 5 IS and CS services 308 6 ES and CS services 309 7 IS, ES and CS services 311 3.2 IPv6 Relay Agent MoS Option 313 This option carries the home network information which was 314 transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius-MoS, 315 TBD]. The DHCP relay agent sends this option to the DHCP server in 316 the Relay-forward Message. 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | OPTION_IPv6-MoS-RELAY | option-len | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Mobility Services DHCP Options August 2007 325 . sub-options . 326 . . 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 option-code 331 OPTION_IPv6-MoS-RELAY (TBD) - 2 bytes . 333 option-len 335 The length of sub-options 337 sub-options 339 A series of IPv6 Relay Agent sub-options. 341 3.2.1. IPv6 Relay Agent Sub-option 343 This sub-option carries the MoS information to the DHCP server. 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | sub-opt-code | sub-opt-len | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | MoS Type | | 350 +-+-+-+-+-+-+-+-+ MoS Information . 351 . . 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 sub-opt-code 356 A 16-bit unsigned integer for the type of the following 357 MoS Information field. Possible values are: 359 1 MoS IP address list 361 2 MoS FQDN list 363 sub-opt-len 365 1 + the length of MoS Information field. 367 MoS type 369 The type of MoS services the server supports. Valid 370 values: 371 1 IS service 372 2 ES service 373 3 both IS and ES services 374 4 CS service 375 5 IS and CS services 377 Mobility Services DHCP Options August 2007 379 6 ES and CS services 380 7 IS, ES and CS services 382 MoS Information 384 An MoS IP address or MoS FQDN to be provided to a mobile 385 node according to the sub-opt-code. 387 When the sub-opt-code is set to 1, the MoS Information field MUST 388 contain the 128-bit IPv6 address of the MoS. 390 When the sub-opt-code is set to 2, the MoS Information field MUST 391 contain the FQDN of the MoS as described in Section 8 of [RFC3315]. 393 Multiple sub-options may exist in a IPv6 Relay Agent option to carry 394 more than one MoS Information (IPv6 address or FQDN). 396 3.3 MoS Information Option 398 This option is included in the Reply message and used to carry MoS 399 information to the mobile node in the form of one or more of MoS IP 400 address(es) or MoS FQDN(s). 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | OPTION_IPv6-MoSINF | option-len | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 . sub-options . 407 . . 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 option-code 412 OPTION_IPv6-MoSINF (TBD).- 2 bytes 414 option-len 416 length of sub-options 418 sub-options 420 A series of MoS Information sub-options. 422 3.3.1 MoS Information Sub-option 424 This sub-option carries the assigned MoS information to the DHCP 425 client. 427 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 429 Mobility Services DHCP Options August 2007 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | sub-opt-code | sub-opt-len | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | MoS Type | | 435 +-+-+-+-+-+-+-+-+ + 436 . MoS Information . 437 . . 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 sub-opt-code 442 A 16-bit unsigned integer for the type of the following 443 MoS Information field. Possible values are: 445 1 MoS IP address 447 2 MoS FQDN 449 sub-opt-len 451 1 + length of MoS Information field. 453 MoS type 455 An 8 bit integer specifying the type of MoS services the 456 server supports. Valid values are: 458 0 NULL 459 1 IS service 460 2 ES service 461 3 both IS and ES services 462 4 CS services 463 5 IS and CS services 464 6 ES and CS services 465 7 IS, ES and CS services 467 MoS Information 469 An MoS IP address or MoS FQDN to be provided to a mobile 470 node according to the sub-opt-code. 472 The sub-opt-code, sub-opt-len and MoS Information fields are set in 473 the same manner as those of an IPv6 Relay Agent sub-option. 475 When MoS type equals NULL, the content of the MoS Information field 476 MUST be considered NULL. 478 4. Option Usage 480 4.1 Usage of DHCPv4 Options for MoS Discovery 481 Mobility Services DHCP Options August 2007 483 The requesting and sending of the proposed DHCPv4 options follow the 484 rules for DHCP options in [RFC2131]. 486 4.1.1 Mobile Node behavior 488 The mobile node may perform the MoS information discovery procedure 489 either during initial association with a network or when the 490 mobility service is required. It may also try to perform the MoS 491 information discovery when it lacks the network information for MoS 492 or needs to change the MoS for some reasons, for instance, to 493 recover from the single point of failure of the existing MoS. 495 In order to acquire the MoS information, the mobile node MUST send 496 either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or 497 a unicast server address, respectively. In this message the mobile 498 node (DHCP client) MUST include the Option Code for the MoS 499 Discovery in the options field. 501 4.1.2 DHCP Server behavior 503 When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message 504 with the MoS Discovery option in the options field, the DHCP server 505 MUST follow the [RFC2131] logic to construct either a DHCPOFFER or 506 DHCPACK message including the MoS Discovery option. The reply 507 message may contain the IP address or the FQDN of the MoS Server. 509 In case that the server cannot find any MoS information, it MUST 510 return the MoS Discovery option by setting the MoS Server address 511 0.0.0.0 with 'enc' 1. 513 4.2 DHCPv6 Options for MoS discovery 515 The requesting and sending of the proposed DHCPv6 options follow the 516 rules for DHCP options in [RFC3315]. 518 4.2.1 Mobile node behavior 520 The mobile node may perform the MoS information discovery procedure 521 either during initial association with a network or when the 522 mobility service is required. It may also try to perform the MoS 523 information discovery when it lacks the network information for MoS 524 or needs to change the MoS for some reasons, for instance, to 525 recover from the single point of failure of the existing MoS 527 In order to acquire the MoS address, the mobile node MUST send an 528 Information-request message to the All_DHCP_Relay_Agents_and_Servers 529 multicast address. In this message the mobile node (DHCP client) 530 MUST include the Option Code for the MoS Discovery option in the 531 option_code. 533 4.2.2 DHCP Relay Agent behavior 534 Mobility Services DHCP Options August 2007 536 Upon receiving the Information-request from the mobile node, the 537 DHCP relay agent MUST forward the message to the DHCP server as per 538 [RFC3315]. 539 If the relay agent determines that the AAAV/NAS has passed MoS 540 information for this mobile node and has available MoS information 541 for it, the relay agent MUST include the MoS information in the MIP6 542 Relay Agent option, and attach this option in the Relay-forward 543 message. 544 In case the relay agent does not maintain any MoS information for 545 the requesting mobile node, it simply forwards the received message 546 to the DHCP server according to the [RFC3315]. 548 Upon receiving a Relay-reply message from the DHCPv6 server, the 549 relay agent MUST follow the guidelines defined in [RFC3315]. The 550 relay agent extracts the Reply message from the Relay Message option 551 in the Relay-reply message and relays it to the mobile node. 553 4.2.3 DHCP Server behavior 555 When the DHCP Server receives the Information-request message with 556 the MoS Identifier option in the Relay-forward message, it looks for 557 a MIP6 Relay Agent Option containing MoS Information. The 558 Information-request message may not include the MIP6 Relay Agent 559 option in case there was no MoS information available at the NAS / 560 DHCP Relay Agent for a mobile node. 562 The DHCP server MUST follow the following logic to construct a Reply 563 message with the MoS Information option, and include the Reply 564 message in the payload of a Relay Message option of Relay-reply 565 message. 567 If the DHCP server has the requested MoS information, it MUST 568 include the information in the MoS Information option. The server 569 may provide the matching information either extracted from the MIP6 570 Relay Agent option or from the preconfigured information available 571 locally. 573 5. Security Considerations 575 The security considerations in [RFC2131] apply. If an adversary 576 manages to modify the response from a DHCP server or insert its own 577 response, an MN could be led to contact a rogue Mobility Server, 578 possibly one that then would provide wrong information, event or 579 command for handover. 581 It is recommended to use either DHCP authentication option described 582 in [RFC3118] where available, or rely upon link layer security. This 583 will also protect the denial of service attacks to DHCP servers. 584 [RFC3118] provides mechanisms for both entity authentication and 585 message authentication. 587 6. IANA Considerations 588 Mobility Services DHCP Options August 2007 590 This document registers the following dhcpv4 options with IANA: 592 IPv4-IS 593 IPv4-ES 594 IPv4-CS 596 This document also registers the following dhcpv6 options with IANA: 598 IPv6-MoSINF 599 IPv6-MoS 601 This document also registers the following dhcpv6 Relay options with 602 IANA: 604 IPv6-MoS-RELAY 606 7. Acknowledgements 608 Acknowledgements to the design team members for their comments. 610 8. Normative References 612 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 613 2131, March 1997. 615 [RFC1035] Mockapetris, P., "Domain names - implementation and 616 specification", STD 13, RFC 1035, November 1987. 618 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 619 RFC3396, November 2002. 621 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 623 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 624 Droms et al, July 2003 626 9. Informative References 628 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 629 Networks: Media Independent Handover Services 631 [MoS-DNS] Bajko, G. " Locating Mobility Servers", draft-bajko-mos- 632 dns-discovery-01, November 2007, work in progress. 634 10. Authors' Addresses 636 Gabor Bajko 638 Mobility Services DHCP Options August 2007 640 Nokia 641 gabor.bajko@nokia.com 643 Subir Das 644 Telcordia 645 subir@research.telcordia.com 647 Mobility Services DHCP Options August 2007 649 Full Copyright Statement 651 Copyright (C) The IETF Trust (2008). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 This document and the information contained herein are provided on 658 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 659 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 660 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 661 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 662 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 663 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 664 FOR A PARTICULAR PURPOSE. 666 Intellectual Property 668 The IETF takes no position regarding the validity or scope of any 669 Intellectual Property Rights or other rights that might be claimed 670 to pertain to the implementation or use of the technology described 671 in this document or the extent to which any license under such 672 rights might or might not be available; nor does it represent that 673 it has made any independent effort to identify any such rights. 674 Information on the procedures with respect to rights in RFC 675 documents can be found in BCP 78 and BCP 79. 677 Copies of IPR disclosures made to the IETF Secretariat and any 678 assurances of licenses to be made available, or the result of an 679 attempt made to obtain a general license or permission for the use 680 of such proprietary rights by implementers or users of this 681 specification can be obtained from the IETF on-line IPR repository 682 at http://www.ietf.org/ipr. 684 The IETF invites any interested party to bring to its attention any 685 copyrights, patents or patent applications, or other proprietary 686 rights that may cover technology that may be required to implement 687 this standard. Please address the information to the IETF at ietf- 688 ipr@ietf.org. 690 Acknowledgment 692 Funding for the RFC Editor function is provided by the IETF 693 Administrative Support Activity (IASA).