Network Working Group H. Jeon Request for Comments: 5692 S. Jeong Category: Standards Track ETRI M. Riegel NSN October 2009 Transmission of IP over Ethernet over IEEE 802.16 Networks
AbstractThis 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 connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (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. Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
1. Introduction ....................................................4 2. Requirements ....................................................4 3. Terminology .....................................................4 4. The IEEE 802.16 Link Model ......................................4 4.1. Connection-Oriented Air Interface ..........................4 4.2. MAC Addressing in IEEE 802.16 ..............................5 4.3. Unidirectional Broadcast and Multicast Support .............6 4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet ......6 5. Ethernet Network Model for IEEE 802.16 ..........................6 5.1. IEEE 802.16 Ethernet Link Model ............................7 5.2. Ethernet without Native Broadcast and Multicast Support ....8 5.3. Network-Side Bridging Function .............................8 5.4. Segmenting the Ethernet into VLANs .........................9 6. Transmission of IP over Ethernet over IEEE 802.16 Link ..........9 6.1. Generic IP over Ethernet Network Scenario ..................9 6.2. Transmission of IP over Ethernet ..........................10 6.2.1. IPv4-over-Ethernet Packet Transmission .............10 6.2.2. IPv6-over-Ethernet Packet Transmission .............11 6.2.3. Maximum Transmission Unit ..........................11 6.2.4. Prefix Assignment ..................................11 7. Operational Enhancements for IP over Ethernet over IEEE 802.16 .........................................................12 7.1. IP Multicast and Broadcast Packet Processing ..............12 7.1.1. Multicast Transmission Considerations ..............12 7.1.2. Broadcast Transmission Considerations ..............12 7.2. DHCP Considerations .......................................13 7.3. Address Resolution Considerations .........................13 8. Public Access Recommendations ..................................14 9. Security Considerations ........................................15 10. Acknowledgments ...............................................16 11. References ....................................................16 11.1. Normative References .....................................16 11.2. Informative References ...................................17 Appendix A. Multicast CID Deployment Considerations ..............19 Appendix B. Centralized vs. Distributed Bridging ................19
802.16] specifies a fixed-to-mobile, broadband wireless access system. The IEEE 802.16 standard defines a packet CS (Convergence Sublayer) for interfacing with specific packet-based protocols as well as a generic packet CS (GPCS) to provide an upper-layer, protocol- independent interface. This document describes transmission of IPv4 and IPv6 over Ethernet via the Ethernet-specific part of the packet CS as well as of the GPCS in the access network based on IEEE 802.16. Ethernet has been originally architected and designed for a shared medium while the IEEE 802.16 uses a point-to-multipoint architecture like other cellular radio transmission systems. Hence, Ethernet on top of IEEE 802.16 is realized by bridging between IEEE 802.16 radio connections that connect a BS (Base Station) and its associated SSs (Subscriber Stations). Under the resource constraints of radio transmission systems and the particularities of the IEEE 802.16 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. RFC2119]. RFC5154].
the SSs 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. [Subscriber Side] [Network Side] | | | + | | | + +--+--+ +--+--+ +--+-+-+--+ | MAC | | MAC | | MAC | +-----+ +-----+ +---------+ | PHY | | PHY | | PHY | +-+-+-+ +-+-+-+ +-+-+-+-+-+ + + | | | | + + + + | +-----CID#w------+ | + + + + +-------CID#x--------+ + + + +++++++++++++++++CID#y+++++++++++++++++ + +++++++++++++++++++CID#z+++++++++++++++++++ SS#1 SS#2 BS Figure 1: Basic IEEE 802.16 Link Model Figure 1, so that it provides a single layer-2 link between the SS and its associated wired link on the network side.
802.16] does not support bidirectional native broadcast and multicast for IP packets. While 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, uplink connections from the SSs to the BS provide only unicast transmission capabilities. Furthermore, the use of multicast CIDs for realizing downlink multicast transmissions is not necessarily preferable due to the reduced transmission efficiency of multicast CIDs for small multicast groups. Appendix A provides more background information about the issues arising with multicast CIDs in IEEE 802.16 systems. MBS (Multicast and Broadcast Service), as specified in IEEE 802.16, also does not cover IP broadcast or multicast data because MBS is invisible to the IP layer.
Figure 2. This is equivalent to today's switched Ethernet with twisted pair wires or fibres connecting the hosts to a bridge ("Switch"). The network-side bridging function can be realized either by a single centralized network-side bridge or by multiple interconnected bridges, preferably arranged in hierarchical order. The single centralized network-side bridge allows best control of the broadcasting and forwarding behavior of the Ethernet over IEEE 802.16. Appendix B explains the issues of a distributed bridging architecture when no assumptions about the location of the access router can be made. The BS MUST forward all the service flows belonging to one SS to one port of the network-side bridging function. No more than one SS MUST be connected to one port of the network-side bridging function. The separation method for multiple links on the connection between the BS and the network-side bridging function is out of scope for this document. Either layer-2 transport or layer-3 tunneling may be used. If the Ethernet over IEEE 802.16 is extended to multiple end stations behind the SS (i.e., SS#4 in the figure below), then the SS SHOULD support bridging according to [802.1D] and its amendment [802.16k], a.k.a. subscriber-side bridge, between all its subscriber-side ports and the IEEE 802.16 air link.
------------------------ IP Link -------------------------- [Subscriber Side] [Network Side] [Subscriber Side] | | | | | | ETH ETH ETH ETH ETH ETH | | | | | | | | +---------+---------+ | +-+---+-+ | | | Bridging Function | | |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 802.1D] and its amendment [802.16k] to interconnect the attached SSs and pass Ethernet frames between the point-to-point connections associated with the attached SSs. However, to enhance the IEEE 802.16 Ethernet link model by avoiding broadcast or multicast packet flooding,
additional IP-specific functionalities MAY be provided by the network-side bridging function in addition to the mandatory functions, according to Section 5.1 of [802.1D]. 802.1Q] by assigning and handling the VLAN-IDs on the virtual bridge ports. If an SS is directly connected to a subscriber-side bridge supporting VLANs, the port associated with such an SS MAY be enabled as trunk port. On trunk ports, Ethernet frames are forwarded in the [802.1Q] frame format. Figure 3.
+--+--+ ---|AR|SS| +--+--+* +----+ * +----+ +Host| +----+--+ * | +-------+ /+----+ |Host|SS|* * * * **| BS +------+ \ / +----+ +----+--+ * | +-----+ \ \ / ++Host| +----+--+ * +----+ \ \ +-+--------+ / +----+ |Host|SS|* \ +--+ ++ +----+ +----+--+ +---+Bridging| +----+ --+ AR ++ |Function+---+ AR +--- +----+ \ +--+ | +----+ \ +----+ / +-+--------+ +----+ +------+--+ | +---+ / |Host+-+Bridge|SS|* * * *| BS | / +----+ +------+--+ * | +---+ +----+/ * +----+ |Host+ +----+--+ * +----+ |Host|SS|* +----+--+ Figure 3: Generic IP over Ethernet Network Scenario Using IEEE 802.16 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 IP addresses onto Ethernet MAC addresses. Hosts transmitting IPv4 over Ethernet packets over the IEEE 802.16 MUST follow the operations specified in [RFC0894]. RFC2131]. RFC0826] MUST be used for finding the destination Ethernet MAC address.
RFC2464] defines transmission of IPv6 packets over Ethernet networks, which includes an encapsulation of IPv6 packets into Ethernet frames; that document includes rules for mapping IPv6 addresses to Ethernet addresses (i.e., MAC addresses). Hosts transmitting IPv6-over-Ethernet packets over IEEE 802.16 MUST follow the operations specified in [RFC2464]. Section 8.3 in [RFC5121]. RFC3315] MUST be performed. In this case, an AR supports a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server or relay function. When stateless address autoconfiguration is required, the stateless address configuration according to [RFC4862] and [RFC4861] MUST be performed. RFC4861] MUST be used for determining the destination Ethernet MAC address. RFC2460] mandates 1280 bytes as a minimum Maximum Transmission Unit (MTU) size for the link layer and recommends at least 1500 bytes for IPv6 over Ethernet transmission. [RFC0894] also specifies 1500 bytes as a maximum length of IPv4 over Ethernet. Therefore, the default MTU of IPv6 packets and IPv4 packets on an Ethernet over IEEE 802.16 link MUST be 1500 bytes.
as well. The same IPv4 prefix and the same set of IPv6 prefixes MAY be assigned to all hosts attached to the Ethernet over IEEE 802.16 to make best usage of Ethernet behavior. Sharing the prefix means locating all hosts on the same subnetwork. RFC4541]. Broadcasting messages to all radio-side side ports SHOULD be prevented. Further information on the prevention of multicasting or broadcasting messages to all radio-side ports is given in the following sections. Section 5.1, the network- side bridging function can process all multicast data and multicast control messages according to [RFC4541] in order to maintain IP multicast membership states and forward IP multicast data to only ports suitable for the multicast group.
IGMP-related broadcast packets can be forwarded according to the [RFC4541]. ARP-related broadcast SHOULD be processed as specified in Section 7.3. RFC3046] MAY be used to avoid DHCPv4 broadcast replies. Option 82 consists of two types of sub-options: Circuit ID and Remote ID. The DHCPv4 Relay Agent is usually located on the network-side bridging function as the Layer 2 DHCPv4 Relay Agent. The port number of the network-side bridging function can be used as Circuit ID, and Remote ID may be left unspecified. Note that using option 82 requires DHCPv4 servers that are aware of option 82. In the IPv6-over-Ethernet case, DHCPv6 clients use their link-local addresses and the All_DHCP_Relay_Agents_and_Servers multicast address to discover and communicate with DHCPv6 servers or Relay Agents on their link. Hence, DHCPv6-related packets are unicasted or multicasted. The network-side bridging function SHOULD handle the DHCPv6-related unicast packets based on [802.1D] and SHOULD transmit the DHCPv6-related multicast packets as specified in Section 7.1.1. 802.1D].
Upon receiving an ARP Request from an SS, the network-side bridging function SHOULD unicast an ARP Reply back to the SS with the Ethernet address of the target host, provided that the target address matches an entry in the ARP cache. However, in case of receiving an ARP Request from a host behind a subscriber-side bridge, the network-side bridging function SHOULD discard the request if the target host is also behind the same subscriber-side bridge, i.e., on the same port of the network-side bridge. Otherwise, the ARP Request MAY be flooded. The network-side bridging function SHOULD silently discard any received self-ARP Request. In the IPv6-over-Ethernet case, Neighbor Solicitation messages are multicasted to the solicited-node multicast address for the address resolution, including a duplicate address detection. The solicited- node multicast address facilitates the efficient querying of hosts without disturbing all hosts on the same link. The network-side bridging function SHOULD transmit the Neighbor Solicitation messages specified in Section 7.1.1. Figure 4 depicts the public access scenario. In this scenario, the AR is connected to a network-side bridge. The AR MAY perform security filtering, policing, and accounting of all traffic from hosts, e.g., like an NAS (Network Access Server). If the AR functions as the NAS, all the traffic from SSs SHOULD be forwarded to the AR, not bridged at the network-side bridging function -- even in the case of traffic between SSs served by the same AR. The bridge SHOULD forward upstream traffic from hosts toward the AR but MUST perform normal bridging operation for downstream traffic from the AR and MUST bridge SEcure Neighbor Discovery (SEND) [RFC3971] messages to allow applicability of security schemes. In the IPv4-over-Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562] can be used for the public access network to ensure that traffic from all hosts is always directed to the AR. The MAC-FF is performed in the network-side bridging function; thus, the bridge filters broadcast ARP Requests from all the hosts and responds to the ARP Requests with an Ethernet MAC address of the AR. In the IPv6-over-Ethernet case, unique IPv6 prefixes per SS can be assigned because doing so forces all IPv6 packets from SSs to be transferred to the AR and thus results in layer-3 separation between
SSs. Alternatively, common IPv6 prefixes can be assigned to all SSs served by the same AR in order to exploit the efficient multicast support of Ethernet link in the network side. In this case, a Prefix Information Option (PIO) [RFC4861] carrying the common IPv6 prefixes SHOULD be advertised with the On-link flag (L-Flag) reset so that it is not assumed that the addresses matching the prefixes are available on-link. The AR should relay packets between SSs within the same AR. +-+--+ |H|SS| +- - - - - - - - - - + +-+--+* +----+ | +------+ +-+--+ * | +-----+ | | |H|SS|* * * * * *| BS +-----+Bridge+-+ +-+--+ * | +-----+ | | +-----+ | * +----+ | +------+ | | B | +-+--+ * | +-+ r | | +-------+ |H|SS|* | i +---+AR(NAS)+-- +---+ +-+--+ | | d | | +-------+ | H ++ +-+ g | +---+ \ +----+ | +------+ | | e | | +---+ +--+--+ | +----+ | | +-----+ | H +--+Br|SS|* * * * | BS | | |Bridge+-+ | +---+ +--+--+ * | +----+ | +---+ / * +----+ | +------+ | | H ++ +-+--+ * +---+ |H|SS|* | Bridging Function | +-+--+ +- - - - - - - - - - + Figure 4: Public Access Network Using IEEE 802.16 802.16], which provides the capabilities of admission control and ciphering of the traffic carried over the air interface. A Traffic Encryption Key (TEK) is generated by the SS and BS on completion of successful mutual authentication and is used to secure the air interface. The IEEE 802.16 Ethernet link model described in Section 5.1 represents a bridged (switched) Ethernet architecture with point-to- point links between the SS and its bridge port. Even though the bridged Ethernet model prevents messaging between SSs on the same link without passing through the bridge, it is still vulnerable, e.g., by malicious reconfiguration of the address table of the bridge
in the learning process. This recommendation does not cause new security issues beyond those that are already known for the bridged Ethernet architecture. For example, link security mechanisms according to [802.1AE] can be used on top of this recommendation to resolve the security issues of the bridged Ethernet. As the generic IP over Ethernet network using IEEE 802.16 emulates a standard Ethernet link, existing IPv4 and IPv6 security mechanisms over Ethernet can still be used. The public access network using IEEE 802.16 can secure isolation of each of the upstream links between hosts and AR by adopting SEcure Neighbor Discovery (SEND) [RFC3971] for securing neighbor discovery processes. [802.16] IEEE Std 802.16-2009, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", May 2009. [802.16k] IEEE Std 802.16k-2007, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges, Amendment 5: Bridging of IEEE 802.16", March 2007. [802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", June 2004. [802.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. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 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 IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. [802.1AE] IEEE Std 802.1AE-2006, "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", August 2006. [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. [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006.
802.1D] cannot take advantage of the multicast CIDs because it relies on unicast connections or bidirectional broadcast connections. A further drawback of deploying multicast CIDs for distributing broadcast control messages, like ARP Requests, is the inability to prevent the waking up of dormant-mode SSs by messages not aimed for them. Whenever a message is sent over a multicast CID, all associated stations have to power up and receive and process the message. While this behavior is desirable for multicast and broadcast traffic, it is harmful for link-layer broadcast control messages aimed for a single SS, like an ARP Request. All other SSs are wasting scarce battery power for receiving, decoding, and discarding the message. Low power consumption is an extremely important aspect in a wireless communication. Furthermore, it should be kept in mind that multicast CIDs are only efficient for a large number of subscribed SSs in a cell. Due to incompatibility with advanced radio-layer algorithms based on feedback information from the receiver side, multicast connections require much more radio resources for transferring the same information as unicast connections.
The operational enhancements described in Section 7 of this document are based on the availability of additional information about all the hosts attached to the Ethernet. Flooding all ports of the bridge can be avoided when a priori information is available to determine the port to which an Ethernet frame has to be delivered. Best performance can be reached by a centralized database containing all information about the hosts attached to the Ethernet. A centralized database can be established by either a centralized bridge device or a hierarchical bridging structure with dedicated uplink and downlink ports like in the public access case, where the uppermost bridge is able to retrieve and maintain all the information. As the generic case of the IP over Ethernet over IEEE 802.16 link model does not make any assumptions about the location of the AR (an AR may eventually be attached to an SS), a centralized bridging system is recommended for the generic case. In the centralized system, every connection over the air of a link should be attached to a single centralized bridge. A distributed bridging model is appropriate, in particular, for the public access mode, where Ethernet frames, which do not have entries in the bridge behind the BS, are sent upstream until finally reaching a bridge that has an entry for the destination MAC address.