RFC 5154

RFC 5154: IP over IEEE 802.16 Problem Statement and Goals 🌸

Okay bestie, RFC 5154 is giving informational energy 💅 It's from the Network Working Group, dated April 2008. J. Jee (the Ed. one, from ETRI) led the writing, with S. Madanapalli from Ordyn Technologies and J. Mandin from Runcom. It's category Informational, so it's a "here's what's going on" doc, not a standard ✨ Its header doesn't say it obsoletes or updates anything, so it's a standalone vibe 🦋

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Abstract 🫶

So this doc is about the problems you run into when you try to run IP over IEEE 802.16 networks. It finds the specific gaps in the IEEE 802.16 Media Access Control (MAC) layer for IPv4 and IPv6 support 🔥 It also gives you an overview of IEEE 802.16 network characteristics and convergence sublayers, plus the common terminology used as the base guideline when building a solution framework.

Table of Contents 🎀

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Overview of the IEEE 802.16 MAC Layer  . . . . . . . . . . . .  4
  3.1.  Transport Connections  . . . . . . . . . . . . . . . . . .  4
  3.2.  IEEE 802.16 PDU Format . . . . . . . . . . . . . . . . . .  5
  3.3.  IEEE 802.16 Convergence Sublayer . . . . . . . . . . . . .  5
4.  IP over IEEE 802.16 Problem Statement and Goals  . . . . . . .  6
  4.1.  Root Problem . . . . . . . . . . . . . . . . . . . . . . .  6
  4.2.  Point-to-Point Link Model for IP CS: Problems  . . . . . .  8
  4.3.  Ethernet-Like Link Model for Ethernet CS: Problems . . . .  9
  4.4.  IP over IEEE 802.16 Goals  . . . . . . . . . . . . . . . . 10
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
  8.2.  Informative References . . . . . . . . . . . . . . . . . . 12

1. Introduction 🌈

Broadband Wireless Access networks are the glow-up for low-bandwidth wireless. They're built for things users actually want, like high quality data and voice service, fast mobility, wide coverage, and more ✨ The IEEE 802.16 Working Group on Broadband Wireless Access Standards writes standards and recommended practices to help people develop and deploy broadband Wireless Metropolitan Area Networks [IEEE802.16].

Recently the WiMAX Forum, and especially its NWG (Network Working Group), has been defining the IEEE 802.16 network architecture. That includes IPv4, IPv6, Mobility, Interworking with different networks, AAA, and so on 🧚 The NWG is basically doing work above the layers that IEEE 802 standards cover, which is usually just the physical and link layers. WiBro (Wireless Broadband) is a Korean effort focused on the 2.3 GHz spectrum band, and it's also based on the IEEE 802.16 specification [IEEE802.16] 🇰🇷

IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at the MAC. Physically, though, it's arranged as a point-to-multipoint structure. The Base Station (BS) sits at one end of each connection, and an individual Subscriber Station (SS) sits at the other end 💜 The IEEE 802.16 convergence sublayer (CS) is the top part of the MAC, and its job is to assign transmit-direction Service Data Units (coming from a higher layer application, like IP or Ethernet at the BS or SS) to a specific outbound transport connection. IEEE 802.16 defines two convergence sublayer types: the ATM Convergence Sublayer (CS) and the Packet CS. The IP Specific Subpart (IP CS) and the 802.3 Ethernet Specific Subpart (Ethernet CS) of the Packet CS are within the current scope of IETF efforts 🎀

Configuring the IP Subnet over an IEEE 802.16 network is a bit of a puzzle 🧩 That's because of its point-to-point, connection-oriented nature, and because IP CS and Ethernet CS exist and assume different higher-layer functionality. An IP Subnet is a topological area that uses the same IP address prefix, where that prefix is not further subdivided except into individual addresses, as specified in [RFC4903]. The IP Subnet configuration depends on the underlying link-layer's characteristics, and it decides the overall IP operation on the network. IP CS and Ethernet CS of IEEE 802.16 assume different higher layer capabilities: IP routing functionality for IP CS, and bridging functionality for Ethernet CS. So the link-layer characteristics beneath IP can change depending on which convergence sublayer is adopted 👑

This document provides the feasible IP Subnet model for each IP CS and Ethernet CS, and it specifies the problems in running IP for each case 💖 It also gives an overview of IEEE 802.16 network characteristics, focusing specifically on the convergence sublayers, plus the common terminology to be used as the base guideline when defining solution frameworks.

