idnits 2.17.1 draft-ietf-v6ops-802-16-deployment-scenarios-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 815. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (October 1, 2006) is 6417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-mipshop-fmipv6-rfc4068bis' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-bb-deployment-scenarios' is defined on line 719, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fmipv6-rfc4068bis-00 == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fh80216e-00 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-security-overview-05 == Outdated reference: A later version (-08) exists of draft-iab-link-encaps-02 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M-K. Shin 3 Internet-Draft ETRI 4 Intended status: Informational Y-H. Han 5 Expires: April 4, 2007 KUT 6 S-E. Kim 7 KT 8 D. Premec 9 Siemens Mobile 10 October 1, 2006 12 IPv6 Deployment Scenarios in 802.16(e) Networks 13 draft-ietf-v6ops-802-16-deployment-scenarios-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 4, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document provides detailed description of IPv6 deployment and 47 integration methods and scenarios in wireless broadband access 48 networks in coexistence with deployed IPv4 services. In this 49 document we will discuss main components of IPv6 IEEE 802.16 access 50 network and its differences from IPv4 IEEE 802.16 networks and how 51 IPv6 is deployed and integrated in each of the IEEE 802.16 52 technologies using tunneling mechanisms and native IPv6. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Wireless Broadband Access Network Technologies - IEEE 58 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 60 2.2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . 5 61 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 6 62 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 10 63 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13 64 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 14 66 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 15 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 74 Intellectual Property and Copyright Statements . . . . . . . . . . 22 76 1. Introduction 78 Recently, broadband wireless access network is emerging for wireless 79 communication for user requirements such as high quality data/voice 80 service, fast mobility, wide coverage, etc. The IEEE 802.16 Working 81 Group develops standards and recommended practices to support the 82 development and deployment of broadband wireless metropolitan area 83 networks. 85 Whereas the [IEEE802.16] standard addresses fixed wireless 86 applications only, the [IEEE802.16e] standard serves the needs of 87 fixed, nomadic, and fully mobile networks. It adds mobility support 88 to the original standard so that mobile subscriber stations can move 89 during services. The standardization of IEEE 802.16e is completed, 90 which plans to support mobility up to speeds of 70~80 mile/h that 91 will enable the subscribers to carry mobile devices such as PDAs, 92 phones, or laptops. IEEE 802.16e is one of the most promising access 93 technologies which would be applied to the IP-based broadband mobile 94 communication. 96 As the deployment of wireless broadband access network progresses, 97 users will be connected to IPv6 networks. While the IEEE 802.16 98 defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 99 MAC payload, a complete description of IPv4/IPv6 operation and 100 deployment is not present. In this document, we will discuss main 101 components of IPv6 IEEE 802.16 access network and its differences 102 from IPv4 IEEE 802.16 networks and how IPv6 is deployed and 103 integrated in each of the IEEE 802.16 technologies using tunneling 104 mechanisms and native IPv6. 106 This document extends works of [I-D.ietf-v6ops-bb-deployment- 107 scenarios] and follows the structure and common terminology of the 108 document. 110 2. Wireless Broadband Access Network Technologies - IEEE 802.16 112 This section describes the infrastructure that is based on IEEE 113 802.16 networks providing wireless broadband services to the 114 customer. It also describes a way to deploy IPv6 over IEEE 802.16 115 networks. 117 2.1. Elements of IEEE 802.16 Networks 119 The IEEE 802.11 access network (WLAN) has driven the revolution of 120 wireless communication. However, the more people use it the more its 121 limitations such as short range and lack of mobility support arose. 122 Compared with such IEEE 802.11 network, IEEE 802.16 supports enhanced 123 features such as wider coverage and mobility. So it is expected that 124 IEEE 802.16 network could be the next step of IEEE 802.11 network. 126 The mechanism of transporting IP traffic over IEEE 802.16 networks is 127 outlined in [IEEE802.16], but the details of IPv6 operations over 128 IEEE 802.16 are being discussed now. 130 Here are some of the key elements of an IEEE 802.16 network: 132 o MS: Mobile Station. A station in the mobile service intended to 133 be used while in motion or during halts at unspecified points. A 134 mobile station (MS) is always a subscriber station (SS) which must 135 provide mobility function. 137 o BS: Base Station. A generalized equipment set providing 138 management and control of MS connections. There is a 139 unidirectional mapping between BS and MS medium access control 140 (MAC) peers for the purpose of transporting a service flow's 141 traffic. A connection is identified by a connection identifier 142 (CID). All traffic is carried on the connection. Sometimes there 143 can be alternative IEEE 802.16 network deployment where a BS is 144 integrated with an access router, composing one box in view of 145 implementation. 147 o AR: Access Router. A generalized equipment set providing IP 148 connectivity between BS and IP based network. An AR performs 149 first hop routing function to all MS. 151 Figure 1 illustrates the key elements of IEEE 802.16(e) networks. 153 Customer | Access Provider | Service Provider 154 Premise | | (Backend Network) 156 +-----+ +----+ +----+ +--------+ 157 | MSs |--(802.16)--| BS |-----| | | Edge | ISP 158 +-----+ +----+ | AR |---| Router |==>Network 159 +--| | | (ER) | 160 | +----+ +--------+ 161 +-----+ +----+ | | +------+ 162 | MSs |--(802.16)--| BS |--+ +--|AAA | 163 +-----+ +----+ |Server| 164 +------+ 166 Figure 1: Key Elements of IEEE 802.16(e) Networks 168 2.2. Deploying IPv6 in IEEE 802.16 Networks 170 [IEEE802.16] specifies two modes for sharing the wireless medium: 171 point-to-multipoint (PMP) and mesh (optional). This document only 172 focuses on PMP mode. 174 Some of the factors that hinder deployment of native IPv6 core 175 protocols are introduced by [I-D.jee-16ng-problem-statement]. The 176 summary of them is as follows: 178 1. Lacking of Facility for IPv6 Native Multicasting 180 IEEE 802.16 PMP mode is a connection oriented technology without bi- 181 directional native multicast support. IPv6 neighbor discovery 182 [RFC2461] supports various functions for the interaction between 183 nodes attached on the same subnet, such as on-link determination and 184 address resolution. It is designed with no dependence on a specific 185 link layer technology, but requires that the link layer technology 186 support native multicast. This lacking of facility for IPv6 native 187 multicast results in inappropriateness to apply the standard neighbor 188 discover protocol specially regarding, address resolution, router 189 discovery, stateless auto-configuration and duplicated address 190 detection. 192 2. Impact on IPv6 Subnet Model 194 IEEE 802.16 is different from existing wireless access technologies 195 such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the 196 encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a 197 complete description of IPv6 operation is not present. IEEE 802.16 198 can rather benefit from IETF input and specification to support IPv6 199 operation. Especially, BS should look at the classifiers and decide 200 where to send the packet, since IEEE 802.16 connection always ends at 201 BS, while IPv6 connection terminates at a default router. This 202 operation and limitation may be dependent on the given subnet model 203 [I-D.madanapalli-16ng-subnet-model-analysis]. 205 3. Multiple Convergence Sublayers (CS) 207 There are operational complexity problems of IP over 802.16 caused by 208 the existence of multiple convergence sublayers [I-D.iab-link- 209 encaps]. We should consider which type of Convergence Sublayer (CS) 210 can be efficiently used on each subnet models and scenarios. IEEE 211 802.16 CS delivers and classifies various kinds of higher layer PDUs 212 such as ATM, IPv4 packet and IPv6 packets over radio channel. For 213 this purpose, IEEE 802.16 introduces the Connection Identifier (CID). 214 Generally, CS performs the following functions in terms of IP packet 215 transmission: 1) Receipt of protocol data units (PDUs) from the 216 higher layer, 2) Performing classification and CID mapping of the 217 PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt 218 of PDUs from the peer MAC SAP, and 5) Forwarding the PDUs to the 219 corresponding AR. The specification of IEEE 802.16 defines several 220 CSs for carrying IP packets, but does not provide a detailed 221 description of how to carry them. The several CSs are generally 222 classified into two types of CS: IPv6 CS and Ethernet CS. 224 In addition, due to the problems caused by the existence of multiple 225 convergence sublayers [I-D.iab-link-encaps], the mobile access 226 scenarios need solutions about how roaming will work when forced to 227 move from one CS to another. Note that, at this phase this issue is 228 the out of scope of this draft. It should be also discussed in 16ng 229 WG. 231 There are two different deployment scenarios: fixed and mobile 232 access. A fixed access scenario substitudes for existing wired-based 233 access technologies such as digital subscriber line (xDSL) and cable 234 network. This fixed access scenario can provide nomadic access 235 within the radio coverages, which is called Hot-zone model. A mobile 236 access scenario is for new paradigm for voice, data and video over 237 mobile network. This scenario can provide high speed data rate 238 equalivent to wire-based Internet as well as mobility function 239 equivalent to cellular system. The mobile access scenario can be 240 classified into two different IPv6 sunbet models: shared IPv6 prefix 241 link model and point-to-point link model. 243 2.2.1. Mobile Access Deployment Scenarios 245 Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as 246 well as fixed communication. [IEEE802.16e] has been standardized to 247 provide mobility features on IEEE 802.16 environments. This use case 248 will be implemented only with the licensed spectrum. IEEE 802.16 BS 249 might be deployed with a proprietary backend managed by an operator. 250 All original IPv6 functionalities [RFC2461], [RFC2462] will not 251 survive. Some architectural characteristics of IEEE 802.16 networks 252 may affect the detailed operations of NDP [RFC2461]. 254 There are two possible IPv6 subnet models for mobile access 255 deployment scenarios: shared IPv6 prefix link model and point-to- 256 point link model [I-D.madanapalli-16ng-subnet-model-analysis]. The 257 mobile access deployment models, WiMax and WiBro, fall within this 258 deployment model. 260 1. Shared IPv6 Prefix Link Model 262 This link model represents IEEE 802.16 mobile access network 263 deployment where a subnet consists of only single interface of AR and 264 multiple MSs. Therefore, all MSs and corresponding interface of AR 265 share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be 266 different from the interface of AR. 268 +-----+ 269 | MS1 |<-(16)-+ 270 +-----+ | 271 +-----+ | +-----+ +-----+ +--------+ 272 | MS2 |<-(16)-+----| BS1 |--+->| AR |----| Edge | ISP 273 +-----+ +-----+ | +-----+ | Router +==>Network 274 | +--------+ 275 +-----+ +-----+ | 276 | MS3 |<-(16)-+----| BS2 |--+ 277 +-----+ | +-----+ 278 +-----+ | 279 | MS4 |<-(16)-+ 280 +-----+ 282 Figure 2: Shared IPv6 Prefix Link Model 284 2. Point-to-Point Link Model 286 This link model represents IEEE 802.16 mobile access network 287 deployment where a subnet consists of only single AR, BS and MS. 288 That is, each connection to a mobile node is treated as a single 289 link. Each link between the MS and the AR is allocated a separate, 290 unique prefix or unique set of prefixes by the AR. The point-to- 291 point link model follows the recommendations of [RFC3314]. 293 +-----+ 294 | MS1 |<-(16)---------+ 295 +-----+ | 296 +-----+ +-----+ +-----+ +--------+ 297 | MS2 |<-(16)------| BS1 |--+->| AR |----| Edge | ISP 298 +-----+ +-----+ | +-----+ | Router +==>Network 299 | +--------+ 300 +-----+ +-----+ | 301 | MS3 |<-(16)------| BS2 |--+ 302 +-----+ +-----+ 303 +-----+ | 304 | MS4 |<-(16)---------+ 305 +-----+ 307 Figure 3: Point-to-Point Link Model 309 2.2.1.1. IPv6 Related Infrastructure Changes 311 IPv6 will be deployed in this scenario by upgrading the following 312 devices to dual-stack: MS, BS, AR and ER. In this scenario, IEEE 313 802.16 BSs have only MAC and PHY layers without router function and 314 operates as a bridge. The BS does not need to support IPv6. 315 However, if IPv4 stack is loaded to them for management and 316 configuration purpose, it is expected that BS should be upgraded by 317 implementing IPv6 stack, too. 319 2.2.1.2. Addressing 321 IPv6 MS has two possible options to get an IPv6 address. These 322 options will be equally applied to the other scenario below (Section 323 2.2.2). 325 1. IPv6 MS can get the IPv6 address from an access router using 326 stateless auto-configuration. In this case, router discovery and DAD 327 operation should be properly operated over IEEE 802.16 link. 329 2. IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6 330 server. In this case, the DHCPv6 server would be located in the 331 service provider core network and the AR should provide DHCPv6 relay 332 agent. This option is similar to what we do today in case of DHCPv4. 334 In this scenario, a router and multiple BSs form an IPv6 subnet and a 335 single prefix is allocated to all the attached MSs. All MSs attached 336 to same AR can be on same IPv6 link. 338 As for the prefix assignment, in case of shared IPv6 prefix link 339 model, one or more IPv6 prefixes are assigned to the link and hence 340 shared by all the nodes that are attached to the link. In point-to- 341 point link model, the AR assigns a unique prefix or set of unique 342 prefixes for each MS. 344 2.2.1.3. IPv6 Transport 346 In a subnet, there are always two underlying links: one is the IEEE 347 802.16 wireless link between MS and BS, and the other is a wired link 348 between BS and AR. The IPv6 packet should be classified by IPv6 349 source/destination addresses, etc. BS generates the flow based on 350 the classification. It also decides where to send the packet or just 351 forward the packet to the ACR, since IEEE 802.16 connection always 352 ends at BS while IPv6 connection terminates at the AR. This 353 operation may be dependent on IPv6 subnet models. 355 If stateless auto-configuration is used to get an IPv6 address, 356 router discovery and DAD operation should be properly operated over 357 IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD 358 [RFC2461] does not adapt well to the 802.16 air interface as there is 359 no native multicast support and when supported consumes air bandwidth 360 as well as it would have adverse effect on MSs that were in the 361 dormant mode. An optimization, called Relay DAD, may be required to 362 perform DAD. However, in case of point-to-point link model, DAD is 363 easy since each connection to a MN is treated as a unique IPv6 link. 365 Note that in this scenario IPv6 CS may be more appropriate than 366 Ethernet CS to transport IPv6 packets, since there are some overhead 367 of Ethernet CS (e.g., Ethernet header) under mobile access 368 environments . 370 Simple or complex network equipments may constitute the underlying 371 wired network between the AR and the ER. If the IP aware equipments 372 between the AR and the ER do not support IPv6, the service providers 373 can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6 374 packets between the AR and the ER. 376 The service providers are deploying tunneling mechanisms to transport 377 IPv6 over their existing IPv4 networks as well as deploying native 378 IPv6 where possible. Native IPv6 should be preferred over tunneling 379 mechanisms as native IPv6 deployment option might be more scalable 380 and provide required service performance. Tunneling mechanisms 381 should only be used when native IPv6 deployment is not an option. 382 This can be equally applied to other scenario below (Section 2.2.2). 384 2.2.1.4. Routing 386 In general, the MS is configured with a default route that points to 387 the the AR. Therefore, no routing protocols are needed on the MS. 388 The MS just sends to the AR by default route. 390 The AR can configure multiple link to ER for network reliability. 391 The AR should support IPv6 routing protocol such as OSPFv3 [RFC2740] 392 or IS-IS for IPv6 when connected to the ER with multiple links. 394 The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service 395 provider network. The routing information of the ER can be 396 redistributed to the AR. Prefix summarization should be done at the 397 ER. 399 2.2.1.5. Mobility 401 As for mobility management, the movement between BSs is handled by 402 Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in 403 certain cases (e.g., fast handover [I-D.ietf-mipshop-fmipv6- 404 rfc4068bis]) the link mobility information must be available for 405 facilitating layer 3 handoff procedure. 407 Mobile IPv6 defines that movement detection uses Neighbor 408 Unreachability Detection to detect when the default router is no 409 longer bi-directionally reachable, in which case the mobile node must 410 discover a new default router. Periodic Router Advertisements for 411 reachability and movement detection may be unnecessary because IEEE 412 802.16 MAC provides the reachability by its Ranging procedure and the 413 movement detection by the Handoff procedure. 415 IEEE 802.16 defines L2 triggers whether refresh of an IP address is 416 required during the handoff. Though a handoff has occurred, an 417 additional router discovery procedure is not required in case of 418 intra-subnet handoff. Also, faster handoff may be occurred by the L2 419 trigger in case of inter-subnet handoff. 421 Also, IEEE 802.16g which is under-developed defines L2 triggers for 422 link status such as link-up, link-down, handoff-start. These L2 423 triggers may make Mobile IPv6 procedure more efficient and faster. 424 In addition, Mobile IPv6 Fast Handover assumes the support from link- 425 layer technology, but the particular link-layer information being 426 available, as well as the timing of its availability (before, during 427 or after a handover has occurred), differs according to the 428 particular link-layer technology in use. This issue is also being 429 discussed in [I-D.ietf-mipshop-fh80216e]. 431 2.2.2. Fixed/Nomadic Deployment Scenarios 433 The IEEE 802.16 access networks can provide plain Ethernet 434 connectivity end-to-end. Wireless DSL deployment model is an example 435 of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless 436 Internet service providers (Wireless ISPs) have planned to use IEEE 437 802.16 for the purpose of high quality broadband wireless service. A 438 company can use IEEE 802.16 to build up mobile office. Wireless 439 Internet spreading through a campus or a cafe can be also implemented 440 with it. The distinct point of this use case is that it can use 441 unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 & 3.5GHz) 442 band. By using the unlicensed band, an IEEE 802.16 BS might be used 443 just as a wireless switch/hub which a user purchases to build a 444 private wireless network in his/her home or laboratory. 446 Under fixed access model, the IEEE 802.16 BS will be deployed using 447 an IP backbone rather than a proprietary backend like cellular 448 systems. Thus, many IPv6 functionalities such as [RFC2461], 449 [RFC2462] will be preserved when adopting IPv6 to IEEE 802.16 450 devices. 452 This scenario also represents IEEE 802.16 network deployment where a 453 subnet consists of multiple MSs and multiple interface of the 454 multiple BSs. Multiple access routers can exist. There exist 455 multiple hosts behind an SS (networks behind an MS may exist). When 456 802.16 access networks are widely deployed like WLAN, this case 457 should be also considered. Hot-zone deployment model falls within 458 this case. 460 +-----+ +-----+ +-----+ ISP 1 461 | SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network 462 +-----+ | | +-----+ +-----+ 463 +-----+ | +-----+ | 464 | SS2 |<-(16)+-----| BS1 |--| 465 +-----+ +-----+ | +-----+ +-----+ ISP 2 466 +->| AR2 |----| ER2 |===>Network 467 +-----+ +-----+ +-----+ | +-----+ +-----+ 468 |Hosts|<-->|SS/GW|<-(16)------| BS2 |--+ 469 +-----+ +-----+ +-----+ 470 This network 471 behind MS may exist 473 Figure 4: Fixed/Nomadic Deployment Scenario 475 While Figure 3 illustrates a generic deployment scenario, the 476 following Figure 4 shows in more detail how an existing DSL ISP would 477 integrate the 802.16 access network into its existing infrastructure. 479 +-----+ +---+ +-----+ +-----+ ISP 1 480 | SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network 481 +-----+ | | b| | +-----+ +-----+ 482 +-----+ | +-----+ |E r| | 483 | SS2 |<-(16)+-----| BS1 |-----|t i| | 484 +-----+ +-----+ |h d|--+ 485 | g| | +-----+ +-----+ ISP 2 486 +-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network 487 | SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+ 488 +-----+ +-----+ +---+ | 489 | 490 +-----+ +-----+ | 491 | TE |<-(DSL)-----|DSLAM|------------+ 492 +-----+ +-----+ 494 Figure 5: Integration of 802.16 access into DSL infrastructure 496 In this approach the 802.16 BS is acting as a DSLAM (Digital 497 Subscriber Line Access Multiplexer). On the network side, the BS is 498 connected to an Ethernet bridge which can be separate equipment or 499 integrated into BRAS (Broadband Remote Access Server). 501 2.2.2.1. IPv6 Related Infrastructure Changes 503 IPv6 will be deployed in this scenario by upgrading the following 504 devices to dual-stack: MS, BS, AR and ER. In this scenario, IEEE 505 802.16 BSs have only MAC and PHY layers without router function and 506 operates as a bridge. The BS does not need to support IPv6. 507 However, if IPv4 stack is loaded to them for management and 508 configuration purpose, it is expected that BS should be upgraded by 509 implementing IPv6 stack, too. 511 The BRAS in Figure 4 is providing the functionality of the AR. The 512 Ethernet bridge is necessary for protecting the BRAS from 802.16 link 513 layer peculiarities. The Ethernet bridge relays all traffic received 514 through BS to its network side port(s) connected to BRAS. Any 515 traffic received from BRAS is relayed to appropriate BS. Since 516 802.16 MAC layer has no native support for multicast (and broadcast) 517 in the uplink direction, the Ethernet bridge will emulate Ethernet 518 level multicast (and broadcast) by relaying the multicast frame 519 received from the MS to all of its ports. Ethernet bridge may also 520 provide some IPv6 specific functions to increase link efficiency of 521 the 802.16 radio link (see Section 2.2.2.3). 523 2.2.2.2. Addressing 525 One or more IPv6 prefixes can be shared to all the attached MSs. 526 Prefix delegation can be required since networks can exist behind SS. 528 2.2.2.3. IPv6 Transport 530 Note that in this scenario Ethernet CS may be more appropriate than 531 IPv6 CS to transport IPv6 packets, since the scenario need to support 532 plain Ethernet connectivity end-to-end. However, the IPv6 CS can 533 also be supported. Every MS and the BS has the Ethernet type MAC 534 address. If the MS is using IP CS, then the BS needs to take care of 535 the Ethernet header. In the upstream direction, the BS will need to 536 generate an appropriate Ethernet header and prepend it to the IP 537 datagram. In the downstream direction, the BS will use the 538 destination address from the Ethernet header to identify the MS and 539 then it will strip the Ethernet header before relaying the IP 540 datagram over the 802.16 MAC connection. Ethernet bridge may provide 541 implementation of authoritative address cache and Relay DAD. 542 Authoritative address cache is a mapping between the IPv6 address and 543 the MAC addresses of all attached MSs. 545 The bridge builds its authoritative address cache by parsing the IPv6 546 Neighbor Discovery messages used during address configuration (DAD). 547 Relay DAD means that the Neighbor Solicitation message used in DAD 548 process will be relayed only to the MS which already has configured 549 the solicited address as its own address (if such MS exist at all). 551 2.2.2.4. Routing 553 In this scenario, IPv6 multi-homing considerations exist. For 554 example, if there exist two routers to support MSs, default router 555 must be selected. 557 The Edge Router runs the IGP used in the SP network such as OSPFv3 558 [RFC2740] or IS-IS for IPv6. The connected prefixes have to be 559 redistributed. Prefix summarization should be done at the Edge 560 Router. 562 2.2.2.5. Mobility 564 No mobility functions are supported in fixed access scenario. 565 However, mobility can support in the radio coverage without any 566 mobility protocol like WLAN technology. Therefore, a user can access 567 Internet nomadically in the coverage. 569 2.3. IPv6 Multicast 571 In IEEE 802.16 air link, downlink connections can be shared among 572 multiple MSs, enabling multicast channels with multiple MSs receiving 573 the same information from the BS. MBS may be used to efficiently 574 implement multicast. However, it is not clear how to do this, as 575 currently CID is assigned by BS, but in MBS it should be done at an 576 AR and it's network scope. For MBS how this mapping will happen is 577 not clear, so MBS discussions have been postponed in WiMax for now. 578 Note that it should be intensively researched later, since MBS will 579 be one of the killer services in IEEE 802.16 networks. 581 In order to support multicast services in IEEE 802.16, Multicast 582 Listener Discovery (MLD) [RFC2710] must be supported between the MS 583 and AR. Also, the inter-working with IP multicast protocols and 584 Multicast and Broadcast Service (MBS) should be considered. 586 MBS defines Multicast and Broadcast Services, but actually, MBS seems 587 to be a broadcast service, not multicasting. MBS adheres to 588 broadcast services, while traditional IP multicast schemes define 589 multicast routing using a shared tree or source-specific tree to 590 deliver packets efficiently. 592 In IEEE 802.16 networks, two types of access to MBS may be supported: 593 single-BS access and multi-BS access. Therefore, these two types of 594 services may be roughly mapped into Source-Specific Multicast. 596 2.4. IPv6 QoS 598 In IEEE 802.16 networks, a connection is unidirectional and has a QoS 599 specification. The QoS has different semantics with IP QoS (e.g., 600 diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS 601 parameters of the service flow associated with that connection. In 602 order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label 603 for IPv6) mapping to IEEE 802.16 link specifics should be provided. 605 2.5. IPv6 Security 607 When initiating the connection, an MS is authenticated by the AAA 608 server located at its service provider network. All the parameters 609 related to authentication (username, password and etc.) are forwarded 610 by the BS to the AAA server. The AAA server authenticates the MSs 611 and once authenticated. When an MS is once authenticated and 612 associated successfully with BS, IPv6 address will be acquired by the 613 MS with stateless autoconfiguration or DHCPv6. Note the initiation 614 and authentication process is the same as used in IPv4. 616 IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may 617 be used within the global end-to-end architecture. But, we don't 618 have PKIs across organizations and IPsec isn't integrated with IEEE 619 802.16 network mobility management. 621 IEEE 802.16 network threats may be different from IPv6 and IPv6 622 transition threat models [I-D.ietf-v6ops-security-overview]. It 623 should be also discussed. 625 2.6. IPv6 Network Management 627 For IPv6 network management, the necessary instrumentation (such as 628 MIBs, NetFlow Records, etc) should be available. 630 Upon entering the network, an MS is assigned three management 631 connections in each direction. These three connections reflect the 632 three different QoS requirements used by different management levels. 633 The first of these is the basic connection, which is used for the 634 transfer of short, time-critical MAC management messages and radio 635 link control (RLC) messages. The primary management connection is 636 used to transfer longer, more delay-tolerant messages such as those 637 used for authentication and connection setup. The secondary 638 management connection is used for the transfer of standards-based 639 management messages such as Dynamic Host Configuration Protocol 640 (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network 641 Management Protocol (SNMP). 643 IPv6 based IEEE 802.16 network can be managed by IPv4 or IPv6 when 644 network elements are implemented dual stak. For example, network 645 management system (NMS) can send SNMP message by IPv4 with IPv6 646 related object identifier. Also, an NMS can use IPv6 for SNMP 647 request and response including IPv4 related OID. 649 3. IANA Considerations 651 This document requests no action by IANA. 653 4. Security Considerations 655 Please refer to Section 2.5 "IPv6 Security" technology sections for 656 details. 658 5. Acknowledgements 660 This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- 661 scenarios]. We thank all the authors of the document. Special 662 thanks are due to Maximilian Riegel, Jonne Soininen, Brian E 663 Carpenter, Jim Bound, and Jung-Mo Moon for extensive review of this 664 document. 666 6. References 668 6.1. Normative References 670 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 671 Discovery for IP Version 6 (IPv6)", RFC 2461, 672 December 1998. 674 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 675 Autoconfiguration", RFC 2462, December 1998. 677 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 678 Listener Discovery (MLD) for IPv6", RFC 2710, 679 October 1999. 681 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 682 RFC 2740, December 1999. 684 6.2. Informative References 686 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 687 Generation Partnership Project (3GPP) Standards", 688 RFC 3314, September 2002. 690 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 691 in IPv6", RFC 3775, June 2004. 693 [I-D.jee-16ng-problem-statement] 694 Jee, J., "16ng Problem Statement", 695 draft-jee-16ng-problem-statement-02 (work in progress), 696 October 2005. 698 [I-D.madanapalli-16ng-subnet-model-analysis] 699 Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 700 based Networks", 701 draft-madanapalli-16ng-subnet-model-analysis-01 (work in 702 progress), September 2006. 704 [I-D.ietf-mipshop-fmipv6-rfc4068bis] 705 Koodli, R., "Fast Handovers for Mobile IPv6", 706 draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in 707 progress), May 2006. 709 [I-D.ietf-mipshop-fh80216e] 710 Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e 711 Networks", draft-ietf-mipshop-fh80216e-00 (work in 712 progress), April 2006. 714 [I-D.ietf-v6ops-security-overview] 715 Davies, E., "IPv6 Transition/Co-existence Security 716 Considerations", draft-ietf-v6ops-security-overview-05 717 (work in progress), September 2006. 719 [I-D.ietf-v6ops-bb-deployment-scenarios] 720 Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband 721 Access Networks", 722 draft-ietf-v6ops-bb-deployment-scenarios-05 (work in 723 progress), June 2006. 725 [I-D.iab-link-encaps] 726 Aboba, B., "Multiple Encapsulation Methods Considered 727 Harmful", draft-iab-link-encaps-02 (work in progress), 728 August 2006. 730 [IEEE802.16] 731 "IEEE 802.16-2004, IEEE standard for Local and 732 metropolitan area networks, Part 16: Air Interface for 733 fixed broadband wireless access systems", October 2004. 735 [IEEE802.16e] 736 "IEEE Std. for Local and metropolitan area networks Part 737 16: Air Interface for Fixed and Mobile Broadband Wireless 738 Access Systems Amendment 2: Physical and Medium Access 739 Control Layers for Combined Fixed and Mobile Operation in 740 Licensed Bands and Corrigendum 1", February 2006. 742 Authors' Addresses 744 Myung-Ki Shin 745 ETRI 746 161 Gajeong-dong Yuseng-gu 747 Daejeon, 305-350 748 Korea 750 Phone: +82 42 860 4847 751 Email: myungki.shin@gmail.com 753 Youn-Hee Han 754 KUT 755 Gajeon-Ri 307 Byeongcheon-Myeon 756 Cheonan-Si Chungnam Province, 330-708 757 Korea 759 Email: yhhan@kut.ac.kr 761 Sang-Eon Kim 762 KT 763 17 Woomyeon-dong, Seocho-gu 764 Seoul, 137-791 765 Korea 767 Email: sekim@kt.co.kr 769 Domagoj Premec 770 Siemens Mobile 771 Heinzelova 70a 772 10010 Zagreb 773 Croatia 775 Email: domagoj.premec@siemens.com 777 Full Copyright Statement 779 Copyright (C) The Internet Society (2006). 781 This document is subject to the rights, licenses and restrictions 782 contained in BCP 78, and except as set forth therein, the authors 783 retain all their rights. 785 This document and the information contained herein are provided on an 786 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 787 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 788 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 789 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 790 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 791 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 793 Intellectual Property 795 The IETF takes no position regarding the validity or scope of any 796 Intellectual Property Rights or other rights that might be claimed to 797 pertain to the implementation or use of the technology described in 798 this document or the extent to which any license under such rights 799 might or might not be available; nor does it represent that it has 800 made any independent effort to identify any such rights. Information 801 on the procedures with respect to rights in RFC documents can be 802 found in BCP 78 and BCP 79. 804 Copies of IPR disclosures made to the IETF Secretariat and any 805 assurances of licenses to be made available, or the result of an 806 attempt made to obtain a general license or permission for the use of 807 such proprietary rights by implementers or users of this 808 specification can be obtained from the IETF on-line IPR repository at 809 http://www.ietf.org/ipr. 811 The IETF invites any interested party to bring to its attention any 812 copyrights, patents or patent applications, or other proprietary 813 rights that may cover technology that may be required to implement 814 this standard. Please address the information to the IETF at 815 ietf-ipr@ietf.org. 817 Acknowledgment 819 Funding for the RFC Editor function is provided by the IETF 820 Administrative Support Activity (IASA).