RFC 5121
Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks
RFC 5121: Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks ✨
okay bestie, let's start with the basics 🎀 This is RFC 5121, from the Network Working Group, dated February 2008. It's a Standards Track document, so it's a real protocol spec, not just a discussion piece 💅. The five authors are B. Patil (Nokia Siemens Networks), F. Xia (Huawei USA), B. Sarikaya (Huawei USA), JH. Choi (Samsung AIT), and S. Madanapalli (Ordyn Technologies). The title is "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks." It doesn't obsolete or update any other RFCs, so it's a clean slate 🦋
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Abstract
okay so IEEE Std 802.16 is an air interface spec for fixed and mobile Broadband Wireless Access Systems 📡 The service-specific convergence sublayers that upper-layer protocols plug into are part of the 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) carries all the packet-based protocols, like Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet) 🧚
IPv6 packets can be sent and received through the IP-specific part of the Packet CS. This document covers how IPv6 gets addressed and operates over that IP-specific part, for hosts served by a network using the IEEE Std 802.16 air interface. It recommends giving each host a unique prefix (or prefixes), and it lets the host use multiple identifiers within that prefix, including randomly generated interface identifiers. It's giving privacy-friendly energy 🙈✨
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. IEEE 802.16 Convergence Sublayer Support for IPv6 . . . . . . 4
4.1. IPv6 Encapsulation over the IP CS of the MAC . . . . . . . 7
5. Generic Network Architecture Using the 802.16 Air Interface . 8
6. IPv6 Link . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. IPv6 Link in 802.16 . . . . . . . . . . . . . . . . . . . 9
6.2. IPv6 Link Establishment in 802.16 . . . . . . . . . . . . 10
6.3. Maximum Transmission Unit in 802.16 . . . . . . . . . . . 11
7. IPv6 Prefix Assignment . . . . . . . . . . . . . . . . . . . . 12
8. Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 12
8.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 12
8.3. Router Lifetime and Periodic Router Advertisements . . . . 13
9. IPv6 Addressing for Hosts . . . . . . . . . . . . . . . . . . 13
9.1. Interface Identifier . . . . . . . . . . . . . . . . . . . 13
9.2. Duplicate Address Detection . . . . . . . . . . . . . . . 13
9.3. Stateless Address Autoconfiguration . . . . . . . . . . . 14
9.4. Stateful Address Autoconfiguration . . . . . . . . . . . . 14
10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. WiMAX Network Architecture and IPv6 Support . . . . . 17
Appendix B. IPv6 Link in WiMAX . . . . . . . . . . . . . . . . . 19
Appendix C. IPv6 Link Establishment in WiMAX . . . . . . . . . . 19
Appendix D. Maximum Transmission Unit in WiMAX . . . . . . . . . 201. Introduction ✨
okay so IEEE 802.16e is an air interface for fixed and mobile broadband wireless access systems 📶 The IEEE 802.16 [802.16] standard specifies that air interface, including the Medium Access Control (MAC) layer and multiple physical layer (PHY) specifications. It can be deployed in licensed as well as unlicensed spectrum. The PHY and MAC are specified in IEEE 802.16, but the details of IPv4 and IPv6 operation over the air interface aren't in there. That's the gap this document fills: it specifies how IPv6 operates over the IEEE 802.16 air interface 💖
IPv6 packets can be carried over the IEEE Std 802.16 specified air interface in two ways:
- the IP-specific part of the Packet CS or
- the 802.3[802.3]-specific part of the Packet CS
The scope here is limited to IPv6 over the IP CS only, so the 802.3-specific part is out of scope 🚫
IEEE 802.16 covers the PHY and MAC details, and the convergence sublayers are part of the MAC. The packet convergence sublayer includes the IP-specific part that the IPv6 layer uses 🧚
The mobile station (MS)/host connects to an access router through a base station (BS). The host and the BS are linked at the link and physical layers via the IEEE Std 802.16 air interface. The IPv6 link from the MS ends at an access router, which may be part of the BS or an entity beyond the BS. From the point of view of the IPv6 link between the MS and access router (AR), the base station is a layer 2 entity. It relays IPv6 packets between the AR and the host over a point-to-point connection across the air interface 🌈
2. Terminology 🎀
The terminology here is based on the definitions in "IP over 802.16 Problem Statement and Goals" [PS-GOALS].
- IP CS - The IP-specific part of the Packet convergence sublayer is called IP CS. IPv6 CS and IP CS are used interchangeably 🦋
- Subscriber station (SS), Mobile Station (MS), Mobile Node (MN) - Subscriber station, mobile station, and mobile node are used interchangeably in this document. They all mean the same thing, which is an IP host 💜
3. Conventions Used in This Document 💅
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 RFC 2119 [RFC2119]. Those are the key words, so they're the ones to watch for, bestie 👑
4. IEEE 802.16 Convergence Sublayer Support for IPv6 ✨
Okay bestie, so the IEEE 802.16 MAC has two main service-specific convergence sublayers 💅:
- ATM convergence sublayer
- Packet convergence sublayer
The Packet CS is the one for packet-based protocols, which include:
- IEEE Std 802.3(Ethernet)
- Internet Protocol (IPv4 and IPv6)
The service-specific CS sits on top of the MAC Common Part Sublayer (CPS), as you can see in Figure 1 🦋. It's responsible for:
- accepting packets (Protocol Data Units, PDUs) from the upper layer,
- performing classification of the packet/PDU based on a set of defined classifiers that are service specific,
- delivering the CS PDU to the appropriate service flow and transport connection, and
- receiving PDUs from the peer entity.
Payload header suppression (PHS) is also a function of the CS but is optional 🌸.
Here's the concept of the service-specific CS in relation to the MAC:
------------------------------\
| ATM CS | Packet CS | \
------------------------------ \
| MAC Common Part Sublayer | \
| (Ranging, scheduling, etc.)| 802.16 MAC
------------------------------ /
| Security | /
|(Auth, encryption, key mgmt)| /
------------------------------/
| PHY |
------------------------------
Figure 1: IEEE 802.16 MACSo the classifiers for each specific upper-layer protocol (Ethernet and IP) are defined in the IEEE 802.16 specification 📜. They're what let packets from the upper layer get processed by the right service-specific part of the Packet CS. IPv6 can be transported directly over the IP-specific part of the Packet CS (IP CS), and IPv4 packets also go over that same IP-specific part 💖. The classifiers used by the IP CS are what let the MAC tell IPv4 and IPv6 packets apart and map each one to a specific transport connection over the air interface.
Here are the options for IPv6 transport over the Packet CS of IEEE 802.16 🎀:
+-------------------+
| IPv6 |
+-------------------+ +-------------------+
| IPv6 | | Ethernet |
+-------------------+ +-------------------+
| IP-specific | | 802.3-specific |
| part of Packet CS | | part of Packet CS |
|...................| |...................|
| MAC | | MAC |
+-------------------+ +-------------------+
| PHY | | PHY |
+-------------------+ +-------------------+
(1) IPv6 over (2) IPv6 over
IP-specific part 802.3/Ethernet-
of Packet CS specific part
of Packet CS
Figure 2: IPv6 over IP- and 802.3-specific parts of the Packet CSOkay so the figure shows that there are multiple ways IPv6 can be sent over an 802.16 air interface 🧚. But this document is only about IPv6 over the IP CS, nothing else. IP over Ethernet is covered in [IPoE-over-802.16], and IPv4 over the IP CS is covered in [IPv4-over-IPCS] 🌈.
Now, the negotiation part, which is lowkey important 👑. Right after ranging (an 802.16 air interface procedure) and the SBC-REQ/RSP exchange (802.16 specific), the MS and BS swap their capabilities using REG-REQ (Registration Request) and REG-RSP (Registration Response) 802.16 MAC messages. These management frames negotiate things like which Convergence Sublayer the MS and BS support. By default, Packet, IPv4, and 802.3/Ethernet are supported. IPv6 over the IP CS is supported by the MS and the BS only when the IPv6 support bit in the capability negotiation messages (REG-REQ and REG-RSP) shows that support, in the parameter "Classification/PHS options and SDU (Service Data Unit) encapsulation support" (refer to [802.16]) 🫶. Also, when the transport connection for IPv6 packets is being set up, the DSA-REQ (Dynamic Service Addition) and DSA-RSP messages between the BS and MS use the CS-Specification TLV to say which CS that connection shall use 💅.
When an IPv6 packet has the IEEE 802.16 6-byte MAC header in front of it, the header itself says nothing about the payload type 🙈. Everything depends on the classifiers. Based on the classification rules, the MAC layer picks an appropriate transport connection to send the packet on. An IPv6 packet goes over a transport connection that's specifically set up for carrying these packets ✨.
Sending IPv6 can happen through multiple methods, either via the IP CS or via Ethernet interfaces. So every Internet host connected via an 802.16 link:
- MUST be able to send and receive IPv6 packets via IP CS when the MS and BS indicate IPv6 protocol support over IP CS
- MUST be able to send and receive IPv6 packets over the Ethernet (802.3)-specific part of the Packet CS when the MS and BS indicate IPv6 protocol support over Ethernet CS. However, when the MS and BS indicate IPv6 protocol support over both IP CS and Ethernet CS, the MS and BS MUST use IP CS for sending and receiving IPv6 packets.
When the MS and BS support IPv6 over IP CS, it MUST be used as the default mode for transporting IPv6 packets over IEEE 802.16 and the recommendations in this document that are followed. If the MS and BS can't negotiate a common convergence sublayer for IPv6 transport, the transport connection won't get set up, and the host won't be able to send or receive IPv6 packets at all 😭.
If a host supports more than one way of transporting IPv6, the default pick (IPv6 over the IP CS or IPv6 over 802.3) is IPv6 over IP CS, as long as the BS also supports that 💜.
No matter what, the MS and BS MUST negotiate at most one convergence sublayer for IPv6 transport on a given link 🔥.
And for interoperability between devices that support different encapsulations, it is REQUIRED that BS implementations support all standards-track encapsulations defined for 802.16 by the IETF 🌸. When this specification was written, that's the only encapsulation, but more specifications are being worked on. It is, however, not required that BS implementations use every encapsulation they support, since some modes of operation may be off by configuration 🧁.
4.1. IPv6 Encapsulation over the IP CS of the MAC 🎀
The IPv6 payload carried over the IP-specific part of the Packet CS gets encapsulated by the 6-byte IEEE 802.16 generic MAC header. The format of the IPv6 packet encapsulated by the generic MAC header is in Figure 3 below. The 6-byte MAC header format is described in the [802.16] specification. The CRC (cyclic redundancy check) is optional. It should be noted that the actual MAC address is not included in the MAC header 🙈.
---------/ /-----------
| MAC SDU |
--------/ /------------
||
||
MSB \/ LSB
---------------------------------------------------------
| Generic MAC header| IPv6 Payload | CRC |
---------------------------------------------------------
Figure 3: IPv6 encapsulationSo for IPv6 packets going via the IP CS over IEEE 802.16, the IPv6 layer talks straight to the 802.16 MAC 🦋. It hands the IPv6 packet to the Packet CS of the IEEE 802.16 MAC. The Packet CS has a set of classifiers that decide how the packet gets handled. The IP classifiers the MAC uses look at fields in the IP header and the transport protocol. That includes the IP Traffic class, the Next header field, the Masked IP source and destination addresses, and the Protocol source and destination port ranges. "Next header" here means the last header in the IP header chain 💅. After parsing these classifiers, the MAC maps the upper-layer packet to a specific service flow and transport connection to use. Then it wraps the IPv6 packet in the 6-byte MAC header (that's the MAC SDU) and sends it off 🚀.
Here's the operation on the downlink (the transmission from the BS to the host). The uplink works the same way in reverse 🌈:
----------- ----------
| IPv6 Pkt| |IPv6 Pkt|
----------- ----------
| | /|\
| | |
--[SAP]--------------------- ---------[SAP]--------
||-| |----------| | | /|\ |
|| \ / 0---->[CID1] | | --- |-------- |
|| Downlink 0\/-->[CID2] | | |Reconstruct| |
|| classifiers0/\-->[....] | | | (undo PHS)| |
|| 0---->[CIDn] | | --- ------- |
||--------------| | | /|\ |
| | | | |
| {SDU, CID,..} | | {SDU, CID,..} |
| | | | /|\ |
| v | | | |
------[SAP]----------------- |-------[SAP]---------
| 802.16 MAC CPS |------>| 802.16 MAC CPS |
---------------------------- ----------------------
BS MS
Figure 4: IPv6 packet transmission: Downlink5. Generic Network Architecture Using the 802.16 Air Interface ✨
okay so in a network that uses the 802.16 air interface, the host/MS hooks up to an IPv6 access router (AR) 🛜. The BS is only a layer 2 entity, bestie 💅. The AR can be built right into the BS, or it can be a separate thing sitting somewhere beyond the BS in the access network. One AR can be attached to multiple BSs too 🦋. IPv6 packets travel between the MS and BS over a point-to-point transport connection, and each one is identified by its own unique Connection Identifier (CID). That transport connection is a MAC layer link between the MS and the BS, so it's giving very organized 🎀. The figures below show the possible architectures, and they're super generic on purpose. There are more esoteric setups out there, but they're out of scope for this doc 🙈.
Option A:
+-----+ CID1 +--------------+
| MS1 |------------/| BS/AR |-----[Internet]
+-----+ / +--------------+
. /---/
. CIDn
+-----+ /
| MSn |---/
+-----+Figure 5: IPv6 AR as an integral part of the BS
Option B:
+-----+ CID1 +-----+ +-----------+
| MS1 |----------/| BS1 |----------| AR |-----[Internet]
+-----+ / +-----+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+Figure 6: IPv6 AR is separate from the BS
These network models are just examples 💖. They're here to show the point-to-point link between the MS and the AR 🫶.
6. IPv6 Link 🌈
"Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] defines a link as a communication facility or medium where nodes can talk to each other at the link layer, which is the layer right under IP. Routers bound a link because they're the ones that decrement the Hop limit field in the IPv6 header 👑. When an MS moves around within a link, it can keep using its IP addresses, which is so iconic 😭. This is a layer 3 definition, and it's NOT the same as the '(L2) link' term in IEEE 802 standards, so don't mix them up 💀.
6.1. IPv6 Link in 802.16 🧚
In 802.16, the transport connection between an MS and a BS carries user data, and in this case that user data is IPv6 packets. Each transport connection is represented by a CID, and an MS and a BS can have multiple transport connections between them 🌸.
When an AR and a BS are colocated, the whole collection of transport connections to an MS counts as one single link ✨. When an AR and a BS are separated, it's recommended to set up a tunnel between the AR and the BS. The granularity of that tunnel should be no greater than 'per MS' or 'per service flow' (an MS can have multiple service flows, and those get identified by a service flow ID) 🍓. Then the tunnel(s) for an MS, combined with that MS's transport connections, form one single point-to-point link 🔥.
The collection of service flows (tunnels) to an MS is defined as one single link. Each link that uses the same higher-layer protocol has only an MS and an AR on it. Each MS belongs to a different link, and a different prefix should be assigned to each unique link 💜. This link is fully consistent with a standard IP link, no exceptions, and it matches the definition of a point-to-point link in neighbor discovery for IPv6 [RFC4861] 🎀. So the point-to-point link model for IPv6 operation over the IP-specific part of the Packet CS in 802.16 SHOULD be used 🫶. A unique IPv6 prefix(es) per link (MS/host) MUST be assigned 👑.
6.2. IPv6 Link Establishment in 802.16 🦋
So, to get IPv6 packets flowing between the MS and the AR, the link between them (going through the BS) has to be set up first. This section walks through that setup 🌷.
The MS goes through the network entry procedure as specified by 802.16. Here's the high-level version:
- The MS does initial ranging with the BS. Ranging is how an MS gets time aligned with the BS 🕰️. The MS is synced with the BS once ranging wraps up successfully and it's ready to set up a connection ✨.
- The MS and BS swap basic capabilities they need for effective communication during initialization, using SBC-REQ/RSP (802.16 specific) messages 💅.
- The MS moves on to an authentication phase. Authentication is based on Privacy Key Management version 2 (PKMv2), as defined in the IEEE Std 802.16 specification 🔐.
- Once authentication succeeds, the MS does 802.16 registration with the network 🎟️.
- The MS and BS do a capability exchange following 802.16 procedures, and protocol support gets indicated in this exchange 🧠. The CS capability parameter says which classification/PHS options and SDU encapsulation the MS supports. By default, Packet, IPv4, and 802.3/Ethernet shall be supported. So if this parameter is missing from REG-REQ (an 802.16 message), it means those named options are supported by the MS/SS 🙌. Support for IPv6 over the IP-specific part of the Packet CS is indicated by Bit #2 of the CS capability parameter (refer to [802.16]) 🌈.
- The MS MUST request the establishment of a service flow for IPv6 packets over IP CS if the MS and BS have confirmed they can support IPv6 over IP CS 💖. The service flow MAY also be triggered by the network as a result of pre-provisioning 🌟. The service flow sets up a link between the MS and the AR, and IPv6 packets can be sent and received over it 🚀.
- The AR and MS SHOULD send router advertisements and solicitations as specified in neighbor discovery [RFC4861] 📣.
The flow above doesn't show the actual 802.16 messages used for ranging, capability exchange, or service flow establishment. If you want those details, they're all in [802.16] 📚.
6.3. Maximum Transmission Unit in 802.16 🍭
The MTU value for IPv6 packets on an 802.16 link is configurable 🎛️. The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500 octets 🍓.
The 802.16 MAC PDU is made of a 6-byte header, then an optional payload, then an optional CRC that covers the header and the payload 📦. The PDU length is indicated by the Len parameter in the Generic MAC header, and Len is 11 bits in size. So the total MAC PDU size comes out to 2048 bytes 🤯. The IPv6 payload size can vary. In certain deployment scenarios, the MTU value can go higher than the default ✨.
Neighbor discovery for IPv6 [RFC4861] defines an MTU option that an AR MUST advertise via router advertisement (RA) if a value other than 1500 is being used 📡. The MN processes this option as defined in [RFC4861] 💜. Nodes that implement Path MTU Discovery [RFC1981] MAY use that mechanism to figure out the MTU for IPv6 packets 🔍.
7. IPv6 Prefix Assignment 🎀
The MS and the AR are connected through a point-to-point connection at the IPv6 layer. So each MS can be treated as being on its own separate subnet 🏠. A CPE (Customer Premise Equipment) type of device that serves multiple IPv6 hosts may be the endpoint of the connection 💅. So one or more /64 prefixes SHOULD be assigned to a link 💖. The prefixes are advertised with the on-link (L-bit) flag set, as specified in [RFC4861] 🚩. The size and number of prefixes is a configuration issue 🛠️. Dynamic Host Configuration Protocol (DHCP) or Authentication, Authorization, and Accounting (AAA)-based prefix delegation MAY be used to give one or more prefixes to an MS for an AR connected over 802.16 🌸. Everything else about the prefixes also gets handled through configuration ⭐.
8. Router Discovery 🧚♀️
8.1. Router Solicitation 💌
Once the IPv6 link is set up, the MS may send a router solicitation message to ask the AR for a router advertisement message. That's how it grabs the info it needs, as described in the neighbor discovery for IPv6 spec [RFC4861] 🙏. An MS that's network attached may also send router solicitations at any time 💫. Movement detection at the IP layer for an MS is, in lots of cases, based on receiving periodic router advertisements 👀. An MS can also notice changes in its attachment through link triggers or other means, and it can respond to those triggers by sending router solicitations 🔔. The router solicitation goes over the IPv6 link that was set up earlier 🛤️. The MS sends router solicitations to the all-routers multicast address, and they're carried over the point-to-point link to the AR via the BS 📬. The MS doesn't need to know the link-local address of the AR to send a router solicitation at any time 🙌. Using router advertisements for movement detection is not recommended for MNs connected via 802.16 links, because the periodic router advertisements would have to come really often 🥲.
8.2. Router Advertisement 📣
The AR SHOULD send a number of router advertisements (a configurable value) to the MS as soon as the IPv6 link is established 🌞. The AR also sends unsolicited router advertisements periodically, as per [RFC4861] ⏰. The interval between periodic router advertisements is longer than what neighbor discovery for IPv6 specifies, though, and that's covered in the next section 🫠.
8.3. Router Lifetime and Periodic Router Advertisements ⏳
The router lifetime SHOULD be set to a large value, preferably in hours 🕐. This document overrides the router lifetime value spec in "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] 📝. The AdvDefaultLifetime in the router advertisement MUST be either zero or between MaxRtrAdvInterval and 43200 seconds 🔢. The default value is 2 * MaxRtrAdvInterval ✨.
802.16 hosts can transition to an idle mode, and when they do, the radio link between the BS and the MS gets torn down 😴. Paging is needed if the network has to deliver packets to the MS 📟. To avoid waking up a mobile that's sitting in idle mode and burning resources on the air interface, the interval between periodic router advertisements SHOULD be set quite high 🌙. The MaxRtrAdvInterval value in this document overrides the recommendation in "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] 🙅♀️. The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds 🕰️. The default value for MaxRtrAdvInterval is 10800 seconds 🍯.
9. IPv6 Addressing for Hosts 🏡
The addressing scheme for IPv6 hosts in 802.16 networks follows the IETF's recommendation for hosts in "IPv6 Node Requirements" [RFC4294] 📖. The IPv6 node requirements [RFC4294] specify a set of RFCs that apply to addressing, and those same RFCs apply to hosts that use 802.16 as the link layer for carrying IPv6 packets 🌟.
9.1. Interface Identifier 🪪
The MS has a 48-bit globally unique MAC address, as specified in 802.16 [802.16] 🔑. This MAC address MUST be used to generate the modified EUI-64 format-based interface identifier, as specified in "IP Version 6 Addressing Architecture" [RFC4291] 💅. The modified EUI-64 interface identifier is used in stateless address autoconfiguration ⚡. Just like on other links that support IPv6, EUI-64-based interface identifiers aren't mandatory, and other mechanisms, like random interface identifiers from "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941], MAY also be used 🕵️♀️✨.
9.2. Duplicate Address Detection 💖
okay so DAD SHOULD be performed as per "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address Autoconfiguration" [RFC4862]. the IPv6 link over 802.16 is specified in this document as a point-to-point link 🦋. based on this criteria, it may be redundant to perform DAD on a global unicast address that is configured using the EUI-64 or generated as per RFC 4941 [RFC4941] for the interface as part of the IPv6 Stateless Address Autoconfiguration Protocol [RFC4862], as long as the following two conditions are met 🫶:
- The prefixes advertised through the router advertisement messages by the access router terminating the 802.16 IPv6 link are unique to that link.
- The access router terminating the 802.16 IPv6 link does not autoconfigure any IPv6 global unicast addresses from the prefix that it advertises.
9.3. Stateless Address Autoconfiguration 🌸
when stateless address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC4862]. no skipping this one, bestie 💅.
9.4. Stateful Address Autoconfiguration ✨
when stateful address autoconfiguration is performed, it MUST be performed as specified in [RFC4861] and [RFC3315]. same energy here, it's a must-do 👑.
10. Multicast Listener Discovery 🧚
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] SHOULD be supported as specified by the hosts and routers attached to each other via an 802.16 link 💜. the access router that has hosts attached to it via a point-to-point link over an 802.16 SHOULD NOT send periodic queries if the host is in idle/dormant mode 🙈. the AR can obtain information about the state of a host from the paging controller in the network ✨.
11. Security Considerations 💀
this document does not introduce any new vulnerabilities to IPv6 specifications or operation 🔥. the security of the 802.16 air interface is the subject of [802.16]. it should be noted that 802.16 provides capability to cipher the traffic carried over the transport connections. a traffic encryption key (TEK) is generated by the MS and BS on completion of successful authentication and is used to secure the traffic over the air interface 🔐. an MS may still use IPv6 security mechanisms even in the presence of security over the 802.16 link. in addition, the security issues of the network architecture spanning beyond the 802.16 base stations are the subject of the documents defining such architectures, such as WiMAX Network Architecture [WiMAXArch] in Sections 7.2 and 7.3 of Stage 2, Part 2.
bestie, this part is SERIOUS. the security stuff across the air interface and the whole network architecture beyond the base stations is where the real risks live, so don't skip the cited documents 😭.
12. Acknowledgments 🎀
the authors would like to acknowledge the contributions of the 16NG working group chairs Soohong Daniel Park and Gabriel Montenegro as well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ Johnston, Dave Thaler, Bruno Sousa, Alexandru Petrescu, Margaret Wasserman, and Pekka Savola for their review and comments 🙌. review and comments by Phil Barber have also helped in improving the document quality 🌈.
13. References 📚
13.1. Normative References 🍓
[802.16] "IEEE Std 802.16e: 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", October 2005, <http://standards.ieee.org/
getieee802/download/802.16e-2005.pdf>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 4291,
February 2006.
[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.13.2. Informative References 🦋
[802.3] "IEEE Std 802.3-2005: IEEE Standard for
Information technology-Telecommunications and
information exchange between systems-Local and
metropolitan area networks--Specific requirements
Part 3: Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications", December 2005,
<http://standards.ieee.org/getieee802/
802.3.html>.
[IPoE-over-802.16] Jeon, H., Riegel, M., and S. Jeong, "Transmission
of IP over Ethernet over IEEE 802.16 Networks",
Work in Progress, January 2008.
[IPv4-over-IPCS] Madanapalli, S., Park, S., and S. Chakrabarti,
"Transmission of IPv4 packets over IEEE 802.16's
IP Convergence Sublayer", Work in Progress,
November 2007.
[PS-GOALS] Jee, J., Madanapalli, S., and J. Mandin, "IP over
802.16 Problem Statement and Goals", Work
in Progress, December 2007.
[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.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 4941,
September 2007.
[WMF] "WiMAX Forum", <http://www.wimaxforum.org>.
[WiMAXArch] "WiMAX End-to-End Network Systems Architecture",
September 2007.Appendix A. WiMAX Network Architecture and IPv6 Support 🌍
the WiMAX (Worldwide Interoperability for Microwave Access) forum [WMF] has defined a network architecture in which the air interface is based on the IEEE 802.16 standard 📡. the addressing and operation of IPv6 described in this document are applicable to the WiMAX network as well 💖.
WiMAX is an example architecture of a network that uses the 802.16 specification for the air interface. WiMAX networks are also in the process of being deployed in various parts of the world, and the operation of IPv6 within a WiMAX network is explained in this appendix 🌏.
the WiMAX network architecture consists of the Access Service Network (ASN) and the Connectivity Service Network (CSN). the ASN is the access network that includes the BS and the AR in addition to other functions such as AAA, mobile IP foreign agent, paging controller, location register, etc. the ASN is defined as a complete set of network functions needed to provide radio access to a WiMAX subscriber. the ASN is the access network to which the MS attaches. the IPv6 access router is an entity within the ASN. the term ASN is specific to the WiMAX network architecture. the CSN is the entity that provides connectivity to the Internet and includes functions such as mobile IP home agent and AAA. the figure below shows the WiMAX reference model 🗺️:
-------------------
| ---- ASN | |----|
---- | |BS|\ R6 -------| |---------| | CSN|
|MS|-----R1----| ---- \---|ASN-GW| R3 | CSN | R5 | |
---- | |R8 /--|------|----| |-----|Home|
| ---- / | | visited| | NSP|
| |BS|/ | | NSP | | |
| ---- | |---------| | |
| NAP | \ |----|
------------------- \---| /
| | /
| (--|------/----)
|R4 ( )
| ( ASP network )
--------- ( or Internet )
| ASN | ( )
--------- (----------)
Figure 7: WiMAX network reference modelthree different types of ASN realizations called profiles are defined by the architecture 🧩. ASNs of profile types A and C include BS' and ASN-gateway(s) (ASN-GW), which are connected to each other via an R6 interface. an ASN of profile type B is one in which the functionality of the BS and other ASN functions are merged together. no ASN-GW is specifically defined in a profile B ASN. the absence of the R6 interface is also a profile B specific characteristic. the MS at the IPv6 layer is associated with the AR in the ASN. the AR may be a function of the ASN-GW in the case of profiles A and C and is a function in the ASN in the case of profile B. when the BS and the AR are separate entities and linked via the R6 interface, IPv6 packets between the BS and the AR are carried over a Generic Routing Encapsulation (GRE) tunnel. the granularity of the GRE tunnel should be on a per-MS basis or on a per-service-flow basis (an MS can have multiple service flows, each of which is identified uniquely by a service flow ID) 🎯. the protocol stack in WiMAX for IPv6 is shown below 🥞:
|-------|
| App |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
| |
|-------| /------ -------
| | / IPv6 | | |
| IPv6 |- - - - - - - - - - - - - - - - / | | |-->
| | --------------- -------/ | | IPv6|
|-------| | \Relay/ | | | |- - - | |
| | | \ / | | GRE | | | |
| | | \ /GRE | - | | | | |
| |- - - | |-----| |------| | | |
| IPv6CS| |IPv6CS | IP | - | IP | | | |
| ..... | |...... |-----| |------|--------| |-----|
| MAC | | MAC | L2 | - | L2 | L2 |- - - | L2 |
|-------| |------ |-----| |----- |--------| |-----|
| PHY |- - - | PHY | L1 | - | L1 | L1 |- - - | L1 |
-------- --------------- ----------------- -------
MS BS AR/ASN-GW CSN Rtr
Figure 8: WiMAX protocol stackas can be seen from the protocol stack description, the IPv6 end-points are constituted in the MS and the AR. the BS provides lower-layer connectivity for the IPv6 link 🧠✨.
Appendix B. IPv6 Link in WiMAX ✨
okay so WiMAX is basically a network built on the IEEE Std 802.16 air interface 📡 and this appendix explains how an IPv6 link looks inside a WiMAX network 🦋 the MS and the AR are connected through two things:
- a transport connection identified by a Connection Identifier (CID) over the air interface (so between the MS and BS), and
- a GRE tunnel between the BS and AR that carries the IPv6 packets 🎀
from IPv6's point of view, the MS and the AR are connected by a point-to-point link 💅 the air transport connection plus the GRE tunnel between the BS and AR together make a (point-to-point) tunnel at the layer below IPv6 🌸
the collection of service flows (tunnels) going to an MS is treated as a single link 🧚 each link has only an MS and an AR, each MS belongs to a different link, and no two MSs share the same link 🙈 a different prefix should be assigned to each unique link ✨ and honestly this link is fully consistent with a standard IP link, no exceptions, and it matches the definition of a point-to-point link in [RFC4861] 👑 iconic
Appendix C. IPv6 Link Establishment in WiMAX
so the mobile station does its initial network entry exactly as 802.16 specifies 🫶 once that's done successfully, the ASN gateway/AR kicks off the establishment of the initial service flow (ISF) for IPv6 towards the MS ✨ the ISF is a GRE tunnel between the ASN-GW/AR and the BS, and the BS then asks the MS to set up a transport connection over the air interface 🦋
the end result is a transport connection over the air for carrying IPv6 packets, plus a GRE tunnel between the BS and AR for relaying them 💖 once the ISF is up, IPv6 packets can be sent and received between the MS and AR 🔥 the ISF is what lets the MS talk to the AR for host configuration procedures, and after the ISF is established the AR can send a router advertisement to the MS 🌈
an MS can also set up multiple service flows with different quality of service (QoS) characteristics 💅 the ISF can be considered the primary service flow, and the ASN-GW/AR treats each ISF, along with the other service flows to that same MS, as one unique link managed as a (virtual) interface 👑 it's giving organized
Appendix D. Maximum Transmission Unit in WiMAX
okay the WiMAX forum [WMF] says the Max SDU size is 1522 octets 🌸 so the IPv6 path MTU can be 1500 octets, right? 🙈 but here's the plot twist 😭 the GRE tunnel overhead between the BS and AR, plus the 6-byte MAC header over the air interface, means using 1500 would end up fragmenting packets 💀
so it is recommended that the MTU for IPv6 be set to 1400 octets in WiMAX networks, and that this value (which is different from the default) be communicated to the MS 🧚 ngl this is such a main character fix 💜
also, the 1522-octet number is a WiMAX forum specification, not the size of the SDU that can be sent over 802.16, which actually has a higher limit 🦋 don't mix those up bestie 🫶
Authors' Addresses 💖
these are the people who wrote it, bestie, so here are their details 🎀
Basavaraj Patil
Nokia Siemens Networks
6000 Connection Drive
Irving, TX 75039
USA
EMail: basavaraj.patil@nsn.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
EMail: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
EMail: sarikaya@ieee.org
JinHyeock Choi
Samsung AIT
Networking Technology Lab
P.O.Box 111
Suwon, Korea 440-600
EMail: jinchoe@samsung.com
Syam Madanapalli
Ordyn Technologies
1st Floor, Creator Building, ITPL.
Off Airport Road
Bangalore, India 560066
EMail: smadanapalli@gmail.comFull Copyright Statement 🌈
the legal bit, verbatim so nothing gets lost 📜
Copyright (C) The IETF Trust (2008).
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 🦋
okay so the IETF doesn't take a position on whether any IP rights claimed over the tech in this doc are valid or in scope 🫶 it also doesn't say whether licenses are available, and it hasn't checked for rights on its own either 🙈 if you want the rules around RFC documents and rights, check out BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, any licensing assurances, and the results of any attempt to get a general license for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 💅
and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, the IETF invites you to tell them 💖 send it to ietf-ipr@ietf.org 🌸 bestie you're literally helping everyone 👑
📦 where this page comes from
- ietf: rfc5121 2008-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms