Network Working Group J-C. Lee Internet-Draft ETRI Expires: April 18, 2006 Y-H. Han Samsung AIT M-K. Shin ETRI H-J. Jang Samsung AIT H-J. Kim ETRI October 15, 2005 Considerations of NDP over IEEE 802.16 Networks draft-lee-ndp-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 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IEEE 802.16 issued standards for the new PHY and MAC for providing Lee, et al. Expires April 18, 2006 [Page 1] Internet-Draft NDP over IEEE 802.16 Networks October 2005 broadband wireless access network. It is characterized by very high data rates and wider range of which technologies are different from existing wireless access technologies such as IEEE 802.11 or 3G. Accordingly, the use of IPv6 over IEEE 802.16 network is currently undefined. There are several issues to be considered in deploying IPv6 over IEEE 802.16 network. Among them, this document will describe issues related to neighbor discovery protocol (NDP) over IEEE 802.16 networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Problem Statements . . . . . . . . . . . . . . . . . . . . 4 1.3.1. Issues regarding ND protocol itself . . . . . . . . . 4 1.3.2. Architectural and Operational Issues . . . . . . . . . 6 1.4. Specification of Requirements . . . . . . . . . . . . . . 8 2. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Case 4: BS and router in one box + Prefix to subnet . . . 9 2.1.1. Addresses . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. Address Autoconfiguration . . . . . . . . . . . . . . 11 2.1.3. Router and Prefix Discovery . . . . . . . . . . . . . 11 2.1.4. Redirect function . . . . . . . . . . . . . . . . . . 12 3. The use of ND messages . . . . . . . . . . . . . . . . . . . . 13 3.1. Router Solicitation Message . . . . . . . . . . . . . . . 13 3.2. Router Advertisement Message . . . . . . . . . . . . . . . 13 3.3. Neighbor Solicitation Message . . . . . . . . . . . . . . 14 3.4. Neighbor Advertisement Message . . . . . . . . . . . . . . 15 3.5. Redirect Message . . . . . . . . . . . . . . . . . . . . . 15 4. Conceptual Model of a Host . . . . . . . . . . . . . . . . . . 17 4.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 17 5. Summary Matrix . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Case 4: BS and router in one box + Prefix to subnet . . . 18 6. Secuirty Considerations . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Lee, et al. Expires April 18, 2006 [Page 2] Internet-Draft NDP over IEEE 802.16 Networks October 2005 1. Introduction The IEEE802.11 network has driven the revolution of wireless communication, but as the more people use it, more of its limitations like short range or lack of mobility support have been revealed. Compared with IEEE802.11 network, IEEE802.16 supports enhanced features like wider range and mobility. Thus, it is expected that IEEE802.16 network would be the next step of IEEE802.11 network. The IEEE802.11 MAC protocol is almost same as the IEEE802.3 protocol with the exception of being able to be used over an air medium. Thus, most of the existing layer 3 protocols can be used without any modification. The structure of IEEE802.16 protocol is, however, much different from the IEEE802.11 protocol. Therefore, it is needed to consider if IPv6 runs well over IEEE802.16 networks. There are several issues to be considered in deploying IPv6 over IEEE802.16 network [I-D.shin-ipv6-ieee802.16]. Among them, this document will describe issues about the Neighbor Discovery Protocol [RFC2461]. 1.1. Scope of this Document The considerations described in this document are only applied to the subnet composed of BS and MS(s) attached to that BS over the IEEE802.16 network. We are considering two BS deployment cases and two addressing cases each, but only one scenario that adopts BS integrated with router function and allocates a same prefix to all MS(s) attached to one BS would be considered in this version of draft. 1.2. Terminology 802.16 subnet: The subnet composed of MS(s) attached to the same BS. This terminology is only used in this document. SS: Subscriber Station. A general equipment set providing connectivity between subscriber equipment and a BS. MS: Lee, et al. Expires April 18, 2006 [Page 3] Internet-Draft NDP over IEEE 802.16 Networks October 2005 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. 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. NS: Neighbor Solicitation message NA: Neighbor Advertisement message RS: Router Solicitation message RA: Router Advertisement message and all other terminologies declared in [RFC2461] 1.3. Problem Statements 1.3.1. Issues regarding ND protocol itself Sending to and Receiving from multicast address: 1. The 802.16 MAC header doesn't include a MAC address, so we can't send to or receive from multicast address as the way how Lee, et al. Expires April 18, 2006 [Page 4] Internet-Draft NDP over IEEE 802.16 Networks October 2005 802.3 and 802.11 do. 2. How to join multicast addresses (all-nodes multicast address, solicited-node multicast address) required for DAD? or is there any way to send or receive multicast packet without joining multicast address? Address autoconfiguration: 1. Creation of link-local address (requires DAD): basically, IPv6 node creates link-local address for use on a single link. Link-local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present. In order to create link-local addresses, DAD should be done to guarantee the uniqueness of the link-local addresses in a link. This DAD MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration [RFC2462]. The problem in processing DAD is that the procedure for DAD uses NS message sent to solicited-node multicast address and NA message sent to all-node multicast address. 2. Creation of global scope address (requires DAD): IPv6 host can create its global-scope addresses by appending an interface identifier to a prefix obtained from RA message. Even in this case, DAD should be done with the same reason as link-local address case. Conceptual sending algorithm: 1. Address Resolution (solicited-node multicast address): When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next-hop node is known, the sender examines the Neighbor Cache for link-layer information about that neighbor. If no entry exists, the sender creates new one, and then initiates Address Resolution. For multicast- capable interfaces Address Resolution consists of sending a NS message destined for solicited-node multicast address and waiting for a NA message. There are two problems with this issues. The one is whether Address Resolution is needed or not over 802.16 network and the other is if Address Resolution is needed, how we send NS message destined for solicited-node multicast address. Lee, et al. Expires April 18, 2006 [Page 5] Internet-Draft NDP over IEEE 802.16 Networks October 2005 2. Neighbor Unreachability Detection: whenever an IPv6 node accesses its Neighbor Cache entry while transmitting a unicast packet, the sender checks Neighbor Unreachability Detection related information according to NUD algorithm. If there is no need to do Address Resolution, NUD is not needed. Router and Prefix discovery: 1. Sending Router Solicitation message to all-router multicast address: Router Discovery is used to locate neighboring routers as well as learn prefixes and configuration parameters related to address autoconfiguration. This procedure consists of sending RS message to All-routers multicast address and receiving RA message. The problem is how we send RS message destined for all-routers multicast address. 2. Set the 'L' bit in Prefix Information option or not? (on-link determination): The Prefix Information option has 'L' bit indicating this prefix can be used for on-link determination. As what mentioned before we have two policies on allocating prefixes to the MS(s). The determination of setting 'L' bit is dependent on this policy. Redirect function Is it needed in 802.16 network environment? 1.3.2. Architectural and Operational Issues We consider two types of the Base Station deployment mode and two policies on how we allocate prefixes to the Mobile Station. IEEE 802.16 Base Station Deployment Modes We describe two possible deployment architectures of IEEE 802.16 network. Figure 1 and 2 show the two cases. 1. Router separation from BS: In Figure 1, routers are located separated with IEEE 802.16 BSs. 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. A simple or complex network equipments may constitute the underlying wired network between BSs and router. In a subnet, therefore, there are always two underlying links including IEEE 802.16 wireless link between SS and BS. In this case, the methods of IPv6 adoption to IEEE 802.16 may depend on the underlying network Lee, et al. Expires April 18, 2006 [Page 6] Internet-Draft NDP over IEEE 802.16 Networks October 2005 architecture between BSs and router. /-------------------------------------\ | Backbend Network | \-------------------------------------/ | | /-----------\ /-----------\ | Router1 | | Router2 | \-----------/ \-----------/ / / | \ \ / / | \ \ / / | \ \ / / | \ \ / | | | \ / | | | \ BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10 Figure 1. IEEE 802.16 deployment architecture with BS and Router in separated boxes 2. BS and router in one box: Figure 2 represents an alternative IEEE 802.16 network deployment where a BS is integrated with a router, composing one box in view of implementation. A subnet consists of only single router and single BS. In this case, many IPv6 functionalities can be implemented without much consideration about the underlying network implementation. Only IEEE 802.16 link will be taken into consideration for IPv6 adoption. /------------------\ | Backbend Network | \------------------/ / \ / \ / \ --------- --------- | Router1 | | Router2 | | BS1 | | BS2 | --------- --------- Figure 2. IEEE 802.16 deployment architecture with BS and Router in one box. IPv6 ND Prefix Allocation Policies There are two possible addressing schemes as follows. 1. Prefix to SS: [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 Lee, et al. Expires April 18, 2006 [Page 7] Internet-Draft NDP over IEEE 802.16 Networks October 2005 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. Prefix to Subnet: Different usage scenario such as 'Hot zone' 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. (* hot zone: an area served by one BS, similar meaning to Hotspot in 802.11) As a result of above combinations, we can consider the following four cases for the scenarios of IPv6 adoption to IEEE 802.16 networks. +--+---------------------------+------------------+ | | Deployment | Addressing | +--+---------------------------+------------------+ | 1| Router separation from BS | Prefix to SS | +--+---------------------------+------------------+ | 2| Router separation from BS | Prefix to subnet | +--+---------------------------+------------------+ | 3| BS and router in one box | Prefix to SS | +--+---------------------------+------------------+ | 4| BS and router in one box | Prefix to subnet | +--+---------------------------+------------------+ *** Among above cases we will only consider case 4 in this version of draft. 1.4. 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 April 18, 2006 [Page 8] Internet-Draft NDP over IEEE 802.16 Networks October 2005 2. Protocols 2.1. Case 4: BS and router in one box + Prefix to subnet 2.1.1. Addresses 2.1.1.1. link-local address Basically, the procedure to create link-local address follows [RFC2462]. 802.16 interface also has 48bits MAC address as other 802.x family [IEEE802.16]. Therefore, this 48bits MAC address of 802.16 interface can be used for making interface identifier. Duplicate Address Detection: Usually the link between MS and BS resembles a point-to-point link, hence if BS allocates different prefix to each MS there is no need to do DAD. But if BS allocates unique prefix to MS(s) belong to 802.16 subnet, DAD should be done. This case will be described in Section 2.1.2.1 later. 2.1.1.2. Multicast address ND has several multicast addresses used for its service, but 802.16 MAC header doesn't include MAC address, and thus this makes it harder to deliver and receive ND multicast packet. In 802.3, a corresponding MAC address to the each link-local multicast address [RFC2464] is maintained and the layer 2 of each node can recognize the multicast packets. Thus, the delivery of the multicast packets is done in a distributed manner, but 802.16 does not manage such MAC address for the multicast, so the multicasting needs to be handled centrally. In spite of this limitation, we can use ND service without big modification of ND protocol by using the characteristics of 802.16 network. all-nodes multicast address (link-scoped) All IPv6 nodes which have unicast address should join this multicast address. There are two cases to send packets to all- nodes multicast destination; the one is to send Unsolicited Router Advertisement (RA) message to MS(s) and the other is to send Unsolicited Neighbor Advertisement (NA) message to the adjacent neighbor. Lee, et al. Expires April 18, 2006 [Page 9] Internet-Draft NDP over IEEE 802.16 Networks October 2005 Unsolicited RA message: The BS knows MS(s) list attached to itself, hence it can send Unsolicited Router Advertisement message to MS(s) in a unicast manner. Unsolicited NA message: This case could be happen in case that link-layer address of a node is changed. *** Needs further study... *** solicited-node multicast address (link-scoped) All IPv6 nodes which have unicast address should join the corresponding multicast address. This address is used for address resolution, but usually there is no need to do address resolution over 802.16 network in scenario 4, because the next hop of MS is always BS. But there might be some other cases under consideration. all-routers multicast address (link-scoped) This address is used in Router Solicitation message. The MS can send this message to the adjacent router without support of multicast because its only neighbor is BS. To support the multicast communication, the BS can manage the multicast group and handle the delivery in a central manner. When the BS receives the multicast packets, it can apply the selective decision to optimize the airlink resources based on the type of multicast packets. 1. Some types of multicast traffic may be filtered off and be dropped by the BS. 2. Some types of multicast traffic such as all-nodes multicast may be delivered in a unicast manner to all MSs. 3. Some types of traffic such as solicited-node or all-routers multicast may be delivered in a unicast manner to the some of nodes (its members). 4. Some types of traffic may be forwarded to a specific node. 5. Some types of traffic may be delivered by using a shared CIDs. In case of 1), for example, the BS can drop the NS for DAD, which will be mention in detail in Section 2.1.2.1. In case of 2), the BS knows MS list attached to itself, hence it can send Unsolicited RA/NA to MS(s) by using basic connection allocated to each MS. For 3), it is necessary for the BS to manage each multicast membership. In case Lee, et al. Expires April 18, 2006 [Page 10] Internet-Draft NDP over IEEE 802.16 Networks October 2005 of 4), if the BS can predict the respondent of the multicast packet based on the collected information during network (re)entry or through some ways, it may forward the multicast packet to the specific node. For 5), the BS can allocate one or more shared Connection IDs (CIDs) across all or some MSs, which enables the BS to send only a single copy of the packet and all the members of a single multicast group can receive it. In addition to the membership knowledge, the BS needs to define the several kinds of CIDs, and be able to map the multicast addresses to the corresponding 802.16 CIDs. This approach seems to be similar to [RFC2464]. The BS may use the mix of 1)~5) for the efficiency of air resources. For instance, it can use the approaches of 1), 4) and 5) together. However, how to implement the assignment of CIDs and the mapping of CIDs depends on the BS implementation and is out of scope of this document. 2.1.1.3. Anycast address Same as the unicast case. 2.1.2. Address Autoconfiguration The IPv6 host can create link-local unicast address and global-scope unicast address in a stateless manner [RFC2462]. Before completing address autoconfiguration procedure in Section 2.1 scenario, the IPv6 host must do DAD to check uniqueness of address. In this scenario, DAD operates as follows. 2.1.2.1. Duplicate Address Detection (DAD) There might be various implementation techniques for DAD implementation over 802.16 networks. When the BS has the list of all MS's IP addresses on that link, it can check whether the target address in NS is unique or not. If unique, it may be filtered off as described 1. of Section 2.1.1.2, otherwise the BS may forward the packets. o As described in Section 2.1.1.2 before, MS can't send NS message in a multicast manner. Instead, the MS sends NS message to BS directly. o The BS acts in a manner descried Section 2.1.1.2. 2.1.3. Router and Prefix Discovery Mainly described in Section 2.1.1.2. Lee, et al. Expires April 18, 2006 [Page 11] Internet-Draft NDP over IEEE 802.16 Networks October 2005 2.1.3.1. Unsolicited Router Advertisement The BS would send Unsolicited RA through interface(s) whose AdvSendAdvertisements flag is set TRUE. This case is also described in Section 2.1.1.2. 2.1.4. Redirect function Redirect message shall not be used since MS's next-hop is always BS and there is no better choice. Lee, et al. Expires April 18, 2006 [Page 12] Internet-Draft NDP over IEEE 802.16 Networks October 2005 3. The use of ND messages 3.1. Router Solicitation Message IP fields: Source address ip address assigned to sending interface or unspecified address(::) Destination address all-router multicast address (ff02::2, link-local scope) Valid options: Source link-layer address "The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise it SHOULD be included on link layers that have addresses." [RFC2461] A 802.16 interface has 48bits MAC address, but it is not be used in sending or receiving packets except for initialization process. Therefore, this option will not be included. 3.2. Router Advertisement Message The transmission of periodic RAs may not be proper in 802.16 networks in view of resource efficiency. When the MS is attached to link, the BS may begin to transmit RAs. Once the configurable number of RAs is sent, the BS may not send more RAs to limit the multicast packets. The BS can reply with the RA only in response to RS. IP fields: Source address link-local address assigned to the interface from which this message is sent. Destination address Lee, et al. Expires April 18, 2006 [Page 13] Internet-Draft NDP over IEEE 802.16 Networks October 2005 source address of an invoking router solicitation message or all-nodes multicast address(ff02::1, link-local scope) ICMP fields: Router Lifetime "...0 indicates that the router is not a default router and SHOULD NOT appear on the default router list..."[RFC2461]. BS always acts as default router of MS, hence this field should not be set 0. Possible options: Prefix Information In cases that adopt IPv6 ND Prefix Allocation Policy 2, each MS comprising 802.16 subnet with same prefix advertised by BS as other MS(s) is not on-link with each other. Therefore set 'L' bit off. 3.3. Neighbor Solicitation Message IP fields: Source address address assigned to the interface from which this message is sent or unspecified address (::, in case of DAD) Destination address solicited-node multicast address (ff02:0:0:0:0:1:ffxx:xxxx, link-local scope, in case of address resolution) or target address (in case of DAD) Possible options: Source link-layer address "...Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations." [RFC2461]. Does not include this option with same reason as Section 3.1. Lee, et al. Expires April 18, 2006 [Page 14] Internet-Draft NDP over IEEE 802.16 Networks October 2005 3.4. Neighbor Advertisement Message neighbor solicitation messages shall be discarded by BS except if it is part of NUD. IP fields: Source address address assigned to the interface from which the advertisement is sent. Destination address for solicited advertisements: - source address of an invoking neighbor solicitation - all-nodes multicast address (if the source address of solicitation message is ::) for unsolicited advertisement: - all-nodes multicast address (ff02::1, link-local scope) Possible options: Target link-layer address "...This option MUST be included on link layers that have addresses when responding to multicast solicitations..."[RFC2461]. Does not include this option with same reason as Section 3.1 and the next hop of MS is always BS, hence this option is meaningless except for Unsolicited Neighbor Advertisement. 3.5. Redirect Message This message shall not be used because MS's next-hop is always BS and there is no better choice. IP fields: Source address Lee, et al. Expires April 18, 2006 [Page 15] Internet-Draft NDP over IEEE 802.16 Networks October 2005 link-local address assigned to the interface from which this message is sent. Destination address source address of the packet that triggered the redirect. Lee, et al. Expires April 18, 2006 [Page 16] Internet-Draft NDP over IEEE 802.16 Networks October 2005 4. Conceptual Model of a Host 4.1. Conceptual Data Structures Neighbor Cache: Usually the MS has neighbor caches, but it might be empty as described in Section 2.1.1.2. This also means that there is no need to do NUD. If the MS should do address resolution by some other reason, its next hop would be BS and the neighbor cache entry would be filled with the MAC address of the BS. In this case, MS would do NUD. Even if there are neighbor caches, it would not be used in sending procedure. Destination Cache: No special issue. Prefix List: No special issue. Default Router List: No special issue. Lee, et al. Expires April 18, 2006 [Page 17] Internet-Draft NDP over IEEE 802.16 Networks October 2005 5. Summary Matrix 5.1. Case 4: BS and router in one box + Prefix to subnet +--------+-----------+--------+--------+---------+--------+---+---+ | | Router |Address | | | | | | | |& Prefix | Auto- |Address | Next-hop| Packet | | | | |& Parameter|Config- |Resolut-|Determin-|Transmi-|NUD|DAD| | |discovery |uration |ion |ation |ssion | | | +--------+-----------+--------+--------+---------+--------+---+---+ | RS | O | O | | | | | | +--------+-----------+--------+--------+---------+--------+---+---+ | RA | O | O | | | | | | +--------+-----------+--------+--------+---------+--------+---+---+ | NS | | | X(O) | | | O | O | +--------+-----------+--------+--------+---------+--------+---+---+ | NA | | | X(O) | | | O | O | +--------+-----------+--------+--------+---------+--------+---+---+ |Redirect| | | | | | | | +--------+-----------+--------+--------+---------+--------+---+---+ |Neighbor| | | | | | | | |cache | | | | | O | | | +--------+-----------+--------+--------+---------+--------+---+---+ |Destina-| | | | | | | | |tion | | | | O | O | | | |cache | | | | | | | | +--------+-----------+--------+--------+---------+--------+---+---+ |Prefix | | | | | | | | |List | | | | O | | | | +--------+-----------+--------+--------+---------+--------+---+---+ |Default | | | | | | | | |Router | | | | O | O | | | |List | | | | | | | | +--------+-----------+--------+--------+---------+--------+---+---+ | DAD | | O | | | | | | +--------+-----------+--------+--------+---------+--------+---+---+ | NUD | | | | | X(O) | | | +--------+-----------+--------+--------+---------+--------+---+---+ o Axis X: Operations. o Axis Y: Messages, Data Structures, and Operations used by operations. o O : a Message or Data Structure is used. o X(O): Basically a Message or Data Structure is not used, but used under special condition. Lee, et al. Expires April 18, 2006 [Page 18] Internet-Draft NDP over IEEE 802.16 Networks October 2005 6. 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 April 18, 2006 [Page 19] Internet-Draft NDP over IEEE 802.16 Networks October 2005 7. References 7.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. 7.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-01 (work in progress), October 2005. Lee, et al. Expires April 18, 2006 [Page 20] Internet-Draft NDP over IEEE 802.16 Networks October 2005 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 Youn-Hee Han Samsung AIT P.O. Box 111 Suwon 440-600 Korea Fax: Email: yh21.han@samsung.com Myung-Ki Shin ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-350 Korea Fax: +82 42 861 5404 Email: mkshin@pec.etri.re.kr 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 April 18, 2006 [Page 21] Internet-Draft NDP over IEEE 802.16 Networks October 2005 Hyoung-Jun Kim ETRI 161 Gajeong-dong Yuseong-gu Daejeon, 305-350 Korea Fax: +82 42 861 5404 Email: khj@etri.re.kr Lee, et al. Expires April 18, 2006 [Page 22] Internet-Draft NDP over IEEE 802.16 Networks October 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. Lee, et al. Expires April 18, 2006 [Page 23]