V6ops S. Kim Internet-Draft S. Park Expires: December 3, 2005 S. Kim H. Kim KT June 2005 Problem Statement in IPv6 over WiBro draft-kim-v6ops-ipv6overwibro-issues-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 December 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document proposes two issues both in WiBro and in IEEE 802.16 environment. Firstly, it describes needs to define payload header suppression (PHS) rules for IPv6 packets. Secondly, it accounts for the need to discuss IPv6 address auto-configuration. Kim, et al. Expires December 3, 2005 [Page 1] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 3. PHS rules for IPv6 packets . . . . . . . . . . . . . . . . . . 4 3.1 PHS in the IEEE 802.16 . . . . . . . . . . . . . . . . . . 4 3.2 Header considerations . . . . . . . . . . . . . . . . . . 4 3.3 v6ops considerations . . . . . . . . . . . . . . . . . . . 5 4. IPv6 address Auto-Configuration over IEEE 802.16 . . . . . . . 6 4.1 Modes affecting IPv6 multicast . . . . . . . . . . . . . . 6 4.2 v6op Considerations . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Kim, et al. Expires December 3, 2005 [Page 2] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 1. Introduction WiBro is deeply related with IEEE 802.16 specification. Some parts of WiBro technology are developed by Korea. The other parts comply with IEEE 802.16 specification. This document deals with two issues. One is about payload header suppression (PHS). In WiBro, downlink and uplink bandwidth is approximately 18Mbps and 6Mbps respectively. Limited bandwidth is one of the problems for quality in the IEEE 802.16 wireless network both fixed and mobile environment. In most cases, bandwidth for a user could be not enough because many subscriber stations (SS) share the bandwidth. Therefore using wireless bandwidth efficiently is important. One of the ways to increase radio bandwidth is reducing size of media access control (MAC) frames. The PHS is one of the methods that can achieve such goal effectively. The PHS is defined in the IEEE 802.16 specification. This document focuses on PHS rules for IPv6. For now, IPv6 PHS rules have not been specified. This draft would like to describe the needs for setting PHS rules to clarify the reason why v6ops should do it. The other issue is how to transmit IP multicast when a SS performs IPv6 address auto-configuration in 802.16 wireless environments. RFC 3041 about auto-configuration is made for fixed IPv6 networks. However, it is not applied in 802.16 wireless environments. Unlike fixed network such as IEEE 802.3 and 802.16, wireless networks have downsides such as limited bandwidth, expose to hacking and packet loss. This document proposes that v6ops working group needs to consider ways to transmit IP multicast from SS to base station (BS). 2. Terms and Abbreviations Base station (BS): A generalized equipment sets providing connectivity, management, and control of the subscriber station (SS). Subscriber station (SS): A generalized equipment set providing connectivity between subscriber equipment and a base station (BS) Convergence Sublayer(CS): The packet CS resides on top of the IEEE Std 802.16 MAC CPS. Common Part Sublayer(CPS): The MAC CPS provides the core MAC functionality of system access, bandwidth allocation, connection establishment, and connection maintenance. It receives data from the Kim, et al. Expires December 3, 2005 [Page 3] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 various CSs, through the MAC SAP, classified to particular MAC connections. Classifier: a set of matching criteria applied to each packet entering the IEEE Std 802.16 network. It consists of some protocol- specific packet matching criteria (destination IP address, for example), a classifier priority, and a reference to a CID. If a packet matches the specified packet matching criteria, it is then delivered to the SAP for delivery on the connection defined by the CID. Payload header suppression index (PHSI): An 8-bit mask that indicates which bytes in the Payload Header Suppression Field (PHSF) to suppress and which bytes not to be suppressed 3. PHS rules for IPv6 packets 3.1 PHS in the IEEE 802.16 While PHS rules can be applied in various cases such as IPv4, IPv6, etc., this draft focuses on setting PHS rules for IPv6 packets. The IEEE 802.16 physical and MAC layer can transmit IPv6 packets from/to BS to/from SS. Convergence Sublayer (CS), positioned in 802.16e MAC layer, assembles or dissembles incoming/outgoing IPv6 packets. Then, the classifier in CS extracts information for transmission from IPv6 packet header and transforms incoming IPv6 packets into MAC protocol data unit (PDU) that can be processed in the IEEE 802.16 MAC CPS. The classifier in CS performs PHS for IPv6 during the transformation. The PHS for IPv6 is the process of suppressing the repetitive portion of IPv6 packet headers at the sender and restoring the headers at the receiver. IPv6 PHS is defined as optional in IEEE 802.16. PHS has a Payload Header Suppression Valid (PHSV) option to verify or not verify the payload header before suppressing it. PHS has also a Payload Header Suppression Mask (PHSM) option to allow select bytes not to be suppressed. More information is available in the 5.2.3 of IEEE Std 802.16-2004 specification. 3.2 Header considerations To setting IPv6 PHS efficiently, v6ops working group should consider each header described as below. Kim, et al. Expires December 3, 2005 [Page 4] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 3.4.1 IPv6 header - Traffic class - Flow label - Payload length - Next header - Hop Limit - Source address and Destination address. etc 3.4.2 IPv6 Option header - Destination Option Header - Routing header - Fragment header - Authentication Header - Encapsulating Security Payload header - Destination Option header. etc 3.3 v6ops considerations Considering limited bandwidth and instability in 802.16 wireless environments, the probability to transmit IPv6 packet to PSS is lower than fixed networks. Reducing the length of IPv6 packets by setting PHS rules is a way to overcome wireless networks limitations. If IPv6 PHS is applied to Ipv6 option headers, more IPv6 packets can be transmitted. IPv6 PHS is effective when a lot of IPv6 packets are transmitted, which have many repetitive parts in IPv6 header. Setting the detail of IPv6 PHS is more related with IP layer than MAC layer because IPv6 header is used in IP layer. Only IP layer can decide which parts of IPv6 header can be suppressed when applying PHS rules. Therefore, V6ops working group should pay attention to setting PHS rules for IPv6. Kim, et al. Expires December 3, 2005 [Page 5] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 4. IPv6 address Auto-Configuration over IEEE 802.16 4.1 Modes affecting IPv6 multicast IEEE 802.16 defines two transmission modes with which a BS and a SS (or a SS and a SS) communicate. One is the PMP (point-to-multipoint) mode, the other is the mesh mode. In WiBro specification, only PMP mode is considered. 4.1.1 PMP mode A BS broadcasts IEEE 802.16 MAC frames periodically to its area when transmitting data from the BS to SSs. Therefore, each frame can be shared by SSs. On the contrary, SSs share the uplink to the BS on a demand basis. In other words, SSs cannot communicate each other without BS. The MAC scheduler located in the BS, controls uplink/downlink in IEEE 802.16 environments. 4.1.2 Mesh mode In the Mesh mode, IEEE 802.16 MAC frames can be transmitted using other SSs. In some cases, direct communication between SSs is possible. Therefore, SSs can send SS-initiated IPv6 multicast messages to BS and other SSs. More information is available in 6.2 of IEEE Std 802.16-2004 specification. 4.2 v6op Considerations Both in PMP and mesh mode, IEEE 802.16 specification can be changed in order to send SS-initiated Ipv6 multicast for IPv6 address Auto- configuration. For example, a certain SS in a BS and other SS in other BS can have same IP address because groups of BSs can have different IP allocation policies and IP management policies which has not specified in the IEEE 802.16 specification. Therefore, v6ops needs to consider both MAC layer and IP layer in order that a SS- initiated multicast to all SSs can be transmitted. 5. Acknowledgments Thanks to Eun-Kyoung Paik for her cooperation and excellent review comments. 6. Security Considerations Kim, et al. Expires December 3, 2005 [Page 6] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 6.1.1 PHS for IPv6 When PHS rule is applied to IPv6 packets, BS and SS should be authorized and authenticated in WiBro. 6.1.2 IPv6 multicast transmission in IEEE 802.16 When IPv6 multicast transmission in IEEE 802.16 is applied to IPv6 packets, BS and SS should be authorized and authenticated in WiBro. 7. Normative References [IEEE P802.16e/D9, June 2005] "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". [IEEE Std 802.16-2004(Revision of IEEE Std 802.16-2001)] "IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems". [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. Kim, et al. Expires December 3, 2005 [Page 7] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 Authors' Addresses Sung Il Kim KT Convergence Laboratory 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6118 Fax: +82-2-526-5200 Email: semperor@kt.co.kr Se Jun Park KT Convergence Laboratory 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6116 Fax: +82-2-526-5200 Email: semperor@kt.co.kr Sang Eon Kim KT Convergence Laboratory 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6117 Fax: +82-2-526-5200 Email: sekim@kt.co.kr Kim, et al. Expires December 3, 2005 [Page 8] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 Han-Lim Kim KT Convergence Laboratory 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6189 Fax: +82-2-526-5200 Email: nangel@kt.co.kr Kim, et al. Expires December 3, 2005 [Page 9] Internet-Draft Problem Statement in IPv6 over WiBro June 2005 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 (2005). 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. Kim, et al. Expires December 3, 2005 [Page 10]