Network Working Group H. Jeon Internet-Draft S. Jeong Intended status: Standards Track ETRI Expires: March 5, 2007 M. Riegel Siemens Sep 2006 Transmission of IPv6 packets over Ethernet CS over IEEE 802.16 network draft-jeon-ipv6-over-ieee802.16-ethcs-00.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 March 5, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes transmission of IPv6 packets over Ethernet CS over IEEE 802.16 network. In this document, two possible network deployment scenarios are discussed and behaviors for corresponding scenario are suggested in order to support IPv6 transmission over Ethernet CS over IEEE 802.16 network. Jeon, et al. Expires March 5, 2007 [Page 1] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Assumption . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. IEEE 802.16 Network Model on IPv6 over Ethernet CS . . . . . . 4 6. Transmission on IPv6 over Ethernet CS . . . . . . . . . . . . 6 6.1. On-Link Issue . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 8 7. IPv6 NDP Operations on IPv6 over Ethernet CS . . . . . . . . . 8 7.1. Identification Cache Table . . . . . . . . . . . . . . . . 8 7.2. Router Discovery, Prefix Discovery and Parameter Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 7.3. Address Resolution . . . . . . . . . . . . . . . . . . . . 9 7.4. Duplicate Address Detection . . . . . . . . . . . . . . . 9 7.5. IPv6 NDP Multicast Transmission . . . . . . . . . . . . . 10 7.5.1. Solicited-node Multicast Transmission using Replicated Unicast . . . . . . . . . . . . . . . . . . 10 7.5.2. All-node Multicast Transmission using Common CID . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Jeon, et al. Expires March 5, 2007 [Page 2] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 1. Introduction TBD 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]. Base Station (BS): A generalized equipment set providing connectivity, management, and control of the subscriber station. Subscriber Station (SS): A generalized equipment set providing connectivity between subscriber equipment and a base station. Service-specific Convergence Sublayer (CS): 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. Connection Identifier (CID): A 16 bit value that identifies a connection to equivalent peers in the MAC of the base station and subscriber station. Source SS: SS which initiates IPv6 NDP message. Target SS: SS which is identified with target field in IPv6 NDP message. Source BS: BS where Source SS is located. Target BS: BS where Target SS is located. Dynamic Service Addition (DSA): The set of messages and protocols that allow the base station and subscriber station to add the characteristics of a service flow. Jeon, et al. Expires March 5, 2007 [Page 3] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 Multicast and Broadcast Services: Globally defined service flow that carries broadcast or multicast information towards a plurality of SS. Multicast and Broadcast Services Connection ID (MBS-CID): Traffic CID for MBS. Common Connection Identifier (CCID): CID shared by all SSs and BS for the purpose of transmitting IPv6 Neighbor Discovery messages with all-node multicast address. 4. Assumption This document supposes following assumption. o All SSs attached to same AR share one or multiple prefixes so that multiple BSs and SSs form an IPv6 subnet. All MSs attached to different BSs under the same AR, can be on same IPv6 link o IEEE 802.16 BS supports local realy function. In general, MAC Bridge does not relay incoming packet to its incoming port again. Hence, IPv6 Neighbor Discovery messages cannot be transmitted to other SSs served by same BS without local relay function. This document supposes IEEE 802.16 BS relays the IPv6 Neighbor Discovery messages before delivering them to MAC Bridge. 5. IEEE 802.16 Network Model on IPv6 over Ethernet CS IEEE 802.16 access technology is different from existing wireless access technologies such as IEEE 802.11 or 3G, because IEEE 802.16 only defines the encapsulation of an IP packet into an IEEE 802.16 MAC payload without a complete description of IPv6 operation. Also, the existence of various Convergence Sublayers (CS) introduces various IEEE 802.16 based network deployment architecture. This document discusses possible deployment scenarios in case of VLAN CS as well as Ethernet CS. Figure 1 shows IEEE 802.16 network deployment scenario with direct host-to-host communication. In this scenario, a BS is separated from an access router, there exist multiple access routers in a link, and a subnet consists of multiple BSs and SSs. In addition to that, there may exist a network behind SS/Gateway, i.e. Wireless DSL equipment. The network behind SS/Gateway can support various access network technologies such as 802.11, Ethernet, and so on. Jeon, et al. Expires March 5, 2007 [Page 4] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 Ethernet links BSs to ARs and they are connected via Ethrenet Swithch. In this scenario, SS and BS utilize VLAN CS as well Ethernet CS and VLANs comprise SSs attached to several BSs. When the VLANs are deployed, direct host-to-host communication is available. Thus, IP features such as multi-homing and native multicasting can be easily supported. +-----+ +---+ +----+ +-----+ ISP 1 | SS1 |-+ | | +---|AR1 |---| ER1 |===>Net +-----+ | | S| | +----+ +-----+ +-----+ | +-----+ |E w| | | SS2 |-+--| BS1 |--|t i| | +-----+ +-----+ |h t|--+ | c| | +----+ +-----+ ISP 2 +-----+ +-----+ +-----+ | h| +---|AR2 |---| ER2 |===>Net |Hosts|--|SS/GW|----| BS2 |--| | +----+ +-----+ +-----+ +-----+ +-----+ +---+ This network may exist behind SS/GW Figure 1. IEEE 802.16 Network Model on IPv6 over Ethernet CS (with direct host-to-host communication) Figure 2 shows the case attaching SSs over Ethernet CS without direct host-to-host communication. In general public access case, direct communication between hosts is restricted because of security issue, such as attacks by malicious users. In this case, connections from SS are extended from the BS to the AR. The extension can be achieved by using GRE tunnel with CID granularity. Jeon, et al. Expires March 5, 2007 [Page 5] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 +-----+ | SS1 |-----+ +-----+ | | | +-----+ | +-----+ +---+ +----+ ISP | SS2 |-----+-----| BS1 |----------|AR |---| ER |===>Net +-----+ | +-----+ +---+ +----+ | ____________ | ()__________() +-----+ +-----+ | GRE Tunnel |Hosts|--|SS/GW |----+ +-----+ +-----+ Figure 2. IEEE 802.16 Network Model on IPv6 over Ethernet CS (without direct host-to-host communication) 6. Transmission on IPv6 over Ethernet CS 6.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. According to [I-D.ietf-ipv6-2461bis], IP node performs a longest prefix match against the prefix list in order to decide whether the destination of the IP packet is on-link or not. Therefore, SSs sharing a prefix can be said to on-link IP nodes. Section 5 says that direct communication among SSs is depending on the type of IEEE 802.16 network model scenario. Above the second scenario does not support direct communication between SSs and it results in the problem of locating SSs on-link in terms of IP packet transfer. By the way, VLAN in the first scenario allows each SSs to communicate each other directly. Therefore, all IPv6 NDP messages can be exchanged between SSs and there is no On-Link issue. This document considers behaviors in the first scenario. First scenario will be handled in next version of document. 6.2. Frame Format [IEEE802.16e] defines several CSs for carrying upper layer data. Currently, IP CS and Ethernet CS is defined to transport packet-based protocols. IPv6 packets can be transmitted in IEEE 802.16 Generic Jeon, et al. Expires March 5, 2007 [Page 6] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 MAC frames with Ethernet CS as shown in Figure 2. When Ethernet CS is used, Ethernet header MUST be included in the payload of IEEE 802.16 MAC frame. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H|E| Type |S|C|EKS|R|LEN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LEN LSB | CID MSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID LSB | HCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet | +- -+ / header / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | +- -+ | header | +- -+ | and | +- -+ / payload ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. IEEE 802.16 Frame Format for IPv6 over Ethernet CS o H: Header Type. Shall be set to zero for Generic MAC header o E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload is encrypted. o Type: This field indicates the subheaders and special payload types present in the message payload o S: Extended Subheader Field (ESF). If ESF = 1, the extended subheader is present. If ESF = 1, no extended subheader is included o C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included o R: Reserved. Shall be set to zero. o EKS: Encryption Key Sequence o LEN: Length o CID: Connection Identifier Jeon, et al. Expires March 5, 2007 [Page 7] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 o HCS: Header Check Sequence o CRC: An optional 4 octets field (refer to Section 6.3.3.5 in [IEEE 802.16]. CRC appended to the PDU after encryption. 6.3. Maximum Transmission Unit Since IEEE 802.16 provides link layer fragmentation and reassembly function, the MTU for IEEE 802.16 link is not specified in [IEEE802.16]. However, in the Ethernet CS deployment model, BSs and ARs may be connected via Ethernet. Therefore, a value of 1500 octets is recommended for the MTU of the IPv6 packets in order to keep compatibility with Ethernet. Note that the value does not consider where stacked VLANs are tranferred over the air and GRE tunnel is established between BS and AR. Deployment scenario considering above situation should consider additional sizes by VLAN header and GRE header. 7. IPv6 NDP Operations on IPv6 over Ethernet CS 7.1. Identification Cache Table BS maintains Identification Cache Table (ICT), which includes information on SSs covered by the BS. The ICT contains MAC address, IPv6 address of SS, and DAD flag. If DAD flag is set, the ICT should include tentative target address in DAD Neighbor Solicitation (NS). The ICT should be preferable co-located with the bridging table. The ICT is constructed by following operations. o BS can learn L2 address of SS during the initial ranging procedure of IEEE 802.16 specified in Section 6.3.1.1 in [IEEE 802.16]. (Note that this approach may be not sufficient if there are multiple hosts connected behind a MAC bridge on SS. We need a reliable mechanism also to learn MAC addreesses behind the SS.) o BS can learn L3 address of SS with Target field in DAD NS which is not responded with DAD NA. (NOTE: it seems unreliable. We have to look for another method, not using DAD NS/NA) 7.2. Router Discovery, Prefix Discovery and Parameter Discovery Router Discovery, Prefix Discovery and Parameter Discovery procedures are achieved by receiving Router Advertisement (RA) message. The RA is advertised by using all-node multicast transmission. If IEEE 802.16 does not support IPv6 multicast transmission, the multicast transmission should be emulated with the way described in Section Jeon, et al. Expires March 5, 2007 [Page 8] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 7.5.2. Considering the power consumption on SS, we recommend that AR should just unicast the RA in response with RS without using all-node multicast transmission. It can prevent SS from frequently being woken in idle mode. There can be drawbacks caused by the non-periodic RA messages. We will consider the drawbacks in next version of doucment. 7.3. Address Resolution When Source SS sends NS for Address Resolution, MAC bridge function on Source BS relays the NS toward backbone Ethernet link. Each BSs attached the backbone receive the NS and identify Target BS for the NS by referring its own ICT. Other BSs, not Target BS, ignore the NS. If network approves the proxy function for NDP, Target BS refers the ICT and responds to the NS instead of Target SS. Otherwise, Target BS relays the NS message toward its own air using replicated unicast mechanism specified in Section 7.5.1. Target SS responds to the NS. 7.4. Duplicate Address Detection When Source BS receive DAD NS from Source SS, the Source BS set DAD flag in ICT to non-zero and store tentative address in Target Address field in DAD NS so that it can identify who sends the DAD NS. MAC bridge on Source BS relays the DAD NS toward backbone Ethernet link. Each BSs attached the backbone receive the DAD NS and identify Target BS for the DAD NS by referring its own ICT. Other BSs, not Target BS, ignore the DAD NS. If network approves the proxy function for NDP, Target BS refers the ICT to see whether the tentative target address in the DAD NS exists in its own ICT table. If it exists, Target BS responds with DAD NA. Otherwise, discard the DAD NS message silently. If the proxy function is not available, Target BS relays the DAD NS message toward its own air using replicated unicast mechanism specified in Section 7.5.1. If the tentative target address is in use, Target SS responds with DAD NA. Otherwise, the DAD NS message is ignored. When each BSs receive the DAD NA message, the BSs refer to DAD flag and tentative target address in ICT table to see whether Source SS is Jeon, et al. Expires March 5, 2007 [Page 9] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 located in its serving area. If existing, the BS sends the DAD NA using Common CID specified in Section 7.5.2. 7.5. IPv6 NDP Multicast Transmission IPv6 Neighbor Discovery messages except Redirect are destined to link-local scoped multicast address such as all-router multicast address, all-node multicast address, and solicited-node multicast address. Since IEEE 802.16 specification does not provide dedicated CIDs for IPv6 multicast packet transmission, any available traffic CID value needs to be allocated for multicasting IPv6 packet. Following subsections describe how to transmit the packets with link- local scoped multicast address into IEEE 802.16 network according to different type of link-local scoped multicast address. 7.5.1. Solicited-node Multicast Transmission using Replicated Unicast In the wireless environment, it is important to avoid all-node multicast transmission in order to prevent unrelated SSs from frequently being woken from idle mode. Solicited-node multicast address is not for all nodes and can be seen a pseudo-unicast. Hence, we can leave the above situation out of consideration when using solicited-node multicasting. Replicated Unicast is to deliver IPv6 Neighbor Discovery messages by repeated unicast transmissions towards SSs involved in the multicast address of the IPv6 Neighbor Discovery message. 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. (Note that we need further consideration to obtaining MAC addresses of multiple hosts behind a SS.) Jeon, et al. Expires March 5, 2007 [Page 10] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 7.5.2. All-node Multicast Transmission using Common CID This section defines Common CID (CCID) for transmitting all-node 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. 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 all-node 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 all-node 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 with all-node multicast address towards all SSs via the CCID. 8. Security Considerations 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. 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. Jeon, et al. Expires March 5, 2007 [Page 11] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 9.2. Informative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-07 (work in progress), May 2006. [I-D.ietf-v6ops-802-16-deployment-scenarios] Shin, M. and Y. Han, "ISP IPv6 Deployment Scenarios in Wireless Broadband Access Networks", draft-ietf-v6ops-802-16-deployment-scenarios-00 (work in progress), May 2006. [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. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Jeon, et al. Expires March 5, 2007 [Page 12] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 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 Sangjin Jeong Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-1877 Email: sjjeong@gmail.com Max Riegel Siemens St-Martin-Str 76 Munich, 81541 Germany Phone: +49-89-636-75194 Email: maximilian.riegel@siemens.com Jeon, et al. Expires March 5, 2007 [Page 13] Internet-Draft IPv6 over IEEE 802.16 Ethernet CS Sep 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jeon, et al. Expires March 5, 2007 [Page 14]