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