2. Terminology 📚

• Subscriber Station (SS): An end-user equipment that provides connectivity to the IEEE 802.16 networks. It can be either fixed/nomadic or mobile equipment. In a mobile environment, the SS represents the Mobile Subscriber Station (MS) introduced in [IEEE802.16e].
• Base Station (BS): A generalized equipment set that provides connectivity, management, and control between the subscriber station and the IEEE 802.16 networks.
• Access Router (AR): An entity that performs an IP routing function to provide IP connectivity for the subscriber station (SS or MS).
• Protocol Data Unit (PDU): This refers to the data format passed from the lower edge of the MAC to the PHY, which typically contains SDU data after fragmentation/packing, encryption, etc.
• Service Data Unit (SDU): This refers to the data format passed to the upper edge of the MAC.
• IP Subnet: A topological area that uses the same IP address prefix, where that prefix is not further subdivided except into individual addresses, as specified from [RFC4903].
• Link: A topological area bounded by routers, which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet, as specified from [RFC4903].
• Transport Connection: The MAC layer connection in IEEE 802.16 between an SS (MS) and BS, with specific Quality of Service (QoS) attributes. Several types of connections are defined, including broadcast, unicast, and multicast. Each transport connection is uniquely identified by a 16-bit connection identifier (CID). A transport connection is a unique connection intended for user traffic. The scope of the transport connection is between the SS (MS) and the BS.
• Connection Identifier (CID): A 16-bit value that identifies a connection to equivalent peers in the IEEE 802.16 MAC of the SS (MS) and BS.
• Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS defined in [IEEE802.16].
• 802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined in [IEEE802.16].
• IP CS: The IP specific subpart of the Packet CS defined in [IEEE802.16].
• IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 (Packet, IPv4).
• IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 (Packet, IPv6).

3. Overview of the IEEE 802.16 MAC Layer 🔍

IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at the MAC, physically arranged in a point-to-multipoint structure. The BS terminates one end of each connection, and an individual SS terminates the other end of each connection 🦋 Each SS in the network has a 48-bit MAC address. The BS has a 48-bit unique identifier called "BSId". The BS and SS learn each other's MAC Address/BSId when the SS enters the network. The BS may also have a 48-bit MAC address, but the SS only knows about it if it's using the Ethernet CS 🌸

3.1. Transport Connections 🚀

User data traffic travels in both the BS-bound (uplink) and SS-bound (downlink) directions, carried on unidirectional "transport connections". Each transport connection has a particular set of associated parameters, which indicate characteristics such as cryptographic suite and quality of service.

After an SS successfully enters the IEEE 802.16 network, no data traffic is possible yet, because there are no transport connections between the BS and the SS. Transport connections are established through a 3-message signaling sequence within the MAC layer, usually initiated by the BS 💅

A downlink-direction transport connection is regarded as "multicast" if it has been made available (via MAC signaling) to more than one SS. Uplink-direction connections are always unicast 🎀

3.2. IEEE 802.16 PDU Format 📦

An IEEE 802.16 PDU (i.e., the format that is transmitted over the airlink) consists of a Generic MAC header, various optional subheaders, and a data payload.

The IEEE 802.16 Generic MAC header carries the Connection Identifier (CID) of the connection that the PDU is associated with. We should observe that there is no source or destination address present in the raw IEEE 802.16 MAC header 👀

3.3. IEEE 802.16 Convergence Sublayer ✨

okay so the convergence sublayer (CS) is basically the translator 🎀 It's the part of the MAC that maps between the MAC service and the internal connection-oriented service of the MAC CPS (Common Part Sublayer), using classification and encapsulation. Bestie, this is giving middleman energy and I'm obsessed.

Classification is where it gets fun 💅 It takes transmit-direction Service Data Units (the stuff coming down from a higher-layer app, like an IP stack at the BS or SS) and assigns each one to a specific outbound transport connection. The CS keeps an ordered "classifier table," and every entry has a classifier and a target CID. A classifier is a conjunction of one or more subclassifiers. Each subclassifier looks at one packet field (like the destination MAC address in an Ethernet frame, or the Type of Service (TOS) field of an IP datagram inside an Ethernet frame) and checks it against a particular value or range of values.

So how does matching work? The CS starts at the first entry of the table and walks down to the last, checking the Service Data Unit's fields against each entry's classifier. The first match wins 🏆 Then the CS associates the Service Data Unit with the target CID for eventual transmission, and the rest of the IEEE 802.16 MAC and PHY processing takes over. Iconic.

