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