Network Working Group M-K. Shin Internet-Draft J-M. Moon Expires: August 30, 2006 ETRI Y-H. Han Samsung AIT February 26, 2006 Scenarios and Considerations of IPv6 in IEEE 802.16 Networks draft-shin-ipv6-ieee802.16-02 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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract As the deployment of IEEE 802.16 networks progresses, IPv6 will be introduced in IEEE 802.16 networks. The characteristics of IEEE 802.16 networks put special considerations on how IPv6 is used. This document describes scenarios and considerations on IPv6 adoption in IEEE 802.16 networks. Shin, et al. Expires August 30, 2006 [Page 1] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 2. Assumptions and Scenarios . . . . . . . . . . . . . . . . . . 5 2.1. Deployment Models . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Hot Zone . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Cellular-like . . . . . . . . . . . . . . . . . . . . 5 2.2. BS Architecture . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Router Separation from BS . . . . . . . . . . . . . . 6 2.2.2. BS and Router in One Box . . . . . . . . . . . . . . . 6 2.3. Addressing Issues . . . . . . . . . . . . . . . . . . . . 7 2.3.1. A Unique Prefix to a MS . . . . . . . . . . . . . . . 7 2.3.2. A Single Prefix to Attached MSs . . . . . . . . . . . 8 2.4. Convergence Sublayer (CS) Types . . . . . . . . . . . . . 8 2.4.1. IP Convergence Sublayer (CS) . . . . . . . . . . . . . 8 2.4.2. Ethernet Convergence Sublayer (CS) . . . . . . . . . . 9 2.5. Summary of Scenarios . . . . . . . . . . . . . . . . . . . 9 3. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Neighbor Discovery for IPv6 . . . . . . . . . . . . . . . 11 3.1.1. Address Resolution . . . . . . . . . . . . . . . . . . 11 3.1.2. Neighbor Unreachability Detection . . . . . . . . . . 12 3.1.3. Duplcate Address Detection . . . . . . . . . . . . . . 12 3.1.4. Router and Prefix Discovery . . . . . . . . . . . . . 12 3.1.5. Redirect Function . . . . . . . . . . . . . . . . . . 13 3.2. Transmission of IPv6 Packets . . . . . . . . . . . . . . . 13 3.3. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 14 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Mobile IPv6 Fast Handovers . . . . . . . . . . . . . . . . 15 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Multicast Listener Discovery . . . . . . . . . . . . . . . 16 5.2. Interworking with IP Multicast and MBS . . . . . . . . . . 16 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Security Threat Analysis . . . . . . . . . . . . . . . . . 17 7. Multiple Interfaces with Different Properties . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Shin, et al. Expires August 30, 2006 [Page 2] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 1. Introduction IEEE 802.16d/e [IEEE802.16][IEEE802.16e] supports MSs (Mobile Stations) moving at vehicular speeds and thereby specifies a system for combined fixed and mobile broadband wireless access. As the deployment of IEEE 802.16 networks progresses, the IEEE 802.16 MSs will be connected to IPv6 networks. The characteristics of IEEE 802.16 networks put special considerations on how IPv6 is used. This document describes scenarios and considerations on IPv6 adoption in IEEE 802.16 networks. 1.1. Scope of this Document This document presents issues with discussion on the use of IPv6 protocols when operating over IEEE 802.16 networks. In order to achieve this, operational, architectural, and addressing scenarios are first described. The scenarios have an influence on how to adopt IPv6 to IEEE 802.16 networks. Then, the following considerations will be intensively discussed based on the scenarios : Basic IP In this part, basic IPv6 issues such as Neighbor Discovery, IPv6 packet transmission, addressing, and IPv6 control/management protocols are discussed. Mobility In this part, issues on interworking with the link layer mobility mechanism and Mobile IPv6 are discussed. Multicast In this part, MBS and IPv6 multicast interworking issues are discussed. Security In this part, IPsec and threat model issues are discussed. Multiple Interface with Different Characteristics In this part, some requirements for multiple interfaces with differerent characteristics (e.g., WLAN) are discussed. Shin, et al. Expires August 30, 2006 [Page 3] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 1.2. Terminology SS: Subscriber Station. A general equipment set providing connectivity between subscriber equipment and a BS. 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) unless specifically excepted otherwise in this document. BS: Base Station. A generalized equipment set providing connectivity, management and control of MS connections. 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). All traffic is carried on a connection. CID: Connection IDentifier. A 16-bit value that identifies a connection to equivalent peers in the MAC of the BS and the MS. It maps to a service flow identifier (SFID), which also defines QoS parameters of the service flow associated with that connection. MBS: Multicast and Broadcast Services. Some globally defined service flows may carry broadcast or multicast information that should be delivered to a multiple of SSs or MSs. 1.3. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Shin, et al. Expires August 30, 2006 [Page 4] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 2. Assumptions and Scenarios IEEE 802.16e 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. Some of the problems with IPv6 adoption in IEEE 802.16 networks are described in [I-D.jee-ipv6-802.16-problem-statement]. In this section, several issues about the operation and the architecture of IEEE 802.16e networks are addressed. The issues have an influence on how to adopt IPv6 to IEEE 802.16 networks. 2.1. Deployment Models From an operational perspective, there are two use cases of IEEE 802.16 standards. 2.1.1. Hot Zone 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. Large numbers of 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, the 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, the 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 devices. 2.1.2. Cellular-like IEEE 802.16 BS can offer both fixed communications and mobile functions unlike IEEE 802.11. In particular, IEEE 802.16e working group has been standardizing the mobility features. The final specification of IEEE 802.16e will provide 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 Shin, et al. Expires August 30, 2006 [Page 5] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 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. 2.2. BS Architecture We describe two possible deployment architectures of IEEE 802.16 networks. Figure 1 and 2 illustrate the two cases. 2.2.1. Router Separation from BS In Figure 1, routers are located separated with IEEE 802.16 BSs. In this case, IEEE 802.16 BSs have only MAC and PHY layers without router function. A router and several BSs form an IPv6 subnet. BSs may not have IPv6 stack. But, for management and configuration purpose, IPv6 stack will be loaded to them. A simple or complex network equipments may constitute the underlying wired network between BSs and router. In a subnet, therefore, there are always two underlying links including IEEE 802.16 wireless link between MS and BS. In this case, the methods of IPv6 adoption to IEEE 802.16 may depend on the underlying network architecture between BSs and router. Note that this draft does not address this scenario at this phase. Its considerations will be discussed later. 2.2.2. BS and Router in One Box Figure 2 represents an alternative IEEE 802.16 network deployment where a BS is integrated with a router, composing one box in view of implementation. A subnet consists of only single router and single BS. In this case, many IPv6 functionalities can be implemented without much consideration about the underlying network implementation. Only IEEE 802.16 link will be taken into consideration for IPv6 adoption. Shin, et al. Expires August 30, 2006 [Page 6] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 /-------------------------------------\ | Backbend Network | \-------------------------------------/ | | /-----------\ /-----------\ | Router1 | | Router2 | \-----------/ \-----------/ / / | \ \ / / | \ \ / / | \ \ / / | \ \ / | | | \ / | | | \ BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10 Figure 1: IEEE 802.16e deployment architecture with BS and Router in seperated boxes /------------------\ | Backbend Network | \------------------/ / \ / \ / \ --------- --------- | Router1 | | Router2 | | BS1 | | BS2 | --------- --------- Figure 2: IEEE 802.16e deployment architecture with BS and Router in one box 2.3. Addressing Issues There are two possible addressing schemes as follows. 2.3.1. A Unique Prefix to a 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. This recommendation can be also applied to IEEE 802.16 network system if it is reasonable to the given usage scenario (e.g., 'Cellular-like' usage scenario). In such case, many IPv6 functionalities can be implemented without difficulty. Shin, et al. Expires August 30, 2006 [Page 7] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 2.3.2. A Single Prefix to Attached MSs Different usage scenario such as 'Hot zone' would not allow RFC 3314 recommendation because of the compatibility with the existing IPv6 devices. In this case, there will be more issues for adopting IPv6 to IEEE 802.16. 2.4. Convergence Sublayer (CS) Types IEEE 802.16 Convergence Sublayer (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. [IEEE802.16] defines several CSs for carrying IP packets, but does not provide a detailed description of how to carry them. The several CSs are classified into two types of CS: IP CS and Ethernet CS. The followings include the description of the two types. 2.4.1. IP Convergence Sublayer (CS) Using IP CS, an IEEE 802.16 MAC frame is followed by IPv6 header. That is, IP CS only carries IP packets as the payloads of IEEE 802.16 MAC frame. In terms of IP layer, therefore, the link-layer addresses of IPv6 neighbors are not utilized at all. Accordingly, it is not easy (or even needless) to support address resolution, router discovery, and address auto-configuration, etc. With IP CS, the classification and CID mapping will be performed based on destination IP address, source IP address, destination port, and source port. Sometimes, the QoS-related fields of IPv6 header such as 'class' and 'flow label' may be additionally used for QoS and prioritization purposes. IP CS is adequate to support the point-to-point type of communication between a SS and a BS/Router when the next-hop of the outbound packets sent by a SS is pre-defined and fixed to a network node, such as BS or access router. At this case, it is not well-grounded to support all IPv6-related function. Rather, some functions will be implemented in a proprietary manner. IP CS does not require any header to carry a link-layer address, it can save some bandwidth of IEEE 802.16 air-link. Shin, et al. Expires August 30, 2006 [Page 8] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 2.4.2. Ethernet Convergence Sublayer (CS) [IEEE802.16] introduces 'IPv6(v4)-over-ethernet CS' which permits classifiers that examine fields in Ethernet headers as well as fields of IPv6 (and encapsulated TCP/UDP headers) that are encapsulated in IEEE 802.3-style frames. An IEEE 802.16 MAC frame is followed by IEEE 802.3 Ethernet header, which then followed by IP header. This type of CS can well support IEEE 802-style broadcast network service. The emulation of the broadcast network with Ethernet CS can allow IP layer to see an IEEE 802.16 link as a LAN and support IPv6 neighbor discovery (ND) protocol without difficulty. Ethernet CS can also support point-to-point service via PPPoE optionally. Since additional IEEE 802.3 Ethernet header is always located between IEEE 802.16 MAC frame and IPv6 header, some overload over IEEE 802.16 air-link is inevitable. But, it can be alleviated by using IEEE 802.16 Payload Header Suppression. For the detailed description of Ethernet CS, see [I-D-mandin-ip-over- 80216-ethcs]. 2.5. Summary of Scenarios As a result of the combination of the above four issues, we got 16 scenarios as follows. Shin, et al. Expires August 30, 2006 [Page 9] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 +--+---------------+---------------------------+----------------------+-----+ | #| Depolyment | BS Architecture | Addressing | CS | +--+---------------+---------------------------+----------------------+-----+ | 1| Hot zone | Router separation from BS | Unique Prefix to a MS| IP | +--+---------------+---------------------------+----------------------+-----+ | 2| Hot zone | Router separation from BS | Single Prefix to MSs | IP | +--+---------------+---------------------------+----------------------+-----+ | 3| Hot zone | BS and router in one box | Unique Prefix to a MS| IP | +--+---------------+---------------------------+----------------------+-----+ | 4| Hot zone | BS and router in one box | Single Prefix to MSs | IP | +--+---------------+---------------------------+----------------------+-----+ | 5| Cellular-like | Router separation from BS | Unique Prefix to a MS| IP | +--+---------------+---------------------------+----------------------+-----+ | 6| Cellular-like | Router separation from BS | Single Prefix to MSs | IP | +--+---------------+---------------------------+----------------------+-----+ | 7| Cellular-like | BS and router in one box | Unique Prefix to a MS| IP | +--+---------------+---------------------------+----------------------+-----+ | 8| Cellular-like | BS and router in one box | Single Prefix to MSs | IP | +--+---------------+---------------------------+----------------------+-----+ | 9| Hot zone | Router separation from BS | Unique Prefix to a MS| Eth | +--+---------------+---------------------------+----------------------+-----+ |10| Hot zone | Router separation from BS | Single Prefix to MSs | Eth | +--+---------------+---------------------------+----------------------+-----+ |11| Hot zone | BS and router in one box | Unique Prefix to a MS| Eth | +--+---------------+---------------------------+----------------------+-----+ |12| Hot zone | BS and router in one box | Single Prefix to MSs | Erh | +--+---------------+---------------------------+----------------------+-----+ |13| Cellular-like | Router separation from BS | Unique Prefix to a MS| Eth | +--+---------------+---------------------------+----------------------+-----+ |14| Cellular-like | Router separation from BS | Single Prefix to MSs | Eth | +--+---------------+---------------------------+----------------------+-----+ |15| Cellular-like | BS and router in one box | Unique Prefix to a MS| Eth | +--+---------------+---------------------------+----------------------+-----+ |16| Cellular-like | BS and router in one box | Single Prefix to MSs | Eth | +--+---------------+---------------------------+----------------------+-----+ Figure 3: Scenarios considered for IPv6 adoption to IEEE 802.16 Note that at this phase, we don't address considerations according to all the senarios. These will be intensively discussed later. Shin, et al. Expires August 30, 2006 [Page 10] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 3. Basic IP 3.1. Neighbor Discovery for IPv6 In IEEE 802.16 networks, some Neighbor Discovery [RFC2461] messages can be unnecessary in certain cases, since MS and BS/router links resemble a point-to-point link; hence, the MS's only neighbor is the the BS/router which is already known through the link configuration (e.g., network entry) mechanisms. Also, Neighbor Discovery packets with a multicast destination address (e.g., all-node-multicast, or all-router-multicast addresses) are also transmitted as normal IEEE 802.16 MAC frames, as the same as regular unicast packets. Normal 802.16 MAC headers do not include MAC addresses. Instead, in order to identify connections to equivalent peers in the MAC of the BS/ router and the MS, CID is used. In certain cases, multicast CID may be provided for in the downlink. It can be useful to tranmit efficiently link-local multicast destination packets (e.g, Router Advertisements) from BS/router to MSs. The packet transmission issues are discussed in section 3.2. In some scenarios, the router may be separated from the BS. Two different link connections must be bridged for one network connection between and the MS and the router (e.g., 802.16 link + Ethernet). In case of the scenarios, the operations and issues may be different (i.e., CID mapping and Neighbor Discovery packets transmission). These issues will be discussed later. Note that considerations of Neighbor Discovery in IEEE 802.16 networks are being discussed in an other document [I-D.lee-ndp- ieee802.16]. Neighbor Solicitation and Neighbor Advertisement messages can be classified into three functions; Address Resolution, Neighbor Unreachabilit Detection and Duplcate Address Detection. Also, Router Solicitation and Router Advertisement messages are used for Router and Prefix Discovery. 3.1.1. Address Resolution Neighbor Solicitation and Neighbor Advertisement messages for address resolution delivered between the MS and BS/router are not needed, since MS and BS/router links resemble a point-to-point link; hence, the MS's only neighbor is the BS/router which is already known through the link configuration (e.g., network entry) mechanisms. Actually, Neighbor Cache entries may be unnecessary. Since CID is used for link-layer transmission, CID connection state is maintained, instead of Neighbor Cache entries. The MS uses CID which is provided to each connection by the BS/router. It must ensure the uniqueness Shin, et al. Expires August 30, 2006 [Page 11] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 of such connections on the link. 3.1.2. Neighbor Unreachability Detection In general, Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes. However, this function is used only between MS and BS/router, since the MS's only neighbor is the BS/router. The Neighbor Unreachability Detection portion of IPv6 Neighbor Discovery protocol is not needed, since MS and BS/router don't maintain Neighbor Cache entries. But the MS and BS/router must know their neighbor reachability at the IP layer in certain cases. A BS/ router is considered reachable if the MS has recently received a confirmation that packets sent recently to the neighbor were received by its IP layer. Reachability confirmation can be gathered in two ways: hints from upper layer protocols that indicate a connection is making "forward progress", or from link layer mechanisms that indicate a "link up" in IEEE 802.16 networks. 3.1.3. Duplcate Address Detection Usually, a BS/router may assign a prefix that is unique to a MS. Therefore, this avoids the necessity to perform Duplicate Address Detection. The allocation of a prefix to a MS will alow the MSs to implement the IPv6 stateless address auto-configuration [RFC2462] and privacy extension [RFC3041] without the need for further Duplicate Address Detection. However, if BS/router assigns a single prefix to all of its attached MSs, Duplicate Address Detection must send Neighbor Solicitation messages with an unspecified source address targeting its own tentative address. In order to efficiently perform a multicast Neighbor Advertisement for a response, a BS/router can perform proxy Neighbor Advertisements for one or more other MSs. In certain cases, multicast CID may be used to send the proxy Neighbor Advertisements to the MSs in the downlink. It might be dependent on the scenarios of IPv6 addressing scenarios described in section 2.3. This issus is also discussed in section 3.3. 3.1.4. Router and Prefix Discovery Router Discovery is already performed by link layer configuration mechanisms. As for Prefix Discovery, a BS/router trasmits Router Advertisements that contain Prefix Information to the advertising interface whose corresponding AdvSendAdvertisements flag is TRUE. Shin, et al. Expires August 30, 2006 [Page 12] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 The AdvSendAdvertisements flag must be set when CID is set for a connection. A BS/router must not send Router Advertisements out to any interface that is not an advertising interface. In this case, a multicast CID can be used to to transmit the Router Advertisements to the MSs in the downlink. To obtain Router Advertisements quickly, a MS can send Router Solicitations to its BS/router. In this case, the MS's CID is used to identify the MS. 3.1.5. Redirect Function The Redirect message is not necessary in IEEE 802.16 networks, since the MS's only router is the BS/router and the MS cannot send a packet to other MS without the BS/router. 3.2. Transmission of IPv6 Packets IEEE 802.16 MAC header format is described in [IEEE802.16]. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H|E| Type |R|C|EKS|R|LEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LEN LSB | CID MSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID LSB | HCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IEEE 802.16 MAC header format It is importmant to see that there is no MAC address in IEEE 802.16 the MAC header format. Similar to general point-to-point links, the MAC address is not used for link-layer transmission. Hence, mapping unicast or multicast addresses to IEEE 802.16 MAC addresses is unnecessary. Also, link-local addressess may be not needed for transmission of link-local destination packets. Instead, CID is used to identify connections to equivalent peers in the MAC of the BS and the MS in IEEE 802.16 networks. In some scenarios, the router may be separated from the BS. Two different link connections must be bridged for one network connection between and the MS and the router (e.g., 802.16 link + Ethernet). In these cases, standard Path MTU Disovery may not work well. These issues is being discussed in [I-D.shin-16ng-ipv6-transmission]. Shin, et al. Expires August 30, 2006 [Page 13] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 In certain cases, multicast CID can be provided for in the downlink. It can be useful to transmit efficiently link-local multicast destination packets in the downlink. 3.3. IPv6 Addressing There are two possiblities to allocate an IPv6 prefix in 802.16 networks. The simple method is to assign a unique prefix to a MS. This avoids the necessity to perform Duplicate Address Detection. The second method is to assign a single prefix to all of its attached MSs. In this case, Duplicate Address Detection must be supported. It might be dependent on the scenarios of the IPv6 addressing model. This issus should be intensively researched later, since it will affect the protocol implementation of Duplicate Address Detection. Shin, et al. Expires August 30, 2006 [Page 14] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 4. 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. 4.1. Mobile IPv6 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 rechability and movement detection may be unnecessary becasue IEEE 802.16 MAC provides the reachabilty by the Ranging procedure and the movement detection by the Handoff procedure. 4.2. Mobile IPv6 Fast Handovers In addition, IEEE 802.16 defines L2 triggers whether refresh of a IP address is required during the handoff. 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. Also, IEEE 802.16g which is under-developed defines L2 triggers for link status auch as link-up, link-down, handoff-start. These L2 triggers may make the mobile IPv6 procedure more efficient and faster. In addition, 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. This issue is also being dicussed in [I-D.jang-mipshop-fh80216e]. Shin, et al. Expires August 30, 2006 [Page 15] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 5. Multicast In order to support multicast services in IEEE 802.16, Multicast Listener Discovery [RFC2710] must be supported between the MS and BS/ router. Also, interworking with IP multicast protocols and MBS should be considered. 5.1. Multicast Listener Discovery Within IEEE 802.16 networks, a MS connects to its BS/router via point-to-point links. Multicast Listener Discovery sends 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 Multicast Listener Discovery reports for link-local addresses in IEEE 802.16 network environment may not always be necessary. Multicast Listener Discovery is needed for multicast group knowledge that is not link- local. 5.2. Interworking with IP Multicast and MBS MBS defines Multicast and Broadcast Services, but actually, MBS seems to be a broadcast service, not multicasting. MBS adheres to broadcast services, while taditional 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 multicast and broadcast services (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. It should be intensively researched later, since MBS will be one of the killer services in IEEE 802.16 networks. Shin, et al. Expires August 30, 2006 [Page 16] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 6. Security 6.1. IPsec 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. 6.2. Security Threat Analysis IEEE 802.16 network threats may be different with IPv6 and IPv6 transition threat models [I-D.ietf-v6ops-security-overview]. It will be discussed later. Shin, et al. Expires August 30, 2006 [Page 17] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 7. Multiple Interfaces with Different Properties If a MS has additional interfaces on which IP is used (such as Ethernet, WLAN), then there may be additional problems for the device. Some of these problems are : Protocol inconsitancy problems with the same fuctionalities: If an MS has additional interfaces on which IP is used, we need to figure out any protocol inconsitancy if there are protocol issues (modification) in IEEE 802.16 networks. Two or more different versions of protocols (e.g., NDP) may be required within the TCP/IP stack on the same MS. Roaming/movement problems between heterogenous networks: will be discussed later. MS multi-homing problems: will be discussed later. Shin, et al. Expires August 30, 2006 [Page 18] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 8. Security Considerations As for security, it is briefly discussed in section 6. Shin, et al. Expires August 30, 2006 [Page 19] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [I-D.ietf-mipshop-fast-mipv6] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. 9.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.jang-mipshop-fh80216e] Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", draft-jang-mipshop-fh80216e-01 (work in progress), December 2005. [I-D.ietf-v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-03 Shin, et al. Expires August 30, 2006 [Page 20] Internet-Draft IPv6 in IEEE 802.16 Networks February 2006 (work in progress), October 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.lee-ndp-ieee802.16] Lee, J., "Considerations of NDP over IEEE 802.16 Networks", draft-lee-ndp-ieee802.16-00 (work in progress), October 2005. [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 802.16e/D10 Draft, IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", August 2005. Shin, et al. Expires August 30, 2006 [Page 21] Internet-Draft IPv6 in IEEE 802.16 Networks February 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 Jung-Mo Moon ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 6748 Email: jmmoon@etri.re.kr Youn-Hee Han Samsung AIT P.O. Box 111 Suwon 440-600 Korea Email: yh21.han@gmail.com Shin, et al. Expires August 30, 2006 [Page 22] Internet-Draft IPv6 in IEEE 802.16 Networks February 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, et al. Expires August 30, 2006 [Page 23]