idnits 2.17.1 draft-daniel-dhc-mihis-opt-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 386), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 9, 2006) is 6429 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) == Missing Reference: 'ieee80221' is mentioned on line 303, but not defined -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Daniel Park 3 Internet-Draft SAMSUNG Electronics 4 Expires: March 10, 2007 Y. Ohba 5 Toshiba 6 J. Jee 7 ETRI 8 September 9, 2006 10 DHCP Option for Discovering IEEE 802.21 Information 11 draft-daniel-dhc-mihis-opt-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 10, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). All Rights Reserved. 42 Abstract 44 In IEEE 802 Standard, the Media Independent Handover (MIH) Services 45 are under work through IEEE 802.21 Working Group. It is consist of 46 three services, Media Independent Event Service (MIES), Media 47 Independent Command Service (MICS) and Media Independent Information 48 Service (MIIS). This document provides a mechanism by which the DHCP 49 can provide information about the MIIS Discovery Information. 51 1. Introduction 53 In IEEE 802 Standard, the Media Independent Handover Services are 54 under work through IEEE 802.21 Working Group. It is consist of three 55 services, Media Independent Event Service (MIES), Media Independent 56 Command Service (MICS) and Media Independent Information Service 57 (MIIS). 59 MIIS provides a framework by which a MIH function both in the mobile 60 node and in the network can discover and obtain homogeneous and 61 heterogeneous network information within a geographical area to 62 facilitate handovers. In the larger scope, the macro objective is to 63 acquire a global view of the heterogeneous networks to facilitate 64 seamless handovers when roaming across these networks. MIIS includes 65 support for various Information Elements (IEs) stored in Information 66 Server (IS). IEs provide information that is essential for a 67 handover module to make intelligent handover decision. Figure 1 68 gives a high level description of scenario that distinguish between 69 two different types of mobility as Horizontal Handovers and Vertical 70 Handovers. 72 Media Specific Media Independent Information Service 73 Technology 75 +------------+ +----------------------------------+ 76 | | ^ | | 77 | +--------+ | | | +-------+ +--------+ | 78 | | GSM | | | | | BSTN 1| . . . . | BSTN x | | 79 | +--------+ | V | +-------+ +--------+ | 80 | . | e | . | 81 | . | r | . | 82 | . | t | +-------+ +-------+ | 83 | +--------+ | i | | BS 1 | . . . . | BS y | | 84 | | 802.16 | | c | +-------+ +-------+ | 85 | +--------+ | a | | 86 | | l | ------------+-----+ 87 | | | / /-----| GNI | 88 | +--------+ | H | +------+ +------+ +------+ | +-----+ 89 | | 802.11 | | O | | AP 1 | | AP 2 | . . | AP z | | | LLI | 90 | +--------+ | s | +------+ +------+ +------+ | +-----+ 91 | | | | | | HLSI| 92 +------------+ +----------------------------------+ +-----+ 94 ---Horizontal HOs----------------> 96 98 Depending on the type of mobility support for different types of 99 information elements may be necessary for performing handovers. 101 MIIS provides the capability for obtaining the necessary information 102 for handovers. This includes information about lower layers such as 103 neighbor maps and other link layer parameters as well as information 104 about available higher layer services such as access to internet 105 connectivity, availability of VPN services, etc. The set of 106 different higher services privided by the MIIS may constantly evolve. 107 At the same time, the list of access networks that are supported by 108 MIIS may also evolve. 110 A schema defines structure of information. A schema is used in the 111 802.21 information service to define the structure of each 112 information element as well as the relationship among different 113 information elements supported. A schema is defined by a language 114 and may be represented in multiple ways. Examples include Resource 115 Description Framework (RDF) which is based on XML which is used in 116 802 MIBs, Variants or a simple TLV representation of different 117 information elements. The MIIS schema is classified into two major 118 categories. 120 - Basic schema that is essential for every MIH to support and 122 - Extended schema that is optional and can be vendor specific 124 Note: further details are described in [ieee80221]. 126 This document defines new DHCPv4[RFC2131] and DHCPv6 [RFC3315] 127 options as MIIS Discovery Option for discovering MIIS Information. 129 2. Requirements 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. MIIS Discovery Information 137 The following information is defined as MIIS Discovery Information. 139 o A list of IP addresses of MIIS Information Servers. This 140 information is used by an MIIS client on a host to communicate with 141 MIIS Information Servers using an MIIS transport protocol. (Note: an 142 MIIS transport protocol is being defined in MIPSHOP WG) 144 o An URL of an extended schema. This information is used by an MIIS 145 client on a host to obtain an extended schema that is located at a 146 specified URL. The extended schema may be stored in a node that is 147 not acting as an MIIS Information Server. The MIIS client needs to 148 know the URL of the extended schema regardless of whether the 149 extended schema is stored in an MIIS Information Server or not. 151 o An DHCP option for a schema URL is needed for an extended schema 152 only. for the basic schema, an IANA-assigned persistent URL will be 153 used and the URL is supposed to be pre-configured in an MIIS client 154 on a host, thus an DHCP option for a basic schema URL is not needed. 156 4. MIIS Discovery Option 158 This option specifies the MIIS Discovery Information that client 159 should use when discovering the handover information of MIIS somehow 160 via the Dynamic Host Configuration Protocol [RFC2131]. 162 4.1 MIIS Information Server IPv4 Address Option for DHCPv4 164 The DHCPv4 format of the MIIS Information Server IPv4 Address Option 165 is shown as follows; 167 0 1 168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | option-code | option-length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 +Information Server IPv4 Address+ 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 The option-code for this option is TBD. The length of this option 180 MUST be a multiple of 4. 182 Information Server IPv4 Address field contains an IPv4 address of a 183 MIIS Information Server. In a single Information Server IPv4 Address 184 case, the length is 4. if multiple addresses are in use, the 185 Information Servers are listed in the order of preference. 187 A DHCPv4 client requests the MIIS Information Server IPv4 Address 188 Option in a Parameter Request List as described in [RFC2131] and 189 [RFC2132]. 191 The DHCPv4 client MUST try the records in the order listed in the 192 MIIS Information Server IPv4 Address option. 194 4.2 MIIS Extended Schema URL Option for DHCPv4 196 0 1 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | option-code | option-length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 + MIIS Extended Schema URL + 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 The option-code for this option is TBD. The length of this option is 207 variable. 209 MIIS Extended Schema URL field contains one URL of IEEE 802.21 210 Information Service Schema where the resource represented by the URL 211 is an Extended Schema [ieee80221]. The length of option is variable. 213 A DHCPv4 client requests the MIIS Extended Schema URL Option in a 214 Parameter Request List as described in [RFC2131] and [RFC2132]. 216 4.3 MIIS Information Server IPv6 Address Option for DHCPv6 218 The DHCPv6 format of the MIIS Information Server IPv6 Address Option 219 is shown as follows; 220 0 1 2 3 221 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 2 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | option-code | option-length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + + 227 | Information Server IPv6 Address | 228 + + 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 The option-code for this option is TBD. The length of this option 235 MUST be a multiple of 16. 237 Information Server IPv6 Address field contains an IPv6 address of a 238 Information Server. In a single Information Server IPv6 Address 239 case, the length is 16. if multiple addresses are in use, the 240 Information Servers are listed in the order of preference. 242 A DHCPv6 client requests the MIIS Information Server IPv6 Address 243 Option in an Option Request Option as described in [RFC3315]. 245 The DHCPv6 client MUST try the records in the order listed in the 246 MIIS Information Server IPv6 Address option. 248 4.4 MIIS Extended Schema URL Option for DHCPv6 250 0 1 2 3 251 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 2 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | option-code | option-length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 + + 257 | MIIS Extended Schema URL | 258 + + 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 The option-code for this option is TBD. The length of this option is 263 variable. 265 MIIS Extended Schema URL field contains one URL of IEEE 802.21 266 Information Service Schema where the resource represented by the URL 267 is an Extended Schema [ieee80221]. The length of option is variable. 269 A DHCPv6 client requests the MIIS Extended Schema URL Option in an 270 Options Request Option as described in [RFC3315]. 272 5. Security Considerations 274 A rogue DHCP server can issue invalid or incorrect MIIS Discovery 275 Information. This may cause denial of service due to unreachability 276 or makes the client to reach incorrect destination. 278 In case of DHCPv4, the authenticated DHCP [RFC3118] can be also used 279 for secure exchange between clients and MIIS Information Server 280 locations. 282 In case of DHCPv6, the security considerations are described in 283 Section 23 of [RFC3315]. 285 6. IANA Considerations 287 IANA is requested to assign values for the MIIS Discovery Option code 288 - MIIS Information Server IPv4 Address Option for DHCPv4, MIIS 289 Extended Schema URL Option for DHCPv4, MIIS Information Server IPv6 290 Address Option for DHCPv6, MIIS Extended Schema URL Option for DHCPv6 291 - in accordance with [RFC2939]. 293 7. Acknowledgements 295 Thanks to IEEE 802.21 folks for their effort on this issue. 296 Specially thanks to David Hankins for his valuable comments. 298 8. No I-D References 300 All references cited in this section MUST be added into the 301 Informative References before publishing it officially. 303 [ieee80221] IEEE P802.21/D01/08, Draft IEEE standard for Local and 304 Metropolitan Area Networks: Media Independent Handover Services. 306 9. References 307 9.1 Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 313 of New DHCP Options and Message Types", BCP 43, RFC 2939, 314 September 2000. 316 9.2 Informative References 318 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 319 2131, March 1997. 321 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 322 Extensions", RFC 2132, March 1997. 324 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 325 Messages", RFC 3118, June 2001. 327 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 328 M. Carney, "Dynamic Host Configuration Protocol for IPv6 329 (DHCPv6)", RFC 3315, July 2003. 331 Authors' Addresses 333 Soohong Daniel Park 334 Mobile Convergence Laboratory, SAMSUNG Electronics 336 EMail: soohong.park@samsung.com 338 Yoshihiro Ohba 339 Toshiba 341 EMail: yohba@tari.toshiba.com 343 Junghoon Jee 344 ETRI 346 EMail: jhjee@etri.re.kr 348 Intellectual Property Statement 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at 370 ietf-ipr@ietf.org. 372 Disclaimer of Validity 374 This document and the information contained herein are provided on an 375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 377 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 378 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 379 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 382 Copyright Statement 384 Copyright (C) The Internet Society (2006). This document is subject 385 to the rights, licenses and restrictions contained in BCP 78, and 386 except as set forth therein, the authors retain all their rights. 388 Acknowledgment 390 Funding for the RFC Editor function is currently provided by the 391 Internet Society.