RFC 5692
Transmission of IP over Ethernet over IEEE 802.16 Networks
Transmission of IP over Ethernet over IEEE 802.16 Networks 📡
okay bestie, this is RFC 5692 🎀 and it's giving "how do we get IP and Ethernet running over IEEE 802.16 (the fixed wireless tech)" 🦋 it's Part 1 of 4!
RFC 5692 is a Standards Track doc from the Network Working Group 💜 It was published in October 2009 and has three authors: H. Jeon and S. Jeong (both from ETRI) and M. Riegel (from NSN) ✨ This title block doesn't list anything it obsoletes or updates, so there's nothing to flag there 🙈
Abstract
okay so the abstract is basically the whole vibe 💅 It explains how to send IPv4 over Ethernet, and IPv6 over Ethernet too, in an access network that uses IEEE 802.16 cellular radio tech. Ethernet on top of 802.16 works by bridging the connections 802.16 already gives between a base station and its subscriber stations 🌸
Radio systems have tight resource limits, and 802.16's MAC functions weren't really built for Ethernet, so the doc says IP over Ethernet over 802.16 can seriously benefit from adding IP-specific support functions on top of Ethernet over 802.16. The big rule is that it has to stay fully compatible with standard IP over Ethernet behavior 🫶 no breaking the normal stuff!
Status of This Memo
this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking people to discuss it and suggest improvements 🔥 For the current standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they explain your rights and restrictions for this doc. Code Components pulled from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the BSD License says 🙈
This doc may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅
Table of Contents
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 ................191. Introduction ✨
IEEE 802.16 [802.16] is a fixed-to-mobile broadband wireless access system 📡 okay so it covers both fixed and mobile setups!
802.16 defines a packet CS (Convergence Sublayer) so it can talk to specific packet-based protocols, and it also has a generic packet CS (GPCS), which is an upper-layer interface that doesn't care what protocol is on top 🧚 This doc explains how IPv4 and IPv6 get carried over Ethernet, using the Ethernet-specific part of the packet CS and also the GPCS, in an access network built on IEEE 802.16 💖
Ethernet was originally designed for a shared medium, but 802.16 uses point-to-multipoint architecture, like other cellular radio systems do 🌈 So Ethernet on top of 802.16 works by bridging between the 802.16 radio connections that link a BS (Base Station) with its associated SSs (Subscriber Stations) 🫶
Because radio systems have resource constraints, and 802.16 has its own quirks for making Ethernet work, it makes sense to add IP-specific support functions in the Ethernet layer above 802.16. And yep, you still have to keep 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 🦋
The terminology in this doc is based on the definitions in "IP over 802.16 Problem Statement and Goals" [RFC5154] ✨
4. The IEEE 802.16 Link Model 📡
4.1. Connection-Oriented Air Interface
the IEEE 802.16 MAC sets up connections between a BS and its associated SSs so user data can go over the air 🌸 Each connection is its own service flow, and it's identified by a 16-bit Connection Identifier (CID) number. Every flow also has a defined Quality of Service (QoS) profile 💖
You can have multiple connections between one BS and one SS, and each one has its own QoS class and direction 🫶 Even though the BS and all the SSs each have unique 48-bit MAC addresses, packets over the air are only identified in the IEEE 802.16 MAC header by the CID of that particular connection. The connections get set up by MAC management messages between the BS and the SS, either during network entry or later on, on demand 🧚
[Subscriber Side] [Network Side]
| | | +
| | | +
+--+--+ +--+--+ +--+-+-+--+
| MAC | | MAC | | MAC |
+-----+ +-----+ +---------+
| PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+-+-+
+ + | | | | + +
+ + | +-----CID#w------+ | + +
+ + +-------CID#x--------+ + +
+ +++++++++++++++++CID#y+++++++++++++++++ +
+++++++++++++++++++CID#z+++++++++++++++++++
SS#1 SS#2 BSFigure 1: Basic IEEE 802.16 Link Model 🍓
4.2. MAC Addressing in IEEE 802.16
every SS has a unique 48-bit MAC address 💅 That address gets used during the initial ranging process to identify the SS, and it may be verified later in the PKM (Privacy Key Management) authentication phase. Once authentication succeeds, the BS sets up and keeps a list of attached SSs based on their MAC addresses, purely for MAC management purposes 🙈
Both the BSs and the SSs get MAC addresses, but packets over the air are forwarded only based on the CID value of the particular connection in the IEEE 802.16 MAC header. Because the receiver doesn't rely on the MAC addresses in the payload to receive a radio frame, you can transport arbitrary source and destination MAC addresses in Ethernet frames between an SS and its BS 🌈 This is required for bridging Ethernet frames toward an SS that's attached to a bridge connected to another network ✨
Since the service flows and their CID values are assigned to individual SSs in a managed way, the BS can bundle all the unicast connections that belong to one SS into a single link on the network side, as shown in Figure 1. That gives the SS one layer-2 link to its associated wired link on the network side 👑
4.3. Unidirectional Broadcast and Multicast Support
okay real talk, current IEEE 802.16 [802.16] does not support bidirectional native broadcast and multicast for IP packets 😭 Downlink connections can do multicast to a group of SSs and unicast from the BS to one SS, but uplink connections from the SSs to the BS are unicast only 💀
Using multicast CIDs for downlink multicast isn't necessarily the move, either, because they're less efficient for small multicast groups 🙈 Appendix A has more background on the multicast CID issues in IEEE 802.16 systems 🦋
Also, MBS (Multicast and Broadcast Service), which is specified in IEEE 802.16, doesn't cover IP broadcast or multicast data, because MBS is invisible to the IP layer 🫣
4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet ✨
okay so IEEE 802.16 gives you two solutions 🫶 for moving Ethernet frames over its MAC connections.
The packet CS is built for packet-based protocols 💅. It sorts higher-layer packets by looking at their header field values and assigns each one to the right service flow. It has multiple protocol-specific parts so that different kinds of packets can travel over IEEE 802.16 🦋. The Ethernet-specific part of the packet CS handles Ethernet by defining classification rules based on Ethernet header information ✨.
The GPCS (Generic Packet Convergence Sublayer) is the other option, and it may be used instead to transfer Ethernet frames 🌸. The GPCS doesn't define classification rules for each kind of payload. It relies on higher-layer functionality outside the scope of IEEE 802.16 to do the assigning of packets to particular service flows 😭.
5. Ethernet Network Model for IEEE 802.16 🌈
Like in today's wired Ethernet networks, bridging is required to connect more than two devices 🎀. In IEEE 802.16, the point-to-point connections between SSs and the BS can be bridged so that Ethernet is realized over the IEEE 802.16 access network 🍓.
5.1. IEEE 802.16 Ethernet Link Model 💖
bestie, this part is literally the blueprint 🧚. To realize Ethernet on top of IEEE 802.16, all the point-to-point connections belonging to an SS MUST be connected to a network-side bridging function, as shown in 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#4Figure 2: IEEE 802.16 Ethernet Link Model
5.2. Ethernet without Native Broadcast and Multicast Support 📣
current IEEE 802.16 doesn't define broadcast and multicast of Ethernet frames 😭. So, Ethernet frames that are broadcast or multicast SHOULD be replicated and then carried via unicast transport connections on the IEEE 802.16 access link. The network-side bridging function does the replication and forwarding for Ethernet broadcast and multicast over the IEEE 802.16 radio links 🫶.
5.3. Network-Side Bridging Function 🌷
the network-side bridging function MUST create a new radio-side port whenever a new SS attaches to any of the BSs of the network, or it MUST remove a radio-side port when an associated SS detaches from the BSs. The method for managing the port on the network-side bridging function may depend on the protocol used for establishing multiple links on the connection between the BS and the network-side bridge. The port-managing method is out of scope for this document 💅.
The network-side bridging function MUST be based on [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] ✨.
5.4. Segmenting the Ethernet into VLANs 🎀
it's possible to restrict the size and coverage of the broadcast domain by segmenting the Ethernet over IEEE 802.16 into VLANs, and grouping subsets of hosts into particular VLANs with each VLAN representing an IP link 🧚. Therefore, the network-side bridging function MAY be enabled to support VLANs according to [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 🌈.
6. Transmission of IP over Ethernet over IEEE 802.16 Link 🍓
6.1. Generic IP over Ethernet Network Scenario 🦋
the generic IP over Ethernet network scenario assumes that all hosts are residing on the same link. It lets the hosts communicate directly with each other without detouring 💖. There can be multiple Access Routers (ARs) on the link, and these may reside both on the subscriber side as well as on the network side, as shown in 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
6.2. Transmission of IP over Ethernet 📦
6.2.1. IPv4-over-Ethernet Packet Transmission 🌸
[RFC0894] defines the transmission of IPv4 packets over Ethernet networks 🫶. It has 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] ✨.
6.2.1.1. Address Configuration 🧚
IPv4 addresses can be configured manually or assigned dynamically from Dynamic Host Configuration Protocol for IPv4 (DHCPv4) servers [RFC2131] 💅.
6.2.1.2. Address Resolution 🔥
The Address Resolution Protocol (ARP) [RFC0826] MUST be used for finding the destination Ethernet MAC address 💖.
6.2.2. IPv6-over-Ethernet Packet Transmission 💜
[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] 🦋.
6.2.2.1. Router Discovery, Prefix Discovery and Parameter Discovery 📡
Router Discovery, Prefix Discovery, and Parameter Discovery procedures are achieved by receiving Router Advertisement messages. However, periodic Router Advertisement messages can waste radio resource and disturb SSs in dormant mode in IEEE 802.16 😭. Therefore, the AdvDefaultLifetime and MaxRtrAdvInterval SHOULD be overridden with high values specified in Section 8.3 in [RFC5121] 🌈.
6.2.2.2. Address Configuration 🎀
When stateful address autoconfiguration is required, the stateful address configuration according to [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 👑.
6.2.2.3. Address Resolution 💖
The Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for determining the destination Ethernet MAC address ✨.
6.2.3. Maximum Transmission Unit 📏
[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 🔥.
6.2.4. Prefix Assignment 🧁
As Ethernet over IEEE 802.16 may only build a part of a larger Ethernet of arbitrary structure, any kind of prefix assignment that is feasible for Ethernet is applicable for Ethernet over IEEE 802.16 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 🫶.
7. Operational Enhancements for IP over Ethernet over IEEE 802.16 🚀
this section presents operational enhancements to improve network performance and radio resource efficiency for transmission of IP packets over Ethernet over IEEE 802.16 networks 💅.
7.1. IP Multicast and Broadcast Packet Processing ✨
okay bestie, so the network-side bridging function can handle all multicast and multicast control messages following [RFC4541] 💅. And broadcasting messages out to all radio-side ports SHOULD be prevented 🫶. That's the vibe.
More details on stopping multicast or broadcast messages from hitting all radio-side ports are in the sections that follow 🦋.
7.1.1. Multicast Transmission Considerations 🌸
ngl this one is so relatable. Normally, bridges copy IP multicast packets and blast them out every port except the one they came in on 😭. So the multicast packets end up going over the air, even to hosts that never joined the group. Not it. To make bridges handle IP multicast more efficiently, the IP multicast membership info SHOULD be passed between bridges 🧚.
In the IEEE 802.16 Ethernet link model from Section 5.1, the network-side bridging function can process all multicast data and multicast control messages according to [RFC4541]. That lets it keep track of IP multicast membership and forward the multicast data only to ports that fit the multicast group 👑 iconic.
7.1.2. Broadcast Transmission Considerations 🎀
The ordinary bridge floods IP broadcast packets out of every connected port except the one the packet arrived on. Literally not appropriate when resources are scarce and you've got dormant-mode hosts in a wireless network, like an access network based on IEEE 802.16 💀.
The network-side bridging function in the IEEE 802.16 Ethernet link model SHOULD flood all IP broadcast packets, except ARP-, DHCPv4-, and Internet Group Management Protocol (IGMP)-related traffic 🍓.
IGMP-related broadcast packets can be forwarded according to [RFC4541]. ARP-related broadcast SHOULD be processed as specified in Section 7.3 🦋.
7.2. DHCP Considerations 🌈
In the IPv4-over-Ethernet case, DHCPv4 clients may send DHCPDISCOVER and DHCPREQUEST messages with the BROADCAST bit set, asking the DHCPv4 server to broadcast its DHCPOFFER and DHCPACK messages 📣. The network-side bridging function SHOULD filter those broadcast DHCPOFFER and DHCPACK messages and forward them only to the host whose client hardware address is in the chaddr information element 💖.
Another option is the DHCP Relay Agent Information option (option 82) [RFC3046], which MAY be used to avoid DHCPv4 broadcast replies 🧚. Option 82 has two sub-options: Circuit ID and Remote ID. The DHCPv4 Relay Agent is usually sitting on the network-side bridging function as a Layer 2 DHCPv4 Relay Agent. The port number of the network-side bridging function can be used as the Circuit ID, and the Remote ID may be left unspecified 🫶. Heads up though: using option 82 requires DHCPv4 servers that actually understand option 82 ⚠️.
ngl this is the part to double check: option 82 only works if the DHCPv4 server is aware of it.
In the IPv6-over-Ethernet case, DHCPv6 clients use their link-local addresses and the All_DHCP_Relay_Agents_and_Servers multicast address to find and talk to DHCPv6 servers or Relay Agents on their link 🔥. So DHCPv6-related packets are either unicasted or multicasted. The network-side bridging function SHOULD handle DHCPv6-related unicast packets based on [802.1D], and SHOULD transmit DHCPv6-related multicast packets as specified in Section 7.1.1 💜.
7.3. Address Resolution Considerations 💅
In the IPv4-over-Ethernet case, ARP Requests are usually broadcast to every host on the same link to resolve an Ethernet MAC address. That disturbs all the hosts on the link 😭. Proxy ARP fixes this: a device on the same link answers ARP Requests on behalf of the remote host. When IPv4 packets are sent over the IEEE 802.16 Ethernet link, the network-side bridging function uses the Proxy ARP mechanism so that ARP Requests don't get broadcast over the air 🌸.
The network-side bridging function SHOULD maintain an ARP cache large enough to hold ARP entries for all of its serving SSs. The ARP cache SHOULD be updated by any packets, including ARP Requests from SSs, the same way a normal layer-2 bridging device updates its Filtering Database according to [802.1D] 🧚.
When the network-side bridging function gets an ARP Request from an SS, it SHOULD unicast an ARP Reply back to that SS with the Ethernet address of the target host, provided the target address matches an entry in the ARP cache 💖. However, if an ARP Request comes from a host behind a subscriber-side bridge, the network-side bridging function SHOULD discard the request when the target host is also behind that 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 multicast to the solicited-node multicast address for address resolution, including duplicate address detection. The solicited-node multicast address makes it efficient to query hosts without disturbing every host on the link 👑. The network-side bridging function SHOULD transmit the Neighbor Solicitation messages as specified in Section 7.1.1 ✨.
8. Public Access Recommendations 🌍
In the public access scenario, direct communication between nodes is restricted because of security and accounting issues 🔒. Figure 4 shows 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, like an NAS (Network Access Server) 💼.
If the AR functions as the NAS, all traffic from SSs SHOULD be forwarded to the AR, not bridged at the network-side bridging function, even for traffic between SSs served by the same AR 🙅♀️. The bridge SHOULD forward upstream traffic from hosts toward the AR, but it MUST perform normal bridging operation for downstream traffic from the AR, and it MUST bridge SEcure Neighbor Discovery (SEND) [RFC3971] messages so security schemes stay applicable 🔐.
In the IPv4-over-Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562] can be used on the public access network to make sure traffic from all hosts is always directed to the AR 🎯. MAC-FF runs in the network-side bridging function, so the bridge filters broadcast ARP Requests from all hosts and answers them with the Ethernet MAC address of the AR 🫢.
In the IPv6-over-Ethernet case, unique IPv6 prefixes per SS can be assigned, because that forces all IPv6 packets from SSs to go through the AR, giving layer-3 separation between SSs 🧱. Alternatively, common IPv6 prefixes can be assigned to all SSs served by the same AR, to exploit the efficient multicast support of the Ethernet link on 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 it is not assumed that addresses matching those 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.169. Security Considerations 🚨
This recommendation does not introduce new vulnerabilities to IPv4 and IPv6 specifications or operations 🙌. The security of the IEEE 802.16 air interface between SSs and BS is the subject of [802.16], which provides admission control and ciphering of the traffic carried over the air interface 🔐. A Traffic Encryption Key (TEK) is generated by the SS and BS once mutual authentication succeeds, and it 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., to malicious reconfiguration of the bridge's address table during the learning process 😱. This recommendation does not cause new security issues beyond those already known for bridged Ethernet architectures. For example, link security mechanisms according to [802.1AE] can be used on top of this recommendation to resolve the security issues of 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 upstream link between hosts and the AR by adopting SEcure Neighbor Discovery (SEND) [RFC3971] for securing neighbor discovery processes 💜.
10. Acknowledgments 🫶
The authors would like to thank David Johnston, Dave Thaler, Jari Arkko, and others for their inputs to this work 🌷.
11. References 📚
11.1. Normative References
Okay bestie, these are the references you need to have read before you can implement any of this 📚
[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.11.2. Informative References
These are the extra-credit reads 🌸 Super helpful for context, but you don't strictly need them to get the core spec.
[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.
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
802.16 Problem Statement and Goals", RFC 5154, April 2008.Appendix A. Multicast CID Deployment Considerations ✨
Okay so multicast CIDs are honestly iconic for sending the same info to a bunch of SSs under the same BS at once 💅 But deploying them for multicast or broadcast data services comes with some drawbacks, and we need to talk about them 🙈
The first drawback is that multicast CIDs are unidirectional 🦋 They can send info downstream to a bunch of SSs in parallel, but there are no upstream multicast connections at all. So when something needs to go up to the BS, you have to use unicast CIDs to send that multicast message over the air. Then you need a special multicast forwarding function to send it back out to the other SSs on a multicast CID. It's kind of like a bridging function, but there's no appropriate forwarding model available for it yet. And [802.1D] can't use multicast CIDs either, because it relies on unicast connections or bidirectional broadcast connections. Not it 💀
The second drawback shows up when you send broadcast control messages, like ARP Requests, over multicast CIDs. Whenever a message goes out on a multicast CID, every associated station has to power up, receive it, and process it. That's totally the vibe for multicast and broadcast traffic, but it's harmful for a link-layer broadcast control message that's only aimed at one SS, like an ARP Request. All the other SSs are wasting scarce battery power just receiving, decoding, and then discarding the message. Low power consumption is extremely important in wireless, so this one is a big deal 😭
The third drawback is that multicast CIDs only pay off when there's a large number of subscribed SSs in a cell 🌈 They also don't play well with advanced radio-layer algorithms that use feedback from the receiver side. Because of that, multicast connections need way more radio resources than unicast connections to transfer the same info. Keep that in mind, bestie 🫶
Appendix B. Centralized vs. Distributed Bridging 🧚
Okay so this spec introduces a network-side bridging function ✨ It can be realized either by a centralized device or by multiple interconnected bridges working in a distributed way. A common version of the distributed model is when a bridge is directly attached to the BS. In that case, the interface between the BS and the bridging function becomes a software interface inside the operating system of the BS/bridge device. Super clean 💖
The operational enhancements in Section 7 of this document depend on having extra information about all the hosts attached to the Ethernet. If you have that a priori information, you can avoid flooding all the ports of the bridge, since you can work out which port an Ethernet frame needs to go to 🎀
The best performance comes from a centralized database that holds all the information about the hosts attached to the Ethernet 👑 That database can be set up either by a centralized bridge device or by a hierarchical bridging structure with dedicated uplink and downlink ports, like in the public access case. In that setup, the uppermost bridge can retrieve and maintain all the information.
Now, the generic IP over Ethernet over IEEE 802.16 link model doesn't make any assumptions about where the AR is located (an AR may eventually be attached to an SS). So 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 fits especially well for the public access mode 🌸 There, Ethernet frames that don't have entries in the bridge behind the BS get sent upstream until they finally reach a bridge that has an entry for the destination MAC address. Bridging, but make it a journey 🦋
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
Sangjin Jeong
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-1877
EMail: sjjeong@etri.re.kr
Max Riegel
Nokia Siemens Networks
St-Martin-Str 76
Munich, 81541
Germany
Phone: +49-89-5159-32728
EMail: maximilian.riegel@nsn.com📦 where this page comes from
- ietf: rfc5692 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms