idnits 2.17.1 draft-ietf-mipshop-mos-dhcp-options-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE802.21], [MSFD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 08, 2009) is 5587 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-ietf-mipshop-mstp-solution-09 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-mos-dns-discovery-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task force Gabor Bajko 3 Internet Draft Nokia 4 Intended Status: Proposed Standard Subir Das 5 Expires: July 08, 2009 Telcordia Technologies 6 January 08, 2009 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 IEEE 802.21 Mobility Services (MoS) Discovery 10 draft-ietf-mipshop-mos-dhcp-options-10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 08, 2009. 35 Copyright Notice 37 Copyright (c) 2008 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document defines a number of Dynamic Host Configuration Protocol 50 (DHCPv4 and DHCPv6) options that contain a list of domain names 51 or IP addresses that can be mapped to servers providing IEEE 802.21 53 Mobility Services DHCP Options January 2009 55 type of Mobility Service (MoS)[MSFD]. These Mobility Services are 56 used to assist an MN in handover preparation (network discovery) 57 and handover decision (network selection). The services addressed 58 in this document are the Media Independent Handover Services 59 defined in [IEEE802.21]. 61 (1) Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 65 this document are to be interpreted as described in RFC-2119. 67 (2) Terminology and abbreviations used in this document 69 Mobility Services: a set of different services provided by the 70 network to mobile nodes to facilitate handover preparation 71 and handover decision. In this document, Mobility Services refer to 72 the services defined in IEEE 802.21 specifications [IEEE802.21] 74 Mobility Server: a network node providing Mobility Support Services. 76 MIH: Media Independent Handover, as defined in [IEEE802.21]. 78 MIH Service: IS, ES or CS type of service, as defined in 79 [IEEE802.21] 81 Table of Contents 83 1. Introduction .................................................2 84 2. DHCPv4 Options for MoS Discovery..............................3 85 2.1 Domain Name List........................................5 86 2.2 IPv4 Address List.......................................6 87 3. DHCPv6 Options for MoS Discovery..............................6 88 4. Option Usage..................................................8 89 4.1 Usage of DHCPv4 Options for MoS Discovery...............8 90 4.2 Usage of DHCPv6 Options for MoS Discovery...............9 91 5. Security Considerations .....................................10 92 6. IANA Considerations .........................................10 93 7. Acknowledgements ............................................11 94 8. References ..................................................11 95 8.1 Normative References ...................................11 96 8.2 Informative References .................................11 97 Author's Addresses .............................................12 99 Mobility Services DHCP Options January 2009 101 1. Introduction 103 IEEE 802.21 [IEEE802.21] defines three distinct service types to 104 facilitate link layer handovers across heterogeneous technologies: 106 a) Information Services (IS) 107 IS provides a unified framework to the higher layer entities 108 across the heterogeneous network environment to facilitate discovery 109 and selection of multiple types of networks existing within a 110 geographical area, with the objective to help the higher layer 112 mobility protocols to acquire a global view of heterogeneous 113 networks and perform seamless handover across these networks. 115 b) Event Services (ES) 116 Events may indicate changes in state and transmission behavior 117 of the physical, data link and logical link layers, or predict state 118 changes of these layers. The Event Service may also be used to 119 indicate management actions or command status on the part of the 120 network or some management entity. 122 c) Command Services (CS) 123 The command service enables higher layers to control the 124 physical, data link, and logical link layers. The higher layers may 125 control the reconfiguration or selection of an appropriate link 126 through a set of handover commands. 128 In IEEE terminology these services are called Media Independent 129 Handover (MIH) services. While these services may be co-located, 130 the different pattern and type of information they provide does not 131 necessitate the co-location. 133 An MN may make use of any of these MIH service types separately or 134 any combination of them [MSFD]. In practice a Mobility Server may 135 not necessarily host all three of these MIH services together, thus 136 there is a need to discover the MIH services types separately. 138 This document defines new DHCPv4 and DHCPv6 options and sub-options 139 called the MoS Discovery Option, which allows the MN to locate a 140 Mobility Server which hosts the desired service type (i.e. IS, ES 141 or CS) as defined in [IEEE802.21]. Apart from manual configuration, 142 this is one of the possible solutions for locating a server 143 providing Mobility Services. 145 2. DHCPv4 Option for MoS Discovery 147 This section describes the MoS Discovery Option for DHCPv4. Whether 148 the MN receives an MoS address from local or home network will 149 depend on the actual network deployment [MSFD]. The MoS Discovery 151 Mobility Services DHCP Options January 2009 153 Option begins with a option code followed by a length and 154 sub-options. The value of the length octet does not include itself 155 or the option code. The option layout is depicted below: 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Option Code | length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Sub-Option 1 | 162 . . 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | ... | 165 . . 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Sub-Option n | 168 . . 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Option Code 173 OPTION-IPv4-MoS (To Be Assigned) - 1 byte 175 Length 177 An 8-bit field indicating the length of the option 178 excluding the 'Option Code' and the 'Length' fields 180 Sub-options 182 A series of DHCPv4 sub-options. 184 When the total length of a MoS Discovery Option exceeds 254 185 octets, the procedure outlined in [RFC3396] MUST be employed to 186 split the option into multiple, smaller options. 188 A sub-option begins with a sub-option Code followed by a length 189 and a `enc` field. The value of the length octet does not include 190 itself or the Sub-opt Code field. There are two types of encodings, 191 specified by the encoding byte ('enc') that follows the code byte. 192 If the encoding byte has the value 0, it is followed by a list of 193 domain names, as described below (Section 2.1). If the encoding byte 194 has the value 1, it is followed by one or more IPv4 addresses 195 (Section 2.2). 197 All implementations MUST support both encodings. A DHCP server MUST 198 NOT mix the two encodings in the same DHCP message, even if it sends 199 two different instances of the same option. Attempts to do so would 200 result in incorrect client behavior as DHCP processing rules call 202 Mobility Services DHCP Options January 2009 204 for the concatenation of multiple instances of an option into a 205 single option prior to processing the option [RFC3396]. 207 The sub-option layout is depicted below: 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Sub-opt Code | length | enc | FQDN or . 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 . IP Address . 215 . | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 The sub-option Codes are summarized below. 219 +--------------+---------------+ 220 | Sub-opt | Service | 221 | Code* | Name | 222 +==============+===============+ 223 | 1 | IS | 224 +--------------+---------------+ 225 | 2 | CS | 226 +--------------+---------------+ 227 | 3 | ES | 228 +--------------+---------------+ 230 *Note: The values `0` '4' to '255' are reserved and MUST NOT be used. 232 2.1 Domain Name List 234 If the 'enc' byte has a value of 0, the encoding byte is followed by 235 a sequence of labels, encoded according to Section 8 of [RFC3315], 236 quoted below: 238 So that domain names may be encoded uniformly, a domain name 239 or a list of domain names is encoded using the technique 240 described in section 3.1 of [RFC1035]. A domain name, or list 241 of domain names, in DHCP MUST NOT be stored in compressed form, 242 as described in section 4.1.4 of [RFC1035]. 244 [RFC1035] encoding was chosen to accommodate future international- 245 lized domain name mechanisms. The minimum length for this encoding 246 is 3. 248 The option MAY contain multiple domain names, but these should refer 249 to the NAPTR records of different providers, rather than different A 251 Mobility Services DHCP Options January 2009 253 records within the same provider. That is, the use of multiple 254 domain names is not meant to replace NAPTR and SRV records, but 255 rather to allow a single DHCP server to indicate MIH servers 256 operated by multiple providers. 258 The client MUST try the records in the order listed, applying the 259 mechanism described in [MoS-DNS] for each. The client only resolves 260 the subsequent domain names if attempts to contact the first one 261 failed or yielded no common transport protocols between the MN and 262 the server. 264 The sub-option for this encoding has the following format: 266 Code Len enc DNS name of MoS server 267 +-----+---+---+-----+-----+-----+-----+-----+-- 268 |1..3 | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 269 +-----+---+---+-----+-----+-----+-----+-----+-- 271 As an example, consider the case where the server wants to offer 272 two MIH IS servers, "example.com" and "example.net". These would 273 be encoded as follows: 274 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 275 |1..3|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 276 +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 277 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 278 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 279 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 281 2.2 IPv4 Address List 283 If the 'enc' byte has a value of 1, the encoding byte is followed by 284 a list of IPv4 addresses indicating appropriate MIH servers 285 available to the MN. Servers MUST be listed in order of preference. 287 Its minimum length is 5, and the length MUST be a multiple of 4 plus 288 one. The sub-option for this encoding has the following format: 290 Code Len enc IPv4 Address 1 IPv4 Address 2 291 +-----+---+---+-----+----+---+----+----+-- 292 |1..3 | n | 1 | a1 | a2 |a3 | a4 | a1 | ... 293 +-----+---+---+-----+----+---+----+----+-- 295 3. DHCPv6 Option for MoS discovery 297 This section introduces new DHCPv6 option used for MoS discovery. 299 Mobility Services DHCP Options January 2009 301 Whether the MN receives an MoS address from local or home network 302 will depend on the actual network deployment [MSFD]. 304 The MoS Discovery Option begins with a option code followed by a 305 length and sub-options. The value of the length octet does not 306 include itself or the option code. The option layout is depicted 307 below: 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Option Code | length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sub-Option 1 | 314 . . 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | ... | 317 . . 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Sub-Option n | 320 . . 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Option Code 325 OPTION-IPv6-MoS (To Be Assigned) - 2 bytes 327 Length 329 A 16-bit field indicating the length of the option 330 excluding the 'Option Code' and the 'Length' fields. 332 Sub-options 334 A series of DHCPv6 sub-options. 336 The sub-options follow the same format (except the Sub-opt Code and 337 Length value) and 'enc' rules as described in Section 2. The value of 338 the Sub-opt Code and Length are 2-octets and the Length does not 339 include itself or the Sub-opt Code field. The sub-option layout is 340 depicted below: 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | sub-opt Code | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Mobility Services DHCP Options January 2009 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | enc | FQDN or IP Address | 351 . . 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 The sub-option Codes are summarized below. 355 +--------------+---------------+ 356 | Sub-opt | Service | 357 | Code* | Name | 358 +==============+===============+ 359 | 1 | IS | 360 +--------------+---------------+ 361 | 2 | CS | 362 +--------------+---------------+ 363 | 3 | ES | 364 +--------------+---------------+ 366 *Note: The values `0` '4' to '65535' are reserved and MUST NOT be 367 used. 369 4. Option Usage 371 4.1 Usage of DHCPv4 Options for MoS Discovery 373 The requesting and sending of the proposed DHCPv4 option follow the 374 rules for DHCP options in [RFC2131]. 376 4.1.1 Mobile Node behavior 378 The mobile node may perform the MoS information discovery procedure 379 either during initial association with a network or when the 380 mobility service is required. It may also try to perform the MoS 381 information discovery when it lacks the network information for 382 MoS or needs to change the MoS for some reasons, for instance, 383 to recover from the single point of failure of the existing MoS. 385 In order to request an address of a MoS Server, the mobile node 386 (DHCP client) MUST include a MoS Discovery Option into either a 387 DHCPDISCOVER or DHCPINFORM message. The inserted MoS Discovery 388 Option MUST include one or more sub-option(s) with the Sub-opt 389 Code(s) that represents the service(s) the mobile host is 390 interested in. 392 4.1.2 DHCP Server behavior 394 When the DHCP server receives either a DHCPDISCOVER or DHCPINFORM 395 message with a MOS Discovery Option, the DHCP server MUST always 397 Mobility Services DHCP Options January 2009 399 construct the response according to the sub-option code(s) 400 representing the service(s) desired by the mobile node in the 401 sub-option code field. The response message may contain 402 the IP address or the FQDN of the MoS Server. If set of FQDNs in 403 the response message turns out to be more than 256 bytes, the DHCP 404 server should send a reduced list of FQDNs so that they fit into 405 one sub option. 407 In case that the server cannot find any Mobility Server 408 satisfying the requested Sub-opt Code, the server MUST return 409 the MoS Discovery Option with a sub-option by setting the 410 Sub-opt Code to the requested Sub-opt Code and the length of 411 the sub-option to 1. 413 4.2 DHCPv6 Options for MoS discovery 415 The requesting and sending of the proposed DHCPv6 options follow 416 the rules for DHCP options in [RFC3315]. 418 4.2.1 Mobile node behavior 420 The mobile node may perform the MoS information discovery procedure 421 either during initial association with a network or when the 422 mobility service is required. It may also try to perform the MoS 423 information discovery when it lacks the network information for 424 MoS or needs to change the MoS for some reasons, for instance, 425 to recover from the single point of failure of the existing MoS. 427 In order to request an address of a Mobility Server, the mobile 428 node(DHCP client) MUST include a MoS Discovery Option into either 429 a REQUEST or an INFORMATION-REQUEST message. The inserted MoS 430 Discovery Option MUST include one or more sub-option(s) with the 431 Sub-opt Code(s) that represents the service(s) the mobile host is 432 interested in. 434 4.2.2 DHCP Server behavior 436 When the DHCP Server receives either a REQUEST or an INFORMATION- 437 REQUEST message with a MoS Discovery Option, the DHCP server MUST 438 always construct the response according to the sub-option code(s) 439 representing the service desired by the mobile node in the 440 sub-option code field. The response message may contain the IP 441 address or the FQDN of the desired MoS server. 443 In case that the server cannot find any Mobility Server 444 satisfying the requested Sub-opt Code, the server MUST return 445 the MoS Discovery Option with a sub-option by setting the 446 Sub-opt Code to the requested Sub-opt Code and the length of 447 the sub-option to 1. 449 Mobility Services DHCP Options January 2009 451 5. Security Considerations 453 The security considerations in [RFC2131] apply. If an adversary 454 manages to modify the response from a DHCP server or insert its own 455 response, an MN could be led to contact a rogue Mobility Server, 456 possibly one that then would provide wrong information, event or 457 command for handover. 459 It is recommended to use either DHCP authentication option described 460 in [RFC3118] where available, or rely upon link layer security. 462 This will also protect the denial of service attacks to DHCP 463 servers. [RFC3118] provides mechanisms for both entity authentication 464 and message authentication. 466 6. IANA Considerations 468 This document defines one new DHCPv4 option as described in section 469 2. 471 MoS Discovery Option for DHCPv4 (OPTION-IPv4-MoS) To Be Assigned 473 This document creates a new registry for the Sub-Option field in the 474 MoS DHCPv4 option called the "IEEE 802.21 Service Type" (Section 2). 475 IS 1 476 CS 2 477 ES 3 479 The values '0', '4' to '255' are reserved and MUST NOT be used. New 480 values can be allocated by Standards Action or IESG approval. 482 This document also defines one DHCPv6 option as described in 483 section 3. 485 MoS Discovery Option for DHCPv6 (OPTION-IPv6-MoS) To Be Assigned 487 This document creates a new registry for the sub-option field in 488 the MoS DHCPv6 option called the "IEEE 802.21 Service Type" 489 (section 3). 491 IS 1 492 CS 2 493 ES 3 495 The values '0', '4' to '65535' are reserved and MUST NOT be used. 496 New Values can be allocated via Standards Action as defined 497 in [RFC5226]. 499 Mobility Services DHCP Options January 2009 501 7. Acknowledgements 503 Authors would like to acknowledge the following individuals for 504 their valuable comments. 505 Bernie Volz, Vijay Devarapalli, David W. Hankins, Alfred Hoenes, 506 Telemaco Melia, Ralph Droms and Yoshihiro Ohba 508 8. References 510 8.1 Normative References 512 [RFC1035] Mockapetris, P., "Domain names - implementation and 513 specification", STD 13, RFC 1035, November 1987. 515 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 516 2131, March 1997. 518 [RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 519 Droms et al, July 2003 521 [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001 523 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 524 RFC3396, November 2002. 526 [RFC5226] T. Narten and H. Alvestrand, ?Guidelines for Writing an 527 IANA Considerations Section in RFCs? , May 2008. 529 [MSFD] T Melia, Ed., " Mobility Services Framework Design (MSFD)", 530 draft-ietf-mipshop-mstp-solution-09.txt (Work in Progress). 532 [MoS-DNS] Bajko, G., "Locating Mobility Servers", 533 draft-ietf-mipshop-mos-dns-discovery-04.txt (Work in Progress), 535 8.2 Informative References 537 [IEEE802.21] IEEE 802.21 Standard for Local and Metropolitan Area 538 Networks: Media Independent Handover Services 540 Mobility Services DHCP Options January 2009 542 Authors' Addresses 544 Gabor Bajko 545 Nokia 546 e-mail: gabor.bajko@nokia.com 548 Subir Das 549 Telcordia Technologies Inc. 550 e-mail: subir@research.telcordia.com