Network Working Group J. Jee, Editor Internet-Draft ETRI Intended status: Informational Track S. Madanapalli Expires: April 16, 2007 LogicaCMG J. Mandin Runcom G. Montenegro Microsoft S. Park Samsung Electronics M. Riegel Siemens October 13, 2006 IP over 802.16 Problem Statement and Goals draft-ietf-16ng-ps-goals-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 April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft provides overview of 802.16 Network characteristics and Jee, Editor, et al. Expires April 16, 2007 [Page 1] Internet-Draft IP over 802.16 PS and Goals October 2006 Convergence Sublayers, and specifies the problems in running the IETF IP (both IPv4 and IPv6) protocols over 802.16 Networks. This document also presents the goals that point at relevant work to be at IETF. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 4 4.1. Transport Connections . . . . . . . . . . . . . . . . . . 5 4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 5 4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 5 5. 16ng Problem Statement . . . . . . . . . . . . . . . . . . . . 6 5.1. Root Causes . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. IP over 802.16 with IP CS: Problems . . . . . . . . . . . 7 5.2.1. IPv4 over IP CS . . . . . . . . . . . . . . . . . . . 7 5.2.2. IPv6 over IP CS . . . . . . . . . . . . . . . . . . . 8 5.3. IP over 802.16 with Ethernet CS: Problems . . . . . . . . 9 5.3.1. IPv4 over Ethernet CS . . . . . . . . . . . . . . . . 10 5.3.2. IPv6 over Ethernet CS . . . . . . . . . . . . . . . . 10 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Jee, Editor, et al. Expires April 16, 2007 [Page 2] Internet-Draft IP over 802.16 PS and Goals October 2006 1. Introduction Broadband Wireless Access networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, fast mobility, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of broadband Wireless Metropolitan Area Networks [IEEE802.16]. Additionally, IEEE 802.16e is an amendment that adds support for mobility over the base IEEE 802.16 specification [IEEE802.16e]. Recently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, Mobility, Interworking with different networks, AAA, etc). The NWG is thus taking on work at layers above those defined by the IEEE 802 standards (typically limited to the physical and link layers only). Similarly, WiBro (Wireless Broadband), a Korean effort which focuses on the 2.3 GHz spectrum band, is also based on the IEEE 802.16e specification [IEEE802.16e]. IEEE 802.16(e) is different from existing wireless access technologies such as IEEE 802.11 or 3G. For example: immediately subsequent to network entry, an 802.16 SS (Subscriber Station) has no capability whatsoever for data (as opposed to management) connectivity. The criteria by which the BS (Base Station) sets up the 802.16 MAC connections for data transport is not part of the 802.16 standard and depends on the type of data services being offered (ie. the set up of transport connections will be different for IPv4 and IPv6 services). Additionally - as 802.16 is a point-to- multipoint network - an 802.16 subscriber station is not capable of broadcasting (e.g., for neighbor discovery or dynamic address binding) or direct communication to the other nodes in the network. This lacking of facility for native multicasting for IP packet transfer results in inappropriateness to apply the basic IP operation like IPv4 Address Resolution Protocol or IPv6 Neighbor Discovery Protocol. Accordingly, while 802.16 defines the encapsulation of an IP datagram in an IEEE 802.16 MAC payload, complete description of IP operation is not present. Thus, IP operation over IEEE 802.16 can benefit from IETF input and specification. Two styles of convergence sublayers of IEEE 802.16 are considered, IP CS and Ethernet CS. This document will describe the problems identified in adopting IP over IEEE 802.16 networks under considering these two types of convergence sublayers. Also several goals that point at relevant work to be done at IETF are presented subsequently. Jee, Editor, et al. Expires April 16, 2007 [Page 3] Internet-Draft IP over 802.16 PS and Goals October 2006 2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 3. Terminology Subscriber Station (SS): A generalized equipment set providing connectivity between subscriber equipment and a base station (BS) Base Station (BS): A generalized equipment sets providing connectivity, management, and control of the subscriber station (SS). IP Gateway: An entity which performs IP routing function to provide IP connectivity for SSes. Protocol Data Unit (PDU): This refers to the data format passed from the lower edge of the 802.16 MAC to the 802.16 PHY, which typically contains SDU data after fragmentation, encryption, etc. Service Data Unit (SDU): This refers to the data format passed to the upper edge of the 802.16 MAC IP Subnet: Topological area that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses as specifed from [I-D.thaler-intarea-multilink-subnet-issues]. Link: Topological area bounded by routers which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet as specifed from [I-D.thaler-intarea-multilink-subnet-issues]. Transport Connection: IEEE 802.16's MAC connection between a SS and BS with a specific QoS attributes. Each transport connection is identified by an unique identifier called connection identifier. 4. Overview of the IEEE 802.16-2004 MAC layer The topology of the IEEE 802.16-2004 [IEEE802.16] network is point- to-multipoint (PMP): a Base Station (BS) communicates with a number of Subscriber Stations (SSes). Each node in the network possesses a 48-bit MAC address (though in the Base Station this 48-bit unique identifier is called "BSId"). Each node possesses RSA-based authorization mechanism using x.509 certificate attesting to its MAC address/BSId. The [IEEE802.16e] enhanced RSA-based authorization and Jee, Editor, et al. Expires April 16, 2007 [Page 4] Internet-Draft IP over 802.16 PS and Goals October 2006 developed EAP-based authentication defined in [RFC3748] accordingly. So EAP-based authentication is recommended for mobile user. The BS and SS learn each others' MAC Address/BSId during the SS's entry into the network. 4.1. Transport Connections User data traffic (in both the BS-bound and SS-bound directions) is carried on unidirectional "transport connections". Each transport connection has a particular set of associated parameters indicating characteristics such as cryptographic suite and quality-of-service. After successful entry of a SS to the 802.16 network, no data traffic is possible - as there are as yet no transport connections between the BS and SS. Transport connections are established by a 3-message signaling sequence within the MAC layer (usually initiated by the BS). A downlink-direction transport connection is regarded as "multicast" if it has been made available (via MAC signaling) to more than one SS. Uplink-direction connections are always unicast. 4.2. 802.16 PDU format An 802.16 PDU (ie. the format that is transmitted over the airlink) consists of a 6-byte MAC header, various optional subheaders, and a data payload. The 802.16 6-byte MAC header carries the Connection Identifer (CID) of the connection with which the PDU is associated. We should observe that there is no source or destination address present in the raw 802.16 MAC header. 4.3. 802.16 Convergence Sublayer The 802.16 convergence sublayer (CS) is the component of the MAC that is responsible for assigning transmit-direction SDUs (originating from a higher layer application - eg. an IP stack at the BS or SS) to a specific outbound transport connection. The convergence sublayer maintains an ordered "classifier table". Each entry in the classifier table includes a classifier and a target CID. A classifier, in turn, consists of a conjunction of one or more subclassifiers - where each subclassifier specifies a packet field (eg. the destination MAC address in an Ethernet frame, or the TOS field of an IP datagram contained in an Ethernet frame) together with a particular value or range of values for the field. To perform classification on an outbound SDU, the convergence sublayer proceeds from the first entry of the classifier table to the last, and Jee, Editor, et al. Expires April 16, 2007 [Page 5] Internet-Draft IP over 802.16 PS and Goals October 2006 evaluates the fields of the SDU for a match with the table entry's classifier When a match is found, the convergence sublayer associates the SDU with the target CID (for eventual transmission), and the remainder of the 802.16 MAC and PHY processing can take place. 802.16 define numerous convergence sublayer types. The "type" of the convergence sublayer determines the fields that may appear in classifiers eg. o "802.3/Ethernet CS" permits classifiers that examine fields in 802.3-style headers o "IPv4 CS" permits classifiers that examine fields of IPv4 (and encapsulated TCP/ UDP headers) o "IPv6 CS" permits classifiers that examine fields of IPv6 (and encapsulated TCP/ UDP headers) Other CS types include ATM, IPv4-over-ethernet CS and IPv6-over- ethernet CS. An implementation of 802.16 can support multiple CS types. We can observe that the CS type actually defines the type of data interface (eg. IPv4/IPv6 or 802.3 ) that is presented by 802.16 to the higher layer application. 5. 16ng Problem Statement 5.1. Root Causes This section describes common problem statements regardless of convergence sublayer. The following are the root causes that prevent running IP protocols (both IPv4 and IPv6) over 802.16 networks smoothly. The consequences of these characteristics are listed in Section 5.2 and 5.3. - Point-to-Multipoint architecture: The 802.16 is a point-to-multipoint network without bi-directional native multicast support. This prevents IP nodes from multicasting. In 802.16 specification, when the 802.16 MAC receives a unicast/ multicast/broadcast packet from upper Layers, it just looks at the various fields (classifiers) in the headers and maps to the outgoing CID (This can also be a multicast CID in case of downlink). When 802.16 MAC receives a PDU from the PHY, it simply passes it to Jee, Editor, et al. Expires April 16, 2007 [Page 6] Internet-Draft IP over 802.16 PS and Goals October 2006 the layer above the MAC (eg. Ethernet or IP). It is the upper layer's responsibility to deliver the packet to the correct destination which nonetheless is limited by the existence of downlink multicast/broadcast connections for multicast/broadcast frames. Because IP layer services (e.g. IPv4 ARP, DHCPv4, IPv6 NDP, DHCPv6 etc.) rely on link-layer multicast--or services with similar semantics at the link-layer--, alternative mechanisms must be specified. - Limitation of Ethernet capability layer of 802.16: The Ethernet capability layer of 802.16 (called the convergence sublayer) specifies only how Ethernet frames are to be encapsulated over 802.16 wireless connections. This demonstrates that Ethernet CS does not itself emulate Ethernet like functionality, and multicast/ broadcast frames can not be processed at the 802.16 MAC layer only. These frames must be sent to an Ethernet/bridge layer, which in turn may send PDUs back to 802.16 downlink, to send out these multicast/ broadcast frames there should be a downlink multicast/broadcast connection to which all SSes are listening. - Communication among SSes on the same IP Subnet: It is unclear in 802.16 networks how SSes under a certain IP gateway communicate each other under the assumption that they are in same IP Subnet. In IPv6 case, [I-D.ietf-ipv6-2461bis] defines a link as a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. Therefore, IPv6 nodes on the same link can communicate directly without depending on the IP routing facility. By the way, the 802.16 network has a connection oriented feature, where a connection always ends at the BS. There is no support from 802.16 MAC/PHY for the direct communication among SSes under the same IP Subnet. The issues and analysis regarding how to configure an IP Subnet over IEEE 802.16 networks are specified in more detail through the [I-D.ietf-16ng-ipv6-link-model-analysis]. 5.2. IP over 802.16 with IP CS: Problems 5.2.1. IPv4 over IP CS - DHCPv4 IP Address management and assignment: For the IPv4 address management and assignment, IEEE 802.16 network refers primarily to allocation of Dynamic Host Configuration Protocol [RFC2131], static method is configured by manual though. DHCPv4 is a Jee, Editor, et al. Expires April 16, 2007 [Page 7] Internet-Draft IP over 802.16 PS and Goals October 2006 broadcasting-based IP allocation protocol. When initializing its IP configuration, the SS broadcasts a DHCPDISCOVER message on its local physical subnet. After receiving multiple DHCPOFFER messages, the SS broadcasts a DHCPREQUEST message with several options specifying desired configuration values. However, current DHCPv4 operations are tricky because of IEEE 802.16 non-broadcasting characteristics. Especially, DHCPv4 operation is tightly related to ARP facilities (e.g., checking on the uniqueness of allocated network address, etc.). For management and configuration requirements of SS, an IETF- based IP address allocation solutions should be specified in compliance with IEEE 802.16(e) networks. In DHCPv6 [RFC3315] case, it is modeled on DHCPv4, so, the problems described above still remain. For MIP-based mobile terminals, MIPv4 [RFC3344] based IP addressing is used instead of DHCPv4. However, it still requires multicast/broadcast facilities for supporting ICMP Router Advertisement [RFC1256]. - ARP resolution and ARP cache: Address Resolution is the process by which nodes determine the link- layer address of a destination node on the same subnet given only the destination's IP address and it is a mandatory function of TCP/IP. In IPCS case, however, there is no need for address resolution because MAC message is made by IP Gateway) instead of SS and hence ARP cache as 802.16 MAC address is never used as part of the 802.16 Frame. Blocking ARP needs to be implemented by SS itself in an implementation manner. There is no way of how to use ARP facilities on SS. 5.2.2. IPv6 over IP CS - Router Discovery: Because there is no MAC Address used in case of IPCS, it is unclear whether source link layer address need to be carried in the RS (Router Solicitation). As 802.16 MAC Address is not used for delivering the frames the RS may need to have source IP address specified, so that the RA (Router Advertisement) can be sent back. This may require the completion of Link Local Address configuration before sending an RS. For sending periodic Router Advertisements in 802.16 Networks, BS either needs to send the RA in unicast manner for each SS explicitly or send the RA in multicast connection. - Prefix Assignment: If the same IP prefix is shared with multiple SSes then the link Jee, Editor, et al. Expires April 16, 2007 [Page 8] Internet-Draft IP over 802.16 PS and Goals October 2006 consists of multiple SSes. In this model a SS assumes that there exist on-link neighbors and tries to resolve the L2 address for the on-link prefixes. However, direct communication using Link Layer Address between two SSs may not be possible. This poses a problem for sharing a prefix with multiple SSes. - Address Resolution and Neighbor Cache: Address Resolution is the process by which nodes determine the link- layer address of an on-link destination (e.g., a neighbor) given only the destination's IP address. In case of IP CS, there is no need for Address Resolution and hence Neighbor Cache as 802.16 MAC address is never used as part of the 802.16 Frame. - Next-Hop: In case of IPCS, the Next-hop may always be an IP Gateway. - Neighbor Unreachability Detection (NUD): In case of IP CS, a SS may always see the IP Gateway as the next hop, the NUD is required only for the IP Gateway(s). Also the requirement of NUD may depend on the existence of a connection to the BS for that particular destination. If there exists multiple IP Gateways (so the default routers), it is unknown if the NUD is required if an IP Gateway is not serving any 802.16 MAC connection. - Address Autoconfiguration: How Address Autoconfiguration can be achieved in 802.16 networks is dependent on following: 1) Whether the SSes attached to the same BS are neighbors (IP link Model), 2) Whether the prefix is being shared with other SSes. If a unique prefix is assigned to each SS similar to 3G approach, then the subnet consists of only one SS and hence duplicate address detection (DAD) is trivial. If the same prefix is shared with multiple SSes then the subnet consists of multiple SSes and DAD is required. DAD in 802.16 requires explicit multicast support from the Networks as there is no native multicast support. Thus, the explicit mechanism to perform the DAD procedure in the 802.16 network needs to be specified. 5.3. IP over 802.16 with Ethernet CS: Problems We assume that the IP gateway supports Ethernet interface and the IP Gateway sees the Ethernet frame sent by the SS unchanged. Jee, Editor, et al. Expires April 16, 2007 [Page 9] Internet-Draft IP over 802.16 PS and Goals October 2006 5.3.1. IPv4 over Ethernet CS DHCPv4 IP Address management and assignment: In the Ethernet CS case, the SS act as a layer 2 device and IP assignment will be carried through for hosts behind the SS. In this case, the SS simply forwards the DHCPv4 messages between the DHCPv4 client and DHCPv4 server. However, as pointed out in above, Ethernet CS is an optional function over IEEE 802.16 networks, so it can not be applied for all SSes and limitation of DHCPv4 still remains. - ARP resolution and ARP cache: Address Resolution is the process by which nodes determine the link- layer address of a destination node on the same subnet given only the destination's IP address and it is a mandatory function of TCP/IP. In Ethernet CS case, if ARP is blocked by SS like IPCS, there is no way to obtain the MAC address of IP Gateway without ARP process because SS have to generate its ARP request message by itself. There is no way of how to use ARP facilities on SS. 5.3.2. IPv6 over Ethernet CS - Router Discovery: For sending periodic Router Advertisements in 802.16 Networks, BS either needs to send the RA in unicast manner for each SS explicitly or send the RA through the multicast connection if available. - Prefix Assignment: Similar to IP CS case. - Address Resolution and Neighbor Cache: In case of Ethernet CS, if the prefix is shared with L-bit set, the Address Resolution may be required, which in turn requires multicast support from 802.16 MAC. If the prefixes are advertised with L bit reset, then Address Resolution and Neighbor Cache for other SSes may not be required. In this case, Neighbor Cache is maintained only for IP Gateway. - Next-Hop: When Ethernet CS is used and the accompanying Ethernet capability emulation is implemented, the next-hop for the destination IP with the same global prefix with the sender or link local address type would be the destination itself not the IP Gateway. Jee, Editor, et al. Expires April 16, 2007 [Page 10] Internet-Draft IP over 802.16 PS and Goals October 2006 - Neighbor Unreachability Detection (NUD): Same as IP CS case. - Address Autoconfiguration: Same as IP CS case. 6. Gap Analysis This section analyzes gaps between 802.16 networks and possible alternative approaches. 3GPP recommendation [RFC3314]: From the 3GPP recommendation, separate prefixes are allocated to each SSes resulting in the different IP Subnets for each SSes. The IP Gateway on the IEEE 802.16 networks might be comparable to the GGSN of 3GPP network. However, using PPP directly is not feasible in 802.16 networks because there is no PPP Convergence Sublayer that permits classification to transport connections based on fields in a PPP header. LAN model [RFC0894]: It seems that it may be possible to follow the LAN model where BS and IP Gateway reside on the same box. However, the BS implementation to emulate a LAN feature would be different from the previous Wireless LAN bridge. In 802.16, BS does not directly see the destination Ethernet address of the uplink packets to deliver the layer 2 frame toward the downlink direction. Moreover, mostly AP in the wireless LAN translates the 802.11 frame to 802.3 frame by the help of the existence of same LLC. However, there is no LLC in the 802.16 protocol stack thus, it is problematic to convert 802.16 frame to 802.3 frame directly. 7. Goals We need to first identify which "IP Subnet" model is a feasible one depending on each CS is used. According to the identified "IP Subnet" model for each CS, we would specify the following work items. * IPv6 transmission for 802.16 network in case where IPv6 CS is used. * IP transmission for 802.16 network in case where Ethernet CS is used. Jee, Editor, et al. Expires April 16, 2007 [Page 11] Internet-Draft IP over 802.16 PS and Goals October 2006 * IPv4 transmission for 802.16 network in case where IPv4 CS is used. * The standard interface between BS and IP Gateway if necessary. The following are the goals in no particular order that point at relevant work to be done in IETF. Goal #1. Define the feasible IP Subnet models depending on the CS used. Goal #2. Provide the way to reduce the scarce air resources when utilizing the basic IP facility like IPv4 ARP and IPv6 NDP over 802.16 networks. Goal #3. Reduce the power consumption caused by waking up of dormant terminals. Goal #4. Resolve the multilink subnet issues when using IP CS for Ethernet-like subnet model. Goal #5. Work on Ethernet CS should provide interoperability with existing devices that employ Ethernet. Goal #6. Provide the applicability of the previous security works like SEND [RFC3971]. Goal #7. Do not introduce any new security threats. 8. Security Considerations As described in the section 4, several authentication and authorization mechanisms are defined by [IEEE802.16] and [IEEE802.16e]. In [IEEE802.16e] case, PKMv2 EAP-based authentication is recommended for the secure connection between SS and BS/IP Gateway. 9. Acknowledgment We would like to express special thanks to IETF Mobility Working Group members of KWISF (Korea Wireless Internet Standardization Forum) for their initial efforts and remarkably to HeeYoung Jung for his motivation in proceeding this work. We also would like to express special thanks to the previous authors of the previous problem statement document, Myung-Ki Shin, Eun-Kyoung Paik and Jaesun Cha. Jee, Editor, et al. Expires April 16, 2007 [Page 12] Internet-Draft IP over 802.16 PS and Goals October 2006 We also would like to express thanks to Jicheol Lee, Sung Il Kim, Se Jun Park, Sang Eon Kim, Han-Lim Kim and Jung-Mo Moon for their inputs to this work. 10. References 10.1. Normative References [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984. [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Jee, Editor, et al. Expires April 16, 2007 [Page 13] Internet-Draft IP over 802.16 PS and Goals October 2006 10.2. Informative References [I-D.ietf-16ng-ipv6-link-model-analysis] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based Networks", draft-ietf-16ng-ipv6-link-model-analysis-00 (work in progress), October 2006. [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-08 (work in progress), September 2006. [I-D.thaler-intarea-multilink-subnet-issues] Thaler, D., "Issues With Protocols Proposing Multilink Subnets", draft-thaler-intarea-multilink-subnet-issues-00 (work in progress), March 2006. [IEEE802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [IEEE802.16e] IEEE P802.16e-2005, "Draft IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 2005. Authors' Addresses Junghoon Jee ETRI Email: jhjee@etri.re.kr Syam Madanapalli LogicaCMG Email: smadanapalli@gmail.com Jee, Editor, et al. Expires April 16, 2007 [Page 14] Internet-Draft IP over 802.16 PS and Goals October 2006 Jeff Mandin Runcom Email: jeff@streetwaves-networks.com gabriel_montenegro_2000@yahoo.com Microsoft Email: gabriel_montenegro_2000@yahoo.com Soohong Daniel Park Samsung Electronics Email: soohong.park@samsung.com Maximilian Riegel Siemens Email: maximilian.riegel@siemens.com Jee, Editor, et al. Expires April 16, 2007 [Page 15] Internet-Draft IP over 802.16 PS and Goals October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jee, Editor, et al. Expires April 16, 2007 [Page 16]