IEEE 802.16 defines two convergence sublayer types: the ATM CS and the Packet CS. The ATM CS supports ATM directly. The Packet CS has three subparts:

• "The IP Specific Subpart" carries IP packets over a point-to-point connection.
• "The 802.3 Ethernet Specific Subpart" carries packets encoded in the 802.3/Ethernet packet format with 802.3 style headers.
• "The 802.1Q VLAN Specific Subpart" carries 802 style packets that contain 802.1Q VLAN Tags.

Classifiers applied to connections at connection establishment time further sort and subdivide the traffic running over a connection. It's like a second layer of sorting, very organized 🗂️

The classifications for the Ethernet CS include packet over the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 802.3/Ethernet CS, 802.3/Ethernet CS with RObust Header Compression (ROHC) header compression, and 802.3/Ethernet with Enhanced Compressed Real-Time Protocol (ECRTP) header compression.

The classifications for the 802.1Q/VLAN CS include IPv4 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN.

Now the spicy bit 🌶️ The 802.3/Ethernet CS has a packet classification that does not restrict the IP version (packet over the 802.3/Ethernet CS), but the IP CS and the 802.1Q/VLAN CS do. All the IP classifiers for those CSs are either IPv4 or IPv6.

Classifiers also let the MAC be sure certain fields are present in the headers, so it can apply the payload header suppression (PHS) feature of IEEE 802.16 to those headers. Big brain move 🧠

For brevity, this document uses the following naming conventions for particular classifications of particular subparts of particular CSs:

• IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, IPv4)
• IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, IPv6)
• Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 (Packet, 802.3/Ethernet)

An implementation of IEEE 802.16 can support multiple CS types. Mix and match, no cap 💜

Lastly, the CS type, subpart, and classification together define the type of data interface (for example IPv4/IPv6 or 802.3) that IEEE 802.16 presents to the higher-layer application. That's the whole vibe: the CS decides what kind of interface the app actually sees. 🦋

---

4. IP over IEEE 802.16 Problem Statement and Goals 🌸

4.1. Root Problem

The key issue when deploying IP over IEEE 802.16 networks is how to configure an IP Subnet over that link, which is connection-oriented and point-to-point at the MAC level. An IP Subnet is a topological area that uses the same IP address prefix, where that prefix is not further subdivided except into individual addresses. [RFC4903] There are three different IP Subnet models [RFC4968] that are possible for an IEEE 802.16 network:

1. Point-to-point Link Model
2. Ethernet-like Link Model
3. Shared IPv6 Prefix Link Model

Here's how each of those models runs into trouble on IEEE 802.16 🙈

In the point-to-point link model, each SS under a BS resides on a different IP Subnet. So only one SS and one AR exist under an IP Subnet, and IP packets with a link-local scope destination are delivered only within the point-to-point link between an SS and an AR. PPP [RFC1661] has been widely used for this kind of link. However, PPP can't be used directly on IEEE 802.16, because IEEE 802.16 doesn't define a convergence sublayer that can encapsulate and decapsulate PPP frames. So there needs to be a mechanism that provides a point-to-point link between an SS and an AR in the case of the IP CS. The other option is to run PPP over Ethernet using the Ethernet CS. But the Ethernet CS assumes the upper layer's bridging functionality to realize the Ethernet-like link model, so that's a no-go on its own 😤

In the Ethernet-like link model, all SSs under an AR reside on the same IP Subnet. This also applies when SSs are connected to different BSs. The model assumes the underlying link layer provides the equivalent of Ethernet functionality, for example native broadcast and multicast. It seems feasible to apply IEEE 802.16's Ethernet CS to configure this link model. However, IEEE 802.16's MAC is still connection-oriented, and it doesn't provide multicast and broadcast connections for IP packet transfer. Therefore, we need a mechanism like IEEE 802.1D to realize multicast and broadcast. Moreover, frequent IP multicast and broadcast signaling should be avoided so as not to wake up the SSs that are in sleep/idle mode [IEEE802.16e]. Nobody wants a rude wake-up 😴

The shared IPv6 prefix link model eventually results in multi-link subnet problems [RFC4903]. In IEEE 802.16, the BS assigns separate IEEE 802.16 connections to SSs, so the SSs are placed on different links. In this situation, distributing a shared IPv6 prefix to SSs that sit on different links causes multi-link subnet problems. This applies to the IP CS, and even to the Ethernet CS if no bridging functionality is implemented on top of the BS or between the BS and the AR. 🧩

