Network Working Group H. Jeon Internet-Draft ETRI Intended status: Standards Track M. Riegel Expires: April 4, 2007 Siemens S. Jeong ETRI Oct 2006 Transmission of IP Packets over Ethernet over IEEE 802.16 draft-riegel-16ng-ip-over-eth-over-80216-01.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 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the behavior of the Ethernet emulation on top of IEEE 802.16 to efficiently support the transmission of IPv4 as well as IPv6 packets over IEEE 802.16 radio links. Due to resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC layer for the emulation of Ethernet, the transmission Jeon, et al. Expires April 4, 2007 [Page 1] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 of IP over an emulated LAN on top of IEEE 802.16 may considerably benefit by adding IP specific support functions within the Ethernet emulation on top of IEEE 802.16. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 4 4.1. Connection Oriented Air Interface . . . . . . . . . . . . 4 4.2. Convergence Sublayers . . . . . . . . . . . . . . . . . . 4 4.3. Multicast and Broadcast Support in IEEE 802.16 . . . . . . 5 4.4. Solicitation of MAC addresses . . . . . . . . . . . . . . 5 5. The IEEE 802.16 Network Model for Ethernet . . . . . . . . . . 5 5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 5 5.2. Ethernet without Native Broadcast and Multicast Support . 6 5.3. Default Processing of Ethernet Frames . . . . . . . . . . 6 6. Deployment Scenarios for IP over Ethernet over IEEE 802.16 . . 7 6.1. Public Access Scenario . . . . . . . . . . . . . . . . . . 7 6.2. VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . 8 7. Filtering and Forwarding . . . . . . . . . . . . . . . . . . . 8 7.1. IP Broadcast and Multicast Support . . . . . . . . . . . . 8 7.2. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 8 7.3. Identification Cache Table . . . . . . . . . . . . . . . . 9 7.4. Address Resolution Protocol Proxy Function . . . . . . . . 10 7.5. Neighbor Discovery Relay Function . . . . . . . . . . . . 10 7.6. Access Router Behavior . . . . . . . . . . . . . . . . . . 11 8. Transmission of IP over Ethernet . . . . . . . . . . . . . . . 11 8.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 11 8.1.1. Address Resolution . . . . . . . . . . . . . . . . . . 12 8.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 12 8.2.1. Router Discovery, Prefix Discovery and Parameter Discovery . . . . . . . . . . . . . . . . . . . . . . 12 8.2.2. Address Configuration . . . . . . . . . . . . . . . . 13 8.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 13 8.3. Maximum Transmission Unit Consideration . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Jeon, et al. Expires April 4, 2007 [Page 2] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 1. Introduction IEEE 802.16 [IEEE802.16] defines a point-to-multipoint radio transmission system connecting a Base Station (BS) with multiple Subscriber Stations (SSs). IEEE 802.16e [IEEE802.16e] amends the base specification with PHY and MAC functions for supporting mobile terminals by adopting the same data link principles also for mobile networking systems. This document provides a detailed description of the Ethernet emulation on top of IEEE 802.16 with additional functionalities for efficient support of IPv4 packets as well as IPv6 packets. 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 Description of following some terms is taken directly from [IEEE802.16] and [IEEE802.16e]. Base Station (BS): A generalized equipment set providing connectivity, management, and control of the subscriber station. Subscriber Station (SS): A generalized equipment set providing connectivity between subscriber equipment and a base station. Within this document the term SS also represents the Mobile Subscriber Station introduced in IEEE 802.16e Service-specific Convergence Sublayer (CS): Sublayer in IEEE 802.16 MAC layer which classifier external network data and associates them to the proper MAC service flow identifier and connection identifier. Connection Identifier (CID): A 16 bit value that identifies a connection to equivalent peers in the MAC of the base station and subscriber station. Source Node: Host which initiates an IPv6 Neighbor Discovery message using its own unique MAC address. A Source Node may be co-located with a SS or may be behind a SS, when the SS acts as a bridge. Jeon, et al. Expires April 4, 2007 [Page 3] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 Target Node: Host which is addressed by the target field in an IPv6 Neighbor Discovery message. The Target Node has its own unique MAC address and may be co-located with a SS or may be behind a SS, when the SS acts as a bridge 4. The IEEE 802.16 Link Model 4.1. Connection Oriented Air Interface The IEEE 802.16 MAC provides connections between the BS and its associated SSs. Each of these connections is identified by a 16 bit CID number and has defined QoS capabilities. Multiple connections can be established between a BS and a SS, each with its particular QoS class and direction. | | | | +--+--+ +--+--+ +--+--+ +--+-+-+--+ | MAC | | MAC | | MAC | | MAC | +-----+ +-----+ +-----+ +---------+ | PHY | | PHY | | PHY | | PHY | +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | | | | | | | | | +-------|-+-------|-+----CID#w----+ | | | | | +------CID#x------+ | | | +----------------CID#y--------+ | +--------------------------CID#z----------+ SS#1 SS#2 SS#3 BS Figure 1. Basic IEEE 802.16 Link Model While uplink connections provide only unicast transmission capabilities from a particular SS to the BS, downlink connections can be used for unicast transmission from the BS to a particular SS as well as for multicast transmissions to a group of SSs. 4.2. Convergence Sublayers The assignment of higher layer packets to particular service flows and the related CIDs is performed within the IEEE 802.16 convergence sublayer by classifying the packets according to particular header fields. To enable the transmission of different kind of payloads over IEEE 802.16, multiple types of classification types are defined, each specific for one kind of upper layer protocol, like Ethernet, IPv4, IPv6 or even for encapsulated payload, like IPv4 over Ethernet or IPv6 over Ethernet. Optionally the convergence sublayer performs a packet header Jeon, et al. Expires April 4, 2007 [Page 4] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 suppression reducing static parts of the header to a single byte value. With the application of the packet header suppression function there is mostly no difference in header overhead over the air for Ethernet encapsulated IP packets in comparison to plain IP packets. 4.3. Multicast and Broadcast Support in IEEE 802.16 Downlink connections can be shared among multiple SSs, enabling multicast channels with multiple SSs receiving the same information from the BS. Multicast is not enabled in the uplink but must be realized by an entity on top the IEEE 802.16 MAC sending packets received on a unicast uplink downstream on a multicast channel. 4.4. Solicitation of MAC addresses The 48-bit unique MAC address of a SS is used during the initial ranging process for the identification of a SS and verified by the succeeding PKMv2 authentication phase. As a result, the BS establishes a list of solicited-node MAC addresses of all SSs connected to the BS. Note that there may be additional MAC addresses behind SSs when SSs act as bridge connecting networks behind the SSs. The additional MAC addresses may be also solicited when there is a controlled link state for the hosts behind the SS and the SS performs authentication of the link, e.g. by running IEEE 802.1X on the SS. 5. The IEEE 802.16 Network Model for Ethernet 5.1. IEEE 802.16 Ethernet Link Model According to [I-D.ietf-ipv6-2461bis], an IP Link is defined as a communication facility or medium over which nodes can communicate at the link layer, i.e. the layer immediately below IP. IEEE 802.16 provides point-to-point connections between SSs and the BS without enabling any direct SS to SS connectivity. Ethernet is realized on top of IEEE 802.16 by implementing bridging between all SSs with IEEE 802.16 providing the links between the hosts and the bridge behind the BS like the twisted pair wires used in today's switched Ethernet. Jeon, et al. Expires April 4, 2007 [Page 5] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 ------------------------ IP Link ------------------------ | | | | | ETH ETH ETH ETH ETH | | | | | | | +---------+---------+ | | | | | Bridge | | | | | +--+-+---------+-+--+ | | | | | | | | | | +--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+ | MAC | | MAC | | MAC + + MAC | | MAC | | MAC | +-----+ +-----+ +-------+ +-------+ +-----+ +-----+ | PHY | | PHY | | PHY + + PHY | | PHY | | PHY | +-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+ | | | | | | | | | | | | | | | +-------|-+--CID#u-+ | | | | +-CID#x--+-|-------+ | | +----CID#v---+ | | +---CID#y----+ | +--------------CID#w-----+ +-----CID#z--------------+ SS#1 SS#2 BS#1 BS#2 SS#3 SS#4 Figure 2. IEEE 802.16 IP over Ethernet Link Model It is possible to control the size and coverage of IP links by segmenting the Ethernet and grouping particular links into VLANs. Such segmentation is mostly done between BSs, but it is also possible to extend the segmentation over IEEE802.16 links when multiple hosts are attached to a bridge at the SS. 5.2. Ethernet without Native Broadcast and Multicast Support Ethernet is emulated on top of IEEE 802.16 without making use of MBS as defined in 6.3.23 of [IEEE802.16e] to allow full control over the reaction of SSs to broadcast messages. Instead of using MBS, broadcast and multicast messages are transferred in a unicast manner. 5.3. Default Processing of Ethernet Frames If the SS performs a bridging function then it SHALL support Standard Learned Bridging between all its LAN ports and the airlink. The BS SHALL forward all the radio connections belonging to one SS to a port of a bridge performing Standard Learned Bridging between all ports on the radio side and the interfaces towards the network side. When performing Standard Learned Bridging, the SS, when acting as a bridge, or the bridge behind the BSs shall learn all source MAC addresses originating from a port resulting in Dynamic Filtering Entries if the same MAC addresses are not already listed as Static Jeon, et al. Expires April 4, 2007 [Page 6] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 Filtering Entries. The accumulation of all learned MAC to port associations and all Static Filtering Entries derived from solicited- node MAC addresses constitute the Filtering Database. The Standard Learned Bridge shall automatically unlearn a Dynamic Filtering Entry MAC to port relationship after BRIDGETIMEOUT seconds have expired without any traffic from that MAC address. When performing bridging, any packets destined for one of the addresses in the Filtering Database SHALL be forwarded directly to that port and all packets received from a port, for which the packet's destination MAC address is also an entry for that port in the Filtering Database, SHALL be silently discarded. 6. Deployment Scenarios for IP over Ethernet over IEEE 802.16 Figure 3 and 4 show possible deployment scenarios in case of IP over Ethernet over IEEE 802.16. In both figures, the AR is connected to a bridge, which is connected to all BSs. The bridge supports Static Filtering Entries and Standard Learned Bridging, as specified in Section 5.3. Multiple ARs can exist on a link, and a subnet (IP Link) consists of multiple hosts usually being co-located with a SS acting as bridge. The network behind a SS can support various access network technologies, e.g. 802.3, 802.11 or 802.15. 6.1. Public Access Scenario Figure 3 depicts an IEEE 802.16 network deployment scenario without direct host-to-host communication. In the general public access case, direct communication between nodes is restricted because of security and accounting issues. In this scenario, the bridge SHALL forward all packets received from any radio side port to a network side port. Peer-to-peer communication is not supported by the bridge and all packets originated from a SS should be delivered to an AR. +-----+ +-----+ +-------+ | SS |----| BS1 |------| | +------+ +-----+ +-----+ | |-------| AR | |Bridge | +------+ +-----+ +-----+ +-----+ | | |Hosts|--| SS |----| BS2 |------| | +-----+ +-----+ +-----+ +-------+ This network may exist behind SS Figure 3. Network Model without direct host-to-host communication Jeon, et al. Expires April 4, 2007 [Page 7] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 6.2. VLAN Scenario Figure 4 shows the VLAN scenario. Particular SSs grouped into a VLAN can directly communicate with each other when this mode is enabled for the VLAN. Otherwise, direct communication is prohibited and the VLAN shows the same behavior as the public access scenario case. The bridge has been extended to support VLAN capability and configurable direct host-to-host communication. +-----+ +-----+ +-------+ | SS |----| BS1 |------| | +------+ +-----+ +-----+ |Bridge |-------| AR | |(VLAN) | +------+ +-----+ +-----+ +-----+ | | |Hosts|--| SS |----| BS2 |------| | +-----+ +-----+ +-----+ +-------+ This network may exist behind SS Figure 4. Network Model with direct host-to-host communication 7. Filtering and Forwarding 7.1. IP Broadcast and Multicast Support As explained in 5.2, no native MBS support is used for emulation of the Ethernet behavior over IEEE 802.16 links. Only point-to-point connections are established between SSs and BS. Multiple connections belonging to the same SS are feeded into a single bridge port. Broadcast or all-nodes multicast data such as router advertisements are unicasted to intended SS via the point-to-point connection. 7.2. Packet Filtering The bridge SHALL have the ability to enable or disable any filtering functionality defined herein. If a packet is filtered it SHALL be silently discarded. The filtering functionality is based on the information of the Identification Cache Table (ICT), which is an extension of the Filtering Database. Details of the ICT are given in Section 7.3. The bridge SHALL support filtering of all packets received from a network side port to a destination MAC address not existing in the ICT. Jeon, et al. Expires April 4, 2007 [Page 8] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 The bridge SHALL support filtering of all packets received from a network side port to a broadcast or multicast MAC address. If filtering is enabled the bridge SHALL permit all Address Resolution Protocol messages to pass to the ARP Proxy Agent and all Neighbor Discovery messages to pass to the Neighbor Discovery (ND) Relay Agent, as specified in following section. All multicast and multicast control messages are forwarded according to [RFC4541] 7.3. Identification Cache Table The bridge establishes and maintains information about each SS by the mean of an Identification Cache Table (ICT). For IPv4 over Ethernet, the ICT contains for each MAC address, the lifetime if it is not Static Filtering Entry and one or more IPv4 addresses. For IPv6 over Ethernet, the ICT contains for each MAC address, the lifetime if it is not Static Filtering Entry, the link-local address and one or more IPv6 addresses with associated Valid Flags. The ARP Proxy Agent and the ND Relay Agent functions are based on information contained in the ICT. IPv4 addresses can be learned by examining the source address of packets or DHCP Response message. IPv6 link-local addresses can be derived from solicited-node MAC address. Note that Privacy Extension for IPv6 address [RFC3041] is not considered in the current version. The IPv6 address is learned by extracting the Target field in the Neighbor Solicitation (NS) message for Duplicate Address Detection (DAD), if the tentative IPv6 address does not exist yet as a valid IPv6 address in the ICT. In this case, the Valid Flag is set to indicate the tentative IPv6 address has become valid. Otherwise, the IPv6 address in the Target field in a DAD NS message is stored as IPv6 address with Valid Flag is not set to identify the Source Node when the bridge relays the Neighbor Advertisement message from Target Node. The lifetime of each entry follows the lifetime of the Learned Bridge Table. Figure 5 and Figure 6 show the ICT for IPv4 over Ethernet and IPv6 over Ethernet. Jeon, et al. Expires April 4, 2007 [Page 9] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 +---------+----------+------+-------+--~--+--------+ | MAC | Port # | Life | IPv4 | | IPv4 | | address | | time |address| | address| +---------+----------+------+-------+--~--+--------+ | | | | | ... | | +---------+----------+------+-------+--~--+--------+ Figure 5. ICT on Bridge in case of IPv4 over Ethernet +----+-----+----+----------+----------+----+-----+--~--+----+-----+ |MAC |Port#|Life|Solicited-|Link-local|IPv6|Valid| |IPv6|Valid| |addr| |time|node addr | addr |addr|Flag | |addr|Flag | +----+-----+----+----------+----------+----+-----+--~--+----+-----+ | | | | | | | | ... | | | +----+-----+----+----------+----------+----+-----+--~--+----+-----+ Figure 6. ICT on Bridge in case of IPv6 over Ethernet 7.4. Address Resolution Protocol Proxy Function In the case of IPv4 over Ethernet, ARP requests can be responded by the ARP Proxy Agent of the bridge. (refer to Section 8.1.1 for more detail) However, a proxy function in IPv6 over Ethernet is subjected to restriction because of security issues. Support of SeND [RFC3971] has been adopted in the IPv6 over Ethernet case. 7.5. Neighbor Discovery Relay Function In the case of IPv6 over Ethernet, the AR sends periodically Router Advertisement and the Router Advertisement messages can be relayed by the ND Relay Agent of the bridge. The ND Relay Agent unicasts the Router Advertisement via all the already established a point-to-point connections between SSs and bridge. Note that the relaying of Router Advertisement MUST NOT affect validness of SeND Timestamp. When the bridge receives Neighbor Solicitation for DAD, the ND Relay Agent of the bridge performs the same operation as the Relay DAD. The ND Relay Agent looks up in the ICT to detect whether a tentative address in the Neighbor Solicitation message is in use or not. If the tentative address is not in use, the ND Relay Agent discards the Jeon, et al. Expires April 4, 2007 [Page 10] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 Neighbor Solicitation. Otherwise, the Neighbor Solicitation message is relayed only to the addressed Target Node. When the bridge receives the DAD Neighbor Advertisement message from the Target Node, the ND Relay Agent of the bridge identifies the corresponding Source Node by the ICT and then unicasts the DAD Neighbor Advertisement message via the established point-to-point connection to the corresponding Source Node. 7.6. Access Router Behavior The assignment of a common prefix to all SSs means locating them "on- link" in terms of IP packet transfer. According to [I-D.ietf-ipv6-2461bis], an IP node performs a longest prefix match against the prefix list in order to decide whether the destination of the IP packet is on-link or not. Therefore, SSs sharing a prefix can be said to be on-link IP nodes. In the Public Access scenario, all unicast packets originated from a SS should be delivered to an AR even though the SS sends packets to on-link SSs. Therefore, it is necessary for the AR to relay the on- link packets. The AR SHALL have packet-relay functionality. The AR relays packets destined for IP broadcast address and link-local scoped multicast addresses to incoming interface again. When the AR relays packets destined for ab on-link host, the packet may be forwarded onto the incoming interface. It should be prevented that the AR transmits a Redirect message to sender when direct communication between on-link SSs occurs. In the case of the VLAN scenario, direct communication between SSs may be enabled for all SSs belonging to a particular VLAN. In this case, no special handling is required. 8. Transmission of IP over Ethernet 8.1. IPv4 over Ethernet [RFC0894] defines the transmission of IP packets over Ethernet networks. It contains the specification of the encapsulation of the IP packets into Ethernet frames as well as rules for mapping of IP addresses onto Ethernet MAC addresses. The use of ARP [RFC0826] is recommended for dynamic address resolution. Jeon, et al. Expires April 4, 2007 [Page 11] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 8.1.1. Address Resolution The bridge SHALL support an ARP Proxy. The bridge SHALL have the ability to enable or disable the ARP Proxy. If the ARP Proxy is disabled, the ARP Proxy Agent shall pass all ARP packets without discrimination or modification using bridging. The ARP Proxy Agent shall pass all ARP Response packets without discrimination or modification using bridging. If the ARP Proxy is enabled, upon receiving an ARP Request from an radio side interface, the ARP Proxy Agent shall unicast an ARP Response back to the interface provided that the target address matches an entry in the ICT. Otherwise, the ARP Proxy Agent shall flood the ARP Request to all network side interfaces. The ARP Proxy Agent shall silently discard any received self-ARP Requests. Those are requests for a target IP address, that when queried in the ICT results in a response MAC equal to the Request's source MAC address. The ARP Proxy Agent shall issue a gratuitous ARP on the network side interfaces for any new addition to the ICT. An unsolicited broadcast ARP Response constitutes a gratuitous ARP. 8.2. IPv6 over Ethernet The transmission of IPv6 Packets over Ethernet Networks is defined by [RFC2464] providing the frame format for encapsulation of IPv6 packets into Ethernet frames as well as the methods of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. 8.2.1. Router Discovery, Prefix Discovery and Parameter Discovery Router Discovery, Prefix Discovery and Parameter Discovery procedures are achieved by receiving Router Advertisement (RA) messages. The RA is forwarded by using all-nodes IP multicast transmission. This document assumes a point-to-point connection between each SS and bridge. The ND Relay Agent of the bridge unicast the RA from AR via the point-to-point connection. Note that the RA has a long lifetime and minimum packet size which can be sent in IEEE 802.16 to the SSs being in sleep-mode during the periodic wakeup-time. Jeon, et al. Expires April 4, 2007 [Page 12] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 8.2.2. Address Configuration 8.2.2.1. Stateful Address Autoconfiguration When the'M' flag in the received RA is set, a SS should perform stateful address configuration according to [RFC3315]. In this case, an AR supports DHCPv6 server or relay function. 8.2.2.2. Stateless Address Autoconfiguration The global IPv6 addresses is derived based on prefix and EUI-64- derived interface identifier and then confirmed through Duplicate Address Detection (DAD) as specified in [RFC2462]. For DAD, the Source Node sends Neighbor Solicitation to the solicited-node MAC address corresponding to the generated global IPv6 address for DAD. The Neighbor Solicitation is passed to the ND Relay Agent when arriving at the bridge. 8.2.3. Address Resolution The Source Node sends Neighbor Solicitation to the solicited-node address corresponding to the target address for address resolution. Upon receiving the Neighbor Solicitation, the bridge retrieves the port corresponding to the solicited-node MAC address in its ICT and then forwards the Neighbor Solicitation via that port. Finally the Target Node responds to the Neighbor Solicitation. 8.3. Maximum Transmission Unit Consideration When stacked VLAN headers are transferred over GRE tunnels, the sizes of the VLAN headers and the GRE header need to be considered in setting the value of MTU of the transport path. 9. Security Considerations [RFC3971] specifies security mechanisms for ND Protocol and defines means for securing ND Protocol messages. This document aims to fully support security mechanisms specified in [RFC3971]. 10. Informative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", Jeon, et al. Expires April 4, 2007 [Page 13] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 draft-ietf-ipv6-2461bis-08 (work in progress), September 2006. [I-D.ietf-16ng-ps-goals] Jee, J., "IP over 802.16 Problem Statements and Goals", draft-ietf-16ng-ps-goals-00 (work in progress), February 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, "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", December 2005. [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, Jeon, et al. Expires April 4, 2007 [Page 14] Internet-Draft IPoEth over IEEE 802.16 Oct 2006 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. Authors' Addresses Hongseok Jeon Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-3892 Email: jeonhs@etri.re.kr Max Riegel Siemens St-Martin-Str 76 Munich, 81541 Germany Phone: +49-89-636-75194 Email: maximilian.riegel@siemens.com Sangjin Jeong Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-1877 Email: sjjeong@gmail.com Jeon, et al. Expires April 4, 2007 [Page 15] Internet-Draft IPoEth over IEEE 802.16 Oct 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). Jeon, et al. Expires April 4, 2007 [Page 16]