Transmission of IP over Ethernet over IEEE 802.16 Networks
Extracted elements (24)
A centralized network-side bridging function is recommended for the generic IP-over-Ethernet-over-IEEE-802.16 case because it enables best control of broadcasting and forwarding, and allows a centralized database of attached hosts to avoid flooding. Distributed bridging is more appropriate for public access mode.
Current IEEE 802.16 does not support bidirectional native broadcast and multicast for IP packets. Uplink connections provide only unicast transmission, and multicast CIDs for downlink are not preferable for small groups due to reduced transmission efficiency and inability to prevent waking dormant-mode SSs.
Multicast CIDs are inefficient for small multicast groups and for link-layer broadcast control messages (such as ARP Requests) because all associated SSs must wake from dormant mode to receive and process each message, wasting battery power. Unicast replication by the network-side bridging function is preferred.
DHCP Relay Agent Information option 82 (RFC 3046) MAY be used on the network-side bridging function to avoid DHCPv4 broadcast replies, but requires DHCPv4 servers that are aware of option 82.
The Ethernet over IEEE 802.16 link model maintains full compatibility with standard IP over Ethernet behavior (RFC 894 for IPv4, RFC 2464 for IPv6), allowing existing Ethernet-based IP mechanisms to operate without modification at the IP layer.
All point-to-point connections belonging to an SS MUST be connected to a network-side bridging function. The BS MUST forward all service flows belonging to one SS to one port of the network-side bridging function, and no more than one SS MUST be connected to one port.
Ethernet frames that are broadcast or multicast SHOULD be replicated and carried via unicast transport connections on the IEEE 802.16 access link, since IEEE 802.16 does not define native broadcast and multicast for Ethernet frames.
Hosts transmitting IPv4 over Ethernet packets over IEEE 802.16 MUST follow the operations specified in RFC 894. ARP (RFC 826) MUST be used for finding the destination Ethernet MAC address.
Hosts transmitting IPv6-over-Ethernet packets over IEEE 802.16 MUST follow the operations specified in RFC 2464. NDP (RFC 4861) MUST be used for determining the destination Ethernet MAC address.
If Ethernet over IEEE 802.16 is extended to multiple end stations behind the SS, the SS SHOULD support bridging according to IEEE 802.1D and its amendment 802.16k between all its subscriber-side ports and the IEEE 802.16 air link.
In the public access IPv6 case, a Prefix Information Option carrying common IPv6 prefixes SHOULD be advertised with the On-link flag (L-Flag) reset so that SSs do not assume addresses matching the prefixes are available on-link.
In the public access scenario where the AR functions as NAS, the bridge SHOULD forward upstream traffic from hosts toward the AR rather than bridging between SSs, but MUST perform normal bridging for downstream traffic from the AR and MUST bridge SEND (RFC 3971) messages.
The AdvDefaultLifetime and MaxRtrAdvInterval for IPv6 Router Advertisements SHOULD be overridden with high values (as specified in RFC 5121 Section 8.3) to avoid wasting radio resources and disturbing SSs in dormant mode.
The default MTU of both IPv6 and IPv4 packets on an Ethernet over IEEE 802.16 link MUST be 1500 bytes, consistent with RFC 2460 and RFC 894.
The network-side bridging function MUST create a new radio-side port whenever a new SS attaches to any BS, and MUST remove a radio-side port when an associated SS detaches. It MUST be based on IEEE 802.1D and amendment 802.16k.
The network-side bridging function SHOULD filter broadcast DHCPOFFER and DHCPACK messages and forward them only to the host defined by the client hardware address in the chaddr field, to avoid unnecessary radio broadcasts.
The network-side bridging function SHOULD flood all IP broadcast packets except ARP-, DHCPv4-, and IGMP-related traffic, to avoid disturbing dormant-mode hosts and wasting scarce radio resources.
The network-side bridging function SHOULD maintain an ARP cache large enough to accommodate entries for all serving SSs, updated by any packets including ARP Requests, and SHOULD unicast ARP Replies back to requesting SSs using Proxy ARP to avoid broadcasting ARP Requests over the air.
When stateful IPv6 address autoconfiguration is required, DHCPv6 (RFC 3315) MUST be performed. When stateless autoconfiguration is required, RFC 4862 and RFC 4861 MUST be followed.
Each SS has a unique 48-bit MAC address used during initial ranging and PKM authentication. However, forwarding over the air relies solely on CID values in the IEEE 802.16 MAC header, not on MAC addresses in the payload.
IEEE 802.16 establishes connections between a Base Station (BS) and Subscriber Stations (SSs) identified by a 16-bit Connection Identifier (CID). Each connection realizes an individual service flow with a defined QoS profile; packets over the air are identified only by CID, not MAC address.
IEEE 802.16 provides two convergence sublayer options for Ethernet: the Ethernet-specific part of the packet CS, which classifies packets by Ethernet header fields and assigns them to service flows, and the Generic Packet Convergence Sublayer (GPCS), which relies on higher-layer functionality for packet-to-service-flow assignment.
The generic IP over Ethernet network over IEEE 802.16 emulates a standard Ethernet link, so existing IPv4 and IPv6 security mechanisms apply. The public access network can secure upstream isolation between hosts and the AR by adopting SEND (RFC 3971) for neighbor discovery processes.
The IEEE 802.16 air interface is secured by a Traffic Encryption Key (TEK) generated upon successful mutual authentication between SS and BS, providing admission control and ciphering. The bridged Ethernet model remains vulnerable to malicious reconfiguration of the bridge address table during the learning process; IEEE 802.1AE link security can mitigate this.