Network Working Group J-C. Lee Internet-Draft ETRI Expires: August 5, 2006 S. Madanapalli Samsung ISO H-J. Jang Samsung AIT February 2006 NDP over IEEE 802.16 Networks draft-lee-ndp-ieee802.16-01 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 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract IEEE 802.16 issued the new standards for PHY and MAC providing broadband wireless access network. Currently, it is being developed under the assumption that IPv4 is used over it and the use of IPv6 over IEEE 802.16 networks has not been considered yet. Hence, this draft describes several problems in running NDP over IEEE 802.16 Lee, et al. Expires August 5, 2006 [Page 1] Internet-Draft NDP over IEEE 802.16 Networks February 2006 networks and presents some proposed solutions for those problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Specification of Requirements . . . . . . . . . . . . . . 4 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Issues Regarding IEEE 802.16 Architecture . . . . . . . . 5 2.1.1. IEEE 802.16 Network Aspect Issues . . . . . . . . . . 5 2.1.2. IEEE 802.16 Node Aspect Issues . . . . . . . . . . . . 7 2.2. Issues Regarding NDP . . . . . . . . . . . . . . . . . . . 8 2.2.1. Address Autoconfiguration . . . . . . . . . . . . . . 8 2.2.2. Address Resolution . . . . . . . . . . . . . . . . . . 9 2.2.3. Conceptual Sending Algorithm . . . . . . . . . . . . . 9 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Multicast Support . . . . . . . . . . . . . . . . . . . . 11 3.2. Solution CASE 1 . . . . . . . . . . . . . . . . . . . . . 12 3.3. Solution CASE 2 . . . . . . . . . . . . . . . . . . . . . 13 3.4. Solution CASE 3 . . . . . . . . . . . . . . . . . . . . . 14 3.5. Solution CASE 4 . . . . . . . . . . . . . . . . . . . . . 15 4. Secuirty Considerations . . . . . . . . . . . . . . . . . . . 17 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 5.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Lee, et al. Expires August 5, 2006 [Page 2] Internet-Draft NDP over IEEE 802.16 Networks February 2006 1. Introduction The IEEE 802.16 specifies a new PHY and MAC for providing broadband wireless access networks. This protocol is a connection-oriented technology without bi-directional native multicast support that Ethernet can provide. Since IPv6 operation is based on multicast such as router advertisement, this characteristic can be a major reason to prevent IPv6 from being deployed over IEEE 802.16 networks immediately. To deploy IPv6 over IEEE 802.16 networks, we also have to consider different kinds of convergence sublayers and subnet models To deploy IPv6 over IEEE 802.16 networks, we also have to consider convergence sublayers and several subnet models. These factors make problems more complicated. We will describe these problems in more detail later. There are several feasible deployment scenarios [I-D.shin-ipv6- ieee802.16] that we have to consider when we introduce IEEE 802.16 networks. These deployment scenarios may have close relation with problems, thus we will describe proposed solution for these problems according to the each scenario. This problems and solution described in this document may also be an input to other standard organization like WiMax. 1.1. 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 connection identifier (CID). All traffic is carried on a connection. Lee, et al. Expires August 5, 2006 [Page 3] Internet-Draft NDP over IEEE 802.16 Networks February 2006 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. CS: Convergence Sublayer. CS provides any transformation or mapping of external network data, received through the CS service access point (SAP), into MAC SDUs received by the MAC Common Part Sublayer (CPS) through the MAC SAP. PDU: Protocol Data Unit. The data unit exchanged between peer entities of the same protocol layer. On the downward direction, it is the data unit generated for the next lower layer. On the upward direction, it is the data unit received from the previous lower layer. MBS: Multicast and Broadcast Service. Some globally defined service flows which may carry broadcast or multicast information that should be delivered to a plurality of SS or MS. and all other terminologies defined in [RFC2461] 1.2. 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]. Lee, et al. Expires August 5, 2006 [Page 4] Internet-Draft NDP over IEEE 802.16 Networks February 2006 2. Problem Statements The problems can be classified into two categories like "issues regarding IEEE 802.16 architecture" and "issues regarding NDP". 2.1. Issues Regarding IEEE 802.16 Architecture MS, BS, AR comprise IEEE 802.16 networks. When we establish IPv6 networks over IEEE 802.16 technology, we can assume several architectural variations. NDP considerations for IEEE 802.16 networks may be affected by these variations. 2.1.1. IEEE 802.16 Network Aspect Issues IEEE 802.16 connection always ends at BS, which is connected to AR. In this situation, we can make BS integrated with AR or separated from AR, and make the sebnet comprised of one BS & MSs or several BSs & MSs. 2.1.1.1. Subnet Models 1. A Prefix per each MS: [RFC3314] 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. In such case, many IPv6 functionalities can be implemented without difficulty. 2. A Prefix for all MSs attached to BS(s) : Different usage scenario such as 'Hot zone' [I-D.shin-v6ops-deployment-scenarios] would not allow [RFC3314] 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.1.1.2. BS Architecture 1. BS and AR are in one box: This case represents an alternative IEEE 802.16 network deployment where a BS is integrated with a AR. A subnet may consist of a router and a BS. In this case, both of .1 and .2 are possible. Lee, et al. Expires August 5, 2006 [Page 5] Internet-Draft NDP over IEEE 802.16 Networks February 2006 /------------------\ | Backbend Network | \------------------/ / \ / \ / \ --------- --------- | Router1 | | Router2 | | BS1 | | BS2 | --------- --------- Figure 3. BS and AR are in one box 2. BS is separated from AR: 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. With this BS architecture, .1 can't be applied to IPv6 over IEEE 802.16 networks and if ethernet CS is used a L2 tunnel should be used between BS and AR. /-------------------------------------\ | Backbend Network | \-------------------------------------/ | | /-----------\ /-----------\ | Router1 | | Router2 | \-----------/ \-----------/ / / | \ \ / / | \ \ / / | \ \ / / | \ \ / | | | \ / | | | \ BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10 Figure 4. BS is separated from AR 2.1.1.3. Multicast Support IEEE 802.16 is a point-to-multipoint connection oriented technology without bi-directional native multicast support. This prevents IPv6 nodes from multicasting like [RFC2464] without any explicit support on network side. Most of NDP functions depend on the multicast support from the lower layer. So for NDP to function normally on IEEE 802.16 networks, there must be some explicit support for multicasting from network side. More detailed solution for multicast support will be dealt in Section 3.1. The consequence of the lack of optimal multicast supports in IEEE 802.16 networks is that any IP layer protocol like NDP, DHCPv6, IPv4 Lee, et al. Expires August 5, 2006 [Page 6] Internet-Draft NDP over IEEE 802.16 Networks February 2006 ARP depending on the lower layer multicast support may not function normally. 2.1.2. IEEE 802.16 Node Aspect Issues IEEE 802.16 MAC includes service-specific Convergence Sublayers (CS) that interface to higer layers. Some NDP operations may have dependency on the CS that IEEE 802.16 node adopts. 2.1.2.1. Convergence Sublayer Currently, IEEE 802.16 provides two CS: the asynchronous transfer mode (ATM) CS and the packet CS. The ATM CS is used for ATM services, the packet CS is used for transport for all packet-based protocols such as IP, PPP, and ethernet. The primary job of CS is to perform classification of higher-layer PDUs [IEEE802.16]. In this document, only the packet CS would be considered. The packet CS includes ethernet CS and IP CS. IPv6 CS In case of IPv6 CS, its classification parameters are IPv6 header and transport header. If MS adopts IPv6 CS, some kind of tunnel between BS and AR may be needed to transfer IPv6 packets from MS to AR in case that BS is separated from AR. Address resolution process is trivial in case of IPv6 CS, because there is no need to make ethernet header. Ethernet CS When ethernet CS is used, the following parameters are used for classification: destination MAC address, source MAC address, ethertype. For IP over IEEE 802.3/ethernet, IP headers may be included in classification. In case of ethernet CS, IP packet from MS can be delivered to AR without any help of tunnel even though BS is separated from AR. IEEE 802.16 MAC header doesn't include 48bits MAC address, but address resolution process may be needed if MS adopts ethernet CS. The more details about this would be described in solution section. For clarification, the support of ethernet CS doesn't mean IEEE 802.3/ethernet emulation. multicast/broadcast frame can not be processed at the IEEE 802.16 MAC layer. Lee, et al. Expires August 5, 2006 [Page 7] Internet-Draft NDP over IEEE 802.16 Networks February 2006 2.1.2.2. Transport Connection for NDP Message Transmission At MS initialization, two pairs of management connections (uplink/ downlink) shall be established between the MS and the BS and the third pair of management connections may be optionally generated. The basic connection is used to exchange short, time-urgent MAC management messages. The primary management connection is used to exchange longer, more delay-tolerant MAC management messages. Finally, the secondary management connection is used to transfer delay tolerant, standards-based messages like DHCP, TFTP, SNMP etc. But it is unclear that the secondary management connection can be used to transfer NDP messages. Thus, MS and BS are required to set up transport connections for transfering NDP messages. 2.2. Issues Regarding NDP Basically, the lack of native multicast support in IEEE 802.16 networks makes it harder for NDP to function normally and some architectural characteristics of IEEE 802.16 networks may affect the detailed operations of NDP. 2.2.1. Address Autoconfiguration Global/site-local address The explicit multicast support is required to forward unsolicited router advertisement message (RA) to all MSs which belong to a same subnet. This solution would be described in Section 3.1 in detail. Prefix Assignment Prefix assignment has dependency on BS architecture and subnet model. If BS is separated from AR, .1 is impossible because AR have no capability to assign different prefix per each MS (i.e. AR is normal router). .1 and .2 are possible if BS and AR are in one box. If a prefix is shared among MSs then the subnet may consist of one or more BS(s) and multiple MSs (.2). In this model, a MS assumes that every other MS which shares same prefix are on- link, thus it would try to resolve the L2 address for the on-link prefixes. But direct communication using L2 address between two MSs may not be possible because of IEEE 802.16 network's structural reason. One way to prevent this situation is to advertise a prefix with 'L' bit reset. Lee, et al. Expires August 5, 2006 [Page 8] Internet-Draft NDP over IEEE 802.16 Networks February 2006 DAD procedure Duplicate Address Detection must take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration [RFC2462]. DAD procedure has some dependency on subnet model described in Section 2.1.1.1. If a prefix is assigned to each MS (.1) then the subnet consists of only a MS and a BS. Thus, there is no chance to collide with other address and hence DAD procedure seems to be trivial. If MSs share a prefix (.2) then DAD procedure should not be ignored, but DAD in IEEE 802.16 requires explicit multicast support. This problem can be solved through the solution described in Section 3.1 or proxy DAD. In proxy DAD, each BS/AR maintains the list of all addresses that are currently used and then BS/AR does proxy DAD on behalf of each address owner. 2.2.2. Address Resolution Address resolution has dependency on CS and subnet model. In case of ethernet CS, if a prefix is assigned to each MS (.1) address resolution is trivial (the next-hop of each MS's always BS/AR). If a prefix with 'L' bit set is shared among MSs (.2), address resolution is required. In case of IPv6 CS, address resolution is trivial. The next-hop of each MS is always BS/AR (.1) or AR(.2). 2.2.3. Conceptual Sending Algorithm To send an IPv6 packet to a destination, the IPv6 node determines its next-hop firstly (Next hop Determination) and looks up the L2 address of next-hop in neighbor cache (Address Resolution) and finally send the IPv6 packet to the next-hop. Once a neighbor cache entry is made, whenever it is referred its reachability is checked (Neighbor Unreachability Detection). Next Hop Determination It depends on subnet model. In case of .1, the next-hop of the MS is always BS/AR. In case of .2, if MSs share a prefix with 'L' bit set the next-hop determination would be performed as usual. If MSs share a prefix with 'L' bit off, the next-hop of the MS is always BS/AR or AR. Lee, et al. Expires August 5, 2006 [Page 9] Internet-Draft NDP over IEEE 802.16 Networks February 2006 Neighbor Cache The maintenance of neighbor cache depends on CS and subnet model. In case of IPv6 CS, address resolution is not strongly required because there is no ethernet header and hence the next-hop of MS is always BS/AR or AR. If the MS adopts ethernet CS and it shares a prefix with 'L' bit set with other MSs (.2), the address resolution is required and neighbor cache would be maintained. Neighbor Unreachability Detection If MSs share a prefix with 'L' bit set, NUD would be performed as usual and if 'L' bit off or a prefix is assigned to each MS, the NUD would be required only for BS/AR or AR. Lee, et al. Expires August 5, 2006 [Page 10] Internet-Draft NDP over IEEE 802.16 Networks February 2006 3. Solutions In this section, we introduce a proposed multicast support mechanism and describe solution per feasible deployment scenario [I-D.shin- v6ops-deployment-scenarios] 3.1. Multicast Support As mentioned before, some NDP functions need explicit multicast support to function normally over IEEE 802.16 networks. Hence we introduce the solution for multicast support in IEEE 802.16 networks. Mutiple Unicast Multiple unicast is the approach that is very simple but uses more network resources. The BS maintains the list of members which join a specific multicast address and if the BS receives a packet destined for the specific multicast address, it sends a copy of the packet as many times as the number of members. Multicast CID IEEE 802.16 provides support for downlink multicast from BS to MSs (MBS). Multicast CID approach uses this feature of IEEE 802.16. Multicast CID is a CID shared among the member nodes of a multicast group. To transmit multicast packets over the link with multicast CID, each CID should be shared by each multicast group member prior to packet transmission. For NDP, three multicast CIDs are needed (all-nodes multicast address, all-routers multicast address, solicited-node multicast address). The simple operation procedure of this approach is as follows. For more detailed procedure, refer to [I-D.jang-16ng-llm]: 1. Each MS joins following CIDs at initialization stage. + all-nodes multicast CID: all MSs join the all-nodes multicast group by generating the predefined CID for this group. + solicited-node multicast CID: all MSs make its solicit-node multicast by generating the corresponding CID for its group. + all-routers multicast CID: all MSs join the all-routers multicast group by generating the predefined CID for this group if it acts as a router Lee, et al. Expires August 5, 2006 [Page 11] Internet-Draft NDP over IEEE 802.16 Networks February 2006 2. MS may send packets destined for all-node multicast, all- router multicast, solicited-node multicast to BS or AR may send packets destined for all-node multicast, solicited-node multicast to BS. 3. BS delivers packets to MSs through multicast CID. 3.2. Solution CASE 1 +-----+ | MS1 |<-------------+ +-----+ v +-----+ +-------+ +--------+ | MS2 |<---------->|BS/AR1 |<------->| Edge | ISP +-----+ +-------+ | Router +==>Network +--------+ +-----+ +-------+ ^ | Ms3 |<---------->|BS/AR2 |<----------+ +-----+ +-------+ Figure 5. Scenario A o Subnet model: 1.A prefix per each MS. o BS architecture: 1.BS/AR are in one box. o Convergence Sublayer: Both are ok. o Address autoconfiguration: * Unsolicited RA from BS/AR: Use Multicast CID approach. * DAD: DAD procedure is trivial o Address resolution: In case of ethernet CS and IPv6 CS, the next- hop of all MSs is BS/AR. Therefore, address resolution is trivial. o Conceptual sending algorithm * Neighbor cache: In case of ethernet CS, needs only for BS/AR. * NUD: Checks only the reachability of BS/AR. * Next-hop determination: The next-hop of each MS is always BS/AR. Lee, et al. Expires August 5, 2006 [Page 12] Internet-Draft NDP over IEEE 802.16 Networks February 2006 3.3. Solution CASE 2 +-----+ | MS1 |<------+ +-----+ | +-----+ | +-------+ +--------+ | MS2 |<------+--->|BS/AR1 |<------->| Edge | ISP +-----+ +-------+ | Router +==>Network +--------+ +-----+ +-------+ ^ | Ms3 |<---------->|BS/AR2 |<----------+ +-----+ +-------+ Figure 6. Scenario B o Subnet model: 2.A prefix for all MSs attached to a BS/AR. o BS architecture: 1.BS/AR are in one box. o Convergence Sublayer: Both are ok. o Address autoconfiguration: * Unsolicited RA from BS/AR: Use Multicast CID approach. * DAD: Use multicast CID approach for NS/NA message. DAD procedure should be performed as usual. o Address resolution: In case of ethernet CS, address resolution should be performed as usual if MSs share a prefix with 'L' bit set. Use multicast CID approach for NS message. In case of IPv6 CS, the next-hop of MS is always BS/AR. Therefore, address resolution is trivial. o Conceptual sending algorithm * Neighbor cache: In case of ethernet CS, maintain other MS' cache if MSs share a prefix with 'L' bit set. In case of IPv6 CS, needs only for BS/AR. * NUD: If ethernet CS and 'L' bit set checks every entry as usual. Otherwise, checks only the reachability of BS/AR. * Next-hop determination: If ethernet CS and 'L' bit set next-hop d etermination should be performed as usual. Otherwise, the next-hop of each MS is always BS/AR. Lee, et al. Expires August 5, 2006 [Page 13] Internet-Draft NDP over IEEE 802.16 Networks February 2006 3.4. Solution CASE 3 +-----+ | MS1 |<------+ +-----+ | +-----+ | +-----+ +-----+ +--------+ | MSs |<------+----| BS1 |---->| AR |<-->| Edge | ISP +-----+ +-----+ +-----+ | Router +==>Network ^ +--------+ +-----+ +-----+ | | Mss |<-----------| BS2 |--------+ +-----+ +-----+ Figure 7. Scenario C o Subnet model: 2.A prefix for all MSs attached to BSs. o BS architecture: 2.BSs are separated from AR. o Convergence Sublayer: In case of IPv6 CS, L2 tunnel should be used between BS and AR. o Address autoconfiguration: * Unsolicited RA from AR: Use Multicast CID approach. RA should delivered to all BSs. * DAD: Use multicast CID approach for NS/NA message. DAD procedure should be performed as usual. o Address resolution: In case of ethernet CS, address resolution should be performed as usual if MSs share a prefix with 'L' bit set. Use multicast CID approach for NS message. In case of IPv6 CS, the next-hop of MS is always AR. Therefore, address resolution is trivial. o Conceptual sending algorithm * Neighbor cache: In case of ethernet CS, maintain other MS' cache if MSs share a prefix with 'L' bit set. In case of IPv6 CS, needs only for AR. * NUD: If ethernet CS and 'L' bit set checks every entry as usual. Otherwise, checks only the reachability of AR. * Next-hop determination: If ethernet CS and 'L' bit set next-hop determination should be performed as usual. Otherwise, the Lee, et al. Expires August 5, 2006 [Page 14] Internet-Draft NDP over IEEE 802.16 Networks February 2006 next-hop of each MS is always AR. 3.5. Solution CASE 4 +-----+ +-----+ +-----+ ISP 1 | MS1 |<-----+ +->| AR1 |<-->| ER1 |===>Network +-----+ | | +-----+ +-----+ +-----+ | +-----+ | | MS2 |<-----+-----| BS1 |--| +-----+ +-----+ | +-----+ +-----+ ISP 2 +->| AR2 |<-->| ER2 |===>Network +-----+ +-----+ | +-----+ +-----+ | Ms3 |<-----------| BS2 |--+ +-----+ +-----+ Figure 8. Scenario D o Subnet model: 2.A prefix for all MSs attached to BSs. o BS architecture: 2.BSs are separated from ARs. o Convergence Sublayer: In case of IPv6 CS, L2 tunnel should be used between BS and AR. o Address autoconfiguration: * Unsolicited RA from AR: Use Multicast CID approach. RA should delivered to all BSs. * DAD: Use multicast CID approach for NS/NA message. DAD procedure should be performed as usual. o Address resolution: In case of ethernet CS, address resolution should be performed as usual if MSs share a prefix with 'L' bit set. Use multicast CID approach for NS message. In case of IPv6 CS, the next-hop of MS is always one of ARs. Therefore, address resolution is trivial. o Conceptual sending algorithm * Neighbor cache: In case of ethernet CS, maintain other MS' cache if MSs share a prefix with 'L' bit set. In case of IPv6 CS, needs only for AR. * NUD: If ethernet CS and 'L' bit set checks every entry as usual. Otherwise, checks only the reachability of AR. Lee, et al. Expires August 5, 2006 [Page 15] Internet-Draft NDP over IEEE 802.16 Networks February 2006 * Next-hop determination: If ethernet CS and 'L' bit set next-hop determination should be performed as usual. Otherwise, the next-hop of each MS is always AR. Lee, et al. Expires August 5, 2006 [Page 16] Internet-Draft NDP over IEEE 802.16 Networks February 2006 4. Secuirty Considerations Until now there is no special security consideration found for these issues and most of the security considerations might follow [RFC2461]. Lee, et al. Expires August 5, 2006 [Page 17] Internet-Draft NDP over IEEE 802.16 Networks February 2006 5. References 5.1. Normative References [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [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. 5.2. Informative References [I-D.shin-ipv6-ieee802.16] Shin, M., "Scenarios and Considerations of IPv6 in IEEE 802.16 Networks", draft-shin-ipv6-ieee802.16-02 (work in progress), February 2006. [I-D.madanapalli-nd-over-802.16-problems] Madanapalli, S., "IPv6 Neighbor Discovery over 802.16: Problems and Goals", draft-madanapalli-nd-over-802.16-problems-00 (work in progress), December 2005. [I-D.jang-16ng-llm] "Link-local Multicast packet Transmission in 802.16 Networks", January 2006. [I-D.shin-v6ops-deployment-scenarios] "ISP IPv6 Deployment Scenarios in Wireless Broadband Lee, et al. Expires August 5, 2006 [Page 18] Internet-Draft NDP over IEEE 802.16 Networks February 2006 Access Networks", February 2006. Lee, et al. Expires August 5, 2006 [Page 19] Internet-Draft NDP over IEEE 802.16 Networks February 2006 Authors' Addresses Joo-Chul Lee ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-350 Korea Fax: +82 42 861 5404 Email: rune@etri.re.kr Syam Madanapalli Samsung ISO 3/1 Millers Road Bangalore-560 052 India Fax: +91 80 51197777 Email: syam@samsung.com Hee-Jin Jang Samsung AIT P.O. Box 111 Suwon Korea Fax: +82 31 280 9569 Email: heejin.jang@samsung.com Lee, et al. Expires August 5, 2006 [Page 20] Internet-Draft NDP over 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. Lee, et al. Expires August 5, 2006 [Page 21]