idnits 2.17.1 draft-ietf-v6ops-802-16-deployment-scenarios-07.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 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 733. 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 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 (January 28, 2008) is 5904 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fh80216e-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M-K. Shin, Ed. 3 Internet-Draft ETRI 4 Intended status: Informational Y-H. Han 5 Expires: July 31, 2008 KUT 6 S-E. Kim 7 KT 8 D. Premec 9 Siemens Mobile 10 January 28, 2008 12 IPv6 Deployment Scenarios in 802.16 Networks 13 draft-ietf-v6ops-802-16-deployment-scenarios-07 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 31, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document provides a 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 networks and their differences from IPv4 IEEE 802.16 networks and how 51 IPv6 is deployed and integrated in each of the IEEE 802.16 52 technologies. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3 59 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3 60 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4 61 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5 62 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 8 63 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11 64 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 11 66 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 12 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 17 76 1. Introduction 78 As the deployment of IEEE 802.16 access networks progresses, users 79 will be connected to IPv6 networks. While the IEEE 802.16 standard 80 defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 81 MAC payload, a complete description of IPv4/IPv6 operation and 82 deployment is not present. The IEEE 802.16 standards are limited to 83 L1 and L2, so they may be used within any number of IP network 84 architectures and scenarios. In this document, we will discuss main 85 components of IPv6 IEEE 802.16 access networks and their differences 86 from IPv4 IEEE 802.16 networks and how IPv6 is deployed and 87 integrated in each of the IEEE 802.16 technologies. 89 This document extends the work of [RFC4779] and follows the structure 90 and common terminology of that document. 92 1.1. Terminology 94 The IEEE 802.16 related terminologies in this document are to be 95 interpreted as described in [I-D.ietf-16ng-ps-goals]. 96 o Subscriber Station (SS): An end-user equipment that provides 97 connectivity to the 802.16 networks. It can be either fixed/ 98 nomadic or mobile equipment. In mobile environment, SS represents 99 the Mobile Subscriber Station (MS) introduced in [IEEE802.16e]. 100 o Base Station (BS): A generalized equipment set providing 101 connectivity, management, and control between the subscriber 102 station and the 802.16 networks. 103 o Access Router (AR): An entity that performs an IP routing function 104 to provide IP connectivity for subscriber station (SS or MS). 105 o Connection Identifier (CID): A 16-bit value that identifies a 106 connection to equivalent peers in the 802.16 MAC of the SS(MS) and 107 BS. 108 o Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS specific 109 part of the Packet CS defined in 802.16 STD. 110 o IPv6 CS (Convergence Sublayer): IPv6 specific subpart of the 111 Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD. 113 2. Deploying IPv6 in IEEE 802.16 Networks 115 2.1. Elements of IEEE 802.16 Networks 117 [IEEE 802.16e] is an air interface for fixed and mobile broadband 118 wireless access systems. [IEEE 802.16] only specifies the 119 convergence sublayers and the ability to transport IP over the air 120 interface. The details of IPv6 (and IPv4) operations over IEEE 121 802.16 are defined in the 16ng WG. The IPv6 over IPCS definition is 122 already an approved specification [I-D.ietf-16ng-ipv6-over-ipv6cs]. 124 IP over Ethernet CS in IEEE 802.16 is defined in 125 [I-D.ietf-16ng-ip-over-ethernet-over-802.16]. 127 Figure 1 illustrates the key elements of typical mobile 802.16 128 deployments. 130 Customer | Access Provider | Service Provider 131 Premise | | (Backend Network) 133 +-----+ +----+ +----+ +--------+ 134 | SSs |--(802.16)--| BS |-----| | | Edge | ISP 135 +-----+ +----+ | AR |---| Router |==>Network 136 +--| | | (ER) | 137 | +----+ +--------+ 138 +-----+ +----+ | | +------+ 139 | SSs |--(802.16)--| BS |--+ +--|AAA | 140 +-----+ +----+ |Server| 141 +------+ 143 Figure 1: Key Elements of IEEE 802.16(e) Networks 145 2.2. Scenarios and IPv6 Deployment 147 [IEEE802.16] specifies two modes for sharing the wireless medium: 148 point-to-multipoint (PMP) and mesh (optional). This document only 149 focuses on the PMP mode. 151 Some of the factors that hinder deployment of native IPv6 core 152 protocols are already introduced by [I-D.ietf-16ng-ps-goals]. 154 There are two different deployment scenarios: fixed and mobile access 155 deployment scenarios. A fixed access scenario substitutes for 156 existing wired-based access technologies such as digital subscriber 157 lines (xDSL) and cable networks. This fixed access scenario can 158 provide nomadic access within the radio coverages, which is called 159 Hot-zone model. A mobile access scenario exists for the new paradigm 160 of transmitting voice, data and video over mobile networks. This 161 scenario can provide high speed data rates equivalent to the wire- 162 based Internet as well as mobility functions equivalent to cellular 163 systems. There are the different IPv6 impacts on convergence 164 sublayer type, link model, addressing, mobility, etc. between fixed 165 and mobile access deployment scenarios. The details will be 166 discussed below. The mobile access scenario can be classified into 167 two different IPv6 link models: shared IPv6 prefix link model and 168 point-to-point link model. 170 2.2.1. Mobile Access Deployment Scenarios 172 Unlike IEEE 802.11, the IEEE 802.16 BS can provide mobility functions 173 and fixed communications. [IEEE802.16e] has been standardized to 174 provide mobility features on IEEE 802.16 environments. IEEE 802.16 175 BS might be deployed with a proprietary backend managed by an 176 operator. 178 There are two possible IPv6 link models for mobile access deployment 179 scenarios: shared IPv6 prefix link model and point-to-point link 180 model [RFC4968]. There is always a default access router in the 181 scenarios. There can exist multiple hosts behind an MS (networks 182 behind an MS may exist). The mobile access deployment models, Mobile 183 WiMax and WiBro, fall within this deployment model. 185 (1) Shared IPv6 Prefix Link Model 187 This link model represents the IEEE 802.16 mobile access network 188 deployment where a subnet consists of only single AR interfaces and 189 multiple MSs. Therefore, all MSs and corresponding AR interfaces 190 share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix 191 will be different from the interface of the AR. 193 +-----+ 194 | MS1 |<-(16)-+ 195 +-----+ | +-----+ 196 +-----+ +----| BS1 |--+ 197 | MS2 |<-(16)-+ +-----+ | 198 +-----+ | +-----+ +--------+ 199 +->| AR |----| Edge | ISP 200 +-----+ | +-----+ | Router +==>Network 201 | MS3 |<-(16)-+ +-----+ | +--------+ 202 +-----+ +----| BS2 |--+ 203 +-----+ | +-----+ 204 | MS4 |<-(16)-+ 205 +-----+ 207 Figure 2: Shared IPv6 Prefix Link Model 209 (2) Point-to-Point Link Model 211 This link model represents IEEE 802.16 mobile access network 212 deployments where a subnet consists of only single AR, BS and MS. 213 That is, each connection to a mobile node is treated as a single 214 link. Each link between the MS and the AR is allocated a separate, 215 unique prefix or unique set of prefixes by the AR. The point-to- 216 point link model follows the recommendations of [RFC3314]. 218 +-----+ +-----+ +-----+ 219 | MS1 |<-(16)------| |---->| | 220 +-----+ | BS1 | | | 221 +-----+ | | | | +--------+ 222 | MS2 |<-(16)------| |---->| |----| Edge | ISP 223 +-----+ +-----+ | | | Router +==>Network 224 | AR | +--------+ 225 +-----+ +-----+ | | 226 | MS3 |<-(16)------| |---->| | 227 +-----+ | BS2 | | | 228 +-----+ | | | | 229 | MS4 |<-(16)------| |---->| | 230 +-----+ +-----+ +-----+ 232 Figure 3: Point-to-Point Link Model 234 2.2.1.1. IPv6 Related Infrastructure Changes 236 IPv6 will be deployed in this scenario by upgrading the following 237 devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16 238 BSs have only MAC and PHY layers without router functionality and 239 operate as a bridge. The BS should support IPv6 classifiers as 240 specified in [IEEE802.16]. 242 2.2.1.2. Addressing 244 An IPv6 MS has two possible options to get an IPv6 address. These 245 options will be equally applied to the other scenario below (Section 246 2.2.2). 248 (1) An IPv6 MS can get the IPv6 address from an access router using 249 stateless auto-configuration. In this case, router discovery and DAD 250 operation should be properly operated over an IEEE 802.16 link. 252 (2) An IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6 253 server. In this case, the DHCPv6 server would be located in the 254 service provider core network and the AR should provide a DHCPv6 255 relay agent. This option is similar to what we do today in case of 256 DHCPv4. 258 In this scenario, a router and multiple BSs form an IPv6 subnet and a 259 single prefix is allocated to all the attached MSs. All MSs attached 260 to same AR can be on the same IPv6 link. 262 As for the prefix assignment, in case of the shared IPv6 prefix link 263 model, one or more IPv6 prefixes are assigned to the link and hence 264 shared by all the nodes that are attached to the link. In the point- 265 to-point link model, the AR assigns a unique prefix or a set of 266 unique prefixes for each MS. Prefix delegation can be required if 267 networks exist behind an MS. 269 2.2.1.3. IPv6 Transport 271 In an IPv6 subnet, there are always two underlying links: one is the 272 IEEE 802.16 wireless link between the MS and BS, and the other is a 273 wired link between the BS and AR. 275 IPv6 packets can be sent and received via the IP specific part of the 276 packet convergence sublayer. The Packet CS is used for the transport 277 of packet based protocols which include Ethernet and Internet 278 Protocol (IPv4 and IPv6). Note that in this scenario IPv6 CS may be 279 more appropriate than Ethernet CS to transport IPv6 packets, since 280 there is some overhead of Ethernet CS (e.g., Ethernet header) under 281 mobile access environments. However, when PHS (Payload Header 282 Suppression) is deployed it mitigates this overhead through the 283 compression of packet headers. The details of IPv6 operations over 284 the IP specific part of the packet CS defined in 285 [I-D.ietf-16ng-ipv6-over-ipv6cs]. 287 Simple or complex network equipment may constitute the underlying 288 wired network between the AR and the ER. If the IP-aware equipment 289 between the AR and the ER does not support IPv6, the service 290 providers can deploy IPv6-in-IPv4 tunneling mechanisms to transport 291 IPv6 packets between the AR and the ER. 293 The service providers are deploying tunneling mechanisms to transport 294 IPv6 over their existing IPv4 networks as well as deploying native 295 IPv6 where possible. Native IPv6 should be preferred over tunneling 296 mechanisms as native IPv6 deployment options might be more scalable 297 and provide the required service performance. Tunneling mechanisms 298 should only be used when native IPv6 deployment is not an option. 299 This can be equally applied to other scenarios below (Section 2.2.2). 301 2.2.1.4. Routing 303 In general, the MS is configured with a default route that points to 304 the AR. Therefore, no routing protocols are needed on the MS. The 305 MS just sends to the AR using the default route. 307 The AR can configure multiple links to ER for network reliability. 308 The AR should support IPv6 routing protocols such as OSPFv3 [RFC2740] 309 or IS-IS for IPv6 when connected to the ER with multiple links. 311 The ER runs the IGP such as OSPFv3 or IS-IS for IPv6 in the service 312 provider network. The routing information of the ER can be 313 redistributed to the AR. Prefix summarization should be done at the 314 ER. 316 2.2.1.5. Mobility 318 There are two types of handovers for the IEEE 802.16e networks: link 319 layer handover and IP layer handover. In a link layer handover, BSs 320 involved in the handover reside in the same IP subnet. A MS only 321 needs to re-establish a link layer connection with a new BS without 322 changing its IP configuration, such as its IP address, default 323 router, on-link prefix, etc. The link layer handover in IEEE 802.16e 324 is by nature a hard handover since the MS has to cut off the 325 connection with the current BS at the beginning of the handover 326 process and cannot resume communication with the new BS until the 327 handover completes [IEEE802.16e]. In an IP layer handover, the BSs 328 involved reside in different IP subnets, or in different networks. 329 Thus, in an IP layer handover, a MS needs to establish both a new 330 link layer connection, as in a link layer handover, and a new IP 331 configuration to maintain connectivity. 333 IP layer handover for MSs is handled by Mobile IPv6 [RFC3775]. 334 Mobile IPv6 defines that movement detection uses Neighbor 335 Unreachability Detection to detect when the default router is no 336 longer bidirectionally reachable, in which case the mobile node must 337 discover a new default router. Periodic Router Advertisements for 338 reachability and movement detection may be unnecessary because the 339 IEEE 802.16 MAC provides the reachability by its ranging procedure 340 and the movement detection by the Handoff procedure. 342 Mobile IPv6 alone will not solve the handover latency problem for the 343 IEEE 802.16e networks. To reduce or eliminate packet loss and to 344 reduce the handover delay in Mobile IPv6, therefore, Fast Handover 345 for Mobile IPv6 (FMIPv6) [RFC4068] can be deployed together with 346 MIPv6. To perform predictive packet forwarding, the FMIPv6's IP 347 layer assumes the presence of handover-related triggers delivered by 348 the IEEE 802.16 MAC layers. Thus, there is a need for cross-layering 349 design to support proper behavior of the FMIPv6 solution. This issue 350 is also being discussed in [I-D.ietf-mipshop-fh80216e]. 352 Also, [IEEE802.16g] defines L2 triggers for link status such as 353 link-up, link-down, handoff-start. These L2 triggers may make the 354 Mobile IPv6 or FMIPv6 procedure more efficient and faster. 356 2.2.2. Fixed/Nomadic Deployment Scenarios 358 The IEEE 802.16 access networks can provide plain Ethernet end-to-end 359 connectivity. This scenario represents deployment model using 360 Ethernet CS. Wireless DSL deployment model is an example of a fixed/ 361 nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet 362 service providers (Wireless ISPs) have planned to use IEEE 802.16 for 363 the purpose of high quality broadband wireless services. A company 364 can use IEEE 802.16 to build up a mobile office. Wireless Internet 365 spreading through a campus or a cafe can be also implemented with it. 367 +-----+ +-----+ +-----+ ISP 1 368 | SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network 369 +-----+ | | +-----+ +-----+ 370 +-----+ | +-----+ | 371 | SS2 |<-(16)+-----| BS1 |--| 372 +-----+ +-----+ | +-----+ +-----+ ISP 2 373 +->| AR2 |----| ER2 |===>Network 374 +-----+ +-----+ +-----+ | +-----+ +-----+ 375 |Hosts|<-->|SS/GW|<-(16)------| BS2 |--+ 376 +-----+ +-----+ +-----+ 377 This network 378 behind SS may exist 380 Figure 4: Fixed/Nomadic Deployment Scenario 382 This scenario also represents IEEE 802.16 network deployment where a 383 subnet consists of multiple MSs and multiple interfaces of the 384 multiple BSs. Multiple access routers can exist. There exist 385 multiple hosts behind an SS (networks behind an SS may exist). When 386 802.16 access networks are widely deployed as in a WLAN, this case 387 should be also considered. The Hot-zone deployment model falls 388 within this case. 390 While Figure 4 illustrates a generic deployment scenario, the 391 following Figure 5 shows in more detail how an existing DSL ISP would 392 integrate the 802.16 access network into its existing infrastructure. 394 +-----+ +---+ +-----+ +-----+ ISP 1 395 | SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network 396 +-----+ | | b| | +-----+ +-----+ 397 +-----+ | +-----+ |E r| | 398 | SS2 |<-(16)+-----| BS1 |-----|t i| | 399 +-----+ +-----+ |h d|--+ 400 | g| | +-----+ +-----+ ISP 2 401 +-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network 402 | SS3 |<-(16)------| BS2 |-----| | | +-----+ +-----+ 403 +-----+ +-----+ +---+ | 404 | 405 +-----+ +-----+ | 406 | TE |<-(DSL)-----|DSLAM|------------+ 407 +-----+ +-----+ 409 Figure 5: Integration of 802.16 access into DSL infrastructure 411 In this approach the 802.16 BS is acting as a DSLAM (Digital 412 Subscriber Line Access Multiplexer). On the network side, the BS is 413 connected to an Ethernet bridge which can be separate equipment or 414 integrated into the BRAS (Broadband Remote Access Server). 416 2.2.2.1. IPv6 Related Infrastructure Changes 418 IPv6 will be deployed in this scenario by upgrading the following 419 devices to dual-stack: MS, AR, ER, and the Ethernet Bridge. The BS 420 should support IPv6 classifiers as specified in [IEEE802.16]. 422 The BRAS in Figure 5 is providing the functionality of the AR. An 423 Ethernet bridge is necessary for protecting the BRAS from 802.16 link 424 layer peculiarities. The Ethernet bridge relays all traffic received 425 through the BS to its network side port(s) connected to the BRAS. 426 Any traffic received from the BRAS is relayed to the appropriate BS. 427 Since the 802.16 MAC layer has no native support for multicast (and 428 broadcast) in the uplink direction, the Ethernet bridge will 429 implement multicast (and broadcast) by relaying the multicast frame 430 received from the MS to all of its ports. The Ethernet bridge may 431 also provide some IPv6 specific functions to increase link efficiency 432 of the 802.16 radio link (see Section 2.2.2.3). 434 2.2.2.2. Addressing 436 One or more IPv6 prefixes can be shared to all the attached MSs. 437 Prefix delegation can be required if networks exist behind the SS. 439 2.2.2.3. IPv6 Transport 441 Transmisson of IPv6 over Ethernet CS follows [RFC2464] and does not 442 introduce any changes to [RFC4861] and [RFC4862]. However, there are 443 a few considerations in the viewpoint of operation, such as 444 preventing periodic router advertisement messages from an access 445 router and broadcast transmission, deciding path MTU size, and so on. 446 The details about the considerations are described in 447 [I-D.ietf-16ng-ip-over-ethernet-over-802.16]. 449 2.2.2.4. Routing 451 In this scenario, IPv6 multi-homing considerations exist. For 452 example, if there exist two routers to support MSs, a default router 453 must be selected. 455 The Edge Router runs the IGP used in the SP network such as OSPFv3 456 [RFC2740] or IS-IS for IPv6. The connected prefixes have to be 457 redistributed. Prefix summarization should be done at the Edge 458 Router. 460 2.2.2.5. Mobility 462 No mobility functions of Layer 2 and Layer 3 are supported in the 463 fixed access scenario. Like WLAN technology, however, nomadicity can 464 be supported in the radio coverage without any mobility protocol. 465 So, a user can access Internet nomadically in the coverage. 467 Sometime, service users can demand IP session continuity or home 468 address reusability even in the nomadic environment. In case of 469 that, Mobile IPv6 [RFC3775] may be used in this scenario even in the 470 absence of Layer 2's mobility support. 472 2.3. IPv6 Multicast 474 [I-D.ietf-16ng-ip-over-ethernet-over-802.16] realizes IPv6 multicast 475 support by IGMP/MLD proxying [RFC4605] and IGMP/MLD snooping 476 [RFC4541]. Additionally, it may be possible to efficiently implement 477 multicast packet transmission among the multicast subscribers by 478 means of IEEE 802.16 Multicast CIDs. However, such a protocol is not 479 yet available and under development in WiMAX Forum. 481 2.4. IPv6 QoS 483 In IEEE 802.16 networks, a connection is unidirectional and has a QoS 484 specification. Each connection is associated with a single data 485 service flow and each service flow is associated with a set of QoS 486 parameters in [IEEE802.16]. The QoS related parameters are managed 487 using the Dynamic Service Addition (DSA) and Dynamic Service Change 488 (DSC) MAC management messages that specified in [IEEE802.16]. The 489 [IEEE802.16] provides QoS differentiation for the different types of 490 applications by five scheduling service. Four scheduling services 491 are defined in 802.16 such as Unsolicited Grant Service (UGS), real- 492 time Polling Service (rtPS), non-real-time Polling Service (nrtPS) 493 and Best Effort (BE). A fifth scheduling service is Extended Real- 494 time Polling Service (ertPS) that is defined in [IEEE802.16e]. It is 495 required to provide IP layer quality of service mapping to MAC layer 496 QoS types [IEEE802.16], [IEEE802.16e]. 498 2.5. IPv6 Security 500 When initiating the connection, an MS is authenticated by the AAA 501 server located at its service provider network. To achieve that, the 502 MS and the BS use Privacy Key Management [IEEE802.16],[IEEE802.16e], 503 while the BS communicates with the AAA server using a AAA protocol. 504 Once the MS is authenticated with the AAA server, it can associate 505 successfully with the BS and acquire an IPv6 address through 506 stateless autoconfiguration or DHCPv6. Note that the initiation and 507 authentication process is the same as the one used in IPv4. 509 2.6. IPv6 Network Management 511 [IEEE802.16f] includes the management information base for IEEE 512 802.16 networks. For IPv6 network management, the necessary 513 instrumentation (such as MIBs, NetFlow Records, etc) should be 514 available. 516 Upon entering the network, an MS is assigned three management 517 connections in each direction. These three connections reflect the 518 three different QoS requirements used by different management levels. 519 The first of these is the basic connection, which is used for the 520 transfer of short, time-critical MAC management messages and radio 521 link control (RLC) messages. The primary management connection is 522 used to transfer longer, more delay-tolerant messages such as those 523 used for authentication and connection setup. The secondary 524 management connection is used for the transfer of standards-based 525 management messages such as Dynamic Host Configuration Protocol 526 (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network 527 Management Protocol (SNMP). 529 IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when 530 network elements are implemented dual stack. For example, network 531 management systems (NMS) can send SNMP messages by IPv4 with IPv6 532 related object identifiers. Also, an NMS can use IPv6 for SNMP 533 requests and responses including IPv4 related OID. 535 3. IANA Considerations 537 This document requests no action by IANA. 539 4. Security Considerations 541 This document provides a detailed description of various IPv6 542 deployment scenarios and link models for IEEE 802.16 based networks, 543 and as such does not introduce any new security threats. No matter 544 what the scenario applied is, the networks should employ the same 545 link-layer security mechanisms defined in [IEEE802.16e] and IPv6 546 transition security considerations defined in [RFC4942]. However, as 547 already described in [RFC4968], a shared prefix model based mobile 548 access deployment scenario may security implications for protocols 549 that are designed to work within the scope. This is the concern for 550 a shared prefix link model wherein private resources cannot be put 551 onto a public 802.16 based networks. This may restrict the usage of 552 a shared prefix model to enterprise environments. 554 5. Acknowledgements 556 This work extends v6ops work on [RFC4779]. We thank all the authors 557 of the document. Special thanks are due to Maximilian Riegel, Jonne 558 Soininen, Brian E Carpenter, Jim Bound, David Johnston, Basavaraj 559 Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin 560 Jeong, and Jinhyeock Choi for extensive review of this document. We 561 acknowledge Dominik Kaspar for proofreading the document. 563 6. References 565 6.1. Normative References 567 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 568 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 569 September 2007. 571 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 572 Address Autoconfiguration", RFC 4862, September 2007. 574 6.2. Informative References 576 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 577 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 578 Access Networks", RFC 4779, January 2007. 580 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 581 Based Networks", RFC 4968, August 2007. 583 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 584 Co-existence Security Considerations", RFC 4942, 585 September 2007. 587 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 588 RFC 2740, December 1999. 590 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 591 Generation Partnership Project (3GPP) Standards", 592 RFC 3314, September 2002. 594 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 595 in IPv6", RFC 3775, June 2004. 597 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 598 Networks", RFC 2464, December 1998. 600 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 601 "Internet Group Management Protocol (IGMP) / Multicast 602 Listener Discovery (MLD)-Based Multicast Forwarding 603 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 605 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 606 "Considerations for Internet Group Management Protocol 607 (IGMP) and Multicast Listener Discovery (MLD) Snooping 608 Switches", RFC 4541, May 2006. 610 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 611 July 2005. 613 [I-D.ietf-16ng-ps-goals] 614 Jee, J., Madanapalli, S., and J. Mandin, "IP over 802.16 615 Problem Statement and Goals", draft-ietf-16ng-ps-goals-04 616 (work in progress), December 2007. 618 [I-D.ietf-16ng-ipv6-over-ipv6cs] 619 Patil, B., Xia, F., Sarikaya, B., Choi, J., and S. 620 Madanapalli, "Transmission of IPv6 via the IPv6 CS over 621 IEEE 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-11 622 (work in progress), November 2007. 624 [I-D.ietf-16ng-ip-over-ethernet-over-802.16] 625 Jeon, H., "Transmission of IP over Ethernet over IEEE 626 802.16 Networks", 627 draft-ietf-16ng-ip-over-ethernet-over-802.16-04 (work in 628 progress), January 2008. 630 [I-D.ietf-mipshop-fh80216e] 631 Jang, H., Jee, J., Han, Y., Park, S., and J. Cha, "Mobile 632 IPv6 Fast Handovers over IEEE 802.16e Networks", 633 draft-ietf-mipshop-fh80216e-05 (work in progress), 634 November 2007. 636 [IEEE802.16] 637 "IEEE 802.16-2004, IEEE Standard for Local and 638 Metropolitan Area Networks, Part 16: Air Interface for 639 Fixed Broadband Wireless Access Systems", October 2004. 641 [IEEE802.16e] 642 "IEEE Standard for Local and Metropolitan Area Networks 643 Part 16: Air Interface for Fixed and Mobile Broadband 644 Wireless Access Systems Amendment 2: Physical and Medium 645 Access Control Layers for Combined Fixed and Mobile 646 Operation in Licensed Bands and Corrigendum 1", 647 February 2006. 649 [IEEE802.16g] 650 "Draft Amendment to IEEE Standard for Local and 651 Metropolitan Area Networks, Part 16: Air Interface for 652 Fixed Broadband Wireless Access Systems - Management Plane 653 Procedures and Services", January 2007. 655 [IEEE802.16f] 656 "Amendment to IEEE Standard for Local and Metropolitan 657 Area Networks, Part 16: Air Interface for Fixed Broadband 658 Wireless Access Systems - Management Information Base", 659 December 2005. 661 Authors' Addresses 663 Myung-Ki Shin 664 ETRI 665 161 Gajeong-dong Yuseng-gu 666 Daejeon, 305-350 667 Korea 669 Phone: +82 42 860 4847 670 Email: myungki.shin@gmail.com 672 Youn-Hee Han 673 KUT 674 Gajeon-Ri 307 Byeongcheon-Myeon 675 Cheonan-Si Chungnam Province, 330-708 676 Korea 678 Email: yhhan@kut.ac.kr 680 Sang-Eon Kim 681 KT 682 17 Woomyeon-dong, Seocho-gu 683 Seoul, 137-791 684 Korea 686 Email: sekim@kt.co.kr 687 Domagoj Premec 688 Siemens Mobile 689 Heinzelova 70a 690 10010 Zagreb 691 Croatia 693 Email: domagoj.premec@siemens.com 695 Full Copyright Statement 697 Copyright (C) The IETF Trust (2008). 699 This document is subject to the rights, licenses and restrictions 700 contained in BCP 78, and except as set forth therein, the authors 701 retain all their rights. 703 This document and the information contained herein are provided on an 704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 706 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 707 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 708 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Intellectual Property 713 The IETF takes no position regarding the validity or scope of any 714 Intellectual Property Rights or other rights that might be claimed to 715 pertain to the implementation or use of the technology described in 716 this document or the extent to which any license under such rights 717 might or might not be available; nor does it represent that it has 718 made any independent effort to identify any such rights. Information 719 on the procedures with respect to rights in RFC documents can be 720 found in BCP 78 and BCP 79. 722 Copies of IPR disclosures made to the IETF Secretariat and any 723 assurances of licenses to be made available, or the result of an 724 attempt made to obtain a general license or permission for the use of 725 such proprietary rights by implementers or users of this 726 specification can be obtained from the IETF on-line IPR repository at 727 http://www.ietf.org/ipr. 729 The IETF invites any interested party to bring to its attention any 730 copyrights, patents or patent applications, or other proprietary 731 rights that may cover technology that may be required to implement 732 this standard. Please address the information to the IETF at 733 ietf-ipr@ietf.org. 735 Acknowledgment 737 Funding for the RFC Editor function is provided by the IETF 738 Administrative Support Activity (IASA).