We identified the feasible IP Subnet models for IEEE 802.16 networks based on the convergence sublayers. At the current stage, only the IP CS and Ethernet CS of IEEE 802.16 are within the scope of ongoing IETF work. The feasible IP Subnet models for each convergence sublayer are:

1. Point-to-Point Link model for IP CS.
2. Ethernet-like Link Model for Ethernet CS.

Because of the point-to-point nature of the IEEE 802.16 MAC, the Point-to-Point link model is the feasible IP Subnet model for the IP CS. For the Ethernet CS, the Ethernet-like link model is the feasible one. However, in this model, unnecessary multicast and broadcast packets within an IP Subnet should be minimized. ✨

4.2. Point-to-Point Link Model for IP CS: Problems

• Address Resolution:

Address Resolution is the process by which IP nodes determine the link-layer address of a destination node on the same IP Subnet, given only the destination's IP address. With the IP CS, the IEEE 802.16 MAC address isn't used as part of the IEEE 802.16 frame, so the typical use of the Address Resolution Protocol (ARP) or the Neighbor cache doesn't apply. That makes address resolution potentially redundant with the IP CS. For IPv4, ARP cannot be carried by the IP CS, so it isn't used by either the SS or the BS. For IPv6, address resolution is a function of the IP layer, and IP reachability state is maintained through neighbor discovery packets. So blocking neighbor discovery packets would break the neighbor unreachability detection model. Yikes 😬

• Router Discovery:

The BS needs to send the Router Advertisement (RA) with a separate IP prefix in unicast, explicitly to each SS, in order to send periodic router advertisements in IEEE 802.16 networks. 📮

• Prefix Assignment:

A separate IP prefix should be distributed to each SS so they're located on different IP Subnets. When an SS moves between BSs under the same AR, the AR needs to redistribute the same IP Subnet prefix that the SS used at the previous BS. Consistency is everything 💜

• Next-Hop:

An SS's next hop always needs to be the AR that provides IP connectivity on that access network. 🚪

• Neighbor Unreachability Detection (NUD):

Because the SS always sees an AR as its next hop, NUD is required only for that AR. Also, the requirement for NUD may depend on whether a connection to the BS exists for that particular destination. 🔍

• Address Autoconfiguration:

Because a unique prefix is assigned to each SS, the IP Subnet consists of only one SS and an AR. Therefore, duplicate address detection (DAD) is trivial. Easy mode 😎

4.3. Ethernet-Like Link Model for Ethernet CS: Problems

• Address Resolution:

For the Ethernet CS, the sender needs to perform address resolution to fill the destination Ethernet address field, even though that address isn't used for transmitting an IEEE 802.16 frame over the air. That Ethernet destination address is used by a BS or bridge to decide where to forward the Ethernet frame after decapsulating the IEEE 802.16 frame. When the destination's IP address has the same address prefix as its own, the sender should set the Ethernet frame's destination address to the destination itself. To acquire that address, address resolution should be performed through conventional broadcast- and multicast-based ARP or Neighbor Discovery Protocol (NDP). However, if these multicast and broadcast packets aren't filtered (e.g., [RFC4541]), they result in waking up SSs that are in sleep/idle mode [IEEE802.16e]. Filter those, bestie 🧹

• Router Discovery:

All SSs under the AR are located in the same broadcast domain in the Ethernet-like link model. In this environment, sending periodic Router Advertisements to the all-nodes multicast address results in waking up SSs that are in sleep/idle mode [IEEE802.16e]. 📣

• Prefix Assignment:

Because the same IP prefix is shared by multiple SSs, an IP Subnet consists of multiple SSs and an AR. The SS assumes that on-link neighbors exist and tries to resolve the L2 address for on-link prefixes. However, direct communication using link-layer addresses between two SSs isn't possible with the Ethernet CS alone; bridging functionality must be added on top of the BS or between the BS and the AR. 🌉

• Next-Hop:

When the Ethernet CS is used and the accompanying Ethernet capability emulation is implemented, the next hop for a destination IP with the same global prefix as the sender, or a link-local address type, should be the destination itself, not an AR. 🎯

• Neighbor Unreachability Detection (NUD):

All SSs under the same AR are neighbors of each other. Therefore, NUD is required for all the SSs and the AR. Everybody's in the group chat 💬

• Address Autoconfiguration:

