Network Working Group HS. Jeon Internet-Draft ETRI Intended status: Standards Track M. Riegel Expires: September 5, 2007 Siemens SJ. Jeong ETRI March 4, 2007 Transmission of IP over Ethernet over IEEE 802.16 Networks draft-ietf-16ng-ip-over-ethernet-over-802.16-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 September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes the transmission of IPv4 as well as IPv6 over Ethernet in a network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging between the point-to-point radio links, which are provided by IEEE 802.16 between the base station and its Jeon, et al. Expires September 5, 2007 [Page 1] Internet-Draft IPoEth over IEEE 802.16 March 2007 associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over an Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. Jeon, et al. Expires September 5, 2007 [Page 2] Internet-Draft IPoEth over IEEE 802.16 March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . . 5 4.1. Connection Oriented Air Interface . . . . . . . . . . . . 5 4.2. Feeding User Data into the Appropriate Connections . . . . 6 4.3. MAC addressing in IEEE 802.16 . . . . . . . . . . . . . . 6 5. The IEEE 802.16 Network Model for Ethernet . . . . . . . . . . 6 5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 6 5.2. Ethernet without Native Broadcast and Multicast Support . 7 5.3. Segmenting the Ethernet into VLAN . . . . . . . . . . . . 8 5.4. Deployment Scenarios for IP over Ethernet over IEEE 802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4.1. Public Access Scenario . . . . . . . . . . . . . . . . 8 5.4.2. Enterprise LAN Scenario . . . . . . . . . . . . . . . 9 6. Bridge Considerations . . . . . . . . . . . . . . . . . . . . 10 6.1. Multicast and Broadcast Packet Processing . . . . . . . . 10 6.1.1. Multicast Transmission Considerations . . . . . . . . 10 6.1.2. Broadcast Transmission Considerations . . . . . . . . 11 6.2. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. Public Access Scenario Case . . . . . . . . . . . . . 12 6.2.2. Enterprise LAN Scenario Case . . . . . . . . . . . . . 12 7. Access Router Considerations . . . . . . . . . . . . . . . . . 12 8. Prefix Assignment . . . . . . . . . . . . . . . . . . . . . . 12 8.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 12 8.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 13 9. Transmission of IP over Ethernet . . . . . . . . . . . . . . . 13 9.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 13 9.1.1. Address Configuration . . . . . . . . . . . . . . . . 13 9.1.2. Address Resolution . . . . . . . . . . . . . . . . . . 13 9.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 14 9.2.1. Router Discovery, Prefix Discovery and Parameter Discovery . . . . . . . . . . . . . . . . . . . . . . 14 9.2.2. Address Configuration . . . . . . . . . . . . . . . . 14 9.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 14 9.3. Maximum Transmission Unit Consideration . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Jeon, et al. Expires September 5, 2007 [Page 3] Internet-Draft IPoEth over IEEE 802.16 March 2007 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 while adopting the same data link principles also for mobile networking systems. This document describes the transmission of IPv4 as well as IPv6 over Ethernet in a network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging between the point-to-point radio links, which are provided by IEEE 802.16 between the base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the particularities of the IEEE 802.16 MAC for the realization of Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. 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 Access Router (AR): An entity that performs an IP routing function to provide IP connectivity for Subscriber Stations. Base Station (BS): A generalized equipment sets providing connectivity, management, and control of the subscriber station. Connection Identifier (CID): A 16 bit value that identifies a connection to equivalent peers in the MAC of the base station and 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 Jeon, et al. Expires September 5, 2007 [Page 4] Internet-Draft IPoEth over IEEE 802.16 March 2007 Service-specific Convergence Sublayer (CS): Sublayer in the IEEE 802.16 MAC layer which classifies external network data and associates them to the proper MAC service flow identifier and connection identifier. 4. The IEEE 802.16 Link Model 4.1. Connection Oriented Air Interface The IEEE 802.16 MAC establishes multiple connections between a BS and its associated SSs for the transfer of user data over the air. Each of these connections realize an individual Service Flow which is identified by a 16 bit CID number and has a defined QoS profile. Multiple connections can be established between a BS and a SS, each with its particular QoS class and direction. Despite of the BS and all the SS are identified by unique 48bit MAC addresses, packets going over the air are only carrying the CID number of the particular connection. The connections are established by MAC management messages between the BS and the SS during network entry or also later on demand. Unique cryptographic keys are generated during the initial authentication phase between the BS and each of the associated SSs to protect the data transmission over the air. While uplink connections from the SSs to the BS provide only unicast transmission capabilities from, downlink connections can be used for unicast transmission from the BS to a single SS as well as for multicast transmissions to a group of SSs. | | | | | | +--+--+ +--+--+ +--+--+ +--+-+-+--+ | 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 Jeon, et al. Expires September 5, 2007 [Page 5] Internet-Draft IPoEth over IEEE 802.16 March 2007 4.2. Feeding User Data into the Appropriate Connections Assignment of higher layer packets to particular service flows and related CIDs is performed by the convergence sublayer within the IEEE 802.16 MAC. It classifies the packets depending on the values of a defined subset of the payload packet header fields and assigns the packets to the appropriate service flow. To enable the transmission of different kind of payloads over IEEE 802.16, multiple convergence sublayers are defined, each specific for one kind of payload packet type, like Ethernet, IPv4, IPv6 or even for encapsulated payload, like IPv4 over Ethernet or IPv6 over Ethernet. 4.3. MAC addressing in IEEE 802.16 The 48-bit unique MAC address of a SS is used during the initial ranging process for the identification of a SS and is verified by the succeeding PKMv2 authentication phase. Out of it, the BS establishes a list of MAC addresses of all SSs connected to the BS purely for MAC management purposes. While MAC addresses exist for all the SSs as well as the BS the transfer of packets over the air is performed based only on the CID value. It enables the transport of arbitrary source and destination MAC addresses in Ethernet frames between a SS and its BS. This can be leveraged when there are additional MAC addresses to the SS MAC address in the case that the SS acts as an Ethernet bridge for a network behind the SS. Due to the defined mapping of the CIDs to the MAC address of the associated SS, the BS is able to bundle all connections belonging to a particular SS to a single connection on the network side to realize a plain layer 2 forwarding behaviour in the BS. 5. The IEEE 802.16 Network Model for Ethernet 5.1. IEEE 802.16 Ethernet Link Model According to [RFC2461], 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 over IEEE 802.16 by implementing bridging between all SSs with the IEEE 802.16 radio transmission system Jeon, et al. Expires September 5, 2007 [Page 6] Internet-Draft IPoEth over IEEE 802.16 March 2007 providing the point-to-point connections between the hosts and the bridge behind the BS. This is equivalent to today's switched Ethernet with twisted pair wires connecting the hosts to a bridge ("Switch") but in a IEEE 802.16 network the 'twisted pair wires' are usually implemented by per SS connections between the BS and a bridging function. The bridge must be able to create a new port whenever a new SS attaches to any of the BSs of the network or to remove a port when an associated SS detaches from the network. The BS forwards all the service flow belonging to one SS to one radio side port of a bridge behind the BSs. Not more than one SS should be connected to a port of the bridge. If the SS functions as a bridge for multiple hosts behind the SS (i.e. SS#4 in the below figure) then it should support bridging according to [IEEE802.1D] supporting efforts of [IEEE802.16k] between all its LAN ports and the air link. ------------------------ IP Link -------------------------- | | | | | | ETH ETH ETH ETH ETH ETH | | | | | | | | +---------+---------+ | +-+---+-+ | | | Bridge | | |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 Ethernet Link Model 5.2. Ethernet without Native Broadcast and Multicast Support Current IEEE 802.16 [IEEE802.16][IEEE802.16e] does not define any transport connection for IP broadcast and multicast data. Also, Multicast and Broadcast Service (MBS, stated in 6.3.23 of [IEEE802.16e]) cannot be used for the IP broadcast or multicast data because MBS is invisible to IP layer. Hence IP broadcast and Jeon, et al. Expires September 5, 2007 [Page 7] Internet-Draft IPoEth over IEEE 802.16 March 2007 multicast packets should be replicated and then carried via unicast transport connections as IEEE 802.16 access link. Bridge does the replication. 5.3. Segmenting the Ethernet into VLAN It is possible to restrict the size and coverage of an IP link by segmenting the Ethernet and grouping subsets of hosts into VLANs. Therefore, the bridge behind the BSs must be enabled to support VLANs according to [IEEE802.1Q] by assigning and handling the VLAN-IDs of the virtual bridge ports. If a SS itself contains a VLAN enabled bridge or is directly connected to a bridge supporting VLANs, the port associated with such a SS may be enabled as trunk port. On trunk ports, Ethernet frames are forwarded in the [IEEE802.1Q] frame format. 5.4. Deployment Scenarios for IP over Ethernet over IEEE 802.16 Figure 3 and 4 show the deployment scenarios in case of IP over Ethernet over IEEE 802.16. In both figures, an AR is connected to a bridge, which is connected to all BSs. The bridge becomes an aggregation point for all the connections from SSs. Multiple ARs can exist on a link, and an IP Link may consist of multiple hosts either being co-located with a SS or behind a SS connected a bridge. The network behind a SS can support various access network technologies, e.g. 802.3, 802.11 or 802.15. 5.4.1. Public Access Scenario Figure 3 depicts a public access scenario. In the general public access case, direct communication between nodes is restricted because of security and accounting issues and the AR is connected to a network side port of the bridge behind the BSs. In this scenario, the bridge forwards all packets received from any radio side port to all network side ports being in the forwarding state. Peer-to-peer communication is not supported by the bridge and all packets originated from a SS should be delivered to an AR. The AR performs a security filtering, policing and accounting of all traffic from hosts, like a NAS (Network Access Server). Jeon, et al. Expires September 5, 2007 [Page 8] Internet-Draft IPoEth over IEEE 802.16 March 2007 +--+ |SS| +--+* * * +----+ +--+ * | +-------+ |SS|* * * * **| BS +------+ \ +--+ * | +-----+ \ \ +---+ +--+ * +----+ \ \ +-+ B | |SS|* \ +--+ R | +--+ +---+ I | +----+ +----+ | D +---+ AR +--Internet |Host+ +--+ G | +----+ +----+\ +----+ / +-+ E | +----+ +------+--+ | +---+ / +---+ |Host+-+BRIDGE|SS|* * * *| BS | / +----+ +------+--+ * | +---+ +----+/ * +----+ |Host+ +--+ * +----+ |SS|* +--+ Figure 3. Public Access Scenario While the bridge forces all traffic from hosts to reach the AR, it still performs Learning Process and maintains Filtering Database as specified in [IEEE802.1D] and then forwards IP unicast packets from the AR based on the Filtering Database. However, IP broadcast and multicast packets are treated with special rules for Broadcast Data Forwarding and Multicast Data Forwarding as stated in Section 6.1. 5.4.2. Enterprise LAN Scenario The enterprise LAN scenario assumes trust relationship between all hosts and thus enables hosts to directly communicate each other without detouring. Multiple AR may be connected to a link, and ARs may reside on both sides of the network, on the network side of the bridge behind the BSs as well as behind a SS connected to a bridge. Figure 4 depicts the enterprise LAN scenario network model. IP unicast packets from either SSs or AR are forwarded by [IEEE802.1D] based bridging, and IP broadcast and multicast packets are processed on the bridge according to the Broadcast Data Forwarding Rules and Multicast Data Forwarding Rules presented in Section 6.1. Jeon, et al. Expires September 5, 2007 [Page 9] Internet-Draft IPoEth over IEEE 802.16 March 2007 +--+ |SS| +--+* * +----+ * +----+ +Host| +--+ * | +-------+ /+----+ |SS|* * * * **| BS +------+ \ / +----+ +--+ * | +-----+ \ \ +---+/ ++Host| +--+ * +----+ \ \ +-+ B + / +----+ |SS|* \ +--+ R ++ +----+ +--+ +---+ I | +----+ --+ AR ++ | D +---+ AR +--- +----+ \ +--+ G | +----+ \ +----+ / +-+ E | +----+ +------+--+ | +---+ / +---+ |Host+-+BRIDGE|SS|* * * *| BS | / +----+ +------+--+ * | +---+ +----+/ * +----+ |Host+ +--+ * +----+ |SS|* +--+ Figure 4. Enterprise LAN Scenario 6. Bridge Considerations This section discusses operations of the bridge behind the BSs 6.1. Multicast and Broadcast Packet Processing All multicast and multicast control messages shall be processed in the bridge according to [RFC4541]. Broadcasting messages to all radio side ports of the bridge SHOULD be prevented. Further details on prevention of broadcasting messages to all radio side ports are given in the following sections. 6.1.1. Multicast Transmission Considerations Bridge copies the IP multicast packets, like IP broadcast, and forwards into all its available ports, but an incoming port. As a result, the IP multicast packets can be transmitted to SSs which do not participate in the corresponding multicast group. This is why IP multicast membership should be propagated between bridges [RFC4541] describes Internet Group Management Protocol (IGMP) and Jeon, et al. Expires September 5, 2007 [Page 10] Internet-Draft IPoEth over IEEE 802.16 March 2007 Multicast Listener Discovery (MLD) snooping switches. The IGMP/MLD snooping switches examine IGMP/MLD report messages and creates a multicast address entry in its forwarding table. Followings summarize two main processes of IGMP/MLD snooping switches (i.e. bridge). IGMP and MLD Forwarding Rules: A snooping switch that creates a new multicast address entry in its forwarding table with received report messages forwards the report messages only to those ports where multicast routers are attached. The multicast entry can be removed by receiving corresponding IGMP Leave Group/MLD Done messages or timeout mechanism. Multicast Data Forwarding Rules: Packets with a destination IP address outside 224.0.0.0/24 in IPv4 or for IPv6 multicast address with scope 2 or greater except FF02::1 (link-local scope all-nodes multicast address) are forwarded according to the previously created forwarding table and also forwarded on multicast router ports. An unregistered IP multicast packets that does not match any of entries in the forwarding table should be forwarded on ports where multicast routers are attached. 6.1.2. Broadcast Transmission Considerations Bridge floods the IP broadcast packets out of all connected ports except that on which the packets was received. This behaviour in not appropriate with scarce resources and dormant-mode hosts in a wireless network such as IEEE 802.16 based access network. This document defines following forwarding rules on bridges for filtering the IP broadcast data. Note that packets destined for permanently assigned multicast addresses such as 224.0.0.0/24 in IPv4 or FF02::1 in IPv6 are regarded as broadcast data. Broadcast Data Forwarding Rules: The bridge discards all IP broadcast packets except ARP, DHCP (DHCPv4 and DHCPv6), IGMP, and MLD related traffic. The ARP, DHCP, IGMP and MLD related packets received on radio side are forwarded only towards access router, not another radio sides. On the other hand, the allowed IP broadcast packets received on the network side are forwarded on all ports except their incoming port. 6.2. Proxy ARP Proxy ARP provides a process where a device connecting between hosts answers ARP Requests instead of a remote host. In this document, the Proxy ARP is used to force traffic from hosts to access router and avoid broadcasting ARP Requests over the air depending on the particular deployment scenario. A bridge behind the BSs performs the Jeon, et al. Expires September 5, 2007 [Page 11] Internet-Draft IPoEth over IEEE 802.16 March 2007 Proxy ARP process. 6.2.1. Public Access Scenario Case A bridge behind the BSs filters broadcast ARP Requests and responds to all the ARP Requests from radio side port with access router's Ethernet address so that all IPv4 packets from SSs are forwarded to the access router in the public access scenario. Learning the IP and Ethernet address of the access router on bridge follows Section 3.1 in [RFC4562]. 6.2.2. Enterprise LAN Scenario Case The bridge behind the BSs maintains an ARP Cache. The ARP Cache has a sufficient size to accommodate ARP entries for all its serving SSs and is updated by any packets including ARP Requests from SSs like its Filtering Database. Upon receiving the ARP Requests from SSs, the bridge unicasts ARP Replies back to SSs with Ethernet address of target host provided that the target address matches an entry in the ARP Cache. Otherwise, the bridge floods the ARP Requests. The bridge silently discard any received self-ARP Requests. 7. Access Router Considerations In the public access scenario, all packets between SSs will always be relayed via access router. In this situation, the access router may forward packets via same interface on which the access router received the packets. This results in Redirect message from the access router [RFC0792][RFC2461]. Access router in the public access scenario disables above the Redirect function on the interface to which SSs attach. 8. Prefix Assignment 8.1. IPv4 over Ethernet All SSs under the same AR share a single subnet prefix. Sharing the prefix means locating all SSs on the same subnet and it benefits from high address assignment efficiency when concerning scarce IPv4 address space. The prefix can be manually configured or automatically with subnet mask option in DHCPv4 [RFC2132]. Jeon, et al. Expires September 5, 2007 [Page 12] Internet-Draft IPoEth over IEEE 802.16 March 2007 8.2. IPv6 over Ethernet In the enterprise LAN scenario, a single subnet prefix has an advantage over multiple subnet prefixes in simplifying management. However, assignment of unique prefix per SS can be considered in the public access scenario because it forces all packets from SSs to be transferred to an access router. Access router assigns IPv6 prefixes with Prefix Information option as specified in [RFC2461]. 9. Transmission of IP over Ethernet 9.1. IPv4 over Ethernet [RFC0894] defines the transmission of IPv4 packets over Ethernet networks. It contains the specification of the encapsulation of the IPv4 packets into Ethernet frames as well as rules for mapping of IP addresses onto Ethernet MAC addresses. This document follows the operations specified in [RFC0894]. 9.1.1. Address Configuration IPv4 addresses are configured manually or assigned dynamically from DHCPv4 server [RFC2131]. DHCP clients may send DHCP DISCOVER and DHCP REQUEST messages with the BROADCAST bit set to request the DHCP server to broadcast its DHCP OFFER and DHCP ACK messages. The bridge filters these broadcast DHCP OFFER and DHCP ACK messages and forwards the broadcast messages only to the host defined by the client hardware address in the chaddr information element. Alternatively, the DHCP Relay Agent Information Option (option-82) [RFC3046] may be used to avoid DHCP broadcast replies. The option-82 consists of two type of sub-options; Circuit ID and Remote ID. DHCP Relay Agent is located on bridges as Layer 2 DHCP Relay Agent in [TR101]. Bridge port number is possible as Circuit ID and Remote ID may be left unspecified. Note that using option-82 has a requirement that DHCP servers should be aware of the option-82. 9.1.2. Address Resolution SSs use Address Resolution Protocol (ARP) [RFC0826] for finding a destination's Ethernet MAC address. Jeon, et al. Expires September 5, 2007 [Page 13] Internet-Draft IPoEth over IEEE 802.16 March 2007 9.2. IPv6 over Ethernet [RFC2464] defines transmission of IPv6 Packets over Ethernet Networks. Encapsulation of IPv6 packets into Ethernet frames and mapping rules for IPv6 address to Ethernet address (i.e. MAC address) follow [RFC2464]. 9.2.1. Router Discovery, Prefix Discovery and Parameter Discovery Router Discovery, Prefix Discovery and Parameter Discovery procedures are achieved by receiving Router Advertisement messages. In this document, SSs perform above the discovery process by solicited Router Advertisement messages because periodic Router Advertisement messages are discarded on the bridges following the Broadcast Data Forwarding Rules in Section 6.1.2. 9.2.2. Address Configuration 9.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. 9.2.2.2. Stateless Address Autoconfiguration The global IPv6 addresses are derived based on prefix and EUI-64- derived interface identifier and then confirmed through Duplicate Address Detection (DAD) as specified in [RFC2462]. 9.2.3. Address Resolution SS sends Neighbor Solicitation destined for solicited-node address corresponding to the target address in order to determine MAC address of a neighbor and then resolves the MAC address by receiving Neighbor Advertisement as specified in [RFC2461]. 9.3. Maximum Transmission Unit Consideration [RFC2460] requires that link layer support a minimum Maximum Transmission Unit (MTU) size of 1280 bytes and recommends the MTU of at least 1500 bytes be configured for IPv6 over Ethernet transmission. [RFC0894] also specifies 1500 bytes as a maximum length of IPv4 over Ethernet. Therefore, IEEE 802.16 frame should carry a payload size of 1518 bytes including the Ethernet header size of 18 bytes or 1522 bytes including additional VLAN tag size of 4 bytes if present. Jeon, et al. Expires September 5, 2007 [Page 14] Internet-Draft IPoEth over IEEE 802.16 March 2007 The Length field in IEEE 802.16 MAC header has a size of 11 bits and indicates length in bytes of the MAC PDU including CRC and MAC header. Hence PDU size is up to 2048 bytes and the maximum size of payload is 2038 bytes by subtracting size of CRC and MAC header from 2048 bytes. The maximum size of payload is sufficient to carry IPv4 over Ethernet or IPv6 over Ethernet and thus the MTU of IPv4 and IPv6 is the same as specified in [RFC0894] and [RFC2460] respectively. 10. Security Considerations This document does not introduce new vulnerability to operations of IPv4 over Ethernet and IPv6 over Ethernet. [RFC3971] can be adopted for securing neighbor discovery processes. 11. Acknowledgments We would like to express special thanks to David Johnston and Dave Thaler for their inputs to this work. 12. References [I-D.ietf-16ng-ps-goals] Jee, J., "IP over 802.16 Problem Statement and Goals", draft-ietf-16ng-ps-goals-01 (work in progress), February 2007. [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. [IEEE802.16k] IEEE 802.16's Network Management Task Group: 802.16k Pro ject, "http://www.ieee802.org/netman/16k.html". [IEEE802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", June 2004. Jeon, et al. Expires September 5, 2007 [Page 15] Internet-Draft IPoEth over IEEE 802.16 March 2007 [IEEE802.1Q] IEEE Std 802.1Q-2005, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks", May 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. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [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. [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, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006. Jeon, et al. Expires September 5, 2007 [Page 16] Internet-Draft IPoEth over IEEE 802.16 March 2007 [TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", April 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 September 5, 2007 [Page 17] Internet-Draft IPoEth over IEEE 802.16 March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 September 5, 2007 [Page 18]