idnits 2.17.1 draft-ietf-v6ops-802-16-deployment-scenarios-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 796. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 24, 2006) is 6547 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.jee-16ng-problem-statement' is mentioned on line 215, but not defined == Missing Reference: 'RFC 3314' is mentioned on line 516, but not defined == Missing Reference: 'I-D.ietf-mipshop-fh80216e' is mentioned on line 618, but not defined == Unused Reference: 'RFC2119' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC2462' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC3316' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'I-D.mandin-ip-over-80216-ethcs' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-bb-deployment-scenarios' is defined on line 732, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3316 (Obsoleted by RFC 7066) == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-security-overview-04 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-bb-deployment-scenarios-04 == Outdated reference: A later version (-01) exists of draft-shin-16ng-ipv6-transmission-00 Summary: 7 errors (**), 0 flaws (~~), 14 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: November 25, 2006 Y-H. Han 5 KUT 6 May 24, 2006 8 ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks 9 draft-ietf-v6ops-802-16-deployment-scenarios-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document provides detailed description of IPv6 deployment and 43 integration methods and scenarios in wireless broadband access 44 networks in coexistence with deployed IPv4 services. In this 45 document we will discuss main components of IPv6 IEEE 802.16 access 46 network and its differences from IPv4 IEEE 802.16 networks and how 47 IPv6 is deployed and integrated in each of the IEEE 802.16 48 technologies using tunneling mechanisms and native IPv6. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Wireless Broadband Access Network Technologies - IEEE 54 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 56 2.2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . 5 57 2.2.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . 7 58 2.2.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . 9 59 2.2.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . 10 60 2.2.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . 12 61 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13 62 2.4. IPv6 Mobility . . . . . . . . . . . . . . . . . . . . . . 14 63 2.5. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 2.6. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 15 65 2.7. IPv6 Network Management . . . . . . . . . . . . . . . . . 15 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 73 Intellectual Property and Copyright Statements . . . . . . . . . . 22 75 1. Introduction 77 Recently, broadband wireless access network is emerging for wireless 78 communication for user requirements such as high quality data/voice 79 service, fast mobility, wide coverage, etc. The IEEE 802.16 Working 80 Group develops standards and recommended practices to support the 81 development and deployment of broadband wireless metropolitan area 82 networks. 84 Whereas the existing IEEE 802.16 standard [IEEE802.16] addresses 85 fixed wireless applications only, the IEEE 802.16(e) standard 86 [IEEE802.16e] aims to serve the needs of fixed, nomadic, and fully 87 mobile networks. It adds mobility support to the original standard 88 so that mobile subscriber stations can move while receiving services. 89 IEEE 802.16e is one of the most promising access technologies which 90 would be applied to the IP-based broadband mobile communication. 92 WiMAX Forum is an industrial corporation formed to promote and 93 certify compatibility and interoperability of broadband wireless 94 products mainly based on IEEE 802.16. The Network Working Group 95 (NWG) of WiMAX Forum is defining the IEEE 802.16 network architecture 96 (e.g., IPv4, IPv6, Mobility, interworking with different networks, 97 AAA, etc). Similarly, WiBro (Wireless Broadband), Korea effort which 98 focuses on the 2.3 GHz spectrum band, is also based on the IEEE 99 802.16 and IEEE 802.16e specifications. 101 As the deployment of wireless broadband access network progresses, 102 users will be connected to IPv6 networks. While the IEEE 802.16 103 defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 104 MAC payload, a complete description of IPv4/IPv6 operation and 105 deployment is not present. In this document, we will discuss main 106 components of IPv6 IEEE 802.16 access network and its differences 107 from IPv4 IEEE 802.16 networks and how IPv6 is deployed and 108 integrated in each of the IEEE 802.16 technologies using tunneling 109 mechanisms and native IPv6. 111 This document extends works of [I-D.ietf-v6ops-bb-deployment- 112 scenarios] and follows the structure and common terminology of the 113 document. 115 2. Wireless Broadband Access Network Technologies - IEEE 802.16 117 This section describes the infrastructure that exists today in IEEE 118 802.16 networks providing wireless broadband services to the 119 customer. It also describes IPv6 deployment options in these IEEE 120 802.16 networks. 122 2.1. Elements of IEEE 802.16 Networks 124 The IEEE 802.11 access network (WLAN) has driven the revolution of 125 wireless communication but the more people use it the more its 126 limitations like short range or lack of mobility support were 127 revealed. Compared with such IEEE 802.11 network, IEEE 802.16 128 supports enhanced features like wider range and mobility. So it is 129 expected that IEEE 802.16 network could be the next step of IEEE 130 802.11 network. 132 The mechanism of transporting IP traffic over IEEE 802.16 networks is 133 outlined in [IEEE802.16], but the details of IPv6 operations over 134 IEEE 802.16 are being discussed now. 136 Here are some of the key elements of IEEE 802.16 networks 138 MS: Mobile Station. A station in the mobile service intended to be 139 used while in motion or during halts at unspecified points. A mobile 140 station (MS) is always a subscriber station (SS). 142 BS: Base Station. A generalized equipment set providing 143 connectivity, management and control of MS connections. There is a 144 unidirectional mapping between BS and MS medium access control (MAC) 145 peers for the purpose of transporting a service flow's traffic. 146 Connections are identified by a connection identifier (CID) and all 147 traffic is carried on a connection. Sometimes there can be 148 alternative IEEE 802.16 network deployment where a BS is integrated 149 with an access router, composing one box in view of implementation. 151 Figure 1 illustrates the key elements of IEEE 802.16 networks. 153 Customer | Access Provider | Service Provider 154 Premise | | (Backend Network) 156 +-----+ +-----+ +------+ +--------+ 157 | MSs |--(802.16)--| BS |-----+Access+---+ Edge | ISP 158 +-----+ +-----+ |Router| | Router +==>Network 159 +--+---+ +--------+ 160 +-----+ +-----+ | | +------+ 161 | Mss |--(802.16)--| BS |--------+ +--|AAA | 162 +-----+ +-----+ |Server| 163 +------+ 165 Figure 1: Key Elements of IEEE 802.16(e) Networks 167 2.2. Deploying IPv6 in IEEE 802.16 Networks 169 IEEE 802.16 supports two modes such as 2-way PMP (Point-to- 170 Multipoint) and Mesh topology wireless networks. In this document, 171 we focus on 2-way PMP topology wireless networks. 173 There are two different deployment options in current IEEE 802.16 174 networks: Cellular-like and Hot-zone deployment scenarios. IPv6 can 175 be deployed in both of these deployment models. 177 A. Cellular-like Deployment Model 179 IEEE 802.16 BS can offer both fixed communications and mobile 180 functions unlike IEEE 802.11. In particular, IEEE 802.16e working 181 group standardized such mobility features and the specification of 182 IEEE 802.16e provides some competition to the existing cellular 183 systems. This use case will be implemented only with the licensed 184 spectrum. IEEE 802.16 BS might be deployed with a proprietary 185 backend managed by an operator. All original IPv6 functionalities 186 will not survive and some of them might be compromised to efficiently 187 serve IPv6 to this 'Cellular-like' use case. 189 Under the use case, however, IEEE 802.16 standards are still IP- 190 centric, providing packet-switched approach, while cellular standards 191 like GSM have a more circuit-switched approach. 193 B. Hot Zone Deployment Model 195 The success of a Hotspot service with IEEE 802.11 has been prominent. 196 The new IEEE 802.16 standards basically support such Hotspot services 197 with large coverage area and high data rate. An area served by one 198 base station is usually termed 'Hot Zone' because it is considerably 199 larger than an IEEE 802.11 access point service area called Hotspot. 201 Many wireless Internet service providers (Wireless ISPs) have planned 202 to use IEEE 802.16 for the purpose of high quality service. A 203 company can use IEEE 802.16 to build up mobile office. Wireless 204 Internet spreading through a campus or a cafe can be also implemented 205 with it. The distinct point of this use case is that it can use 206 unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 & 3.5GHz) 207 band. By using the unlicensed band, a IEEE 802.16 BS might be used 208 just as a wireless hub which a user purchases to build a private 209 wireless network in his/her home or laboratory. 211 Under 'Hot Zone' use case, a IEEE 802.16 BS will be deployed using an 212 Ethernet (IP) backbone rather than a proprietary backend like 213 cellular systems. Thus, many IPv6 functionalities will be preserved 214 when adopting IPv6 to IEEE 802.16 networks, which brings out many 215 research issues [I-D.jee-16ng-problem-statement] [I-D.madanapalli-nd- 216 over-802.16-problems]. 218 Some of the factors that hinder deployment of native IPv6 core 219 protocols include: 221 1. Lacking of Facility for IPv6 Native Multicasting 223 IEEE 802.16 is a PMP connection oriented technology without bi- 224 directional native multicast support. IPv6 neighbor discovery 225 [RFC2461] supports various functions for the interaction between 226 nodes attached on the same subnet, such as on-link determination and 227 address resolution. It is designed with no dependence on a specific 228 link layer technology, but requires that the link layer technology 229 support native multicast. The specification of IEEE 802.16 provides 230 multicast and broadcast services. However, the aim of such services 231 is to transmit IEEE 802.16 MAC management messages, not IP messages. 232 This lacking of facility for IPv6 native multicast results in 233 inappropriateness to apply the standard neighbor discover protocol 234 specially regarding, address resolution, router discovery, stateless 235 auto-configuration and duplicated address detection. 237 2. Impact of BS on Subnet Model 239 IEEE 802.16 is different from existing wireless access technologies 240 such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the 241 encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a 242 complete description of IPv6 operation is not present. IEEE 802.16 243 can rather benefit from IETF input and specification to support IPv6 244 operation. Especially, BS should look at the classifiers and decide 245 where to send the packet, since IEEE 802.16 connection always ends at 246 BS, while IPv6 connection terminates at a default router. This 247 operation and limitation may be dependent on the given subnet model. 249 Also, we should consider which type of Convergence Sublayer (CS) can 250 be efficiently used on each subnet models. IEEE 802.16 CS provides 251 the tunneling of IP(v6) packets over IEEE 802.16 air-link. The 252 tunnels are identified by the Connection Identifier (CID). 253 Generally, CS performs the following functions in terms of IP packet 254 transmission: 1) Receipt of protocol data units (PDUs) from the 255 higher layer, 2) Performing classification and CID mapping of the 256 PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt 257 of PDUs from the peer MAC SAP. The specification of IEEE 802.16 258 defines several CSs for carrying IP packets, but does not provide a 259 detailed description of how to carry them. The several CSs are 260 generally classified into two types of CS: IPv6 CS and Ethernet CS. 262 While deploying IPv6 in the above mentioned approach, there are four 263 possible typical scenarios as discussed below. 265 2.2.1. Scenario A 267 Scenario A represents IEEE 802.16 access network deployment where a 268 BS is separated from a router, and a subnet consists of only single 269 router and multiple BSs and MSs. Current celluar-like deployment 270 models, WiMax and WiBro, fall within this scenario A. 272 +-----+ 273 | MS1 |<------+ 274 +-----+ | 275 +-----+ | +-----+ +-----+ +--------+ 276 | MSs |<------+----| BS1 |---->| AR |----| Edge | ISP 277 +-----+ +-----+ +-----+ | Router +==>Network 278 ^ +--------+ 279 +-----+ +-----+ | 280 | Mss |<-----------| BS2 |--------+ 281 +-----+ +-----+ 282 <---> IP termination 284 Figure 2: Scenario A 286 2.2.1.1. IPv6 Related Infrastructure Changes 288 IPv6 will be deployed in this scenario by upgrading the following 289 devices to dual-stack: MS, BS (if possible), AR and Edge Router. In 290 this scenario the BS is Layer 3 unaware, so no changes are needed to 291 support IPv6. However, if IPv4 stack is loaded to them for 292 management and configuration purpose, it is expected that BS should 293 be upgraded by implementing IPv6 stack, too. 295 2.2.1.2. Addressing 297 IPv6 MS has two possible options to get an IPv6 address. These 298 options will be equally applied to the other three scenarios below. 300 1. IPv6 MS can get the IPv6 address from an access router using 301 stateless auto-configuration. In this case, router discovery and DAD 302 operation using multicast should be properly operated over IEEE 303 802.16 link. 305 2. IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6 306 server. In this case, the DHCPv6 server would be located in the 307 service provider core network and Edge Router would simply act as a 308 DHCP Relay Agent. This option is similar to what we do today in case 309 of DHCPv4. 311 In this scenario, a router and multiple BSs form an IPv6 subnet and a 312 single prefix is allocated to all the attached MS. All MSs attached 313 to same AR can be on same IPv6 link. 315 2.2.1.3. IPv6 Control and Data Transport 317 In a subnet, there are always two underlying links: one is the IEEE 318 802.16 wireless link between MS and BS, and the other is a wired link 319 between BS and AR. Also, there are multiple BSs on the same link. 321 If stateless auto-configuration is used to get an IPv6 address, 322 router discovery and DAD operation should be properly operated over 323 IEEE 802.16 link. So, BS may support IPv6 basic protocols such as ND 324 using multicast functions, or provide some schemes to facilitate the 325 stateless auto-configuration. Especially, IEEE 802.16 connection 326 terminates at BS, not a router. So, BS should look at the 327 classifiers and decide where to send the packet. In addition, one BS 328 can send the packet to other BSs, since multiple BSs are on the same 329 link. 331 The operation and transmission methods are being intensively 332 discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note 333 that in this scenario Ethernet CS as well as IPv6 CS may be used to 334 transport IPv6 packets. 336 Simple or complex network equipments may constitute the underlying 337 wired network between BS and AR. If the IP aware equipments do not 338 support IPv6, the service providers are deploying IPv6-in-IPv4 339 tunneling mechanisms to transport IPv6 packets between an AR and an 340 Edge router. 342 The service providers are deploying tunneling mechanisms to transport 343 IPv6 over their existing IPv4 networks as well as deploying native 344 IPv6 where possible. Native IPv6 should be preferred over tunneling 345 mechanisms as native IPv6 deployment option might be more scalable 346 and provide required service performance. Tunneling mechanisms 347 should only be used when native IPv6 deployment is not an option. 348 This can be equally applied to other three scenarios below. 350 2.2.1.4. Routing 352 In general, the AR is configured with a default route that points to 353 the Edge router. No routing protocols are needed on these devices 354 which generally have limited resources. 356 The Edge Router runs the IGP used in the ISP network such as OSPFv3 357 or IS-IS for IPv6. The connected prefixes have to be redistributed. 358 Prefix summarization should be done at the Edge Router. 360 2.2.2. Scenario B 362 Scenario B represents IEEE 802.16 network deployment where a BS is 363 separated from a router, there are multiple access routers, and a 364 subnet consists of multiple BS and MSs. If 802.16 access networks 365 are widely deployed like WLAN, this scenario should be also 366 considered. Hot-zone deployment model falls within this scenario B. 368 +-----+ +-----+ +-----+ ISP 1 369 | MS1 |<-----+ +->| AR1 |----| ER1 |===>Network 370 +-----+ | | +-----+ +-----+ 371 +-----+ | +-----+ | 372 | MS2 |<-----+-----| BS1 |--| 373 +-----+ +-----+ | +-----+ +-----+ ISP 2 374 +->| AR2 |----| ER2 |===>Network 375 +-----+ +-----+ | +-----+ +-----+ 376 | Ms3 |<-----------| BS2 |--+ 377 +-----+ +-----+ 378 <---> IP termination 380 Figure 3: Scenario B 382 2.2.2.1. IPv6 Related Infrastructure Changes 384 IPv6 will be deployed in this scenario by upgrading the following 385 devices to dual-stack: MS, BS (if possible), AR and Edge Router. In 386 this scenario the BS is Layer 3 unaware, so no changes are needed to 387 support IPv6. However, if IPv4 stack is loaded to them for 388 management and configuration purpose, it is expected that BS should 389 be upgraded by implementing IPv6 stack, too. 391 2.2.2.2. Addressing 393 In this scenario, multiple BSs and MSs form an IPv6 subnet and 394 multiple prefixes are allocated to all the attached MS. All MSs 395 attached to different BSs under the same AR, can be on same IPv6 396 link. 398 2.2.2.3. IPv6 Control and Data Transport 400 In a subnet, like scenario A, there are always two underlying links: 401 one is the IEEE 802.16 wireless link between MS and BS, and the other 402 is a wired link between BS and AR. Also, there are multiple BSs on 403 the same link. 405 If stateless auto-configuration is used to get an IPv6 address, 406 considerations on router discovery and DAD operation are the same as 407 scenario A. 409 The operation and transmission methods are being intensively 410 discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note 411 that in this scenario Ethernet CS may be more suitable to transport 412 IPv6 packets, rather than IPv6 CS, since this scenario requires 413 broadcast-like functions (e.g., multi-homing). 415 Simple or complex network equipments may constitute the underlying 416 wired network between BS and AR. If the IP aware equipments do not 417 support IPv6, the service providers are deploying IPv6-in-IPv4 418 tunneling mechanisms to transport IPv6 packets between an AR and an 419 Edge router. 421 2.2.2.4. Routing 423 In this scenario, IPv6 multi-homing considerations exist. For 424 example, if there exist two routers to support MSs, default router 425 must be selected. 427 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 428 IS-IS for IPv6. The connected prefixes have to be redistributed. 429 Prefix summarization should be done at the Edge Router. 431 2.2.3. Scenario C 433 Scenario C represents IEEE 802.16 access network deployment where a 434 BS is integrated with a router, composing one box in view of 435 implementation, and a subnet consists of only single BS/router and 436 multiple MSs. 438 +-----+ 439 | MS1 |<------+ 440 +-----+ | 441 +-----+ | +-------+ +--------+ 442 | MS2 |<------+--->|BS/AR1 |---------| Edge | ISP 443 +-----+ +-------+ | Router +==>Network 444 +--------+ 445 +-----+ +-------+ | 446 | Ms3 |<---------->|BS/AR2 |-----------+ 447 +-----+ +-------+ 448 <---> IP termination 450 Figure 4: Scenario C 452 2.2.3.1. IPv6 Related Infrastructure Changes 454 IPv6 will be deployed in this scenario by upgrading the following 455 devices to dual-stack: MS, BS/AR and Edge Router. 457 2.2.3.2. Addressing 459 In this scenario, a single prefix is allocated to all the attached 460 MS. All MSs attached to same BS can be on same IPv6 link. 462 2.2.3.3. IPv6 Control and Data Transport 464 If stateless auto-configuration is used to get an IPv6 address, 465 router discovery and DAD operations should be properly operated over 466 IEEE 802.16 link. So, BS/AR should support IPv6 basic protocols such 467 as ND using multicast functions, or provide some schemes to 468 facilitate the stateless auto-configuration. 470 The operation and transmission methods are being intensively 471 discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note 472 that in this scenario Ethernet CS as well as IPv6 CS may be used to 473 transport IPv6 packets. 475 2.2.3.4. Routing 477 In general, BS/Router is configured with a default route that points 478 to the Edge router. No routing protocols are needed on these devices 479 which generally have limited resources. 481 The Edge Router runs the IGP used in the SP network such as OSPFv3 or 482 IS-IS for IPv6. The connected prefixes have to be redistributed. 483 Prefix summarization should be done at the Edge Router. 485 2.2.4. Scenario D 487 Scenario D represents IEEE 802.16 access network deployment where a 488 BS is integrated with a router, composing one box in view of 489 implementation. In this scenario, a subnet consists of only single 490 BS/router and single MS. This scenario mimics the current 3GPP-like 491 IPv6 deployment model. 493 +-----+ 494 | MS1 |<-------------+ 495 +-----+ v 496 +-----+ +-------+ +--------+ 497 | MS2 |<---------->|BS/AR1 |---------| Edge | ISP 498 +-----+ +-------+ | Router +==>Network 499 +--------+ 500 +-----+ +-------+ | 501 | Ms3 |<---------->|BS/AR2 |-----------+ 502 +-----+ +-------+ 503 <---> IP termination 505 Figure 5: Scenario D 507 2.2.4.1. IPv6 Related Infrastructure Changes 509 IPv6 will be deployed in this scenario by upgrading the following 510 devices to dual-stack: MS, BS/AR and Edge Router. 512 2.2.4.2. Addressing 514 In this case, if stateless auto-configuration is used, 3GPP-like IPv6 515 addressing scheme [RFC 3314] can be used. That is, a unique prefix 516 can be allocated to each MS. [RFC 3314] recommends that a given 517 prefix should be assigned to only one primary PDP context so that 518 3GPP terminals are allowed to generate multiple IPv6 address using 519 the prefix without the concerns of address confliction (DAD). 521 2.2.4.3. IPv6 Control and Data Transport 523 In this scenario, IEEE 802.16 connection and IPv6 termination point 524 are the same, since a BS is integrated with a router. In addition, 525 each MS can be on different IPv6 link. So, many IPv6 protocols can 526 be operated without much consideration about the underlying network 527 implementation. 529 Only IEEE 802.16 link will be taken into consideration for IPv6 530 adoption. For example, DAD operation is not needed since each MS has 531 only a well-known neighbor, a router. The operation and transmission 532 methods are being intensively discussed in other documents [I-D.shin- 533 16ng-ipv6-transmission]. 535 Note that in this scenario IPv6 CS type may be more suitable to 536 transport IPv6 packets rather than Ethernet CS type since broadcast- 537 like functions are not required. 539 2.2.4.4. Routing 541 In general, the access router is configured with a default route that 542 points to the Edge Router. No routing protocols are needed on these 543 devices which generally have limited resources. 545 The Edge Router runs the IGP used in the service provider network 546 such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be 547 redistributed. Prefix summarization should be done at the Edge 548 Router. 550 2.3. IPv6 Multicast 552 In order to support multicast services in IEEE 802.16, Multicast 553 Listener Discovery (MLD) [RFC2710] must be supported between the MS 554 and BS/Router. Also, the inter-working with IP multicast protocols 555 and Multicast and Broadcast Service (MBS) should be considered. 557 Within IEEE 802.16 networks, an MS connects to its BS/router via 558 point-to-point links. MLD allows an MS to send link-local multicast 559 destination queries and reports. The packets are transmitted as 560 normal IEEE 802.16 MAC frames, as the same as regular unicast 561 packets. Especially, multicast CIDs can be used to transmit 562 efficiently query packets on the downlink. 564 There are exactly two IP devices connected to the point-to-point 565 link, and no attempt is made (at the link-layer) to suppress the 566 forwarding of multicast traffic. Consequently, sending MLD reports 567 for link-local addresses in IEEE 802.16 network may not always be 568 necessary. MLD is needed for multicast group knowledge that is not 569 link-local. 571 MBS defines Multicast and Broadcast Services, but actually, MBS seems 572 to be a broadcast service, not multicasting. MBS adheres to 573 broadcast services, while traditional IP multicast schemes define 574 multicast routing using a shared tree or source-specific tree to 575 deliver packets efficiently. 577 In IEEE 802.16 networks, two types of access to MBS may be supported: 578 single-BS access and multi-BS access. Therefore, these two types of 579 services may be roughly mapped into Source-Specific Multicast. 581 Note that it should be intensively researched later, since MBS will 582 be one of the killer services in IEEE 802.16 networks. 584 2.4. IPv6 Mobility 586 As for mobility management, the movement between BSs is handled by 587 Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in 588 certain cases (e.g., fast handover [I-D.ietf-mipshop-fast-mipv6]) the 589 link mobility information must be available for facilitating layer 3 590 handoff procedure. 592 Mobile IPv6 defines that movement detection uses Neighbor 593 Unreachability Detection to detect when the default router is no 594 longer bi-directionally reachable, in which case the mobile node must 595 discover a new default router. Periodic Router Advertisements for 596 reachability and movement detection may be unnecessary because IEEE 597 802.16 MAC provides the reachability by its Ranging procedure and the 598 movement detection by the Handoff procedure, if a BS is integrated 599 with a AR. 601 In addition, IEEE 802.16e has facilities in determining whether the 602 change of MS's IP address is required during the handoff. Therefore, 603 Mobile IPv6 can get a hint from such low-layer facilities, and 604 conduct its Layer 3 mobility protocol only when it is needed. Though 605 a handoff has occurred, an additional router discovery procedure is 606 not required in case of intra-subnet handoff. Also, faster handoff 607 may be occurred by the L2 trigger in case of inter-subnet handoff. 609 Mobile IPv6 Fast Handover assumes the support from link-layer 610 technology, but the particular link-layer information being 611 available, as well as the timing of its availability (before, during 612 or after a handover has occurred), differs according to the 613 particular link-layer technology in use. IEEE 802.16g which is 614 under-developed defines L2 triggers for IEEE 802.16 link status such 615 as link-up, link-down, handoff-start. These L2 triggers may make 616 Mobile IPv6 procedure more efficient and faster. 618 This issue is also being discussed in [I-D.ietf-mipshop-fh80216e]. 620 2.5. IPv6 QoS 622 In IEEE 802.16 networks, a connection is unidirectional and has a QoS 623 specification. The QoS has different semantics with IP QoS (e.g., 624 diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS 625 parameters of the service flow associated with that connection. In 626 order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label 627 for IPv6) mapping to IEEE 802.16 link specifics should be provided. 629 2.6. IPv6 Security 631 When initiating the connection, an MS is authenticated by the AAA 632 server located at its service provider network. All the parameters 633 related to authentication (username, password and etc.) are forwarded 634 by the BS to the AAA server. The AAA server authenticates MSs. If 635 an MS is once authenticated and associated successfully with BS, an 636 IPv6 address will be acquired by the MS. Note the initiation and 637 authentication process is the same as used in IPv4. 639 IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may 640 be used within the global end-to-end architecture. But, we don't 641 have PKIs across organizations and IPsec isn't integrated with IEEE 642 802.16 network mobility management. 644 IEEE 802.16 network threats may be different from IPv6 and IPv6 645 transition threat models [I-D.ietf-v6ops-security-overview]. It 646 should be also discussed. 648 2.7. IPv6 Network Management 650 For IPv6 network management, the necessary instrumentation (such as 651 MIBs, NetFlow Records, etc) should be available. 653 Upon entering the network, an MS is assigned three management 654 connections in each direction. These three connections reflect the 655 three different QoS requirements used by different management levels. 656 The first of these is the basic connection, which is used for the 657 transfer of short, time-critical MAC management message and radio 658 link control (RLC) messages. The primary management connection is 659 used to transfer longer, more delay-tolerant messages such as those 660 used for authentication and connection setup. The secondary 661 management connection is used for the transfer of standards-based 662 management messages such as Dynamic Host Configuration Protocol 663 (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network 664 Management Protocol (SNMP). 666 3. IANA Considerations 668 This document requests no action by IANA. 670 4. Security Considerations 672 Please refer to sec 2.6 "IPv6 Security" technology sections for 673 details. 675 5. Acknowledgements 677 This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- 678 scenarios]. We thank all the authors of the document. 680 6. References 682 6.1. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 688 in IPv6", RFC 3775, June 2004. 690 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 691 Discovery for IP Version 6 (IPv6)", RFC 2461, 692 December 1998. 694 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 695 (IPv6) Specification", RFC 2460, December 1998. 697 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 698 Autoconfiguration", RFC 2462, December 1998. 700 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 701 Listener Discovery (MLD) for IPv6", RFC 2710, 702 October 1999. 704 6.2. Informative References 706 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 707 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 708 Second and Third Generation Cellular Hosts", RFC 3316, 709 April 2003. 711 [I-D.ietf-mipshop-fast-mipv6] 712 Koodli, R., "Fast Handovers for Mobile IPv6", 713 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 714 October 2004. 716 [I-D.madanapalli-nd-over-802.16-problems] 717 Madanapalli, S., "IPv6 Neighbor Discovery over 802.16: 718 Problems and Goals", 719 draft-madanapalli-nd-over-802.16-problems-00 (work in 720 progress), December 2005. 722 [I-D.mandin-ip-over-80216-ethcs] 723 Mandin, J., "Transport of IP over 802.16", 724 draft-mandin-ip-over-80216-ethcs-00 (work in progress), 725 October 2005. 727 [I-D.ietf-v6ops-security-overview] 728 Davies, E., "IPv6 Transition/Co-existence Security 729 Considerations", draft-ietf-v6ops-security-overview-04 730 (work in progress), March 2006. 732 [I-D.ietf-v6ops-bb-deployment-scenarios] 733 Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband 734 Access Networks", 735 draft-ietf-v6ops-bb-deployment-scenarios-04 (work in 736 progress), October 2005. 738 [I-D.shin-16ng-ipv6-transmission] 739 Shin, M. and H. Jang, "Transmission of IPv6 Packets over 740 IEEE 802.16", draft-shin-16ng-ipv6-transmission-00 (work 741 in progress), February 2006. 743 [IEEE802.16] 744 "IEEE 802.16-2004, IEEE standard for Local and 745 metropolitan area networks, Part 16: Air Interface for 746 fixed broadband wireless access systems", October 2004. 748 [IEEE802.16e] 749 "IEEE Std. for Local and metropolitan area networks Part 750 16: Air Interface for Fixed and Mobile Broadband Wireless 751 Access Systems Amendment 2: Physical and Medium Access 752 Control Layers for Combined Fixed and Mobile Operation in 753 Licensed Bands and Corrigendum 1", February 2006. 755 Authors' Addresses 757 Myung-Ki Shin 758 ETRI 759 161 Gajeong-dong Yuseng-gu 760 Daejeon, 305-350 761 Korea 763 Phone: +82 42 860 4847 764 Email: myungki.shin@gmail.com 766 Youn-Hee Han 767 KUT 768 Gajeon-Ri 307 Byeongcheon-Myeon 769 Cheonan-Si Chungnam Province, 330-708 770 Korea 772 Email: yhhan@kut.ac.kr 774 Intellectual Property Statement 776 The IETF takes no position regarding the validity or scope of any 777 Intellectual Property Rights or other rights that might be claimed to 778 pertain to the implementation or use of the technology described in 779 this document or the extent to which any license under such rights 780 might or might not be available; nor does it represent that it has 781 made any independent effort to identify any such rights. Information 782 on the procedures with respect to rights in RFC documents can be 783 found in BCP 78 and BCP 79. 785 Copies of IPR disclosures made to the IETF Secretariat and any 786 assurances of licenses to be made available, or the result of an 787 attempt made to obtain a general license or permission for the use of 788 such proprietary rights by implementers or users of this 789 specification can be obtained from the IETF on-line IPR repository at 790 http://www.ietf.org/ipr. 792 The IETF invites any interested party to bring to its attention any 793 copyrights, patents or patent applications, or other proprietary 794 rights that may cover technology that may be required to implement 795 this standard. Please address the information to the IETF at 796 ietf-ipr@ietf.org. 798 Disclaimer of Validity 800 This document and the information contained herein are provided on an 801 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 802 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 803 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 804 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 805 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 806 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 808 Copyright Statement 810 Copyright (C) The Internet Society (2006). This document is subject 811 to the rights, licenses and restrictions contained in BCP 78, and 812 except as set forth therein, the authors retain all their rights. 814 Acknowledgment 816 Funding for the RFC Editor function is currently provided by the 817 Internet Society.