Duplicate Address Detection (DAD) should be performed among the multiple SSs and the AR that use the same IP prefix. The previous multicast-based DAD causes the problem of waking up SSs that are in sleep/idle mode [IEEE802.16e]. Multicast drama again 🙃

4.4. IP over IEEE 802.16 Goals ✨

okay so this is the wishlist bit 🎀 the goals are listed in no particular order, but each one points at work the IETF still needs to do 💅

• Goal #1. Define the way to provide the point-to-point link model for IP CS. 🦋
• Goal #2. Reduce the power consumption caused by waking up sleep/idle [IEEE802.16e] terminals for Ethernet-like link model. 🔋💤
• Goal #3. Avoid multi-link subnet problems. 🌸
• Goal #4. Allow applicability of security schemes such as SEcure Neighbor Discovery (SEND) [RFC3971]. 🔐
• Goal #5. Do not introduce any new security threats. 🫶
• Goal #6. Review management requirements and specifically the interfaces and specific management model (objects) for IP over IEEE 802.16 in collaboration with IEEE 802.16 working group. 📋

---

5. Security Considerations 🔥

okay this one is serious bestie 😭 this document describes the problem statement and goals for IP over IEEE 802.16 networks, and it does not introduce any new security threats. the IEEE 802.16 link layer uses cryptographic security mechanisms, as specified in [IEEE802.16][IEEE802.16e]. so the security story lives in those specs, not here 🔐✨

---

6. Contributors 🌈

this doc is a joint effort of the problem statement team of the IETF 16ng Working Group. the team members are Junghoon Jee, Syam Madanapalli, Jeff Mandin, Gabriel Montenegro, Soohong Daniel Park, and Maximilian Riegel. they're the real MVPs 👑

the problem statement team members can be reached at:

   Junghoon Jee, jhjee@etri.re.kr

   Syam Madanapalli, smadanapalli@gmail.com

   Jeff Mandin, j_mandin@yahoo.com

   Gabriel Montenegro, g_e_montenegro@yahoo.com

   Soohong Daniel Park, soohong.park@samsung.com

   Maximilian Riegel, maximilian.riegel@nsn.com

---

7. Acknowledgments 🫶

the authors want to give special thanks to David Johnston 💖 for his help with Section 3, "Overview of the IEEE 802.16 MAC Layer", and for carefully reviewing the entire document. they also want to thank Phil Roberts for suggesting the reorganization of the document based on the baseline IP subnet models. iconic reviewer behavior 🧚

the authors also want to thank Jari Arkko, HeeYoung Jung, Myung-Ki Shin, Eun-Kyoung Paik, Jaesun Cha, and the KWISF (Korea Wireless Internet Standardization Forum) for their comments and contributions. everyone who helped gets a sparkly shoutout ✨💜

---

8. References 📚

8.1. Normative References

   [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)",
                  STD 51, RFC 1661, July 1994.

   [RFC3971]      Arkko, J., Kempf, J., Zill, B., and P. Nikander,
                  "SEcure Neighbor Discovery (SEND)", RFC 3971,
                  March 2005.

8.2. Informative References

   [IEEE802.16]   IEEE Std 802.16-2004, "IEEE Standard for Local and
                  metropolitan area networks, Part 16: Air Interface for
                  Fixed Broadband Wireless Access Systems",
                  October 2004.

   [IEEE802.16e]  IEEE Std 802.16e, "IEEE standard for Local and
                  metropolitan area networks, Part 16:Air Interface for
                  fixed and Mobile broadband wireless access systems",
                  October 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.

   [RFC4903]      Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
                  June 2007.

   [RFC4968]      Madanapalli, S., "Analysis of IPv6 Link Models for
                  802.16 Based Networks", RFC 4968, August 2007.

---

Authors' Addresses 💌

   Junghoon Jee (editor)
   ETRI
   161 Gajeong-dong Yuseong-gu
   Daejeon  305-700
   Korea

   Phone: +82 42 860 5126
   EMail: jhjee@etri.re.kr


   Syam Madanapalli
   Ordyn Technologies
   1st Floor, Creator Building, ITPL
   Bangalore - 560066
   India

   EMail: smadanapalli@gmail.com


   Jeff Mandin
   Runcom

   EMail: j_mandin@yahoo.com

---

Full Copyright Statement ©

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 in it are provided on an "AS IS" basis. the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force disclaim all warranties, as written below:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

---

Intellectual Property 🦋

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. it also doesn't claim to have made any independent effort to find those rights. info on how rights work for RFC documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🔍

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org. 💜