Network Working Group H. Jeon Internet-Draft J. Jee Expires: September 7, 2006 ETRI March 6, 2006 IPv6 NDP for Common Prefix Allocation in IEEE 802.16 draft-jeon-ipv6-ndp-ieee802.16-01.txt 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract IPv6 Neighbor Discovery Protocol [RFC 2461] assumes that the underlying link layer support native multicast while IEEE 802.16 is a point-to-multipoint network without bi-directional native multicast support. Such a discordance between IPv6 Neighbor Discovery Protocol and IEEE 802.16 network results in the on-link and multicast issues. This document defines a mechanism, IPv6 NDP Relay and Multicast Emulation, to solve these issues. Jeon & Jee Expires September 7, 2006 [Page 1] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 Neighbor Discovery Issues over IEEE 802.16 . . . . . . . 5 4.1. On-Link Issue . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Multicast Issue . . . . . . . . . . . . . . . . . . . . . 5 4.3. IEEE 802.16 Convergence Sublayer . . . . . . . . . . . . . 5 5. IPv6 Neighbor Discovery Support over IEEE 802.16 . . . . . . . 6 5.1. IP Convergence Sublayer . . . . . . . . . . . . . . . . . 6 5.1.1. IPv6 NDP Relay . . . . . . . . . . . . . . . . . . . . 6 5.1.2. Multicast Emulation . . . . . . . . . . . . . . . . . 7 5.2. Ethernet Convergence Sublayer . . . . . . . . . . . . . . 9 5.2.1. IPv6 NDP Relay . . . . . . . . . . . . . . . . . . . . 9 5.2.2. Multicast Emulation . . . . . . . . . . . . . . . . . 10 6. Consideration for alternative approaches . . . . . . . . . . . 10 6.1. Proxy Neighbor Advertisements . . . . . . . . . . . . . . 10 6.2. Proxy DAD . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Jeon & Jee Expires September 7, 2006 [Page 2] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 1. Introduction IEEE 802.16 [IEEE 802.16][IEEE 802.16e] is a connection-oriented broadband wireless access(BWA) technology. Down-stream in IEEE 802.16 is a point-to-multipoint connection and thus it is possible to broadcast messages toward SS (Subscriber Station) from BS (Base Station). However, up-stream is connected as point-to-point type. Therefore, SS is not capable of multicasting as well broadcasting. IPv6 Neighbor Discovery Protocol (IPv6 NDP) [RFC 2461] aims to solve problems due to the interaction between nodes attached on the same link. It is designed without dependence on a specific link layer technology, but assumes that the link layer technology support a native multicasting. As mentioned above, IEEE 802.16 supports multicast and broadcast in down-stream. However, the original aim of the multicast and broadcast is to transmit IEEE 802.16 MAC management messages for bandwidth allocation, not IP data. Thus, IPv6 Neighbor Discovery message on IEEE 802.16 cannot be delivered to neighboring hosts by means of multicast. IPv6 NDP messages have link-local scoped address as IP destination address. It means those messages have to be delivered toward on-link any hosts. However, when all SSs under same BS are configured with common IPv6 network prefix, IEEE 802.16 disagrees with IPv6 Neighbor Discovery on the definition of on-link host. This is because IPv6 NDP determines the on-link host with assigned prefixs while up-stream in IEEE 802.16 is a point-to-point connection. IEEE 802.16 does not allow direct communication among SSs even though each SS knows that other SSs are neighboring ones at the IP level. Eventually, this discrepancy results in limitation of transmission coverage of IPv6 NDP messages with link-local scoped address. Following the 3GPP model for IPv6 NDP [RFC 3314], Access Router (AR) may assign distinct subnet to each SSs. In the case, IPv6 NDP can be deployed without any modification and some operations in IPv6 NDP such as Address Resolution and Neighbor Unreachability Detection may be unnecessary. However, such a unique prefix allocation disallows network renumbering with prefix and cannot simplify network management. IPv6 over NBMA networks [RFC 2491] presents a general architecture for IPv6 over Non-Broadcast Multiple Access (NBMA) network. Specifically, [RFC 2491] focuses on an NBMA network with SVC mode which utilizes dynamically managed point to point and point to multipoint call between both communication hosts. On the other hand, IEEE 802.16 is employed as access network technology in most cases and thus does not provide communication between end hosts. Therefore, IEEE 802.16 cannot be referred to as NBMA network stated Jeon & Jee Expires September 7, 2006 [Page 3] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 in [RFC 2491]. This document presents a mechanism which can allocate a common network prefix to all SS under the same IPv6 link. Through the mechanism, the standard IPv6 NDP can be applied to IEEE 802.16 networks without modifying conventional host-side operation. 2. Requirements 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]. 3. Terminology Description of following some terms is taken directly from [IEEE 802.16] and [IEEE 802.16e]. BS (Base Station) : A generalized equipment set providing connectivity, management, and control of the subscriber station. SS (Subscriber Station) : A generalized equipment set providing connectivity between subscriber equipment and a base station. CS (Service-specific Convergence Sublayer) : Sublayer in IEEE 802.16 MAC layer which classifier external network data and associates them to the proper MAC service flow identifier and connection identifier. CID (Connection Identifier) : A 16 bit value that identifies a connection to equivalent peers in the MAC of the base station and subscriber station. DSA (Dynamic Service Addition) : The set of messages and protocols that allow the base station and subscriber station to add the characteristics of a service flow. MBS (Multicast and Broadcast Services) : Globally defined service flow that carries broadcast or multicast information towards a plurality of SS. MBS-CID (Multicast and Broadcast Services Connection ID) : Traffic CID for MBS. CCID (Common Connection Identifier) : CID shared by all SSs and BS for the purpose of transmitting IPv6 Neighbor Discovery messages. Jeon & Jee Expires September 7, 2006 [Page 4] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 4. IPv6 Neighbor Discovery Issues over IEEE 802.16 This section summarizes issues when IPv6 Neighbor Discovery is employed over IEEE 802.16 under the condition all SSs are assigned with common prefix address. 4.1. On-Link Issue The assignment of a common prefix to all SSs under a specific AR means locating them "on-link" in terms of IP packet transfer. From [I-D.ietf-ipv6-2461bis], IP node determines destinations are on-link by performing a longest prefix match against the prefix list. Therefore, SSs sharing common prefix can be said to on-link IP nodes. IPv6 NDP is a protocol to solve problems due to the interaction between on-link nodes and requires direct communication between them. By the way, IEEE 802.16 is a connection-oriented network. Even though all data in IEEE 802.16 can be broadcasted to air shared to all SSs, only SS associated with the CID included in the data can receive the data. The connection of IEEE 802.16 always ends at the BS. There is no support from 802.16 MAC/PHY for the direct communication among SSs [I-D.jee-16ng-ps-goals] which results in the problem of locating SSs on-link in terms of IP packet transfer. 4.2. Multicast Issue IPv6 Neighbor Discovery messages excepting Redirect are destined for link-local scoped multicast address such as all-router multicast address, all-node multicast address, and solicited-node multicast address. However, there is no dedicated CIDs for multicasting IPv6 packet in IEEE 802.16. Thus, any available traffic CID value needs to be allocated for multicasting IPv6 packet. 4.3. IEEE 802.16 Convergence Sublayer IEEE 802.16 defines two types of Convergence Sublayer (CS), IP CS and Ethernet CS. When IP CS is applied, BS and AR may need to be tightly coupled by physically or logically by tunneling mechanism like GRE Tunneling (Figure 1 and 2). Therefore, IP packets which are destined for on- link IP nodes needs to be first transfered toward AR. Special consideration is required on the AR in treating IPv6 NDP messages which have different destination forms like link-local unicast, link- local all-nodes multicast, link-local all-routers multicast and Jeon & Jee Expires September 7, 2006 [Page 5] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 solicited node multicast address. +------+ | AR | +-------+ +------+ | AR/BS | // || \\ +-------+ // || \\ <= tunnel // || \\ BS1 BS2 BS3 Figure 1 Figure 2 In case of Ethernet CS, IEEE 802.16 deployment architecture can be configured as shown in Figure 3. Assuming Ethernet link between BS and AR, we can consider similar bridging function on BS to one on WLAN access point. Additional bridging function on BS is to interpret the Ethernet header of packets received from SS and transmit the packets toward expected next node. In Figure 3, such an next node can be another BS, another SS, or AR. +-----+ | AR | +--+--+ | -----+----- / / | \ \ / | | | \ BS1 BS2 BS3 BS4 BS5 Figure 3 5. IPv6 Neighbor Discovery Support over IEEE 802.16 Following subsections provide a mechanism to handle the mentioned respective issues. The mechanism may require explicit cooperation with IEEE 802.16 technology or enhanced bridge function on BS. The mechanism will be described by case of CS type. 5.1. IP Convergence Sublayer 5.1.1. IPv6 NDP Relay By aforementioned "On-Link" issue, IEEE 802.16 does not support Jeon & Jee Expires September 7, 2006 [Page 6] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 direct communication between on-link SSs. Moreover, AR in IP CS case is always a next-hop neighbor even when SS sends data to on-link SSs and thus all data have to be sent to AR as mentioned in the section 4.3. As a result, the AR discards IPv6 NDP messages addressed link- local all-node multicast and solicited node multicast address because the messages do not intend for the AR. Therefore, it is necessary to relay the restricted messages. Multicast Relaying Part (MRP) serves as packets relayer and is located in AR. MRP over AR intercepts packets destined for the multicast addresses and then prepares packet relaying while passing those to upper layer. Intercepting rule of MRP is different according to the case when IEEE 802.16 CS supports IPv6 over Ethernet or native IPv6. In case of IP CS, MRP holds packets, which begin with FF02 in IPv6 address. Note that the MRP does not intercept packets addressed FF02::2. This is due to the assumption the AR serves as default router and there is no other router in the subnet. Table 1 shows IP multicast address types used in IPv6 NDP. +--------------------------------+--------------------------+ | Type | IP Address Type | +--------------------------------+--------------------------+ | Link-local all-nodes | FF02::1 | | multicast address | | +--------------------------------+--------------------------+ | Link-local all-routers | FF02::2 | | multicast address | | +--------------------------------+--------------------------+ | Solicited-node | FF02::1:FFxx:x | | multicast address | | +--------------------------------+--------------------------+ xx:x is last 24 bits of a unicast IPv6 address. Table 1 When BS and AR are coupled as shown in Figure 1, AR should forward unicast packets destined for on-link host. In the case, the packets must be transmitted again via the incoming interface and AR has to transmit Redirect message to sender whenever communication between on-link SSs occurs. This problem can be issue in implementation of AR and MRP can treat the problem. 5.1.2. Multicast Emulation This section describes how to transmit the packets with link-local scoped multicast address into IEEE 802.16 network. We suggest Jeon & Jee Expires September 7, 2006 [Page 7] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 following two different approaches for the purpose of multicast emulation. 5.1.2.1. Multicast Emulation using Common CID IEEE 802.16 enables multicast transmission in down-stream. However, it is difficult to create and maintain CIDs for multicast because there can be manifold multicast sessions. Therefore, this document defines Common CID (CCID) for transmitting multicast data. There is one unique CCID in BS and it is shared by all SSs served by the BS. All SSs can receive data transmitted via the CCID and IPv6 module in SSs see whether the multicast data are destined to themselves or not. Current IEEE 802.16 does not specify CID which can be shared by all SSs and used for IP data. Following describes how to make CCID with existing MBS-CID. [IEEE 802.16e] proposes Multicast and Broadcast Service (MBS), which presents media service to SSs using multicast or broadcast. Under MBS architecture, each SS selects MBS contents and then configures a corresponding CID by the DSA procedure. Such a CID for MBS is referred to as MBS-CID. MBS-CID is one of transport CIDs and is shared by all SSs requesting same media content. CCID can be seen as a special type of MBS-CID. CCID is allocated to BS and all SSs served by the BS utilizing a general DSA procedure in MBS for transmitting link-local multicast data. For the assigning the CCID, we assume that service flow for link-local multicast is globally defined and the service flow is known to BS and all SSs. Once initialization between BS and SS is completed, they perform DSA procedure for creating the link-local multicast service flow. The detailed process creating new service flow and updating CS for mapping of the service flow to CCID is outside scope of this document. BS transmits IPv6 Neighbor Discovery messages relayed by MRP towards all SSs via the CCID. 5.1.2.2. Multicast Emulation using Replicated Unicast The transmission using CCID allows IPv6 Neighbor Discovery messages to be delivered only once per transmission. However, it requires a new CID for multicast. This section shows how to transmit IPv6 Neighbor Discovery messages with existing unicast CID. IPv6 Neighbor Discovery message can be delivered by repeated unicast Jeon & Jee Expires September 7, 2006 [Page 8] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 transmissions towards SSs involved in the multicast address of the IPv6 Neighbor Discovery message. IPv6 Neighbor Discovery messages with link-local all node multicast address should be sent to all SSs and thus they can be transmitted by replicated unicasts via all established CIDs on BS. In this context, IPv6 Neighbor Discovery messages with solicited-node multicast address should be transmitted by replicated unicasts via CIDs of corresponding SSs. Thus, it is required to identify CIDs for solicited-node multicast addresses. Section 6.3.1.1 in [IEEE 802.16] states that a 48-bit universal MAC address of SS is used during the initial ranging process to identify connections to SS. Solicited-node multicast address of SS can be derived by the MAC address. As a result, BS can be aware of the solicited-node multicast addresses with the known MAC address of each SS and match the derived addresses with each CIDs. 5.2. Ethernet Convergence Sublayer 5.2.1. IPv6 NDP Relay In Ethernet CS type, MRP is located in BS. The MRP on BS intercepts packets destined for the multicast addresses from Ethernet CS. The intercepted packets are relayed again toward other SSs served by the same BS while being passed to a bridge operation on the BS. The MRP intercepts packets, which begin with "33-33" in Ethernet address excepting packets addressed routers ("33-33-00-00-00-02"). Table 2 shows Ethernet address corresponding to the multicast address types used in IPv6 NDP. Jeon & Jee Expires September 7, 2006 [Page 9] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 +--------------------------------+--------------------------+ | Type | Ethernet Addr. Type | +--------------------------------+--------------------------+ | Link-local all-nodes | 33-33-00-00-00-01 | | multicast address | | +--------------------------------+--------------------------+ | Link-local all-routers | 33-33-00-00-00-02 | | multicast address | | +--------------------------------+--------------------------+ | Solicited-node | 33-33-FF-xx-xx-xx | | multicast address | | +--------------------------------+--------------------------+ xx-xx-xx is last 24 bits of a unicast IPv6 address. Table 2 5.2.2. Multicast Emulation Same as IP CS case. 6. Consideration for alternative approaches There are a few ways to solve the IP "On-Link" issues over IEEE 802.16 network without depending on the Multicast Relaying Part (MRP) proposed in this I-D. 6.1. Proxy Neighbor Advertisements Through proxy neighbor advertisement, an AR in 802.16 network can accept NS packets on behalf of SS. However, as noted from [I-D.ietf- ipv6-2461bis], this mechanism is not intended as a general mechanism to handle IP nodes, thus it needs more investigation in moving forward based on this scheme. 6.2. Proxy DAD Proxy DAD can be implemented to AR or BS to guarantee the uniqueness of autoconfigured address which is based on the 48-bit MAC address. However, as noted from [RFC 3314], this proxy DAD function would increase the complexity and the amount of state to be kept in the AR. Also, the AR would need to determine when the temporary addresses are no longer in use, which would be difficult. 7. Security Considerations Jeon & Jee Expires September 7, 2006 [Page 10] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 IEEE 802.16e architecture supports a number of mandatory authorization mechanisms such as EAP-TTLS, EAP-SIM and EAP-AKA. [RFC 3971] specifies security mechanisms for NDP and defines securing NDP messages. Basically, our approach of using "MRP" enables SSs to exchange IPv6 NDP messages directly without depending on any proxy function at the AR or BS. Therefore, it has advantage in securing NDP messages by the mechanism specified from [RFC 3971]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-05 (work in progress), October 2005. [I-D.jee-16ng-ps-goals] Jee, J., "IP over 802.16 Problem Statements and Goals", draft-jee-16ng-ps-goals-00 (work in progress), February 2006. [IEEE802.16] IEEE Std 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 P802.16e/D10, "Draft IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", Auguest 2005. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Jeon & Jee Expires September 7, 2006 [Page 11] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Jeon & Jee Expires September 7, 2006 [Page 12] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 2006 Authors' Addresses Hongseok Jeon Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-3892 Email: jeonhs@etri.re.kr Junghoon Jee Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-5126 Email: jhjee@etri.re.kr Jeon & Jee Expires September 7, 2006 [Page 13] Internet-Draft IPv6 NDP for CPA in IEEE 802.16 March 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. Jeon & Jee Expires September 7, 2006 [Page 14]