idnits 2.17.1 draft-bajko-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. 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 ([1]), 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 226 has weird spacing: '...de Len enc ...' == Line 251 has weird spacing: '...e Len enc ...' -- 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 (August 2007) is 6098 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-01) exists of draft-bajko-mos-dns-discovery-00 Summary: 2 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: Standards Track August 2007 5 Expires: February 20, 2007 7 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 8 Mobility Servers (MoS) 9 draft-bajko-mos-dhcp-options-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 20, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines a number of Dynamic Host Configuration 43 Protocol (DHCP-for-IPv4) options that contain a list of domain names 44 or IPv4 addresses that can be mapped to servers providing Mobility 45 Services. Mobility Services are used to assist an MN in handover 46 preparation (network discovery) and handover decision (network 47 selection). The services addressed by this document are the Media 48 Independent Handover Services defined in [1]. 50 Conventions used in this document 51 Mobility Services DHCP Options August 2007 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 [1]. 57 Terminology and abbreviations used in this document 59 Mobility Support Services: comprises of a set of different services 60 provided by the network to mobile nodes to facilitate handover 61 preparation and handover decision. 63 Mobility Server: a network node providing Mobility Support Services. 65 MIH: Media Independent Handover, as defined in [1]. 67 MIH Service: IS, ES or CS type of service, as defined in [1]. 69 Table of Content 71 1. Introduction ...................................................2 72 2. Mobility Server DHCPv4 Options..................................3 73 2.1 Domain Name List .........................................3 74 2.2 IPv4 Address List ........................................5 75 3. Mobility Server DHCPv6 Options..................................5 76 3.1 Domain Name List .........................................6 77 3.2 IPv6 Address List ........................................6 78 4. Security Considerations ........................................6 79 5. IANA Considerations ............................................7 80 6. Acknowledgements ...............................................7 81 7. Normative References ...........................................7 82 8. Informative References .........................................7 83 9. Author's Addresses .............................................8 85 1. Introduction 87 IEEE 802.21 [1] defines three distinct service types to facilitate 88 link layer handovers across heterogeneous technologies: 90 a) Information Services (IS) 91 IS provides a unified framework to the higher layer entities 92 across the heterogeneous network environment to facilitate discovery 93 and selection of multiple types of networks existing within a 94 geographical area, with the objective to help the higher layer 95 mobility protocols to acquire a global view of the heterogeneous 96 networks and perform seamless handover across these networks. 98 b) Event Services (ES) 99 Events may indicate changes in state and transmission behavior 100 of the physical, data link and logical link layers, or predict state 101 changes of these layers. The Event Service may also be used to 102 indicate management actions or command status on the part of the 103 network or some management entity. 105 Mobility Services DHCP Options August 2007 107 c) Command Services (CS) 108 The command service enables higher layers to control the 109 physical, data link, and logical link layers. The higher layers may 110 control the reconfiguration or selection of an appropriate link 111 through a set of handover commands. 113 In IEEE terminology these services are called Media Independent 114 Handover (MIH) services. 115 While these services may be co-located, the different pattern and 116 type of information they provide does not necessitate the co- 117 location. 119 An MN may make use of any of these MIH service types separately or 120 any combination of them. 122 It is anticipated that a Mobility Server will not necessarily host 123 all three of these MIH services together, thus there is a need to 124 discover the MIH services types separately. 126 This document defines three dhcp options [4,5] for DHCPv4 and 127 DHCPv6, one for each of the services defined in [1], namely IS, ES 128 and CS. The options would allow an MN to locate a Mobility Server 129 which hosts the desired MIH service type (IS, ES or CS) the MN is 130 looking for. This is one of the possible solutions for locating a 131 server providing Mobility Services; manual configuration is an 132 example of another. 134 2. Mobility Server DHCPv4 Options 136 This section describes three options for DHCPv4. 138 The Mobility Server DHCPv4 options carry either a 32-bit (binary) 139 IPv4 address or, preferably, a DNS (RFC 1035 [6]) fully-qualified 140 domain name to be used by the MN to locate a server hosting either 141 an IS, an ES or a CS service. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | MoS code | Length | enc | MoS Server ... 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 ... domain name or IP address list ... 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 MoS code: option codes assigned by IANA (tbd) 152 Length: indicates the total number of octets in the option following 153 the 'Length' field, including the encoding byte 154 enc: one byte indicating the encoding type of the next field 156 The options have two encodings, specified by the encoding byte 157 ('enc') that follows the code byte. If the encoding byte has the 158 value 0, it is followed by a list of domain names, as described 160 Mobility Services DHCP Options August 2007 162 below (Section 2.1). If the encoding byte has the value 1, it is 163 followed by one or more IPv4 addresses (Section 2.2). All 164 implementations MUST support both encodings. The 'Length' field 165 indicates the total number of octets in the option following the 166 'Length' field, including the encoding byte. 168 A DHCP server MUST NOT mix the two encodings in the same DHCP 169 message, even if it sends two different instances of the same 170 option. Attempts to do so would result in incorrect client behavior 171 as DHCP processing rules call for the concatenation of multiple 172 instances of an option into a single option prior to processing the 173 option [7]. 175 The code for the MIH IS option is XXX. The code for the MIH ES 176 option is YYY. The code for the MIH CS option is ZZZ. 178 2.1 Domain Name List 180 If the 'enc' byte has a value of 0, the encoding byte is followed by 181 a sequence of labels, encoded according to Section 3.1 of RFC 1035 182 [6], quoted below: 184 Domain names in messages are expressed in terms of a sequence 185 of labels. Each label is represented as a one octet length 186 field followed by that number of octets. Since every domain 187 name ends with the null label of the root, a domain name is 188 terminated by a length byte of zero. The high order two bits of 189 every length octet must be zero, and the remaining six bits of 190 the length field limit the label to 63 octets or less. To 191 simplify implementations, the total length of a domain name 192 (i.e., label octets and label length octets) is restricted to 193 255 octets or less. 195 RFC 1035 encoding was chosen to accommodate future internationalized 196 domain name mechanisms. 197 The minimum length for this encoding is 3. 199 The option MAY contain multiple domain names, but these SHOULD refer 200 to different NAPTR records, rather than different A records. The 201 client MUST try the records in the order listed, applying the 202 mechanism described in [8] for each. The client only resolves the 203 subsequent domain names if attempts to contact the first one failed 204 or yielded no common transport protocols between the MN and the 205 server. 207 Use of multiple domain names is not meant to replace NAPTR and SRV 208 records, but rather to allow a single DHCP server to indicate MIH 209 servers operated by multiple providers. 211 Clients MUST support compression according to the encoding in 212 Section 4.1.4 of "Domain Names - Implementation And Specification" 213 [6]. 215 Mobility Services DHCP Options August 2007 217 Since the domain names are supposed to be different domains, 218 compression will likely have little effect, however. 220 If the length of the domain list exceeds the maximum permissible 221 within a single option (254 octets), then the domain list MUST be 222 represented in the DHCP message as specified in [7]. 224 The DHCP option for this encoding has the following format: 226 Code Len enc DNS name of MoS server 227 +-----+-----+-----+-----+-----+-----+-----+-----+-- 228 | XXX | n | 0 | s1 | s2 | s3 | s4 | s5 | ... 229 +-----+-----+-----+-----+-----+-----+-----+-----+-- 231 As an example, consider the case where the server wants to offer two 232 MIH IS servers, "example.com" and "example.net". These would be 233 encoded as follows: 235 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 236 |XXX|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 | 237 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 238 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 239 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | 240 +---+---+---+---+---+---+---+---+---+---+---+---+---+ 242 2.2 IPv4 Address List 244 If the 'enc' byte has a value of 1, the encoding byte is followed by 245 a list of IPv4 addresses indicating appropriate MIH servers 246 available to the MN. Servers MUST be listed in order of preference. 248 Its minimum length is 5, and the length MUST be a multiple of 4 plus 249 one. The DHCP option for this encoding has the following format: 251 Code Len enc IPv4 Address 1 IPv4 Address 2 252 +-----+-----+-----+-----+-----+-----+-----+-----+-- 253 | XXX | n | 1 | a1 | a2 | a3 | a4 | a1 | ... 254 +-----+-----+-----+-----+-----+-----+-----+-----+-- 256 3. Mobility Server DHCPv6 Options 258 This section defines a DHCP for IPv6 (DHCPv6) option for the 259 discovery of a list of domain names or IPv6 addresses of Mobility 260 Servers. 262 The Mobility Server DHCPv6 options carry either a 128-bit (binary) 263 IPv6 address or, preferably, a DNS (RFC 1035 [6]) fully-qualified 264 domain name to be used by the MN to locate a server hosting either 265 an IS, an ES or a CS service. 267 Mobility Services DHCP Options August 2007 269 The DHCPv6 option for this parameter is similarly formatted to the 270 DHCPv4 option. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | MoS code | Length | enc | MoS Server ... 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | domain name or IP address list ... 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 MoS code: option codes assigned by IANA (tbd) 280 Length: indicates the total number of octets in the option following 281 the 'Length' field, including the encoding byte 282 enc: one byte indicating the encoding type of the next field 284 The options have two encodings, specified by the encoding byte 285 ('enc') that follows the code byte. If the encoding byte has the 286 value 0, it is followed by a list of domain names, as described 287 below (Section 2.1). If the encoding byte has the value 1, it is 288 followed by one or more IPv4 addresses (Section 2.2). All 289 implementations MUST support both encodings. The 'Length' field 290 indicates the total number of octets in the option following the 291 'Length' field, including the encoding byte. 293 A DHCP server MUST NOT mix the two encodings in the same DHCP 294 message, even if it sends two different instances of the same 295 option. Attempts to do so would result in incorrect client behavior 296 as DHCP processing rules call for the concatenation of multiple 297 instances of an option into a single option prior to processing the 298 option [7]. 300 The code for the MIH IS dhcpv6 option is XXX. The code for the MIH 301 ES dhcpv6 option is YYY. The code for the MIH CS dhcpv6 option is 302 ZZZ. 304 3.1 Domain Name List 306 If the 'enc' byte has a value of 0, the encoding byte is followed by 307 a sequence of labels, as described in section 2.1 309 3.2 IPv6 address list 311 If the 'enc' byte has a value of 1, the encoding byte is followed by 312 a list of IPv6 addresses indicating appropriate MoS servers 313 available to the MN. Servers MUST be listed in order of preference. 315 4. Security Considerations 317 The security considerations in RFC 2131 [5]. If an adversary manages 318 to modify the response from a DHCP server or insert its own 319 response, an MN could be led to contact a rogue Mobility Server, 321 Mobility Services DHCP Options August 2007 323 possibly one that then would provide wrong information, event or 324 command for handover. 326 5. IANA Considerations 328 This document registers the following dhcpv4 options with IANA: 330 MIH IS dhcpv4 option 331 MIH ES dhcpv4 option 332 MIH CS dhcpv4 option 334 This document also registers the following dhcpv6 options with IANA: 336 MIH IS dhcpv6 option 337 MIH ES dhcpv6 option 338 MIH CS dhcpv6 option 340 5. Acknowledgements 342 Acknowledgements to the DT members. 344 6. Normative References 346 [1] IEEE 802.21 Standard for Local and Metropolitan Area Networks: 347 Media Independent Handover Services 348 [4] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor 349 Extensions", RFC 2132, March 1997. 350 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 351 March 1997. 352 [6] Mockapetris, P., "Domain names - implementation and 353 specification", STD 13, RFC 1035, November 1987. 354 [7] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", 355 RFC3396, November 2002. 356 [8] Bajko, G. " Locating Mobility Servers", draft-bajko-mos-dns- 357 discovery-00.txt 359 7. Informative References 361 8. Author's Addresses 363 Gabor Bajko 364 Nokia 365 gabor.bajko@nokia.com 367 Mobility Services DHCP Options August 2007 369 Full Copyright Statement 371 Copyright (C) The IETF Trust (2007). 373 This document is subject to the rights, licenses and restrictions 374 contained in BCP 78, and except as set forth therein, the authors 375 retain all their rights. 377 This document and the information contained herein are provided on 378 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 379 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 380 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 381 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 382 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 383 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 384 FOR A PARTICULAR PURPOSE. 386 Intellectual Property 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed 390 to pertain to the implementation or use of the technology described 391 in this document or the extent to which any license under such 392 rights might or might not be available; nor does it represent that 393 it has made any independent effort to identify any such rights. 394 Information on the procedures with respect to rights in RFC 395 documents can be found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use 400 of such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository 402 at http://www.ietf.org/ipr. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at ietf- 408 ipr@ietf.org. 410 Acknowledgment 412 Funding for the RFC Editor function is provided by the IETF 413 Administrative Support Activity (IASA).