idnits 2.17.1 draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2007) is 6259 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-16ng-ps-goals-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 16ng Working Group S. Madanapalli 3 Internet-Draft LogicaCMG 4 Intended status: Standards Track Soohong D. Park 5 Expires: August 11, 2007 Samsung Electronics 6 February 7, 2007 8 Transmission of IPv4 packets over 802.16's IP Convergence Sublayer 9 draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 11, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 IEEE 802.16 is an air interface specification for wireless broadband 43 access. IEEE has specified several service specific convergence 44 sublayers (CS) for 802.16 which are used by upper layer protocols. 45 The ATM CS and Packet CS are the two main service-specific 46 convergence sublayers and these are a part of the 802.16 MAC which 47 the upper layers interface to. The packet CS is used for transport 48 for all packet-based protocols such as Internet Protocol (IP), IEEE 49 Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific 50 part of the Packet CS enables transport of IPv4 packets directly over 51 the 802.16 MAC. 53 This document specifies the frame format, the Maximum Transmission 54 Unit (MTU) and address assignment procedures for transmitting Pv4 55 packets over IP Convergence Sublayer (IPCS) of IEEE 802.16. This 56 document describes on how to deal with Address Resolution Protocol 57 (ARP) and Mapping of multicast IP address to MAC address. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Typical Network Architecture for IPv4 over 802.16 . . . . . . 3 64 4. Frame Format for IPv4 Packets . . . . . . . . . . . . . . . . 4 65 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5 66 6. IPv4 Address Assignment . . . . . . . . . . . . . . . . . . . 6 67 7. Address Resolution Protocol . . . . . . . . . . . . . . . . . 6 68 8. IP Multicast Address Mapping . . . . . . . . . . . . . . . . . 6 69 9. Sending and Receiving IPv4 Packets . . . . . . . . . . . . . . 6 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 13.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 Intellectual Property and Copyright Statements . . . . . . . . . . 10 79 1. Introduction 81 802.16 [6] is a connection oriented access technology for the last 82 mile without bi-directional native multicast support. 802.16 has only 83 downlink multicast support and there is no mechanisms defined for 84 mobile stations to be able to send multicast packets that can be 85 mapped to downlink multicast connection. And also 802.16 MAC does 86 not use the Source and Destination MAC addresses, instead it uses the 87 Connection Identifiers (CIDs), which are assigned dynamically while 88 setting up the MAC connections, for transmitting the 802.16 frames 89 between a Mobile Station and a Base Station. 91 This document specifies a method for encapsulating and transmitting 92 IPv4 [2] and Address Resolution Protocol (ARP) packets over IP CS of 93 IEEE 802.16. This document also specifies the MTU and address 94 assignment method for the 802.16 based networks using IPCS. As the 95 802.16 MAC does not use the source and destination MAC addresses for 96 the frame transmission, this document recommends avoiding ARP and 97 Mapping of multicast IP address to MAC address, and recommends always 98 assigning a default gateway for the mobile stations. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [1]. 104 2. Terminology 106 The terminology in this document is based on the definitions in [10], 107 in addition to the ones specified in this section. 109 Access Router (AR): An entity that performs an IP routing function to 110 provide IP connectivity for Mobile Stations. In WiMAX Networks, the 111 AR is an Access Service Network Gateway. 113 3. Typical Network Architecture for IPv4 over 802.16 115 In a network that utilizes the 802.16 air interface the MS is 116 attached to an Access Router (AR) through a Base Station (BS), a 117 layer 2 entity. The AR can be an integral part of the BS or the AR 118 could be an entity beyond the BS within the access network. IPv4 119 packets between the MS and BS are carried over a point-to-point MAC 120 transport connection which has a unique connection identifier (CID). 121 The packets between BS and AR are carried using L2 tunnel (typically 122 GRE tunnel) so that MS and AR are seen as layer 3 peer entities. At 123 least one L2 tunnel is required for each MS, so that IP packets can 124 be sent to MSs before they acquire IP addresses. The figure below 125 illustrates the network architectures. 127 +-----+ CID1 +------+ +-----------+ 128 | MS1 |----------+| BS |----------| AR |-----[Internet] 129 +-----+ / +------+ +-----------+ 130 . / ____________ 131 . CIDn / ()__________() 132 +-----+ / L2 Tunnel 133 | MSn |-----/ 134 +-----+ 136 Figure 1: Typical Network Architecture for IPv4 over 802.16 138 The above network model serves as an example and is shown to 139 illustrate the point to point link between the MS and the AR. The L2 140 tunnel is not required if BS and AR are integrated into a single box. 142 4. Frame Format for IPv4 Packets 144 IPv6 packets are transmitted in Generic 802.16 MAC frames as shown in 145 the following figure. 147 0 1 148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |H|E| TYPE |R|C|EKS|R|LEN | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | LEN LSB | CID MSB | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | CID LSB | HCS | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | IPv4 | 157 +- -+ 158 | header | 159 +- -+ 160 | and | 161 +- -+ 162 / payload ... / 163 +- -+ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |CRC (optional) | 167 +-+-+-+-+-+-+-+-+ 169 Figure 2: 802.16 MAC Frame Format for IPv4 Packets 171 H: Header Type (1 bit). Shall be set to zero indicating that it 172 is a Generic MAC PDU. 173 E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload 174 is encrypted. 175 R: Reserved. Shall be set to zero. 176 C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included 177 EKS: Encryption Key Sequence 178 LEN: The Length in bytes of the MAC PDU including the MAC header 179 and the CRC if present (11 bits) 180 CID: Connection Identifier (16 bits) 181 HCS: Header Check Sequence (8 bits) 182 CRC: An optional 8-bit field. CRC appended to the PDU after 183 encryption. 184 TYPE: This field indicates the subheaders (Mesh subheader, 185 Fragmentation Subheader, Packing subheader etc and special payload 186 types (ARQ) present in the message payload 188 5. Maximum Transmission Unit 190 The Length parameter of 802.16 MAC frame has a size of 11 bits. 191 Hence the total PDU size is 2048 bytes. The IPv4 payload can be a 192 maximum value of 2038 bytes ( Total PDU size (2048) - (MAC Header (6) 193 + CRC (4)). The default MTU for IPv4 over 802.16 SHOULD be 1920, 194 this would accommodate tunneling overhead for delivering the packets 195 between BS and AR. This size may be reduced or increased by a Path 196 MTU Discovery [8] or by manual configuration of each MS. The minimum 197 and maximum MTUs for IPv4 packets over 802.16 with IPv4 CS are 576 198 bytes and 2038 bytes respectively. 200 6. IPv4 Address Assignment 202 DHCP [4] SHOULD be used for assigning IPv4 address for the MSs. DHCP 203 messages are transported over 802.16 MAC transported connection to 204 and from the AR. In case DHCP server does not reside in AR, the AR 205 SHOULD implement DHCP relay Agent [5]. The DHCP Relay Agent MUST 206 store the information on which interface (L2 Tunnel) it has received 207 the DHCP messages, so that it can relay the DHCP responses to the 208 correct MS. 210 7. Address Resolution Protocol 212 The 802.16 frame header does not contain the source and destination 213 MAC addresses, instead it uses the Connection Identifier (CID) for 214 the MAC frames delivery. This makes classical Address Resolution 215 Protocol (ARP) [3] trivial and unnecessary. If an MS initiates an 216 ARP for address resolution, the AR SHOULD silently discard the ARP 217 packet. All the outgoing packets that arrive at IPv4 layer, should 218 be given to 802.16's IPv4 CS, which would map the packets to 219 appropriate MAC transport connection. 221 The AR MUST be configured as the default gateway for the MSs that 222 have been attached to it. ICMP Router Discovery [9] may be used for 223 discovering the AR IP address. 225 8. IP Multicast Address Mapping 227 Mapping of multicast IP address to a MAC address is not required as 228 the 802.16 MAC address is not used for delivering the MAC frames. 229 The 802.16 uses the Connection ID (CID) for frame delivery hence no 230 address mapping is required. 232 9. Sending and Receiving IPv4 Packets 234 802.16 MAC is a point-to-multipoint connection oriented air- 235 interface, and the process of sending and receiving of IPv4 packets 236 is different from multicast capable shared medium technologies like 237 Ethernet. 239 Before any packets being transmitted, 802.16 transport connection 240 must be established. This connection is consists of 802.16 MAC 241 transport connection between MS and BS and an L2 tunnel between BS 242 and AR. This 802.16 transport connection provides a point-to-point 243 link between MS and AR. all the packets originated at the MS always 244 reach AR before being transmitted to the final destination. 246 IPv4 packets are carried directly in the payload of 802.16 frames 247 when the IPv4 CS is used. IPv4 CS classifies the packet based on 248 upper layer (IP and transport layers)header fields to put the packet 249 on one of the available connections identified by the CID. The 250 classifiers for the IPv4 CS are source and destination IPv4 251 addresses, source and destinations ports, Type-of-Service and IP 252 protocol field. The CS may employ Packet Header Suppression (PHS) 253 after the classification. 255 The BS tunnels the packet that has been received on a particular MAC 256 connection to the AR. BS reconstructs the payload header if the PHS 257 is in use before being the packet is tunneled to the AR. Similarly 258 the packets received on a tunnel interface from the AR, would be 259 mapped to a particular CID using IPv4 classification mechanism. 261 AR performs normal routing for the packets that it receives and 262 forwards the packet based on its forwarding table. However the DHCP 263 relay agent in the AR, MUST maintain the tunnel interface on which it 264 receives DHCP requests, so that it can relay the DHCP responses to 265 the correct MS. One way of doing this is to have a mapping between 266 MAC address and Tunnel Identifier. 268 10. Security Considerations 270 This document specifies transmission of IPv4 packets over 802.16 271 networks with IPv4 Convergence Sublayer and does not introduce any 272 new vulnerabilities to IPv4 specifications or operation. The 273 security of the 802.16 air interface is the subject of [6]. In 274 addition, the security issues of the network architecture spanning 275 beyond the 802.16 base stations is the subject of the documents 276 defining such architectures, such as WiMAX Network Architecture [7]. 278 11. IANA Considerations 280 This document has no actions for IANA. 282 12. Acknowledgements 284 TBD. 286 13. References 288 13.1. Normative References 290 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 291 Levels", BCP 14, RFC 2119, March 1997. 293 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, 294 September 1981. 296 [3] Plummer, D., "Ethernet Address Resolution Protocol: Or 297 converting network protocol addresses to 48.bit Ethernet 298 address for transmission on Ethernet hardware", STD 37, 299 RFC 826, November 1982. 301 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 302 March 1997. 304 [5] Wimer, W., "Clarifications and Extensions for the Bootstrap 305 Protocol", RFC 1542, October 1993. 307 13.2. Informative References 309 [6] "IEEE 802.16e, IEEE standard for Local and metropolitan area 310 networks, Part 16:Air Interface for fixed and Mobile broadband 311 wireless access systems", October 2005. 313 [7] "WiMAX End-to-End Network Systems Architecture, 314 http://www.wimaxforum.org/technology/documents", August 2006. 316 [8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 317 November 1990. 319 [9] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 320 September 1991. 322 [10] Jee, J., "IP over 802.16 Problem Statement and Goals", 323 October 2006, . 326 Authors' Addresses 328 Syam Madanapalli 329 LogicaCMG 330 Bangalore 331 India 333 Email: smadanapalli@gmail.com 335 Soohong Daniel Park 336 Samsung Electronics 337 416 Maetan-3dong, Yeongtong-gu 338 Suwon 442-742 339 Korea 341 Email: soohong.park@samsung.com 343 Full Copyright Statement 345 Copyright (C) The IETF Trust (2007). 347 This document is subject to the rights, licenses and restrictions 348 contained in BCP 78, and except as set forth therein, the authors 349 retain all their rights. 351 This document and the information contained herein are provided on an 352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 359 Intellectual Property 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at 381 ietf-ipr@ietf.org. 383 Acknowledgment 385 Funding for the RFC Editor function is provided by the IETF 386 Administrative Support Activity (IASA).