Network Working Group M-K. Shin Internet-Draft J-M. Moon Expires: April 1, 2006 ETRI September 28, 2005 Considerations of IPv6 in IEEE 802.16 Networks draft-shin-ipv6-ieee802.16-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract As the deployment of IEEE 802.16 networks progresses, IPv6 will be introduced on IEEE 802.16 networks. The characteristics of IEEE 802.16 networks put special considerations on how IPv6 used. This document describes considerations on IPv6 adoption in IEEE 802.16 networks. Shin & Moon Expires April 1, 2006 [Page 1] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 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 Problem Statement . . . . . . . . . . . . . . 5 3. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Neighbor Discovery for IPv6 . . . . . . . . . . . . . . . 7 3.1.1. Address Resolution . . . . . . . . . . . . . . . . . . 7 3.1.2. Neighbor Unreachability Detection . . . . . . . . . . 7 3.1.3. Duplcate Address Detection . . . . . . . . . . . . . . 8 3.1.4. Router and Prefix Discovery . . . . . . . . . . . . . 8 3.1.5. Redirect Function . . . . . . . . . . . . . . . . . . 9 3.2. Transmission of IPv6 Packets . . . . . . . . . . . . . . . 9 3.3. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 9 3.4. IP Control/Management Protocols . . . . . . . . . . . . . 10 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mobile IPv6 Fast Handovers . . . . . . . . . . . . . . . . 11 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Multicast Listener Discovery . . . . . . . . . . . . . . . 12 5.2. Interworking with IP Multicast and MBS . . . . . . . . . . 12 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Security Threat Analysis . . . . . . . . . . . . . . . . . 13 7. Multiple Interface with Different Properties . . . . . . . . . 14 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Shin & Moon Expires April 1, 2006 [Page 2] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 1. Introduction IEEE 802.16d/e [IEEE802.16][IEEE802.16e] supports MSs (Subscriber Stations) moving at vehiclar 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 on IPv6 networks. The characteristics of IEEE 802.16 networks put special considerations on how IPv6 used. This document describes 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. This document classifies the issues into six groups : 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 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 interface with differerent characteristic (e.g., WLAN) are discussed. Shin & Moon Expires April 1, 2006 [Page 3] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 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 connection. 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 conntion 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 plurality of SS or MS. 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 & Moon Expires April 1, 2006 [Page 4] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 2. Assumptions and Problem Statement In order to introduce IPv6 in IEEE 802.16 networks, characteristics of IEEE 802.16 network and considerations on IPv6 adoption should be carefully surveyed. IEEE 802.16d [IEEE802.16] specifies the air interface, including the medium access control layer and multiple phisical layer specifications, of fixed broadband wireless access (BWA) systems supporting multiple services in the 10-66 GHZ bands. Also, operation of IEEE 802.16e [IEEE802.16e]is limited to licensed bands sutiable for mobility below 6 GHz. IEEE 802.16 supports two modes such as 2-way PMP (Point-to- Multipoint) and Mesh topology wireless networks. In this document, we focus on 2-way PMP topology wireless networks. Some of the characteristics of IEEE 802.16 networks are : MS and BS links resemble a point-to-ponit link: In PMP, there are two kinds of nodes such as MS and BS. The downlink, from the BS to the user, operates on a central BS. MS shares the uplink to the BS on a demand basis. The BS controls packet transmission for the uplink and the downlink. For packet transmission between a MS and a BS, a connection should be established between the MS and the BS. A connection is unidirectional and has a QoS specification. Therefore, IEEE 802.16 needs two connections for bidirectional communication. In addition, it defines a multicast/broadcast connection for multiple users to receive the same packets per one transmission. MBS has different characteristics with IP multicast services: Two types of access to multicast and broadcast services (MBS) may be supported: single-BS access and multi-BS access. Single-BS access is implemented over multicast and broadcast transport connections within one BS, while multi-BS access is implemented by transmitting data from Service Flow(s) over multiple BS. It may be different with traditional IP multicast schemes. CID is used to identify a connection: In general IEEE 802.x networks, MAC address is used to generate IPv6 addresses (link-local, global, etc.) and transmit packets at link layer. But, In IEEE 802.16 networks, CID is used to identify a connection to equivalent peers in the MAC of the BS and the MS. Shin & Moon Expires April 1, 2006 [Page 5] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 Actually, existing MAC address is not necessary. The QoS has different semantics with IP QoS (e.g., diffserv): In IEEE 802.16 networks, a connection is unidirectional and has a QoS specification. The QoS has different semantics with IP QoS (e.g., diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS parameters of the service flow associated with that connection. In order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label for IPv6) mapping should be provided. Note that this draft does not address QoS consideration at this phase. Shin & Moon Expires April 1, 2006 [Page 6] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 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 links resemble a point-to-point link; hence, the MS's only neighbor is the default router, BS that is already known through Router Discovery which is performed by link-layer mechanisms. Also, Neighbor Discovery packets with a multicast detination 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 header does not include MAC addresses. Instead, in order to identify connections to equivalent peers in the MAC of the BS and the MS, CID is used. In certain cases, multicast CID can be provided for in the downlink. It can be useful to tranmit efficiently link- local multicast destination packets (e.g, Router Advertisements) from BS to MSs. The packet transmission issues are discussed in section 3.2. Note that considerations of Neighbor Discovery in IEEE 802.16 networks is being discussed in 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 MS and BS are not needed, since MS and BS links resemble a point-to-point link; hence, the MS's only neighbor is the BS that is already known through Router Discovery which is performed by link configuration mechanisms. Actually, Neighbor Cache is unnecessary. Also, CID is used for link-layer transmission. Thus, CID connection state is maintained, instead of Negibor Cache, The MS uses CID which is provideded to each connection by BS. It must ensure the uniqueness of such connection on the link. 3.1.2. Neighbor Unreachability Detection In general, Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes. This fuction is used between MS and BS, since the MS's only neighbor is the BS. Shin & Moon Expires April 1, 2006 [Page 7] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 Neighbor Unreachability Detection portion of IPv6 Neighbor Discovery protocol is not needed, since MS and BS don't maintain Neighbor Cache. But MS and BS must know their neighbor reachability at IP layer in certain cases. A BS 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 trigger mechanisms in IEEE 802.16 networks. 3.1.3. Duplcate Address Detection Usallay, BS shall assign a prefix that is unique to an 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 need for further Duplcate Address Detection. However, if BS asssigns a single prefix to its all of attached MS, 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 response, a BS can perform proxy Neighbor Advertisements for one or more other MSs. In certain this, multicast CID can be used to to send the proxy Neighbor Advertisements to the MSs in the downlink. It might be dependent on implementation of IPv6 addressing/allocation model. This issus is also discussed in section 3.3. 3.1.4. Router and Prefix Discovery Acually, Router Discovery is already performed by link layer configuration mechanisms. As for the Prefix Discovery, BS trasmits Router Advertisements that contain Prefix Information to the advertising interface whose corresponding AdvSendAdvertisements flag is TRUE. The AdvSendAdvertisements flag must set when CID value is set at an interface. An BS must not send Router Advertisements out any interface that is not an advertising interface. In this case, 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 sends Router Solicitations to its BS. In this case, MS's CID is used to identify the MS. Shin & Moon Expires April 1, 2006 [Page 8] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 3.1.5. Redirect Function Redirect message is not necessary in IEEE 802.16 networks, since the MS's only router is the BS. 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 1: IEEE 802.16 MAC header format It is importmant to see that there is no MAC address in IEEE 802.16 MAC header format. Similar to general point-to-point links, 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. 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 certain cases, multicast CID can be provided for in the downlink. It can be useful to tranmit efficiently link-local multicast destination packets in the downlink. 3.3. IPv6 Addressing There are two possiblities to allocate IPv6 prefix in 802.16 networks. The simple method is to assign a unique prefix to an MS. This avoids the necessity to perform Duplicate Address Detection. Second method is to assign a single prefix to its all of attached MSs. In this case, Duplicate Address Detection must be supported. It might be dependent on implementation of IPv6 addressing/allocation model. This issus should be intensively researached later, since it will affect the protocol implementation of Duplcate Address Detection. Shin & Moon Expires April 1, 2006 [Page 9] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 3.4. IP Control/Management Protocols In IPv6 protocols, there is a lot of control/management protocols including ICMP, DHCP, SNMP, DNS, etc. It is important to see that some of these protocols use link-local multicast destination addresses. Within IEEE 802.16 networks, MSs connect to their BSs via point-to-ponit links. Like some of Neighbor Discovery protocols in IEEE 802.16, these pakcets with link-local multicast destination addresses are transmitted as normal IEEE 802.16 MAC frames, as the same as regular unicast packets. Instead, CID is used to identify a connection to equivalent peers in the MAC of the BS and the MS. Also, multicast CID can be used to tranmit efficiently these packets in the downlink. Shin & Moon Expires April 1, 2006 [Page 10] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 4. Mobility As for the mobility management, the movement between BSs is handled by Mobile IPv6 [RFC3775]. Also, in certain cases (e.g., fast handover [I-D.ietf-mipshop-fast-mipv6]) the link mobility information must be available on Mobile IPv6. 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 Advertisement for the rechability and the movement detection may be unnecessary becasue IEEE 802.16 MAC provides the reachabilty by the Ranging procedure and the movement detection by the Handoff procdure. 4.2. Mobile IPv6 Fast Handovers In addition, IEEE 802.16 defines L2 trigger whether refresh of a IP address is required during the handoff. Through a handoff is occured, an additional Router Discovery procedure is not required in case of intra-subnet handoff. Also, faster handoff may be occured by the L2 trigger in case of inter-subnet hnadoff. Also, IEEE 802.16g which is under-developed defines L2 trigger for link status auch as link-up, link-down, handoff-start. These L2 trigger may make the mobile IPv6 procedure more efficient and faster. In addition, Mobile IPv6 Fast Handover assumes the support from the link-layer technology, but the particular link-layer information 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 & Moon Expires April 1, 2006 [Page 11] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 5. Multicast In order to support multicast services in IEEE 802.16, Multicast Listener Discovery [RFC2710] must be supported between MS and BS. Also, interworking with IP multicast protocols and MBS should be considered. 5.1. Multicast Listener Discovery Within IEEE 802.16 networks, an MS connect to its default router, BS 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 CID can be used to transmit efficiently query packets in 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 networks 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 broadcast service, not multicasting. MBS adheres to broadcast service, while taditional IP multicast scheme defines multicast routing using 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 type of services may be roughly mapped into Source-Specific Multicast and Any-Source Multicast, respectively. It should be intensively researched later, since MBS will be one of killer services in IEEE 802.16 networks. Shin & Moon Expires April 1, 2006 [Page 12] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 6. Security 6.1. IPsec IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may be used within global end-to-end architecture. But, we don't have PKIs across organization and IPsec isn't integrated with IEEE 802.16 network mobility management. 6.2. Security Threat Analysis IEEE 802.16 networks threats may be different with IPv6 and IPv6 transition threat models [I-D.ietf-v6ops-security-overview]. It will be discussed later. Shin & Moon Expires April 1, 2006 [Page 13] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 7. Multiple Interface with Different Properties If an 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 protocol inconsitancy if there are protocol issues (modification) in IEEE 802.16 networks. Two or more different version of protocols (e.g., NDP) may be required within 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 & Moon Expires April 1, 2006 [Page 14] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 8. Summary +------------------------------------------------------+ | section | issues | target | wg | +------------------------------------------------------+ | 3.1 | neighbor | protocol | ipv6 | | | discovery | | | +------------------------------------------------------+ | 3.2 | packet | protocol | ipv6 | | | transmission | | | +------------------------------------------------------+ | 3.3 | addressing | operation / | na | | | | implementation| | +------------------------------------------------------+ | 3.4 | control | operation / | na | | | management | implementation| | +------------------------------------------------------+ | 4.1 | mobile | operation / | na | | | ipv6 | implementation| | +------------------------------------------------------+ | 4.2 | fast | protocol | mipshop | | | handover | | | +------------------------------------------------------+ | 5.1 | multicast | operation / | mboned | | | listener | implementation| | +------------------------------------------------------+ | 5.2 | mbs | operation / | mboned | | | interworking | implementation| | +------------------------------------------------------+ | 6.1 | ipsec | operation / | v6ops | | | | implementation| | +------------------------------------------------------+ | 6.2 | threat | operation / | v6ops | | | model | implementation| | +------------------------------------------------------+ | 7 | multiple | operation / | na | | | interfaces | implementation| | +------------------------------------------------------+ Figure 2: Summary of Issues Shin & Moon Expires April 1, 2006 [Page 15] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 9. Security Considerations As for the security, it is briefly discussed in section 6. Shin & Moon Expires April 1, 2006 [Page 16] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 10. References 10.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. 10.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-00 (work in progress), July 2005. [I-D.ietf-v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-02 Shin & Moon Expires April 1, 2006 [Page 17] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 (work in progress), July 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 & Moon Expires April 1, 2006 [Page 18] Internet-Draft IPv6 in IEEE 802.16 Networks September 2005 Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 Email: mkshin@pec.etri.re.kr Jung-Mo Moon ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 6748 Email: jmmoon@etri.re.kr Shin & Moon Expires April 1, 2006 [Page 19] Internet-Draft IPv6 in IEEE 802.16 Networks September 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. Shin & Moon Expires April 1, 2006 [Page 20]