idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-00.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 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 656. 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 210 has weird spacing: '...de Len enc ...' == Line 235 has weird spacing: '...e Len enc ...' == Line 544 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 (April 19, 2008) is 5850 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) -- No information found for draft-ietf-mipshop - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: October 19, 2008 Telcordia 6 April 19, 2008 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Mobility Server (MoS) discovery 10 draft-ietf-mipshop-mos-dhcp-options-00 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 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 55 this document are to be interpreted as described in RFC-2119. 57 Terminology and abbreviations used in this document 59 Mobility Services: comprises of a set of different services provided 60 by the network to mobile nodes to facilitate handover preparation 61 and handover decision. 63 Mobility Server: a network node providing Mobility Support Services. 65 MIH: Media Independent Handover, as defined in [IEEE802.21]. 67 MIH Service: IS, ES or CS type of service, as defined in 68 [IEEE802.21]. 70 Table of Content 72 1. Introduction ...................................................2 73 2. DHCPv4 Options for MoS Discovery................................3 74 2.1 Domain Name List .........................................4 75 2.2 IPv4 Address List ........................................5 76 3. DHCPv6 Options for MoS Discovery................................5 77 3.1 MoS Identifier Option.....................................6 78 3.2 IPv6 Relay Agent MoS Option...............................7 79 3.3 MoS Information Option....................................8 80 4. Option Usage...................................................10 81 4.1 Usage of DHCPv4 Options for MoS Discovery................10 82 4.2 Usage of DHCPv6 Options for MoS Discovery................11 83 5. Security Considerations .......................................11 84 6. IANA Considerations ...........................................11 85 7. Acknowledgements ..............................................12 86 8. Normative References ..........................................12 87 9. Informative References ........................................12 88 10. Author's Addresses ...........................................12 90 1. Introduction 92 IEEE 802.21 [IEEE802.21] defines three distinct service types to 93 facilitate link layer handovers across heterogeneous technologies: 95 a) Information Services (IS) 96 IS provides a unified framework to the higher layer entities 97 across the heterogeneous network environment to facilitate discovery 98 and selection of multiple types of networks existing within a 99 geographical area, with the objective to help the higher layer 100 mobility protocols to acquire a global view of the heterogeneous 101 networks and perform seamless handover across these networks. 103 b) Event Services (ES) 104 Events may indicate changes in state and transmission behavior 105 of the physical, data link and logical link layers, or predict state 106 changes of these layers. The Event Service may also be used to 107 indicate management actions or command status on the part of the 108 network or some management entity. 110 c) Command Services (CS) 111 The command service enables higher layers to control the 112 physical, data link, and logical link layers. The higher layers may 113 control the reconfiguration or selection of an appropriate link 114 through a set of handover commands. 116 In IEEE terminology these services are called Media Independent 117 Handover (MIH) services. 118 While these services may be co-located, the different pattern and 119 type of information they provide does not necessitate the co- 120 location. 122 An MN may make use of any of these MIH service types separately or 123 any combination of them. 125 In practice a Mobility Server may not necessarily host all three of 126 these MIH services together, thus there is a need to discover the 127 MIH services types separately. 129 This document defines three dhcpv4 options, one for each of the 130 services defined in [IEEE802.21], which allow the MN to locate a 131 Mobility Server which hosts the desired service type (i.e. IS, ES or 132 CS). The document also defines three DHCPv6 options which allow the 133 MN to discover Mobility Servers hosting MIH services in different 134 deployment scenarios. Apart from manual configuration, this is one 135 of the possible solutions for locating a server providing Mobility 136 Services. 138 2. DHCPv4 Options for MoS Discovery 140 This section describes the three options for DHCPv4. 142 The DHCPv4 options for MoS discovery carry either a 32-bit (binary) 143 IPv4 address or, preferably, a DNS [RFC1035] fully-qualified domain 144 name (FQDN) to be used by the MN to locate a server hosting either 145 an IS, an ES or a CS MIH service. 147 The options have two encodings, specified by the encoding byte 148 ('enc') that follows the code byte. If the encoding byte has the 149 value 0, it is followed by a list of domain names, as described 150 below (Section 2.1). If the encoding byte has the value 1, it is 151 followed by one or more IPv4 addresses (Section 2.2). All 152 implementations MUST support both encodings. 153 A DHCP server MUST NOT mix the two encodings in the same DHCP 154 message, even if it sends two different instances of the same 155 option. Attempts to do so would result in incorrect client behavior 156 as DHCP processing rules call for the concatenation of multiple 157 instances of an option into a single option prior to processing the 158 option [RFC3396]. 160 The code for the MIH IS option is XXX (to be assigned by IANA, TBD). 161 The code for the MIH ES option is YYY (to be assigned by IANA, TBD). 162 The code for the MIH CS option is ZZZ (to be assigned by IANA, TBD). 164 2.1 Domain Name List 166 If the 'enc' byte has a value of 0, the encoding byte is followed by 167 a sequence of labels, encoded according to Section 3.1 of [RFC1035], 168 quoted below: 170 Domain names in messages are expressed in terms of a sequence 171 of labels. Each label is represented as a one octet length 172 field followed by that number of octets. Since every domain 173 name ends with the null label of the root, a domain name is 174 terminated by a length byte of zero. The high order two bits of 175 every length octet must be zero, and the remaining six bits of 176 the length field limit the label to 63 octets or less. To 177 simplify implementations, the total length of a domain name 178 (i.e., label octets and label length octets) is restricted to 179 255 octets or less. 181 [RFC1035] encoding was chosen to accommodate future international- 182 lized domain name mechanisms. The minimum length for this encoding 183 is 3. 185 The option MAY contain multiple domain names, but these SHOULD refer 186 to different NAPTR records, rather than different A records. The 187 client MUST try the records in the order listed, applying the 188 mechanism described in [MoS-DNS] for each. The client only resolves 189 the subsequent domain names if attempts to contact the first one 190 failed or yielded no common transport protocols between the MN and 191 the server. 193 Use of multiple domain names is not meant to replace NAPTR and SRV 194 records, but rather to allow a single DHCP server to indicate MIH 195 servers operated by multiple providers. 197 Clients MUST support compression according to the encoding in 198 Section 4.1.4 of "Domain Names - Implementation And Specification" 199 [RFC1035]. 201 Since the domain names are supposed to be different domains, 202 compression will likely have little effect, however. 204 If the length of the domain list exceeds the maximum permissible 205 within a single option (254 octets), then the domain list MUST be 206 represented in the DHCP message as specified in [RFC3396]. 208 The DHCP option for this encoding has the following format: 210 Code Len enc DNS name of MoS server 211 +-----+-----+-----+-----+-----+-----+-----+-----+-- 212 | XXX | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 213 +-----+-----+-----+-----+-----+-----+-----+-----+-- 215 As an example, consider the case where the server wants to offer two 216 MIH IS servers, "example.com" and "example.net". These would be 217 encoded as follows: 219 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 220 |XXX|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 221 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 222 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 224 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 226 2.2 IPv4 Address List 228 If the 'enc' byte has a value of 1, the encoding byte is followed by 229 a list of IPv4 addresses indicating appropriate MIH servers 230 available to the MN. Servers MUST be listed in order of preference. 232 Its minimum length is 5, and the length MUST be a multiple of 4 plus 233 one. The DHCP option for this encoding has the following format: 235 Code Len enc IPv4 Address 1 IPv4 Address 2 236 +-----+-----+-----+-----+-----+-----+-----+-----+-- 237 | XXX | n | 1 | a1 | a2 | a3 | a4 | a1 | ... 238 +-----+-----+-----+-----+-----+-----+-----+-----+-- 240 3. DHCPv6 Options for MoS discovery 242 This section introduces new DHCPv6 options used for MoS discovery. 244 Whether the MN receives an MoS address from local or home network 245 will depend on the actual network deployment. In general, following 246 rules apply to discovery rules: 248 a) In a split scenario, where the network access authentication is 249 independent of the home network authentication, the MN will discover 250 the MoS in the local (visited) network. 252 b) In an integrated scenario, where the network access 253 authentication is performed by the home network, the MN will 254 discover the MoS as per the home network policy, usually stored in 255 the subscription profile. When the policy dictates that an MoS 256 located in the home network has to be used, the address of the MoS 257 from the home network may be sent to a NAS (via AAA protocols) to 258 the visited network during the authentication procedure. A DHCP relay 259 agent may be provisioned accordingly to foward the MOS address to 260 the DHCP Server. 262 The DHCPv6 options defined in this section together with the 263 procedures defined in section 4 can support both scenarios. 265 3.1 MoS Identifier Option 267 This option is included in the Information-request message and used 268 to request the address of a specific (e.g., IS, ES, CS or its 269 combination) MoS-type from a DHCP server. 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | OPTION IPv6-MoS | option-len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | MoS-type | Reserved | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 option-code 280 OPTION_IPv6-MoS (TBD) - 2 bytes 282 option-len 284 2 bytes 286 MoS-Type 288 The type of Mobility Services the MN is looking for, 289 i.e. IS, ES or CS or a combination of these: 290 1 IS service 291 2 ES service 292 3 both IS and ES services 293 4 CS service 294 5 IS and CS services 295 6 ES and CS services 296 7 IS, ES and CS services 298 3.2 IPv6 Relay Agent MoS Option 300 This option carries the home network information which was 301 transferred to the NAS from AAAH by using [I-D.ietf-mip6-radius-MoS, 302 TBD]. The DHCP relay agent sends this option to the DHCP server in 303 the Relay-forward Message. 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | OPTION_IPv6-MoS-RELAY | option-len | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 . sub-options . 310 . . 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 option-code 315 OPTION_IPv6-MoS-RELAY (TBD) - 2 bytes . 317 option-len 319 The length of sub-options 321 sub-options 323 A series of IPv6 Relay Agent sub-options. 325 3.2.1. IPv6 Relay Agent Sub-option 327 This sub-option carries the MoS information to the DHCP server. 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | sub-opt-code | sub-opt-len | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | MoS Type | | 334 +-+-+-+-+-+-+-+-+ MoS Information . 335 . . 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 sub-opt-code 340 A 16-bit unsigned integer for the type of the following 341 MoS Information field. Possible values are: 343 1 MoS IP address list 345 2 MoS FQDN list 347 sub-opt-len 349 1 + the length of MoS Information field. 351 MoS type 353 The type of MoS services the server supports. Valid 354 values: 355 1 IS service 356 2 ES service 357 3 both IS and ES services 358 4 CS service 359 5 IS and CS services 360 6 ES and CS services 361 7 IS, ES and CS services 363 MoS Information 365 An MoS IP address or MoS FQDN to be provided to a mobile 366 node according to the sub-opt-code. 368 When the sub-opt-code is set to 1, the MoS Information field MUST 369 contain the 128-bit IPv6 address of the MoS. 371 When the sub-opt-code is set to 2, the MoS Information field MUST 372 contain the FQDN of the MoS as described in Section 8 of [RFC3315]. 374 Multiple sub-options may exist in a IPv6 Relay Agent option to carry 375 more than one MoS Information (IPv6 address or FQDN). 377 3.3 MoS Information Option 379 This option is included in the Reply message and used to carry MoS 380 information to the mobile node in the form of one or more of MoS IP 381 address(es) or MoS FQDN(s). 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | OPTION_IPv6-MoSINF | option-len | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 . sub-options . 388 . . 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 option-code 393 OPTION_IPv6-MoSINF (TBD).- 2 bytes 395 option-len 397 length of sub-options 399 sub-options 401 A series of MoS Information sub-options. 403 3.3.1 MoS Information Sub-option 405 This sub-option carries the assigned MoS information to the DHCP 406 client. 408 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | sub-opt-code | sub-opt-len | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | MoS Type | | 414 +-+-+-+-+-+-+-+-+ + 415 . MoS Information . 416 . . 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 sub-opt-code 421 A 16-bit unsigned integer for the type of the following 422 MoS Information field. Possible values are: 424 1 MoS IP address 426 2 MoS FQDN 428 sub-opt-len 430 1 + length of MoS Information field. 432 MoS type 434 An 8 bit integer specifying the type of MoS services the 435 server supports. Valid values are: 437 0 NULL 438 1 IS service 439 2 ES service 440 3 both IS and ES services 441 4 CS services 442 5 IS and CS services 443 6 ES and CS services 444 7 IS, ES and CS services 446 MoS Information 448 An MoS IP address or MoS FQDN to be provided to a mobile 449 node according to the sub-opt-code. 451 The sub-opt-code, sub-opt-len and MoS Information fields are set in 452 the same manner as those of an IPv6 Relay Agent sub-option. 454 When MoS type equals NULL, the content of the MoS Information field 455 MUST be considered NULL. 457 4. Option Usage 459 4.1 Usage of DHCPv4 Options for MoS Discovery 460 The requesting and sending of the proposed DHCPv4 options follow the 461 rules for DHCP options in [RFC2131]. 463 4.1.1 Mobile Node behavior 465 The mobile node may perform the MoS information discovery procedure 466 either during initial association with a network or when the 467 mobility service is required. It may also try to perform the MoS 468 information discovery when it lacks the network information for MoS 469 or needs to change the MoS for some reasons, for instance, to 470 recover from the single point of failure of the existing MoS. 472 In order to acquire the MoS information, the mobile node MUST send 473 either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or 474 a unicast server address, respectively. In this message the mobile 475 node (DHCP client) MUST include the Option Code for the MoS 476 Discovery in the options field. 478 4.1.2 DHCP Server behavior 480 When the DHCP server receives the DHCPDISCOVER or DHCPINFORM message 481 with the MoS Discovery option in the options field, the DHCP server 482 MUST follow the [RFC2131] logic to construct either a DHCPOFFER or 483 DHCPACK message including the MoS Discovery option. The reply 484 message may contain the IP address or the FQDN of the MoS Server. 486 In case that the server cannot find any MoS information, it MUST 487 return the MoS Discovery option by setting the MoS Server address 488 0.0.0.0 with 'enc' 1. 490 4.2 DHCPv6 Options for MoS discovery 492 The requesting and sending of the proposed DHCPv6 options follow the 493 rules for DHCP options in [RFC3315]. 495 4.2.1 Mobile node behavior 497 The mobile node may perform the MoS information discovery procedure 498 either during initial association with a network or when the 499 mobility service is required. It may also try to perform the MoS 500 information discovery when it lacks the network information for MoS 501 or needs to change the MoS for some reasons, for instance, to 502 recover from the single point of failure of the existing MoS 504 In order to acquire the MoS address, the mobile node MUST send an 505 Information-request message to the All_DHCP_Relay_Agents_and_Servers 506 multicast address. In this message the mobile node (DHCP client) 507 MUST include the Option Code for the MoS Discovery option in the 508 option_code. 510 4.2.2 DHCP Relay Agent behavior 511 Upon receiving the Information-request from the mobile node, the 512 DHCP relay agent MUST forward the message to the DHCP server as per 513 [RFC3315]. 514 If the relay agent determines that the AAAV/NAS has passed MoS 515 information for this mobile node and has available MoS information 516 for it, the relay agent MUST include the MoS information in the MIP6 517 Relay Agent option, and attach this option in the Relay-forward 518 message. 519 In case the relay agent does not maintain any MoS information for 520 the requesting mobile node, it simply forwards the received message 521 to the DHCP server according to the [RFC3315]. 523 Upon receiving a Relay-reply message from the DHCPv6 server, the 524 relay agent MUST follow the guidelines defined in [RFC3315]. The 525 relay agent extracts the Reply message from the Relay Message option 526 in the Relay-reply message and relays it to the mobile node. 528 4.2.3 DHCP Server behavior 530 When the DHCP Server receives the Information-request message with 531 the MoS Identifier option in the Relay-forward message, it looks for 532 a MIP6 Relay Agent Option containing MoS Information. The 533 Information-request message may not include the MIP6 Relay Agent 534 option in case there was no MoS information available at the NAS / 535 DHCP Relay Agent for a mobile node. 537 The DHCP server MUST follow the following logic to construct a Reply 538 message with the MoS Information option, and include the Reply 539 message in the payload of a Relay Message option of Relay-reply 540 message. 542 If the DHCP server has the requested MoS information, it MUST 543 include the information in the MoS Information option. The server 544 may provide the matching information either extracted from the MIP6 545 Relay Agent option or from the preconfigured information available 546 locally. 548 5. Security Considerations 550 The security considerations in [RFC2131] apply. If an adversary 551 manages to modify the response from a DHCP server or insert its own 552 response, an MN could be led to contact a rogue Mobility Server, 553 possibly one that then would provide wrong information, event or 554 command for handover. 556 It is recommended to use either DHCP authentication option described 557 in [RFC3118] where available, or rely upon link layer security. This 558 will also protect the denial of service attacks to DHCP servers. 559 [RFC3118] provides mechanisms for both entity authentication and 560 message authentication. 562 6. IANA Considerations 563 This document registers the following dhcpv4 options with IANA: 565 IPv4-IS 566 IPv4-ES 567 IPv4-CS 569 This document also registers the following dhcpv6 options with IANA: 571 IPv6-MoSINF 572 IPv6-MoS 574 This document also registers the following dhcpv6 Relay options with 575 IANA: 577 IPv6-MoS-RELAY 579 7. Acknowledgements 581 Acknowledgements to the design team members for their comments. 583 8. Normative References 585 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 586 2131, March 1997. 588 [RFC1035] Mockapetris, P., "Domain names - implementation and 589 specification", STD 13, RFC 1035, November 1987. 591 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 592 RFC3396, November 2002. 594 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 596 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 597 Droms et al, July 2003 599 9. Informative References 601 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 602 Networks: Media Independent Handover Services 604 [MoS-DNS] Bajko, G. " Locating Mobility Servers", draft-ietf-mipshop 605 -mos-dns-discovery-00, April 2008, work in progress. 607 10. Authors' Addresses 609 Gabor Bajko 610 Nokia 611 e-mail: gabor.bajko@nokia.com 613 Subir Das 614 Telcordia 615 e-mail: subir@research.telcordia.com 617 Full Copyright Statement 619 Copyright (C) The IETF Trust (2008). 621 This document is subject to the rights, licenses and restrictions 622 contained in BCP 78, and except as set forth therein, the authors 623 retain all their rights. 625 This document and the information contained herein are provided on 626 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 627 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 628 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 629 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 630 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 631 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 632 FOR A PARTICULAR PURPOSE. 634 Intellectual Property 636 The IETF takes no position regarding the validity or scope of any 637 Intellectual Property Rights or other rights that might be claimed 638 to pertain to the implementation or use of the technology described 639 in this document or the extent to which any license under such 640 rights might or might not be available; nor does it represent that 641 it has made any independent effort to identify any such rights. 642 Information on the procedures with respect to rights in RFC 643 documents can be found in BCP 78 and BCP 79. 645 Copies of IPR disclosures made to the IETF Secretariat and any 646 assurances of licenses to be made available, or the result of an 647 attempt made to obtain a general license or permission for the use 648 of such proprietary rights by implementers or users of this 649 specification can be obtained from the IETF on-line IPR repository 650 at http://www.ietf.org/ipr. 652 The IETF invites any interested party to bring to its attention any 653 copyrights, patents or patent applications, or other proprietary 654 rights that may cover technology that may be required to implement 655 this standard. Please address the information to the IETF at ietf- 656 ipr@ietf.org. 658 Acknowledgment 660 Funding for the RFC Editor function is provided by the IETF 661 Administrative Support Activity (IASA).