idnits 2.17.1 draft-ietf-v6ops-802-16-deployment-scenarios-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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 732. ** 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 : ---------------------------------------------------------------------------- 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 (January 16, 2007) is 6309 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 621, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-bb-deployment-scenarios' is defined on line 636, 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 (-04) exists of draft-ietf-16ng-ps-goals-00 == Outdated reference: A later version (-03) exists of draft-ietf-16ng-ipv6-link-model-analysis-02 == 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-01 == Outdated reference: A later version (-08) exists of draft-iab-link-encaps-05 Summary: 6 errors (**), 0 flaws (~~), 8 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: July 20, 2007 KUT 6 S-E. Kim 7 KT 8 D. Premec 9 Siemens Mobile 10 January 16, 2007 12 IPv6 Deployment Scenarios in 802.16(e) Networks 13 draft-ietf-v6ops-802-16-deployment-scenarios-02 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 July 20, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2007). 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. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4 58 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 59 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 5 60 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5 61 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9 62 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 12 63 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 13 65 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 73 Intellectual Property and Copyright Statements . . . . . . . . . . 21 75 1. Introduction 77 As the deployment of IEEE 802.16(e) access network progresses, users 78 will be connected to IPv6 networks. While the IEEE 802.16 defines 79 the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 MAC 80 payload, a complete description of IPv4/IPv6 operation and deployment 81 is not present. In this document, we will discuss main components of 82 IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 83 802.16 networks and how IPv6 is deployed and integrated in each of 84 the IEEE 802.16 technologies using tunneling mechanisms and native 85 IPv6. 87 This document extends works of [I-D.ietf-v6ops-bb-deployment- 88 scenarios] and follows the structure and common terminology of the 89 document. 91 2. Deploying IPv6 in IEEE 802.16 Networks 93 2.1. Elements of IEEE 802.16 Networks 95 The mechanism of transporting IP traffic over IEEE 802.16 networks is 96 outlined in [IEEE802.16]. [IEEE802.16] only specifies the 97 convergence sublayers and the ability to transport IP over the air 98 interface. The details of IPv6 (and IPv4) operations over IEEE 99 802.16 are being discussed now in 16ng WG. 101 Here are some of the key elements of an IEEE 802.16 network. The 102 terminologies in this document "SS(MS)", "BS", and "AR" are to be 103 interpreted as described in [I-D.ietf-16ng-ps-goals]. 105 o Subscriber Station (SS): An end-user equipment that provides 106 connectivity to the 802.16 networks. It can be either fixed/ 107 nomadic or mobile equipment. In mobile environment, SS represents 108 the Mobile Subscriber Station (MS) introduced in IEEE 802.16e 109 specification. 111 o Base Station (BS): A generalized equipment sets providing 112 connectivity, management, and control between the subscriber 113 station and the 802.16 networks. 115 o Access Router (AR): An entity that performs an IP routing function 116 to provide IP connectivity for subscriber station (SS or MS). 118 Figure 1 illustrates the key elements of typical mobile 802.16 119 deployments. 121 Customer | Access Provider | Service Provider 122 Premise | | (Backend Network) 124 +-----+ +----+ +----+ +--------+ 125 | SSs |--(802.16)--| BS |-----| | | Edge | ISP 126 +-----+ +----+ | AR |---| Router |==>Network 127 +--| | | (ER) | 128 | +----+ +--------+ 129 +-----+ +----+ | | +------+ 130 | SSs |--(802.16)--| BS |--+ +--|AAA | 131 +-----+ +----+ |Server| 132 +------+ 134 Figure 1: Key Elements of IEEE 802.16(e) Networks 136 2.2. Scenarios and IPv6 Deployment 138 [IEEE802.16] specifies two modes for sharing the wireless medium: 139 point-to-multipoint (PMP) and mesh (optional). This document only 140 focuses on PMP mode. 142 Some of the factors that hinder deployment of native IPv6 core 143 protocols are already introduced by [I-D.ietf-16ng-ps-goals]. 145 There are two different deployment scenarios: fixed and mobile access 146 deployment scenarios. A fixed access scenario substitudes for 147 existing wired-based access technologies such as digital subscriber 148 line (xDSL) and cable network. This fixed access scenario can 149 provide nomadic access within the radio coverages, which is called 150 Hot-zone model. A mobile access scenario is for new paradigm for 151 voice, data and video over mobile network. This scenario can provide 152 high speed data rate equalivent to wire-based Internet as well as 153 mobility function equivalent to cellular system. The mobile access 154 scenario can be classified into two different IPv6 link models: 155 shared IPv6 prefix link model and point-to-point link model. 157 2.2.1. Mobile Access Deployment Scenarios 159 Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as 160 well as fixed communication. [IEEE802.16e] has been standardized to 161 provide mobility features on IEEE 802.16 environments. IEEE 802.16 162 BS might be deployed with a proprietary backend managed by an 163 operator. Some architectural characteristics of IEEE 802.16 networks 164 may affect the detailed operations of NDP [RFC2461], [RFC2462]. 166 There are two possible IPv6 link models for mobile access deployment 167 scenarios: shared IPv6 prefix link model and point-to-point link 168 model [I-D.ietf-16ng-ipv6-link-model-analysis]. There is alwayes a 169 default access router in the scenarios. There exist multiple hosts 170 behind an MS (networks behind an MS may exist). The mobile access 171 deployment models, Mobile WiMax and WiBro, fall within this 172 deployment model. 174 1. Shared IPv6 Prefix Link Model 176 This link model represents IEEE 802.16 mobile access network 177 deployment where a subnet consists of only single interface of AR and 178 multiple MSs. Therefore, all MSs and corresponding interface of AR 179 share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be 180 different from the interface of AR. 182 +-----+ 183 | MS1 |<-(16)-+ 184 +-----+ | 185 +-----+ | +-----+ +-----+ +--------+ 186 | MS2 |<-(16)-+----| BS1 |--+->| AR |----| Edge | ISP 187 +-----+ +-----+ | +-----+ | Router +==>Network 188 | +--------+ 189 +-----+ +-----+ | 190 | MS3 |<-(16)-+----| BS2 |--+ 191 +-----+ | +-----+ 192 +-----+ | 193 | MS4 |<-(16)-+ 194 +-----+ 196 Figure 2: Shared IPv6 Prefix Link Model 198 2. Point-to-Point Link Model 200 This link model represents IEEE 802.16 mobile access network 201 deployment where a subnet consists of only single AR, BS and MS. 202 That is, each connection to a mobile node is treated as a single 203 link. Each link between the MS and the AR is allocated a separate, 204 unique prefix or unique set of prefixes by the AR. The point-to- 205 point link model follows the recommendations of [RFC3314]. 207 +-----+ 208 | MS1 |<-(16)---------+ 209 +-----+ | 210 +-----+ +-----+ +-----+ +--------+ 211 | MS2 |<-(16)------| BS1 |--+->| AR |----| Edge | ISP 212 +-----+ +-----+ | +-----+ | Router +==>Network 213 | +--------+ 214 +-----+ +-----+ | 215 | MS3 |<-(16)------| BS2 |--+ 216 +-----+ +-----+ 217 +-----+ | 218 | MS4 |<-(16)---------+ 219 +-----+ 221 Figure 3: Point-to-Point Link Model 223 2.2.1.1. IPv6 Related Infrastructure Changes 225 IPv6 will be deployed in this scenario by upgrading the following 226 devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16 227 BSs have only MAC and PHY layers without router function and operates 228 as a bridge. The BS does not need to support IPv6. However, if IPv4 229 stack is loaded to them for management and configuration purpose, it 230 is expected that BS should be upgraded by implementing IPv6 stack, 231 too. 233 2.2.1.2. Addressing 235 IPv6 MS has two possible options to get an IPv6 address. These 236 options will be equally applied to the other scenario below (Section 237 2.2.2). 239 1. IPv6 MS can get the IPv6 address from an access router using 240 stateless auto-configuration. In this case, router discovery and DAD 241 operation should be properly operated over IEEE 802.16 link. 243 2. IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6 244 server. In this case, the DHCPv6 server would be located in the 245 service provider core network and the AR should provide DHCPv6 relay 246 agent. This option is similar to what we do today in case of DHCPv4. 248 In this scenario, a router and multiple BSs form an IPv6 subnet and a 249 single prefix is allocated to all the attached MSs. All MSs attached 250 to same AR can be on same IPv6 link. 252 As for the prefix assignment, in case of shared IPv6 prefix link 253 model, one or more IPv6 prefixes are assigned to the link and hence 254 shared by all the nodes that are attached to the link. In point-to- 255 point link model, the AR assigns a unique prefix or set of unique 256 prefixes for each MS. Prefix delegation can be required if networks 257 can exist behind MS. 259 2.2.1.3. IPv6 Transport 261 In a subnet, there are always two underlying links: one is the IEEE 262 802.16 wireless link between MS and BS, and the other is a wired link 263 between BS and AR. The IPv6 packet should be classified by IPv6 264 source/destination addresses, etc. BS generates the flow based on 265 the classification. It also decides where to send the packet or just 266 forward the packet to the ACR, since IEEE 802.16 connection always 267 ends at BS while IPv6 connection terminates at the AR. This 268 operation may be dependent on IPv6 subnet models. 270 If stateless auto-configuration is used to get an IPv6 address, 271 router discovery and DAD operation should be properly operated over 272 IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD 273 [RFC2461] does not adapt well to the 802.16 air interface as there is 274 no native multicast support. An optimization, called Relay DAD, may 275 be required to perform DAD. However, in case of point-to-point link 276 model, DAD is easy since each connection to a MN is treated as a 277 unique IPv6 link. 279 Note that in this scenario IPv6 CS may be more appropriate than 280 Ethernet CS to transport IPv6 packets, since there are some overhead 281 of Ethernet CS (e.g., Ethernet header) under mobile access 282 environments. However PHS (Packet Header Compression), if deployed, 283 mitigates much of this overhead. 285 Simple or complex network equipments may constitute the underlying 286 wired network between the AR and the ER. If the IP aware equipments 287 between the AR and the ER do not support IPv6, the service providers 288 can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6 289 packets between the AR and the ER. 291 The service providers are deploying tunneling mechanisms to transport 292 IPv6 over their existing IPv4 networks as well as deploying native 293 IPv6 where possible. Native IPv6 should be preferred over tunneling 294 mechanisms as native IPv6 deployment option might be more scalable 295 and provide required service performance. Tunneling mechanisms 296 should only be used when native IPv6 deployment is not an option. 297 This can be equally applied to other scenario below (Section 2.2.2). 299 2.2.1.4. Routing 301 In general, the MS is configured with a default route that points to 302 the the AR. Therefore, no routing protocols are needed on the MS. 303 The MS just sends to the AR by default route. 305 The AR can configure multiple link to ER for network reliability. 306 The AR should support IPv6 routing protocol such as OSPFv3 [RFC2740] 307 or IS-IS for IPv6 when connected to the ER with multiple links. 309 The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service 310 provider network. The routing information of the ER can be 311 redistributed to the AR. Prefix summarization should be done at the 312 ER. 314 2.2.1.5. Mobility 316 As for mobility management, the movement between BSs is handled by 317 Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in 318 certain cases (e.g., fast handover [I-D.ietf-mipshop-fmipv6- 319 rfc4068bis]) the link mobility information must be available for 320 facilitating layer 3 handoff procedure. 322 Mobile IPv6 defines that movement detection uses Neighbor 323 Unreachability Detection to detect when the default router is no 324 longer bi-directionally reachable, in which case the mobile node must 325 discover a new default router. Periodic Router Advertisements for 326 reachability and movement detection may be unnecessary because IEEE 327 802.16 MAC provides the reachability by its Ranging procedure and the 328 movement detection by the Handoff procedure. 330 IEEE 802.16 defines L2 triggers whether refresh of an IP address is 331 required during the handoff. Though a handoff has occurred, an 332 additional router discovery procedure is not required in case of 333 intra-subnet handoff. Also, faster handoff may be occurred by the L2 334 trigger in case of inter-subnet handoff. 336 Also, IEEE 802.16g which is under-developed defines L2 triggers for 337 link status such as link-up, link-down, handoff-start. These L2 338 triggers may make Mobile IPv6 procedure more efficient and faster. 339 In addition, Mobile IPv6 Fast Handover assumes the support from link- 340 layer technology, but the particular link-layer information being 341 available, as well as the timing of its availability (before, during 342 or after a handover has occurred), differs according to the 343 particular link-layer technology in use. This issue is also being 344 discussed in [I-D.ietf-mipshop-fh80216e]. 346 In addition, due to the problems caused by the existence of multiple 347 convergence sublayers [I-D.iab-link-encaps], the mobile access 348 scenarios need solutions about how roaming will work when forced to 349 move from one CS to another. Note that, at this phase this issue is 350 the out of scope of this draft. It should be also discussed in 16ng 351 WG. 353 2.2.2. Fixed/Nomadic Deployment Scenarios 355 The IEEE 802.16 access networks can provide plain Ethernet 356 connectivity end-to-end. Wireless DSL deployment model is an example 357 of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless 358 Internet service providers (Wireless ISPs) have planned to use IEEE 359 802.16 for the purpose of high quality broadband wireless service. A 360 company can use IEEE 802.16 to build up mobile office. Wireless 361 Internet spreading through a campus or a cafe can be also implemented 362 with it. The distinct point of this use case is that it can use 363 unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 & 3.5GHz) 364 band. By using the unlicensed band, an IEEE 802.16 BS might be used 365 just as a wireless switch/hub which a user purchases to build a 366 private wireless network in his/her home or laboratory. 368 Under fixed access model, the IEEE 802.16 BS will be deployed using 369 an IP backbone rather than a proprietary backend like cellular 370 systems. Thus, many IPv6 functionalities such as [RFC2461], 371 [RFC2462] will be preserved when adopting IPv6 to IEEE 802.16 372 devices. 374 This scenario also represents IEEE 802.16 network deployment where a 375 subnet consists of multiple MSs and multiple interface of the 376 multiple BSs. Multiple access routers can exist. There exist 377 multiple hosts behind an SS (networks behind an SS may exist). When 378 802.16 access networks are widely deployed like WLAN, this case 379 should be also considered. Hot-zone deployment model falls within 380 this case. 382 +-----+ +-----+ +-----+ ISP 1 383 | SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network 384 +-----+ | | +-----+ +-----+ 385 +-----+ | +-----+ | 386 | SS2 |<-(16)+-----| BS1 |--| 387 +-----+ +-----+ | +-----+ +-----+ ISP 2 388 +->| AR2 |----| ER2 |===>Network 389 +-----+ +-----+ +-----+ | +-----+ +-----+ 390 |Hosts|<-->|SS/GW|<-(16)------| BS2 |--+ 391 +-----+ +-----+ +-----+ 392 This network 393 behind SS may exist 395 Figure 4: Fixed/Nomadic Deployment Scenario 397 While Figure 4 illustrates a generic deployment scenario, the 398 following Figure 5 shows in more detail how an existing DSL ISP would 399 integrate the 802.16 access network into its existing infrastructure. 401 +-----+ +---+ +-----+ +-----+ ISP 1 402 | SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network 403 +-----+ | | b| | +-----+ +-----+ 404 +-----+ | +-----+ |E r| | 405 | SS2 |<-(16)+-----| BS1 |-----|t i| | 406 +-----+ +-----+ |h d|--+ 407 | g| | +-----+ +-----+ ISP 2 408 +-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network 409 | SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+ 410 +-----+ +-----+ +---+ | 411 | 412 +-----+ +-----+ | 413 | TE |<-(DSL)-----|DSLAM|------------+ 414 +-----+ +-----+ 416 Figure 5: Integration of 802.16 access into DSL infrastructure 418 In this approach the 802.16 BS is acting as a DSLAM (Digital 419 Subscriber Line Access Multiplexer). On the network side, the BS is 420 connected to an Ethernet bridge which can be separate equipment or 421 integrated into BRAS (Broadband Remote Access Server). 423 2.2.2.1. IPv6 Related Infrastructure Changes 425 IPv6 will be deployed in this scenario by upgrading the following 426 devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16 427 BSs have only MAC and PHY layers without router function and operates 428 as a bridge. The BS does not need to support IPv6. However, if IPv4 429 stack is loaded to them for management and configuration purpose, it 430 is expected that BS should be upgraded by implementing IPv6 stack, 431 too. 433 The BRAS in Figure 5 is providing the functionality of the AR. The 434 Ethernet bridge is necessary for protecting the BRAS from 802.16 link 435 layer peculiarities. The Ethernet bridge relays all traffic received 436 through BS to its network side port(s) connected to BRAS. Any 437 traffic received from BRAS is relayed to appropriate BS. Since 438 802.16 MAC layer has no native support for multicast (and broadcast) 439 in the uplink direction, the Ethernet bridge will implement multicast 440 (and broadcast) by relaying the multicast frame received from the MS 441 to all of its ports. The Ethernet bridge may also provide some IPv6 442 specific functions to increase link efficiency of the 802.16 radio 443 link (see Section 2.2.2.3). 445 2.2.2.2. Addressing 447 One or more IPv6 prefixes can be shared to all the attached MSs. 448 Prefix delegation can be required if networks can exist behind SS. 450 2.2.2.3. IPv6 Transport 452 Note that in this scenario Ethernet CS may be more appropriate than 453 IPv6 CS to transport IPv6 packets, since the scenario need to support 454 plain Ethernet connectivity end-to-end. However, the IPv6 CS can 455 also be supported. The MS and BS will consider the connections 456 between the peer IP CSs at the MS and BS to form a point to point 457 link. In the Ethernet CS case, an Ethernet bridge may provide 458 implementation of authoritative address cache and Relay DAD. 459 Authoritative address cache is a mapping between the IPv6 address and 460 the MAC addresses of all attached MSs. 462 The bridge builds its authoritative address cache by parsing the IPv6 463 Neighbor Discovery messages used during address configuration (DAD). 464 Relay DAD means that the Neighbor Solicitation message used in DAD 465 process will be relayed only to the MS which already has configured 466 the solicited address as its own address (if such MS exist at all). 468 2.2.2.4. Routing 470 In this scenario, IPv6 multi-homing considerations exist. For 471 example, if there exist two routers to support MSs, default router 472 must be selected. 474 The Edge Router runs the IGP used in the SP network such as OSPFv3 475 [RFC2740] or IS-IS for IPv6. The connected prefixes have to be 476 redistributed. Prefix summarization should be done at the Edge 477 Router. 479 2.2.2.5. Mobility 481 No mobility functions are supported in fixed access scenario. 482 However, mobility can support in the radio coverage without any 483 mobility protocol like WLAN technology. Therefore, a user can access 484 Internet nomadically in the coverage. 486 2.3. IPv6 Multicast 488 In IEEE 802.16 air link, downlink connections can be shared among 489 multiple MSs, enabling multicast channels with multiple MSs receiving 490 the same information from the BS. MBS may be used to efficiently 491 implement multicast. However, it is not clear how to do this, as 492 currently CID is assigned by BS, but in MBS it should be done at an 493 AR and it's network scope. For MBS how this mapping will happen is 494 not clear, so MBS discussions have been postponed in WiMax for now. 495 Note that it should be intensively researched later, since MBS will 496 be one of the killer services in IEEE 802.16 networks. 498 In order to support multicast services in IEEE 802.16, Multicast 499 Listener Discovery (MLD) [RFC2710] must be supported between the MS 500 and AR. Also, the inter-working with IP multicast protocols and 501 Multicast and Broadcast Service (MBS) should be considered. 503 MBS defines Multicast and Broadcast Services, but actually, MBS seems 504 to be a broadcast service, not multicasting. MBS adheres to 505 broadcast services, while traditional IP multicast schemes define 506 multicast routing using a shared tree or source-specific tree to 507 deliver packets efficiently. 509 In IEEE 802.16 networks, two types of access to MBS may be supported: 510 single-BS access and multi-BS access. Therefore, these two types of 511 services may be roughly mapped into Source-Specific Multicast. 513 2.4. IPv6 QoS 515 In IEEE 802.16 networks, a connection is unidirectional and has a QoS 516 specification. The QoS has different semantics with IP QoS (e.g., 517 diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS 518 parameters of the service flow associated with that connection. In 519 order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label 520 for IPv6) mapping to IEEE 802.16 link specifics should be provided. 522 2.5. IPv6 Security 524 When initiating the connection, an MS is authenticated by the AAA 525 server located at its service provider network. All the parameters 526 related to authentication (username, password and etc.) are forwarded 527 by the BS to the AAA server. The AAA server authenticates the MSs 528 and once authenticated. When an MS is once authenticated and 529 associated successfully with BS, IPv6 address will be acquired by the 530 MS with stateless autoconfiguration or DHCPv6. Note the initiation 531 and authentication process is the same as used in IPv4. 533 IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may 534 be used within the global end-to-end architecture. But, we don't 535 have PKIs across organizations and IPsec isn't integrated with IEEE 536 802.16 network mobility management. 538 IEEE 802.16 network threats may be different from IPv6 and IPv6 539 transition threat models [I-D.ietf-v6ops-security-overview]. It 540 should be also discussed. 542 2.6. IPv6 Network Management 544 For IPv6 network management, the necessary instrumentation (such as 545 MIBs, NetFlow Records, etc) should be available. 547 Upon entering the network, an MS is assigned three management 548 connections in each direction. These three connections reflect the 549 three different QoS requirements used by different management levels. 550 The first of these is the basic connection, which is used for the 551 transfer of short, time-critical MAC management messages and radio 552 link control (RLC) messages. The primary management connection is 553 used to transfer longer, more delay-tolerant messages such as those 554 used for authentication and connection setup. The secondary 555 management connection is used for the transfer of standards-based 556 management messages such as Dynamic Host Configuration Protocol 557 (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network 558 Management Protocol (SNMP). 560 IPv6 based IEEE 802.16 network can be managed by IPv4 or IPv6 when 561 network elements are implemented dual stak. For example, network 562 management system (NMS) can send SNMP message by IPv4 with IPv6 563 related object identifier. Also, an NMS can use IPv6 for SNMP 564 request and response including IPv4 related OID. 566 3. IANA Considerations 568 This document requests no action by IANA. 570 4. Security Considerations 572 Please refer to Section 2.5 "IPv6 Security" technology sections for 573 details. 575 5. Acknowledgements 577 This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- 578 scenarios]. We thank all the authors of the document. Special 579 thanks are due to Maximilian Riegel, Jonne Soininen, Brian E 580 Carpenter, Jim Bound, David Johnston, Basavaraj Patil, Byoung-Jo Kim 581 and Jung-Mo Moon for extensive review of this document. 583 6. References 585 6.1. Normative References 587 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 588 Discovery for IP Version 6 (IPv6)", RFC 2461, 589 December 1998. 591 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 592 Autoconfiguration", RFC 2462, December 1998. 594 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 595 Listener Discovery (MLD) for IPv6", RFC 2710, 596 October 1999. 598 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 599 RFC 2740, December 1999. 601 6.2. Informative References 603 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 604 Generation Partnership Project (3GPP) Standards", 605 RFC 3314, September 2002. 607 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 608 in IPv6", RFC 3775, June 2004. 610 [I-D.ietf-16ng-ps-goals] 611 Jee, J., "IP over 802.16 Problem Statement and Goals", 612 draft-ietf-16ng-ps-goals-00 (work in progress), 613 October 2006. 615 [I-D.ietf-16ng-ipv6-link-model-analysis] 616 Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 617 based Networks", 618 draft-ietf-16ng-ipv6-link-model-analysis-02 (work in 619 progress), January 2007. 621 [I-D.ietf-mipshop-fmipv6-rfc4068bis] 622 Koodli, R., "Fast Handovers for Mobile IPv6", 623 draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in 624 progress), May 2006. 626 [I-D.ietf-mipshop-fh80216e] 627 Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e 628 Networks", draft-ietf-mipshop-fh80216e-01 (work in 629 progress), January 2007. 631 [I-D.ietf-v6ops-security-overview] 632 Davies, E., "IPv6 Transition/Co-existence Security 633 Considerations", draft-ietf-v6ops-security-overview-06 634 (work in progress), October 2006. 636 [I-D.ietf-v6ops-bb-deployment-scenarios] 637 Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband 638 Access Networks", 639 draft-ietf-v6ops-bb-deployment-scenarios-05 (work in 640 progress), June 2006. 642 [I-D.iab-link-encaps] 643 Aboba, B., "Multiple Encapsulation Methods Considered 644 Harmful", draft-iab-link-encaps-05 (work in progress), 645 October 2006. 647 [IEEE802.16] 648 "IEEE 802.16-2004, IEEE standard for Local and 649 metropolitan area networks, Part 16: Air Interface for 650 fixed broadband wireless access systems", October 2004. 652 [IEEE802.16e] 653 "IEEE Std. for Local and metropolitan area networks Part 654 16: Air Interface for Fixed and Mobile Broadband Wireless 655 Access Systems Amendment 2: Physical and Medium Access 656 Control Layers for Combined Fixed and Mobile Operation in 657 Licensed Bands and Corrigendum 1", February 2006. 659 Authors' Addresses 661 Myung-Ki Shin 662 ETRI 663 161 Gajeong-dong Yuseng-gu 664 Daejeon, 305-350 665 Korea 667 Phone: +82 42 860 4847 668 Email: myungki.shin@gmail.com 670 Youn-Hee Han 671 KUT 672 Gajeon-Ri 307 Byeongcheon-Myeon 673 Cheonan-Si Chungnam Province, 330-708 674 Korea 676 Email: yhhan@kut.ac.kr 678 Sang-Eon Kim 679 KT 680 17 Woomyeon-dong, Seocho-gu 681 Seoul, 137-791 682 Korea 684 Email: sekim@kt.co.kr 686 Domagoj Premec 687 Siemens Mobile 688 Heinzelova 70a 689 10010 Zagreb 690 Croatia 692 Email: domagoj.premec@siemens.com 694 Full Copyright Statement 696 Copyright (C) The Internet Society (2007). 698 This document is subject to the rights, licenses and restrictions 699 contained in BCP 78, and except as set forth therein, the authors 700 retain all their rights. 702 This document and the information contained herein are provided on an 703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 705 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 706 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 707 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 710 Intellectual Property 712 The IETF takes no position regarding the validity or scope of any 713 Intellectual Property Rights or other rights that might be claimed to 714 pertain to the implementation or use of the technology described in 715 this document or the extent to which any license under such rights 716 might or might not be available; nor does it represent that it has 717 made any independent effort to identify any such rights. Information 718 on the procedures with respect to rights in RFC documents can be 719 found in BCP 78 and BCP 79. 721 Copies of IPR disclosures made to the IETF Secretariat and any 722 assurances of licenses to be made available, or the result of an 723 attempt made to obtain a general license or permission for the use of 724 such proprietary rights by implementers or users of this 725 specification can be obtained from the IETF on-line IPR repository at 726 http://www.ietf.org/ipr. 728 The IETF invites any interested party to bring to its attention any 729 copyrights, patents or patent applications, or other proprietary 730 rights that may cover technology that may be required to implement 731 this standard. Please address the information to the IETF at 732 ietf-ipr@ietf.org. 734 Acknowledgment 736 Funding for the RFC Editor function is provided by the IETF 737 Administrative Support Activity (IASA).