From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5948.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc5948.txt (limited to 'doc/rfc/rfc5948.txt') diff --git a/doc/rfc/rfc5948.txt b/doc/rfc/rfc5948.txt new file mode 100644 index 0000000..d9e1cc7 --- /dev/null +++ b/doc/rfc/rfc5948.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Madanapalli +Request for Comments: 5948 iRam Technologies +Category: Standards Track S. Park +ISSN: 2070-1721 Samsung Electronics + S. Chakrabarti + IP Infusion + G. Montenegro + Microsoft Corporation + August 2010 + + + Transmission of IPv4 Packets over the IP Convergence Sublayer + of IEEE 802.16 + +Abstract + + IEEE 802.16 is an air interface specification for wireless broadband + access. IEEE 802.16 has specified multiple service-specific + Convergence Sublayers for transmitting upper-layer protocols. The + Packet CS (Packet Convergence Sublayer) is used for the transport of + all packet-based protocols such as the Internet Protocol (IP) and + IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables + the transport of IPv4 packets directly over the IEEE 802.16 Media + Access Control (MAC) layer. + + This document specifies the frame format, the Maximum Transmission + Unit (MTU), and the address assignment procedures for transmitting + IPv4 packets over the IP-specific part of the Packet Convergence + Sublayer of IEEE 802.16. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5948. + + + + + + + + +Madanapalli, et al. Standards Track [Page 1] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Madanapalli, et al. Standards Track [Page 2] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Typical Network Architecture for IPv4 over IEEE 802.16 ..........4 + 3.1. IEEE 802.16 IPv4 Convergence Sublayer Support ..............4 + 4. IPv4 CS Link in 802.16 Networks .................................4 + 4.1. IPv4 CS Link Establishment .................................5 + 4.2. Frame Format for IPv4 Packets ..............................5 + 4.3. Maximum Transmission Unit ..................................6 + 5. Subnet Model and IPv4 Address Assignment ........................8 + 5.1. IPv4 Unicast Address Assignment ...........................8 + 5.2. Address Resolution Protocol ...............................8 + 5.3. IP Broadcast and Multicast ................................8 + 6. Security Considerations .........................................8 + 7. Acknowledgements ................................................9 + 8. References ......................................................9 + 8.1. Normative References .......................................9 + 8.2. Informative References .....................................9 + Appendix A. Multiple Convergence Layers -- Impact on Subnet + Model ................................................11 + Appendix B. Sending and Receiving IPv4 Packets ...................11 + Appendix C. WiMAX IPv4 CS MTU Size ...............................12 + +1. Introduction + + IEEE 802.16 [IEEE802_16] is a connection-oriented access technology + for the last mile. The IEEE 802.16 specification includes the + Physical (PHY) and Media Access Control (MAC) layers. The MAC layer + includes various Convergence Sublayers (CSs) for transmitting higher- + layer packets, including IPv4 packets [IEEE802_16]. + + The scope of this specification is limited to the operation of IPv4 + over the IP-specific part of the Packet CS (referred to as "IPv4 CS") + for hosts served by a network that utilizes the IEEE Std 802.16 air + interface. + + This document specifies a method for encapsulating and transmitting + IPv4 [RFC0791] packets over the IPv4 CS of IEEE 802.16. This + document also specifies the MTU and address assignment method for + hosts using IPv4 CS. + + 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]. + + + + + + +Madanapalli, et al. Standards Track [Page 3] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +2. Terminology + + o Mobile Station (MS) -- The term "MS" is used to refer to an IP + host. This usage is more informal than that in IEEE 802.16, in + which "MS" refers to the interface implementing the IEEE 802.16 + MAC and PHY layers and not to the entire host. + + o Last mile -- The term "last mile" is used to refer to the final + leg of delivering connectivity from a communications provider to a + customer. + + Other terminology in this document is based on the definitions in + [RFC5154]. + +3. Typical Network Architecture for IPv4 over IEEE 802.16 + + The network architecture follows what is described in [RFC5154] and + [RFC5121]. Namely, each MS is attached to an Access Router (AR) + through a Base Station (BS), a Layer 2 (L2) entity (from the + perspective of the IPv4 link between the MS and the AR). + + For further information on the typical network architecture, see + [RFC5121], Section 5. + +3.1. IEEE 802.16 IPv4 Convergence Sublayer Support + + As described in [IEEE802_16], the IP-specific part of the Packet CS + allows the transmission of either IPv4 or IPv6 payloads. In this + document, we are focusing on IPv4 over the Packet Convergence + Sublayer. + + For further information on the IEEE 802.16 Convergence Sublayer and + encapsulation of IP packets, see Section 4 of [RFC5121] and + [IEEE802_16]. + +4. IPv4 CS Link in 802.16 Networks + + In 802.16, the transport connection between an MS and a BS is used to + transport user data, i.e., IPv4 packets in this case. A transport + connection is represented by a service flow, and multiple transport + connections can exist between an MS and a BS. + + When an AR and a BS are co-located, the collection of transport + connections to an MS is defined as a single IPv4 link. When an AR + and a BS are separated, it is recommended that a tunnel be + established between the AR and a BS whose granularity is no greater + + + + + +Madanapalli, et al. Standards Track [Page 4] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + + than "per MS" or "per service flow". (An MS can have multiple + service flows, which are identified by a service flow ID.) Then the + tunnel(s) for an MS, in combination with the MS's transport + connections, forms a single point-to-point IPv4 link. + + Each host belongs to a different IPv4 link and is assigned a unique + IPv4 address, similar to the recommendations discussed in "Analysis + of IPv6 Link Models for IEEE 802.16 Based Networks" ([RFC4968]). + +4.1. IPv4 CS Link Establishment + + In order to enable the sending and receiving of IPv4 packets between + the MS and the AR, the link between the MS and the AR via the BS + needs to be established. This section explains the link + establishment procedure, as described in Section 6.2 of [RFC5121]. + Steps 1-4 are the same as those indicated in Section 6.2 of + [RFC5121]. In step 5, support for IPv4 is indicated. In step 6, a + service flow is created that can be used for exchanging IP-layer + signaling messages, e.g., address assignment procedures using DHCP. + +4.2. Frame Format for IPv4 Packets + + IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the + data payloads of the 802.16 PDU (see Section 3.2 of [RFC5154]). + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |H|E| TYPE |R|C|EKS|R|LEN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LEN LSB | CID MSB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CID LSB | HCS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 | + +- -+ + | header | + +- -+ + | and | + +- -+ + / payload / + +- -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |CRC (optional) | + +-+-+-+-+-+-+-+-+ + + Figure 1. IEEE 802.16 MAC Frame Format for IPv4 Packets + + + +Madanapalli, et al. Standards Track [Page 5] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + + Here, "MSB" means "most significant byte", and "LSB" means "least + significant byte". + + H: Header Type (1 bit). Shall be set to zero, indicating that it + is a Generic MAC PDU. + + E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload + is encrypted. + + R: Reserved. Shall be set to zero. + + C: Cyclic Redundancy Check (CRC) Indicator. 1 = CRC is included; + 0 = No CRC is included. + + EKS: Encryption Key Sequence. + + LEN: The Length, in bytes, of the MAC PDU, including the MAC + header and the CRC, if present (11 bits). + + CID: Connection Identifier (16 bits). + + HCS: Header Check Sequence (8 bits). + + CRC: An optional 8-bit field. The CRC is appended to the PDU + after encryption. + + TYPE: This field indicates the subheaders (Mesh subheader, + Fragmentation subheader, Packing subheader, etc.) and special + payload types (e.g., Automatic Repeat reQuest (ARQ)) present in + the message payload. + +4.3. Maximum Transmission Unit + + The MTU value for IPv4 packets on an IEEE 802.16 link is configurable + (e.g., see the end of this section for some possible mechanisms). + The default MTU for IPv4 packets over an IEEE 802.16 link SHOULD be + 1500 octets. Given the possibility for "in-the-network" tunneling, + supporting this MTU at the end hosts has implications on the + underlying network, for example, as discussed in [RFC4459]. + + Per [RFC5121], Section 6.3, the IP MTU can vary to be larger or + smaller than 1500 octets. + + If an MS transmits 1500-octet packets in a deployment with a smaller + MTU, packets from the MS may be dropped at the link layer silently. + Unlike IPv6, in which departures from the default MTU are readily + advertised via the MTU option in Neighbor Discovery (via router + advertisement), there is no similarly reliable mechanism in IPv4, as + + + +Madanapalli, et al. Standards Track [Page 6] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + + the legacy IPv4 client implementations do not determine the link MTU + by default before sending packets. Even though there is a DHCP + option to accomplish this, DHCP servers are required to provide the + MTU information only when requested. + + Discovery and configuration of the proper link MTU value ensures + adequate usage of the network bandwidth and resources. Accordingly, + deployments should avoid packet loss due to a mismatch between the + default MTU and the configured link MTUs. + + Some of the mechanisms available for the IPv4 CS host to find out the + link's MTU value and mitigate MTU-related issues are: + + o Recent revision of 802.16 by the IEEE (see IEEE 802.16-2009 + [IEEE802_16]) to (among other things) allow the provision of the + Service Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP + phase, such that clients that are compliant with IEEE 802.16 can + infer and configure the negotiated MTU size for the IPv4 CS link. + However, the implementation must communicate the negotiated MTU + value to the IP layer to adjust the IP Maximum Payload Size for + proper handling of fragmentation. Note that this method is useful + only when the MS is directly connected to the BS. + + o Configuration and negotiation of MTU size at the network layer by + using the DHCP interface MTU option [RFC2132]. + + This document recommends that implementations of IPv4 and IPv4 CS + clients SHOULD use the DHCP interface MTU option [RFC2132] in order + to configure its interface MTU accordingly. + + In the absence of DHCP MTU configuration, the client node (MS) has + two alternatives: 1) use the default MTU (1500 bytes), or 2) + determine the MTU by the methods described in IEEE 802.16-2009 + [IEEE802_16]. + + Additionally, the clients are encouraged to run Path MTU (PMTU) + Discovery [RFC1191] or Packetization Layer Path MTU Discovery + (PLPMTUD) [RFC4821]. However, the PMTU mechanism has inherent + problems of packet loss due to ICMP messages not reaching the sender + and IPv4 routers not fragmenting the packets due to the Don't + Fragment (DF) bit being set in the IP packet. The above-mentioned + path MTU mechanisms will take care of the MTU size between the MS and + its correspondent node across different flavors of convergence layers + in the access networks. + + + + + + + +Madanapalli, et al. Standards Track [Page 7] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +5. Subnet Model and IPv4 Address Assignment + + The subnet model recommended for IPv4 over IEEE 802.16 using IPv4 CS + is based on the point-to-point link between the MS and the AR + [RFC4968]; hence, each MS shall be assigned an address with a 32-bit + prefix length or subnet mask. The point-to-point link between the MS + and the AR is achieved using a set of IEEE 802.16 MAC connections + (identified by service flows) and an L2 tunnel (e.g., a Generic + Routing Encapsulation (GRE) tunnel) for each MS between the BS and + the AR. If the AR is co-located with the BS, then the set of IEEE + 802.16 MAC connections between the MS and the BS/AR represent the + point-to-point connection. + + The "next hop" IP address of the IPv4 CS MS is always the IP address + of the AR, because the MS and the AR are attached via a point-to- + point link. + +5.1. IPv4 Unicast Address Assignment + + DHCP [RFC2131] SHOULD be used for assigning an IPv4 address for the + MS. DHCP messages are transported over the IEEE 802.16 MAC + connection to and from the BS and relayed to the AR. In case the + DHCP server does not reside in the AR, the AR SHOULD implement a DHCP + relay agent [RFC1542]. + +5.2. Address Resolution Protocol + + The IPv4 CS does not allow for transmission of Address Resolution + Protocol (ARP) [RFC0826] packets. Furthermore, in a point-to-point + link model, address resolution is not needed. + +5.3. IP Broadcast and Multicast + + Multicast or broadcast packets from the MS are delivered to the AR + via the BS through the point-to-point link. This specification + simply assumes that the broadcast and multicast services are + provided. How these services are implemented in an IEEE 802.16 + Packet CS deployment is out of scope of this document. + +6. Security Considerations + + This document specifies transmission of IPv4 packets over IEEE 802.16 + networks with the IPv4 Convergence Sublayer and does not introduce + any new vulnerabilities to IPv4 specifications or operation. The + security of the IEEE 802.16 air interface is the subject of + [IEEE802_16]. In addition, the security issues of the network + + + + + +Madanapalli, et al. Standards Track [Page 8] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + + architecture spanning beyond the IEEE 802.16 Base Stations is the + subject of the documents defining such architectures, such as the + Worldwide Interoperability for Microwave Access (WiMAX) network + architecture [WMF]. + +7. Acknowledgements + + The authors would like to acknowledge the contributions of Bernard + Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil, + Paolo Narvaez, and Bruno Sousa for their review and comments. The + working group members Burcak Beser, Wesley George, Max Riegel, and DJ + Johnston helped shape the MTU discussion for the IPv4 CS link. + Thanks to many other members of the 16ng Working Group who commented + on this document to make it better. + +8. References + +8.1. Normative References + + [IEEE802_16] "IEEE Std 802.16-2009, Draft Standard for Local and + Metropolitan area networks, Part 16: Air Interface for + Broadband Wireless Access Systems", May 2009. + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [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. + + [RFC1542] Wimer, W., "Clarifications and Extensions for the + Bootstrap Protocol", RFC 1542, October 1993. + + [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. + +8.2. Informative References + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", + RFC 1191, November 1990. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP + Vendor Extensions", RFC 2132, March 1997. + + + + +Madanapalli, et al. Standards Track [Page 9] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + + [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- + Network Tunneling", RFC 4459, April 2006. + + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path + MTU Discovery", RFC 4821, March 2007. + + [RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple + Encapsulation Methods Considered Harmful", RFC 4840, + April 2007. + + [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for + 802.16 Based Networks", RFC 4968, August 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. + + [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE + 802.16 Problem Statement and Goals", RFC 5154, + April 2008. + + [WMF] "WiMAX End-to-End Network Systems Architecture Stage + 2-3 Release 1.2, http://www.wimaxforum.org/", + January 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + +Madanapalli, et al. Standards Track [Page 10] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +Appendix A. Multiple Convergence Layers -- Impact on Subnet Model + + Two different MSs using two different Convergence Sublayers (e.g., an + MS using Ethernet CS only and another MS using IPv4 CS only) cannot + communicate at the data link layer and require interworking at the IP + layer. For this reason, these two nodes must be configured to be on + two different subnets. For more information, refer to [RFC4840]. + +Appendix B. Sending and Receiving IPv4 Packets + + IEEE 802.16 MAC is a point-to-multipoint connection-oriented air + interface, and the process of sending and receiving IPv4 packets is + different from multicast-capable shared-medium technologies like + Ethernet. + + Before any packets are transmitted, an IEEE 802.16 transport + connection must be established. This connection consists of an + IEEE 802.16 MAC transport connection between the MS and the BS and an + L2 tunnel between the BS and the AR (if these two are not + co-located). This IEEE 802.16 transport connection provides a point- + to-point link between the MS and the AR. All the packets originating + at the MS always reach the AR before being transmitted to the final + destination. + + IPv4 packets are carried directly in the payload of IEEE 802.16 + frames when the IPv4 CS is used. IPv4 CS classifies the packet based + on upper-layer (IP and transport layers) header fields to place the + packet on one of the available connections identified by the CID. + The classifiers for the IPv4 CS are source and destination IPv4 + addresses, source and destination ports, Type-of-Service, and IP + Protocol field. The CS may employ Packet Header Suppression (PHS) + after the classification. + + The BS optionally reconstructs the payload header if PHS is in use. + It then tunnels the packet that has been received on a particular MAC + connection to the AR. Similarly, the packets received on a tunnel + interface from the AR would be mapped to a particular CID using the + IPv4 classification mechanism. + + The AR performs normal routing for the packets that it receives, + processing them per its forwarding table. However, the DHCP relay + agent in the AR MUST maintain the tunnel interface on which it + receives DHCP requests so that it can relay the DHCP responses to the + correct MS. The particular method is out of scope of this + specification as it need not depend on any particularities of + IEEE 802.16. + + + + + +Madanapalli, et al. Standards Track [Page 11] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +Appendix C. WiMAX IPv4 CS MTU Size + + The WiMAX (Worldwide Interoperability for Microwave Access) forum has + defined a network architecture [WMF]. Furthermore, WiMAX has + specified IPv4 CS support for transmission of IPv4 packets between + the MS and the BS over the IEEE 802.16 link. The WiMAX IPv4 CS and + this specification are similar. One significant difference, however, + is that the WiMAX Forum [WMF] has specified the IP MTU as 1400 octets + [WMF] as opposed to 1500 in this specification. + + Hence, if an IPv4 CS MS configured with an MTU of 1500 octets enters + a WiMAX network, some of the issues mentioned in this specification + may arise. As mentioned in Section 4.3, the possible mechanisms are + not guaranteed to work. Furthermore, an IPv4 CS client is not + capable of doing ARP probing to find out the link MTU. On the other + hand, it is imperative for an MS to know the link MTU size. In + practice, an MS should be able to sense or deduce the fact that it is + operating within a WiMAX network (e.g., given the WiMAX-specific + particularities of the authentication and network entry procedures), + and adjust its MTU size accordingly. Even though this method is not + perfect, and the potential for conflict may remain, this document + recommends a default MTU of 1500. This represents the WG's consensus + (after much debate) to select the best value for IEEE 802.16 from the + point of view of the IETF, in spite of the WiMAX Forum's deployment. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Madanapalli, et al. Standards Track [Page 12] + +RFC 5948 IPv4 over IEEE 802.16's IPv4 CS August 2010 + + +Authors' Addresses + + Syam Madanapalli + iRam Technologies + #H304, Shriram Samruddhi, Thubarahalli + Bangalore - 560066 + India + + EMail: smadanapalli@gmail.com + + + Soohong Daniel Park + Samsung Electronics + 416 Maetan-3dong, Yeongtong-gu + Suwon 442-742 + Korea + + EMail: soohong.park@samsung.com + + + Samita Chakrabarti + IP Infusion + 1188 Arques Avenue + Sunnyvale, CA + USA + + EMail: samitac@ipinfusion.com + + + Gabriel Montenegro + Microsoft Corporation + Redmond, WA + USA + + EMail: gabriel.montenegro@microsoft.com + + + + + + + + + + + + + + + + +Madanapalli, et al. Standards Track [Page 13] + -- cgit v1.2.3