Network Working Group M-K. Shin Internet-Draft ETRI Expires: November 25, 2006 Y-H. Han KUT May 24, 2006 ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks draft-ietf-v6ops-802-16-deployment-scenarios-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. Shin & Han Expires November 25, 2006 [Page 1] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Wireless Broadband Access Network Technologies - IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 2.2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . 5 2.2.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . 9 2.2.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . 12 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13 2.4. IPv6 Mobility . . . . . . . . . . . . . . . . . . . . . . 14 2.5. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 15 2.7. IPv6 Network Management . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Shin & Han Expires November 25, 2006 [Page 2] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 1. Introduction Recently, broadband wireless access network is emerging for wireless communication for user requirements such as high quality data/voice service, fast mobility, wide coverage, etc. The IEEE 802.16 Working Group develops standards and recommended practices to support the development and deployment of broadband wireless metropolitan area networks. Whereas the existing IEEE 802.16 standard [IEEE802.16] addresses fixed wireless applications only, the IEEE 802.16(e) standard [IEEE802.16e] aims to serve the needs of fixed, nomadic, and fully mobile networks. It adds mobility support to the original standard so that mobile subscriber stations can move while receiving services. IEEE 802.16e is one of the most promising access technologies which would be applied to the IP-based broadband mobile communication. WiMAX Forum is an industrial corporation formed to promote and certify compatibility and interoperability of broadband wireless products mainly based on IEEE 802.16. The Network Working Group (NWG) of WiMAX Forum is defining the IEEE 802.16 network architecture (e.g., IPv4, IPv6, Mobility, interworking with different networks, AAA, etc). Similarly, WiBro (Wireless Broadband), Korea effort which focuses on the 2.3 GHz spectrum band, is also based on the IEEE 802.16 and IEEE 802.16e specifications. As the deployment of wireless broadband access network progresses, users will be connected to IPv6 networks. While the IEEE 802.16 defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 MAC payload, a complete description of IPv4/IPv6 operation and deployment is not present. In this document, we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. This document extends works of [I-D.ietf-v6ops-bb-deployment- scenarios] and follows the structure and common terminology of the document. Shin & Han Expires November 25, 2006 [Page 3] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 2. Wireless Broadband Access Network Technologies - IEEE 802.16 This section describes the infrastructure that exists today in IEEE 802.16 networks providing wireless broadband services to the customer. It also describes IPv6 deployment options in these IEEE 802.16 networks. 2.1. Elements of IEEE 802.16 Networks The IEEE 802.11 access network (WLAN) has driven the revolution of wireless communication but the more people use it the more its limitations like short range or lack of mobility support were revealed. Compared with such IEEE 802.11 network, IEEE 802.16 supports enhanced features like wider range and mobility. So it is expected that IEEE 802.16 network could be the next step of IEEE 802.11 network. The mechanism of transporting IP traffic over IEEE 802.16 networks is outlined in [IEEE802.16], but the details of IPv6 operations over IEEE 802.16 are being discussed now. Here are some of the key elements of IEEE 802.16 networks MS: Mobile Station. A station in the mobile service intended to be used while in motion or during halts at unspecified points. A mobile station (MS) is always a subscriber station (SS). BS: Base Station. A generalized equipment set providing connectivity, management and control of MS connections. There is a unidirectional mapping between BS and MS medium access control (MAC) peers for the purpose of transporting a service flow's traffic. Connections are identified by a connection identifier (CID) and all traffic is carried on a connection. Sometimes there can be alternative IEEE 802.16 network deployment where a BS is integrated with an access router, composing one box in view of implementation. Figure 1 illustrates the key elements of IEEE 802.16 networks. Shin & Han Expires November 25, 2006 [Page 4] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Customer | Access Provider | Service Provider Premise | | (Backend Network) +-----+ +-----+ +------+ +--------+ | MSs |--(802.16)--| BS |-----+Access+---+ Edge | ISP +-----+ +-----+ |Router| | Router +==>Network +--+---+ +--------+ +-----+ +-----+ | | +------+ | Mss |--(802.16)--| BS |--------+ +--|AAA | +-----+ +-----+ |Server| +------+ Figure 1: Key Elements of IEEE 802.16(e) Networks 2.2. Deploying IPv6 in IEEE 802.16 Networks IEEE 802.16 supports two modes such as 2-way PMP (Point-to- Multipoint) and Mesh topology wireless networks. In this document, we focus on 2-way PMP topology wireless networks. There are two different deployment options in current IEEE 802.16 networks: Cellular-like and Hot-zone deployment scenarios. IPv6 can be deployed in both of these deployment models. A. Cellular-like Deployment Model IEEE 802.16 BS can offer both fixed communications and mobile functions unlike IEEE 802.11. In particular, IEEE 802.16e working group standardized such mobility features and the specification of IEEE 802.16e provides some competition to the existing cellular systems. This use case will be implemented only with the licensed spectrum. IEEE 802.16 BS might be deployed with a proprietary backend managed by an operator. All original IPv6 functionalities will not survive and some of them might be compromised to efficiently serve IPv6 to this 'Cellular-like' use case. Under the use case, however, IEEE 802.16 standards are still IP- centric, providing packet-switched approach, while cellular standards like GSM have a more circuit-switched approach. B. Hot Zone Deployment Model The success of a Hotspot service with IEEE 802.11 has been prominent. The new IEEE 802.16 standards basically support such Hotspot services with large coverage area and high data rate. An area served by one base station is usually termed 'Hot Zone' because it is considerably larger than an IEEE 802.11 access point service area called Hotspot. Shin & Han Expires November 25, 2006 [Page 5] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Many wireless Internet service providers (Wireless ISPs) have planned to use IEEE 802.16 for the purpose of high quality service. A company can use IEEE 802.16 to build up mobile office. Wireless Internet spreading through a campus or a cafe can be also implemented with it. The distinct point of this use case is that it can use unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 & 3.5GHz) band. By using the unlicensed band, a IEEE 802.16 BS might be used just as a wireless hub which a user purchases to build a private wireless network in his/her home or laboratory. Under 'Hot Zone' use case, a IEEE 802.16 BS will be deployed using an Ethernet (IP) backbone rather than a proprietary backend like cellular systems. Thus, many IPv6 functionalities will be preserved when adopting IPv6 to IEEE 802.16 networks, which brings out many research issues [I-D.jee-16ng-problem-statement] [I-D.madanapalli-nd- over-802.16-problems]. Some of the factors that hinder deployment of native IPv6 core protocols include: 1. Lacking of Facility for IPv6 Native Multicasting IEEE 802.16 is a PMP connection oriented technology without bi- directional native multicast support. IPv6 neighbor discovery [RFC2461] supports various functions for the interaction between nodes attached on the same subnet, such as on-link determination and address resolution. It is designed with no dependence on a specific link layer technology, but requires that the link layer technology support native multicast. The specification of IEEE 802.16 provides multicast and broadcast services. However, the aim of such services is to transmit IEEE 802.16 MAC management messages, not IP messages. This lacking of facility for IPv6 native multicast results in inappropriateness to apply the standard neighbor discover protocol specially regarding, address resolution, router discovery, stateless auto-configuration and duplicated address detection. 2. Impact of BS on Subnet Model IEEE 802.16 is different from existing wireless access technologies such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a complete description of IPv6 operation is not present. IEEE 802.16 can rather benefit from IETF input and specification to support IPv6 operation. Especially, BS should look at the classifiers and decide where to send the packet, since IEEE 802.16 connection always ends at BS, while IPv6 connection terminates at a default router. This operation and limitation may be dependent on the given subnet model. Shin & Han Expires November 25, 2006 [Page 6] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Also, we should consider which type of Convergence Sublayer (CS) can be efficiently used on each subnet models. IEEE 802.16 CS provides the tunneling of IP(v6) packets over IEEE 802.16 air-link. The tunnels are identified by the Connection Identifier (CID). Generally, CS performs the following functions in terms of IP packet transmission: 1) Receipt of protocol data units (PDUs) from the higher layer, 2) Performing classification and CID mapping of the PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt of PDUs from the peer MAC SAP. The specification of IEEE 802.16 defines several CSs for carrying IP packets, but does not provide a detailed description of how to carry them. The several CSs are generally classified into two types of CS: IPv6 CS and Ethernet CS. While deploying IPv6 in the above mentioned approach, there are four possible typical scenarios as discussed below. 2.2.1. Scenario A Scenario A represents IEEE 802.16 access network deployment where a BS is separated from a router, and a subnet consists of only single router and multiple BSs and MSs. Current celluar-like deployment models, WiMax and WiBro, fall within this scenario A. +-----+ | MS1 |<------+ +-----+ | +-----+ | +-----+ +-----+ +--------+ | MSs |<------+----| BS1 |---->| AR |----| Edge | ISP +-----+ +-----+ +-----+ | Router +==>Network ^ +--------+ +-----+ +-----+ | | Mss |<-----------| BS2 |--------+ +-----+ +-----+ <---> IP termination Figure 2: Scenario A 2.2.1.1. IPv6 Related Infrastructure Changes IPv6 will be deployed in this scenario by upgrading the following devices to dual-stack: MS, BS (if possible), AR and Edge Router. In this scenario the BS is Layer 3 unaware, so no changes are needed to support IPv6. However, if IPv4 stack is loaded to them for management and configuration purpose, it is expected that BS should be upgraded by implementing IPv6 stack, too. Shin & Han Expires November 25, 2006 [Page 7] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 2.2.1.2. Addressing IPv6 MS has two possible options to get an IPv6 address. These options will be equally applied to the other three scenarios below. 1. IPv6 MS can get the IPv6 address from an access router using stateless auto-configuration. In this case, router discovery and DAD operation using multicast should be properly operated over IEEE 802.16 link. 2. IPv6 MS can use DHCPv6 to get an IPv6 address from the DHCPv6 server. In this case, the DHCPv6 server would be located in the service provider core network and Edge Router would simply act as a DHCP Relay Agent. This option is similar to what we do today in case of DHCPv4. In this scenario, a router and multiple BSs form an IPv6 subnet and a single prefix is allocated to all the attached MS. All MSs attached to same AR can be on same IPv6 link. 2.2.1.3. IPv6 Control and Data Transport In a subnet, there are always two underlying links: one is the IEEE 802.16 wireless link between MS and BS, and the other is a wired link between BS and AR. Also, there are multiple BSs on the same link. If stateless auto-configuration is used to get an IPv6 address, router discovery and DAD operation should be properly operated over IEEE 802.16 link. So, BS may support IPv6 basic protocols such as ND using multicast functions, or provide some schemes to facilitate the stateless auto-configuration. Especially, IEEE 802.16 connection terminates at BS, not a router. So, BS should look at the classifiers and decide where to send the packet. In addition, one BS can send the packet to other BSs, since multiple BSs are on the same link. The operation and transmission methods are being intensively discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note that in this scenario Ethernet CS as well as IPv6 CS may be used to transport IPv6 packets. Simple or complex network equipments may constitute the underlying wired network between BS and AR. If the IP aware equipments do not support IPv6, the service providers are deploying IPv6-in-IPv4 tunneling mechanisms to transport IPv6 packets between an AR and an Edge router. The service providers are deploying tunneling mechanisms to transport Shin & Han Expires November 25, 2006 [Page 8] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 IPv6 over their existing IPv4 networks as well as deploying native IPv6 where possible. Native IPv6 should be preferred over tunneling mechanisms as native IPv6 deployment option might be more scalable and provide required service performance. Tunneling mechanisms should only be used when native IPv6 deployment is not an option. This can be equally applied to other three scenarios below. 2.2.1.4. Routing In general, the AR is configured with a default route that points to the Edge router. No routing protocols are needed on these devices which generally have limited resources. The Edge Router runs the IGP used in the ISP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. 2.2.2. Scenario B Scenario B represents IEEE 802.16 network deployment where a BS is separated from a router, there are multiple access routers, and a subnet consists of multiple BS and MSs. If 802.16 access networks are widely deployed like WLAN, this scenario should be also considered. Hot-zone deployment model falls within this scenario B. +-----+ +-----+ +-----+ ISP 1 | MS1 |<-----+ +->| AR1 |----| ER1 |===>Network +-----+ | | +-----+ +-----+ +-----+ | +-----+ | | MS2 |<-----+-----| BS1 |--| +-----+ +-----+ | +-----+ +-----+ ISP 2 +->| AR2 |----| ER2 |===>Network +-----+ +-----+ | +-----+ +-----+ | Ms3 |<-----------| BS2 |--+ +-----+ +-----+ <---> IP termination Figure 3: Scenario B 2.2.2.1. IPv6 Related Infrastructure Changes IPv6 will be deployed in this scenario by upgrading the following devices to dual-stack: MS, BS (if possible), AR and Edge Router. In this scenario the BS is Layer 3 unaware, so no changes are needed to support IPv6. However, if IPv4 stack is loaded to them for management and configuration purpose, it is expected that BS should be upgraded by implementing IPv6 stack, too. Shin & Han Expires November 25, 2006 [Page 9] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 2.2.2.2. Addressing In this scenario, multiple BSs and MSs form an IPv6 subnet and multiple prefixes are allocated to all the attached MS. All MSs attached to different BSs under the same AR, can be on same IPv6 link. 2.2.2.3. IPv6 Control and Data Transport In a subnet, like scenario A, there are always two underlying links: one is the IEEE 802.16 wireless link between MS and BS, and the other is a wired link between BS and AR. Also, there are multiple BSs on the same link. If stateless auto-configuration is used to get an IPv6 address, considerations on router discovery and DAD operation are the same as scenario A. The operation and transmission methods are being intensively discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note that in this scenario Ethernet CS may be more suitable to transport IPv6 packets, rather than IPv6 CS, since this scenario requires broadcast-like functions (e.g., multi-homing). Simple or complex network equipments may constitute the underlying wired network between BS and AR. If the IP aware equipments do not support IPv6, the service providers are deploying IPv6-in-IPv4 tunneling mechanisms to transport IPv6 packets between an AR and an Edge router. 2.2.2.4. Routing In this scenario, IPv6 multi-homing considerations exist. For example, if there exist two routers to support MSs, default router must be selected. The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. 2.2.3. Scenario C Scenario C represents IEEE 802.16 access network deployment where a BS is integrated with a router, composing one box in view of implementation, and a subnet consists of only single BS/router and multiple MSs. Shin & Han Expires November 25, 2006 [Page 10] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 +-----+ | MS1 |<------+ +-----+ | +-----+ | +-------+ +--------+ | MS2 |<------+--->|BS/AR1 |---------| Edge | ISP +-----+ +-------+ | Router +==>Network +--------+ +-----+ +-------+ | | Ms3 |<---------->|BS/AR2 |-----------+ +-----+ +-------+ <---> IP termination Figure 4: Scenario C 2.2.3.1. IPv6 Related Infrastructure Changes IPv6 will be deployed in this scenario by upgrading the following devices to dual-stack: MS, BS/AR and Edge Router. 2.2.3.2. Addressing In this scenario, a single prefix is allocated to all the attached MS. All MSs attached to same BS can be on same IPv6 link. 2.2.3.3. IPv6 Control and Data Transport If stateless auto-configuration is used to get an IPv6 address, router discovery and DAD operations should be properly operated over IEEE 802.16 link. So, BS/AR should support IPv6 basic protocols such as ND using multicast functions, or provide some schemes to facilitate the stateless auto-configuration. The operation and transmission methods are being intensively discussed in other documents [I-D.shin-16ng-ipv6-transmission]. Note that in this scenario Ethernet CS as well as IPv6 CS may be used to transport IPv6 packets. 2.2.3.4. Routing In general, BS/Router is configured with a default route that points to the Edge router. No routing protocols are needed on these devices which generally have limited resources. The Edge Router runs the IGP used in the SP network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. Shin & Han Expires November 25, 2006 [Page 11] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 2.2.4. Scenario D Scenario D represents IEEE 802.16 access network deployment where a BS is integrated with a router, composing one box in view of implementation. In this scenario, a subnet consists of only single BS/router and single MS. This scenario mimics the current 3GPP-like IPv6 deployment model. +-----+ | MS1 |<-------------+ +-----+ v +-----+ +-------+ +--------+ | MS2 |<---------->|BS/AR1 |---------| Edge | ISP +-----+ +-------+ | Router +==>Network +--------+ +-----+ +-------+ | | Ms3 |<---------->|BS/AR2 |-----------+ +-----+ +-------+ <---> IP termination Figure 5: Scenario D 2.2.4.1. IPv6 Related Infrastructure Changes IPv6 will be deployed in this scenario by upgrading the following devices to dual-stack: MS, BS/AR and Edge Router. 2.2.4.2. Addressing In this case, if stateless auto-configuration is used, 3GPP-like IPv6 addressing scheme [RFC 3314] can be used. That is, a unique prefix can be allocated to each MS. [RFC 3314] recommends that a given prefix should be assigned to only one primary PDP context so that 3GPP terminals are allowed to generate multiple IPv6 address using the prefix without the concerns of address confliction (DAD). 2.2.4.3. IPv6 Control and Data Transport In this scenario, IEEE 802.16 connection and IPv6 termination point are the same, since a BS is integrated with a router. In addition, each MS can be on different IPv6 link. So, many IPv6 protocols can be operated without much consideration about the underlying network implementation. Only IEEE 802.16 link will be taken into consideration for IPv6 adoption. For example, DAD operation is not needed since each MS has only a well-known neighbor, a router. The operation and transmission methods are being intensively discussed in other documents [I-D.shin- Shin & Han Expires November 25, 2006 [Page 12] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 16ng-ipv6-transmission]. Note that in this scenario IPv6 CS type may be more suitable to transport IPv6 packets rather than Ethernet CS type since broadcast- like functions are not required. 2.2.4.4. Routing In general, the access router is configured with a default route that points to the Edge Router. No routing protocols are needed on these devices which generally have limited resources. The Edge Router runs the IGP used in the service provider network such as OSPFv3 or IS-IS for IPv6. The connected prefixes have to be redistributed. Prefix summarization should be done at the Edge Router. 2.3. IPv6 Multicast In order to support multicast services in IEEE 802.16, Multicast Listener Discovery (MLD) [RFC2710] must be supported between the MS and BS/Router. Also, the inter-working with IP multicast protocols and Multicast and Broadcast Service (MBS) should be considered. Within IEEE 802.16 networks, an MS connects to its BS/router via point-to-point links. MLD allows an MS to send link-local multicast destination queries and reports. The packets are transmitted as normal IEEE 802.16 MAC frames, as the same as regular unicast packets. Especially, multicast CIDs can be used to transmit efficiently query packets on the downlink. There are exactly two IP devices connected to the point-to-point link, and no attempt is made (at the link-layer) to suppress the forwarding of multicast traffic. Consequently, sending MLD reports for link-local addresses in IEEE 802.16 network may not always be necessary. MLD is needed for multicast group knowledge that is not link-local. MBS defines Multicast and Broadcast Services, but actually, MBS seems to be a broadcast service, not multicasting. MBS adheres to broadcast services, while traditional IP multicast schemes define multicast routing using a shared tree or source-specific tree to deliver packets efficiently. In IEEE 802.16 networks, two types of access to MBS may be supported: single-BS access and multi-BS access. Therefore, these two types of services may be roughly mapped into Source-Specific Multicast. Shin & Han Expires November 25, 2006 [Page 13] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Note that it should be intensively researched later, since MBS will be one of the killer services in IEEE 802.16 networks. 2.4. IPv6 Mobility As for mobility management, the movement between BSs is handled by Mobile IPv6 [RFC3775], if it requires a subnet change. Also, in certain cases (e.g., fast handover [I-D.ietf-mipshop-fast-mipv6]) the link mobility information must be available for facilitating layer 3 handoff procedure. Mobile IPv6 defines that movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router. Periodic Router Advertisements for reachability and movement detection may be unnecessary because IEEE 802.16 MAC provides the reachability by its Ranging procedure and the movement detection by the Handoff procedure, if a BS is integrated with a AR. In addition, IEEE 802.16e has facilities in determining whether the change of MS's IP address is required during the handoff. Therefore, Mobile IPv6 can get a hint from such low-layer facilities, and conduct its Layer 3 mobility protocol only when it is needed. Though a handoff has occurred, an additional router discovery procedure is not required in case of intra-subnet handoff. Also, faster handoff may be occurred by the L2 trigger in case of inter-subnet handoff. Mobile IPv6 Fast Handover assumes the support from link-layer technology, but the particular link-layer information being available, as well as the timing of its availability (before, during or after a handover has occurred), differs according to the particular link-layer technology in use. IEEE 802.16g which is under-developed defines L2 triggers for IEEE 802.16 link status such as link-up, link-down, handoff-start. These L2 triggers may make Mobile IPv6 procedure more efficient and faster. This issue is also being discussed in [I-D.ietf-mipshop-fh80216e]. 2.5. IPv6 QoS In IEEE 802.16 networks, a connection is unidirectional and has a QoS specification. The QoS has different semantics with IP QoS (e.g., diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS parameters of the service flow associated with that connection. In order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label for IPv6) mapping to IEEE 802.16 link specifics should be provided. Shin & Han Expires November 25, 2006 [Page 14] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 2.6. IPv6 Security When initiating the connection, an MS is authenticated by the AAA server located at its service provider network. All the parameters related to authentication (username, password and etc.) are forwarded by the BS to the AAA server. The AAA server authenticates MSs. If an MS is once authenticated and associated successfully with BS, an IPv6 address will be acquired by the MS. Note the initiation and authentication process is the same as used in IPv4. IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may be used within the global end-to-end architecture. But, we don't have PKIs across organizations and IPsec isn't integrated with IEEE 802.16 network mobility management. IEEE 802.16 network threats may be different from IPv6 and IPv6 transition threat models [I-D.ietf-v6ops-security-overview]. It should be also discussed. 2.7. IPv6 Network Management For IPv6 network management, the necessary instrumentation (such as MIBs, NetFlow Records, etc) should be available. Upon entering the network, an MS is assigned three management connections in each direction. These three connections reflect the three different QoS requirements used by different management levels. The first of these is the basic connection, which is used for the transfer of short, time-critical MAC management message and radio link control (RLC) messages. The primary management connection is used to transfer longer, more delay-tolerant messages such as those used for authentication and connection setup. The secondary management connection is used for the transfer of standards-based management messages such as Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network Management Protocol (SNMP). Shin & Han Expires November 25, 2006 [Page 15] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 3. IANA Considerations This document requests no action by IANA. Shin & Han Expires November 25, 2006 [Page 16] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 4. Security Considerations Please refer to sec 2.6 "IPv6 Security" technology sections for details. Shin & Han Expires November 25, 2006 [Page 17] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 5. Acknowledgements This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- scenarios]. We thank all the authors of the document. Shin & Han Expires November 25, 2006 [Page 18] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 6.2. Informative References [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003. [I-D.ietf-mipshop-fast-mipv6] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. [I-D.madanapalli-nd-over-802.16-problems] Madanapalli, S., "IPv6 Neighbor Discovery over 802.16: Problems and Goals", draft-madanapalli-nd-over-802.16-problems-00 (work in progress), December 2005. [I-D.mandin-ip-over-80216-ethcs] Mandin, J., "Transport of IP over 802.16", draft-mandin-ip-over-80216-ethcs-00 (work in progress), October 2005. [I-D.ietf-v6ops-security-overview] Shin & Han Expires November 25, 2006 [Page 19] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-04 (work in progress), March 2006. [I-D.ietf-v6ops-bb-deployment-scenarios] Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband Access Networks", draft-ietf-v6ops-bb-deployment-scenarios-04 (work in progress), October 2005. [I-D.shin-16ng-ipv6-transmission] Shin, M. and H. Jang, "Transmission of IPv6 Packets over IEEE 802.16", draft-shin-16ng-ipv6-transmission-00 (work in progress), February 2006. [IEEE802.16] "IEEE 802.16-2004, IEEE standard for Local and metropolitan area networks, Part 16: Air Interface for fixed broadband wireless access systems", October 2004. [IEEE802.16e] "IEEE Std. for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1", February 2006. Shin & Han Expires November 25, 2006 [Page 20] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 Email: myungki.shin@gmail.com Youn-Hee Han KUT Gajeon-Ri 307 Byeongcheon-Myeon Cheonan-Si Chungnam Province, 330-708 Korea Email: yhhan@kut.ac.kr Shin & Han Expires November 25, 2006 [Page 21] Internet-Draft IPv6 over IEEE 802.16 Scenarios May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shin & Han Expires November 25, 2006 [Page 22]