Network Working Group HS. Jeon Internet-Draft ETRI Intended status: Standards Track M. Riegel Expires: January 10, 2008 NSN SJ. Jeong ETRI July 9, 2007 Transmission of IP over Ethernet over IEEE 802.16 Networks draft-ietf-16ng-ip-over-ethernet-over-802.16-02.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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging between point-to-point radio links, which are provided by IEEE 802.16 between the base station and Jeon, et al. Expires January 10, 2008 [Page 1] Internet-Draft IPoEth over IEEE 802.16 July 2007 its 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 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 January 10, 2008 [Page 2] Internet-Draft IPoEth over IEEE 802.16 July 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. Ethernet Network Model for IEEE 802.16 . . . . . . . . . . . . 6 5.1. IEEE 802.16 Ethernet Link Model . . . . . . . . . . . . . 6 5.2. Ethernet without Native Broadcast and Multicast Support . 8 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 . . . . . . . . 11 6.1.2. Broadcast Transmission Considerations . . . . . . . . 11 6.2. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. Public Access Scenario Case . . . . . . . . . . . . . 12 6.2.2. Enterprise LAN Scenario Case . . . . . . . . . . . . . 12 7. Access Router Considerations . . . . . . . . . . . . . . . . . 12 8. Prefix Assignment . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Public Access Scenario Case . . . . . . . . . . . . . . . 13 8.2. Enterprise LAN Scenario Case . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Multicast CID Deployment Considerations . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Jeon, et al. Expires January 10, 2008 [Page 3] Internet-Draft IPoEth over IEEE 802.16 July 2007 1. Introduction IEEE 802.16 [IEEE802.16] defines a PMP (Point-to-Multipoint) radio transmission system connecting a BS (Base Station) with multiple SSs (Subscriber Stations). 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. Ethernet is a widely deployed transmission technology. It provides unicast transport, handles broadcast and multicast traffic efficiently and provides rich services such as Virtual LANs. However, Ethernet has been originally architected and designed for a shared medium without special considerations for advanced wireless transmission systems. The focus on wired systems requires additional support functions when Ethernet is employed in the IEEE 802.16. This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access 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 BS and its associated SSs. With the resource constraints of radio transmission systems and the particularities of the IEEE 802.16 MAC for the realization of Ethernet, it makes sense to add IP specific support functions in the Ethernet layer above IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. Those IP specific support functions are preferable realized in a centralized device containing also the bridge for aggregation of traffic from all the BSs to provide a more straightforward management solution and allow for effectively commoditized BSs, which are deployed in the IEEE 802.16 based access network in large volume. 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 The terminology in this document is based on the definitions in IP over 802.16 Problem Statement and Goals [I-D.ietf-16ng-ps-goals]. Jeon, et al. Expires January 10, 2008 [Page 4] Internet-Draft IPoEth over IEEE 802.16 July 2007 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. Although the BS and all the SS are associated with unique 48-bit MAC addresses, packets going over the air are only identified in the IEEE 802.16 MAC header by 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, downlink connections can be used for multicast transmission to a group of SSs as well as unicast transmission from the BS to a single SS. The use of multicast CIDs for realizing mulicast transmissions, however, is depreciated because of the reduced transmission efficiency in smaller groups and the complexity of the management of mulitcast CIDs in the BSs as well as in the SSs. Appendix A provides an overview about the issues arising with multicast CIDs in IEEE 802.16 systems. | | | | | | +--+--+ +--+--+ +--+--+ +--+-+-+--+ | 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 January 10, 2008 [Page 5] Internet-Draft IPoEth over IEEE 802.16 July 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 of the values in the defined set 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 the successful authentication, the BS establishes and maintains the list of attached SSs based on their MAC addresses purely for MAC management purposes. While MAC addresses are assigned to all the SSs as well as to the BS the forwarding of packets over the air is performed only on base of the CID value. Not relying on the MAC addresses in the payload for reception of a radio frame allows for the transport of arbitrary source and destination MAC addresses in Ethernet frames between a SS and its BS. This is beneficial when Ethernet frames with arbitrary MAC addresses have to be forwarded to an SS in the case that the SS contains an Ethernet bridge for a network behind the SS. Due to the managed assignment of the service flows and associated CID values to individual SSs, the BS is able to bundle all connections belonging to a particular SS to a single link towards the bridge on the network side to provide plain layer 2 forwarding behaviour in the BS between the radio link towards the SS and its associated wired link on the network side. 5. Ethernet Network Model for IEEE 802.16 5.1. IEEE 802.16 Ethernet Link Model According to [I-D.ietf-ipv6-rfc2461bis], 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 but does not enable any direct SS to SS connectivity. Jeon, et al. Expires January 10, 2008 [Page 6] Internet-Draft IPoEth over IEEE 802.16 July 2007 Ethernet is realized over IEEE 802.16 by implementing bridging according to [IEEE802.1D] and its amendment [IEEE802.16k] between all SSs based on the IEEE 802.16 Ethernet link model, which provides point-to-point connections between the hosts and the bridge behind the BS as shown in Figure 2. This is equivalent to today's switched Ethernet with twisted pair wires connecting the hosts to a bridge ("Switch").In the IEEE 802.16 Ethernet link model, the BS forwards the radio links into wired links towards the bridge. Separation of multiple links on the connection between the BS and the bridge can be achieved by deploying flow identifiers (e.g. VLAN-IDs or GRE KEYS) on the wired path. The BS SHALL forward all the Service Flows belonging to one SS to one radio side port of a bridge according to [IEEE802.1D] and its amendment [IEEE802.16k] behind the BSs. No more than one SS SHALL be connected to one port of the bridge. The bridge SHOULD 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. If the SS functions as a bridge for multiple hosts behind the SS (i.e. SS#4 in the below figure) then the SS SHOULD support bridging according to [IEEE802.1D] and its amendment [IEEE802.16k] between all its LAN ports and the IEEE 802.16 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 Jeon, et al. Expires January 10, 2008 [Page 7] Internet-Draft IPoEth over IEEE 802.16 July 2007 5.2. Ethernet without Native Broadcast and Multicast Support Current IEEE 802.16 [IEEE802.16][IEEE802.16e] does not define broadcast and multicast of IP packets. Also, MBS (Multicast and Broadcast Service as specified in 6.3.23 of [IEEE802.16e]) does not cover IP broadcast or multicast data because MBS is invisible to IP layer. Furthermore MBS has severe radio and management issues, as discussed in Appendix A. Hence IP broadcast and multicast packets SHOULD be replicated and then carried via unicast transport connections as IEEE 802.16 access link. As specified in Section 6, the bridge performs the replication and forwarding. 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 MAY 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 This section discusses the two possible deployment scenarios in case of IP over Ethernet over IEEE 802.16: Public Access scenario and Enterprise LAN scenario. In both scenarios, an AR is connected to a bridge, which is connected to all BSs. The bridge acts as 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 to a bridge. The network behind a SS can support various access network technologies, e.g. 802.3, 802.11 or 802.15. There is a big difference between the scenarios in terms of the service provider policies. The difference is also reflected in Section 6.2 and Section 8. 5.4.1. Public Access Scenario In the Public Access scenario, direct communication between nodes is restricted because of security and accounting issues. Figure 3 depicts the public access scenario. Jeon, et al. Expires January 10, 2008 [Page 8] Internet-Draft IPoEth over IEEE 802.16 July 2007 In the scenario, the AR is connected to a network side port of the bridge behind the BSs. The bridge SHOULD forward all packets received from any radio side port to all network side ports being in the forwarding state. Peer-to-peer communication SHOULD NOT be supported by the bridge and all packets originated from a SS SHOULD be delivered to an AR. The AR SHOULD perform security filtering, policing and accounting of all traffic from hosts, e.g. like a NAS (Network Access Server). +--+ |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 SHOULD be treated with special rules 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 with each other without detouring. Multiple ARs may be connected to a link, and ARs Jeon, et al. Expires January 10, 2008 [Page 9] Internet-Draft IPoEth over IEEE 802.16 July 2007 may reside on both sides of the radio link, 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 SHALL be forwarded by [IEEE802.1D] based bridging. IP broadcast and multicast packets SHOULD be processed in the bridge according to rules presented in Section 6.1. +--+ |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 SHOULD be processed in the bridge according to [RFC4605]. Broadcasting messages to all radio side ports of the bridge SHOULD be prevented. Further information on prevention of multicasting or broadcasting messages to all radio side ports are given in the following sections. Jeon, et al. Expires January 10, 2008 [Page 10] Internet-Draft IPoEth over IEEE 802.16 July 2007 6.1.1. Multicast Transmission Considerations Usually, the bridge replicates the IP multicast packets like IP broadcast packets into all its available ports with the exception of the incoming port. As a result, the IP multicast packets would be transmitted even to SSs which do not participate in the corresponding multicast group. To allow bridges to handle IP multicast more efficiently the IP multicast membership should be propagated between bridges. IGMP/MLD proxying in [RFC4605] is a simple mechanism for multicast packets forwarding based on the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information, which works only in a basic tree topology. An IGMP/MLD proxy device does learning and proxying group membership information and forwards the IP multicast packets based on the membership information. Typically, the proxy device is located at an aggregation point, which has a single upstream interface and multiple downstream interfaces. The IEEE 802.16 Ethernet link model in Section 5.1 has a simple tree topology and [RFC4541] provides an application guide how bridge, non-IP device, to examine and learn group membership. Hence, [RFC4605] can be applied to the IEEE 802.16 Ethernet link model to reduce the multicast packet flooding. The bridge in the IEEE 802.16 Ethernet link model SHOULD play a role in proxying IGMP/MLD messages as specified in [RFC4605]. The bridge SHOULD perform the host portion of IGMP/MLD process on its network side port and the router portion of IGMP/MLD process on its all radio side ports. Note that the bridge SHOULD perform IGMP/MLD Querier on only radio side ports, which are already subscribed with received IGMP/MLD membership report messages. This is due to the reduction of flooding of IGMP/MLD Query messages. The bridge SHOULD maintain subscription information on each radio side port with received IGMP/ MLD membership report messages and forward multicast packets from a network side port to radio side ports based on the subscription information. In case of multicast packets from radio side ports, the bridge SHOULD forward the packets to a network side port as well as radio side ports, except the incoming radio side port, based on the subscription information. 6.1.2. Broadcast Transmission Considerations The bridge typically floods the IP broadcast packets out of all connected ports except the port on which the packet was received. This behaviour in not appropriate with scarce resources and dormant- mode hosts in a wireless network such as an IEEE 802.16 based access network. Jeon, et al. Expires January 10, 2008 [Page 11] Internet-Draft IPoEth over IEEE 802.16 July 2007 The bridge in the IEEE 802.16 Ethernet link model SHOULD discard all IP broadcast packets except ARP, DHCP (DHCPv4 and DHCPv6), IGMP, and MLD related traffic. The ARP, DHCP, IGMP and MLD related packets SHOULD be forwarded with special rules specified in this specification. Note that packets destined for permanently assigned multicast addresses such as 224.0.0.0/24 in IPv4 or FF02::1 in IPv6 are also regarded as broadcast data. 6.2. Proxy ARP Proxy ARP provides a process where a device on the link between hosts answers ARP Requests instead of the remote host. In this specification, the Proxy ARP mechanism is used to force all traffic from hosts to the access router and to avoid broadcasting ARP Requests over the air depending on the particular deployment scenario. The Proxy ARP process is usually co-located with the bridge behind the BS. 6.2.1. Public Access Scenario Case The bridge behind the BSs SHOULD filter broadcast ARP Requests and SHOULD respond to all the ARP Requests from radio side port with the access router's Ethernet MAC address so that all IPv4 packets from SSs are forwarded to the access router. 6.2.2. Enterprise LAN Scenario Case The bridge behind the BSs SHOULD maintain an ARP Cache large enough to accommodate ARP entries for all its serving SSs. The ARP Cache SHOULD be updated by any packets including ARP Requests from SSs in the same way the bridge is updating its Filtering Database. Upon receiving the ARP Requests from SSs, the bridge SHOULD unicast 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 MAY flood the ARP Requests. The bridge SHOULD 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 scenario, the access router SHOULD forward packets via same interface on which the access router received the packets, if source and destination addresses are reachable on the same interface. This would result in a Redirect message from the access router [RFC0792][I-D.ietf-ipv6-rfc2461bis]. The Redirect message SHOULD be suppressed. Jeon, et al. Expires January 10, 2008 [Page 12] Internet-Draft IPoEth over IEEE 802.16 July 2007 8. Prefix Assignment 8.1. Public Access Scenario Case Unique IPv6 prefix per SS SHOULD be assigned because it results in layer 3 separation between SSs and it forces all packets from SSs to be transferred to an AR. The AR SHOULD assign the IPv6 prefixes with Prefix Information option as specified in [RFC2461]. One IPv4 prefix SHOULD be assigned to all SSs in a way that 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]. 8.2. Enterprise LAN Scenario Case The AR SHOULD assign all SSs one IPv4 prefix in IPv4 over Ethernet and one or more IPv6 prefixes in IPv6 over Ethernet so that all SSs under the same AR share the subnet prefix. Sharing the prefix means locating all SSs on the same subnetwork. 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. IP over Ethernet over IEEE802.16 MUST follow the operations specified in [RFC0894]. 9.1.1. Address Configuration IPv4 addresses can be 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 SHOULD filter 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 usually located on bridges as Layer 2 DHCP Relay Jeon, et al. Expires January 10, 2008 [Page 13] Internet-Draft IPoEth over IEEE 802.16 July 2007 Agent, like described in [TR101]. Bridge port number is possible as Circuit ID and Remote ID may be left unspecified. Note that using option-82 requires option-82 aware DHCP servers. 9.1.2. Address Resolution SSs MUST use Address Resolution Protocol (ARP) [RFC0826] for finding a destination's Ethernet MAC address. 9.2. IPv6 over Ethernet [RFC2464] defines transmission of IPv6 Packets over Ethernet Networks. In this document, encapsulation of IPv6 packets into Ethernet frames and mapping rules for IPv6 address to Ethernet address (i.e. MAC address) MUST 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 specification, 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 SS SHOULD derive its global IPv6 addresses based on prefix and EUI- 64-derived interface identifier and then confirmed through Duplicate Address Detection (DAD) as specified in [I-D.ietf-ipv6-rfc2462bis] and [I-D.ietf-ipv6-rfc2461bis]. 9.2.3. Address Resolution SS SHOULD send Neighbor Solicitation destined for solicited-node address corresponding to the target address in order to determine MAC address of a neighbor and then resolve the MAC address by receiving Neighbor Advertisement as specified in [I-D.ietf-ipv6-rfc2461bis]. Jeon, et al. Expires January 10, 2008 [Page 14] Internet-Draft IPoEth over IEEE 802.16 July 2007 9.3. Maximum Transmission Unit Consideration [RFC2460] requires that the link layer support a minimum Maximum Transmission Unit (MTU) size of 1280 bytes and recommends a MTU size of at least 1500 bytes 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. 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 MAC PDU size is up to 2048 bytes and the maximum size of payload is 2038 bytes by subtracting size of CRC and IEEE 802.16 MAC header from 2048 bytes. Since the size of MAC PDU is sufficient to encapsulate an Ethernet packet carrying IP data size of 1500 bytes, the size of the largest IPv4 and IPv6 packets over Ethernet over IEEE 802.16 SHOULD be 1500 bytes 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 The authors would like to thank David Johnston, Dave Thaler, and others for their inputs to this work. 12. References 12.1. Normative 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. [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. [I-D.ietf-ipv6-rfc2462bis] Jeon, et al. Expires January 10, 2008 [Page 15] Internet-Draft IPoEth over IEEE 802.16 July 2007 Thomson, S., "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress), May 2005. [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. [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. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for Jeon, et al. Expires January 10, 2008 [Page 16] Internet-Draft IPoEth over IEEE 802.16 July 2007 IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. 12.2. Informative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 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, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", April 2006. Appendix A. Multicast CID Deployment Considerations IEEE 802.16 allows for downlink CIDs associated to multiple SSs to support efficient transport of multicast and broadcast data. While this looks in theory promising for solving the issue of the scarce radio resource it introduces a number of issues in real deployments: o Incompatibility with advanced radio layer algorithms based on feedback information from the receiver: Many of the most advanced algorithms for enhancing the capacity of radio links like HARQ, Interference cancellation or MIMO are based on feedback from the receiver side and do not work with multiple receivers on the same CID. o Incompatibility with advanced antenna systems: Advanced antenna systems deploy multiphase antenna arrays to direct the transmission to the particular receiver. Advanced antenna systems work well with unicast links but the state of the art is not able to support efficiently multicast links. Jeon, et al. Expires January 10, 2008 [Page 17] Internet-Draft IPoEth over IEEE 802.16 July 2007 o Increased interference level due to higher transmission power for multicast links: Multicast links can not deploy advanced radio layer algorithms like HARQ and therefore have to use higher transmission power level to generate the signal to noise ratio required for error-free detection. Higher transmission power also increases the interference level in the cell as well as in neighbor cells, which reduces the overall capacity of a cell. o Reduced efficiency with mobile terminals: A multicast CID must be configured to provide sufficient signal to noise ratio to the most distant terminal. If terminals are moving, the radio transmission characteristics may change and may require frequent re-adjustments of the radio link parameters. As more moving terminals are associated with a multicast CID as more likely the link conditions require high reserves to keep all terminals permanently connected. o Loss of power-down capabilities: Terminals associated to a multicast CID have to wake up and decode the frames whenever frames as send. This makes it difficult to keep terminals for longer periods in low power consumption states. o Increased complexity of the system: Each multicast CID requires its own encryption key. This requires that SSs have to have the capability to establish and maintain multiple encryption keys. The BS requires for each of the multicast CIDs an instance of the group key management system. Taking the many drawbacks of multicast CIDs into account, the high complexity and low transmission efficiency restricts the usability for only exceptional cases when power consumption of SSs is no issue, when SSs are hardly moving and when multicast CIDs are serving a high number of SSs concurrently. All these conditions are hardly fulfilled in today's mobile networking environment with small cell sizes, fast moving terminals and a huge variety of information sources which makes it unlikely that two users in a cell are requesting concurrently the same information. Jeon, et al. Expires January 10, 2008 [Page 18] Internet-Draft IPoEth over IEEE 802.16 July 2007 Authors' Addresses HongSeok Jeon Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-3892 Email: hongseok.jeon@gmail.com Max Riegel Nokia Siemens Networks St-Martin-Str 76 Munich, 81541 Germany Phone: +49-89-636-75194 Email: maximilian.riegel@nsn.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 January 10, 2008 [Page 19] Internet-Draft IPoEth over IEEE 802.16 July 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 January 10, 2008 [Page 20]