idnits 2.17.1 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2010) is 5070 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 16ng Working Group S. Madanapalli 2 Internet-Draft Ordyn Technologies 3 Intended status: Standards Track Soohong D. Park 4 Expires: December 4, 2010 Samsung Electronics 5 S. Chakrabarti 6 IP Infusion 7 G. Montenegro 8 Microsoft Corporation 9 June 2, 2010 11 Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer 12 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 14 Abstract 16 IEEE 802.16 is an air interface specification for wireless broadband 17 access. IEEE 802.16 has specified multiple service specific 18 Convergence Sublayers for transmitting upper layer protocols. The 19 packet CS (Packet Convergence Sublayer) is used for the transport of 20 all packet-based protocols such as Internet Protocol (IP) and IEEE 21 802.3 (Ethernet). The IP-specific part of the Packet CS enables the 22 transport of IPv4 packets directly over the IEEE 802.16 Media Access 23 Control (MAC). 25 This document specifies the frame format, the Maximum Transmission 26 Unit (MTU) and address assignment procedures for transmitting IPv4 27 packets over the IP-specific part of the Packet Convergence Sublayer 28 of IEEE 802.16. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 4, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Typical Network Architecture for IPv4 over IEEE 802.16 . . . . 4 78 3.1. IEEE 802.16 IPv4 Convergence Sublayer Support . . . . . . 4 79 4. IPv4 CS link in 802.16 Networks . . . . . . . . . . . . . . . 5 80 4.1. IPv4 CS link establishment . . . . . . . . . . . . . . . . 5 81 4.2. Frame Format for IPv4 Packets . . . . . . . . . . . . . . 5 82 4.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6 83 5. Subnet Model and IPv4 Address Assignment . . . . . . . . . . . 8 84 5.1. IPv4 Unicast Address Assignment . . . . . . . . . . . . . 9 85 5.2. Address Resolution Protocol . . . . . . . . . . . . . . . 9 86 5.3. IP Broadcast and Multicast . . . . . . . . . . . . . . . . 9 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 93 Appendix A. Multiple Convergence Layers - Impact on Subnet 94 Model . . . . . . . . . . . . . . . . . . . . . . . . 11 95 Appendix B. Sending and Receiving IPv4 Packets . . . . . . . . . 11 96 Appendix C. WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 99 1. Introduction 101 IEEE 802.16 [IEEE802_16] is a connection oriented access technology 102 for the last mile. The IEEE 802.16 specification includes the PHY 103 and MAC layers. The MAC includes various Convergence Sublayers (CS) 104 for transmitting higher layer packets including IPv4 packets 105 [IEEE802_16]. 107 The scope of this specification is limited to the operation of IPv4 108 over the IP-specific part of the packet CS (referred to as "IPv4 CS") 109 for hosts served by a network that utilizes the IEEE Std 802.16 air 110 interface. 112 This document specifies a method for encapsulating and transmitting 113 IPv4 [RFC0791] packets over the IPv4 CS of IEEE 802.16. This 114 document also specifies the MTU and address assignment method for 115 hosts using IPv4 CS. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Terminology 123 o Mobile Station (MS) - The term MS is used to mean an IP host. 124 This usage is more informal than that in IEEE 802.16, in which 125 "MS" refers to the interface implementing the IEEE 802.16 MAC and 126 PHY layers and not to the entire host. 128 Other terminology in this document is based on the definitions in 129 [RFC5154]. 131 3. Typical Network Architecture for IPv4 over IEEE 802.16 133 The network architecture follows what is described in [RFC5154] and 134 [RFC5121]. Namely, each MS is attached to an Access Router (AR) 135 through a Base Station (BS), a layer 2 entity (from the perspective 136 of the IPv4 link between the MS and the AR). 138 For further information on the typical network architecture, see 139 [RFC5121] section 5. 141 3.1. IEEE 802.16 IPv4 Convergence Sublayer Support 143 As described in [IEEE802_16], the IP-specific part of the packet CS 144 allows the transmission of either IPv4 or IPv6 payloads. In this 145 document, we are focusing on the IPv4 over Packet Convergence 146 Sublayer. 148 For further information on the IEEE 802.16 Convergence Sublayer and 149 encapsulation of IP packets, see [RFC5121] section 4 and 150 [IEEE802_16]. 152 4. IPv4 CS link in 802.16 Networks 154 In 802.16, the transport connection between an MS and a BS is used to 155 transport user data, i.e., IPv4 packets in this case. A transport 156 connection is represented by a service flow, and multiple transport 157 connections can exist between an MS and a BS. 159 When an AR and a BS are colocated, the collection of transport 160 connections to an MS is defined as a single IPv4 link. When an AR 161 and a BS are separated, it is recommended that a tunnel be 162 established between the AR and a BS whose granularity is no greater 163 than 'per MS' or 'per service flow' (An MS can have multiple service 164 flows which are identified by a service flow ID). Then the tunnel(s) 165 for an MS, in combination with the MS's transport connections, forms 166 a single point-to-point IPv4 link. 168 Each host belongs to a different IPv4 link and is assigned an unique 169 IPv4 address per recommendations in [RFC4968]. 171 4.1. IPv4 CS link establishment 173 In order to enable the sending and receiving of IPv4 packets between 174 the MS and the AR, the link between the MS and the AR via the BS 175 needs to be established. This section explains the link 176 establishment procedures following section 6.2 of [RFC5121]. Steps 177 1-4 are same as indicated in 6.2 of [RFC5121]. In step 5, support 178 for IPv4 is indicated. In step 6, a service flow is created that can 179 be used for exchanging IP layer signaling messages, e.g. address 180 assignment procedures using DHCP. 182 4.2. Frame Format for IPv4 Packets 184 IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the 185 data payloads of the 802.16 PDU ( see section 3.2 of [RFC5154] ). 187 0 1 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |H|E| TYPE |R|C|EKS|R|LEN | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | LEN LSB | CID MSB | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | CID LSB | HCS | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | IPv4 | 197 +- -+ 198 | header | 199 +- -+ 200 | and | 201 +- -+ 202 / payload / 203 +- -+ 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |CRC (optional) | 207 +-+-+-+-+-+-+-+-+ 209 Figure 1: IEEE 802.16 MAC Frame Format for IPv4 Packets 211 Here, "MSB" means "most significant byte", and "LSB" means "least 212 significant byte". 213 H: Header Type (1 bit). Shall be set to zero indicating that it 214 is a Generic MAC PDU. 215 E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload 216 is encrypted. 217 R: Reserved. Shall be set to zero. 218 C: CRC Indicator. 1 = CRC is included, 0 = No CRC is included 219 EKS: Encryption Key Sequence 220 LEN: The Length in bytes of the MAC PDU including the MAC header 221 and the CRC if present (11 bits) 222 CID: Connection Identifier (16 bits) 223 HCS: Header Check Sequence (8 bits) 224 CRC: An optional 8-bit field. CRC appended to the PDU after 225 encryption. 226 TYPE: This field indicates the subheaders (Mesh subheader, 227 Fragmentation Subheader, Packing subheader etc and special payload 228 types (ARQ) present in the message payload 230 4.3. Maximum Transmission Unit 232 The MTU value for IPv4 packets on an IEEE 802.16 link is configurable 233 (e.g., see the bottom of this section for some possible mechanisms). 235 The default MTU for IPv4 packets over an IEEE 802.16 link SHOULD be 236 1500 octets. Given the possibility for "in-the-network" tunneling, 237 supporting this MTU at the endhosts has implications on the 238 underlying network, for example, as discussed in [RFC4459]. 240 Per [RFC5121] section 6.3, the IP MTU can vary to be larger or 241 smaller than 1500 octets. 243 If an MS transmits 1500-octet packets in a deployment with a smaller 244 MTU, packets from the MS may be dropped at the link-layer silently. 245 Unlike IPv6, in which departures from the default MTU are readily 246 advertised via the MTU option in Neighbor Discovery (via router 247 advertisement), there is no similarly reliable mechanism in IPv4, as 248 the legacy IPv4 client implementations do not determine the link MTU 249 by default before sending packets. Even though there is a DHCP 250 option to accomplish this, DHCP servers are required to provide the 251 MTU information only when requested. 253 5. Subnet Model and IPv4 Address Assignment The Subnet Model 254 recommended for IPv4 over IEEE 802.16 using IPv4 CS is based on the 255 point-to-point link between MS and AR [RFC4968], hence each MS shall 256 be assigned an address with 32bit prefix-length or subnet-mask. The 257 point-to-point link between MS and AR is achieved using a set of IEEE 258 802.16 MAC connections (identified by service flows) and an L2 tunnel 259 (e.g., a GRE tunnel) per MS between BS and AR. If the AR is co- 260 located with the BS, then the set of IEEE 802.16 MAC connections 261 between the MS and BS/AR represent the point-to- point connection. 262 The 'Next hop' IP address of the IPv4 CS MS is always the IP address 263 of the AR, because MS and AR are attached via a point-to-point link. 264 5.1. IPv4 Unicast Address Assignment DHCP [RFC2131] SHOULD be used 265 for assigning IPv4 address for the MS. DHCP messages are transported 266 over the IEEE 802.16 MAC connection to and from the BS and relayed to 267 the AR. In case the DHCP server does not reside in the AR, the AR 268 SHOULD implement a DHCP relay Agent [RFC1542]. 5.2. Address 269 Resolution Protocol The IPv4 CS does not allow for transmission of 270 ARP [RFC0826] packets. Furthermore, in a point-to-point link model, 271 address resolution is not needed. 5.3. IP Broadcast and Multicast 272 Multicast or broadcast packets from the MS are delivered to the AR 273 via the BS through the point-to-point link. This specification 274 simply assumes that the broadcast and multicast services are 275 provided. How these services are implemented in an IEEE 802.16 276 Packet CS deployment is out of scope of this document. Discovery and 277 configuration of the proper link MTU value ensures adequate usage of 278 the network bandwidth and resources. Accordingly, deployments should 279 avoid packet loss due to a mismatch between the default MTU and the 280 configured link MTUs. 282 Some of the mechanisms available for the IPv4 CS host to find out 284 the link's MTU value and mitigate MTU-related issues are: 286 o The IEEE recently revised 802.16 (see IEEE 802.16-2009 287 [IEEE802_16]) to (among other things) allow providing the Service 288 Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase, 289 such that IEEE 802.16 compliant clients can infer and configure 290 the negotiated MTU size for the IPv4 CS link. However, the 291 implementation must communicate the negotiated MTU value to the IP 292 layer to adjust the IP Maximum payload size for proper handling of 293 fragmentation. Note that this method is useful only when MS is 294 directly connected to the BS. 295 o Configuration and negotiation of MTU size at the network layer by 296 using the DHCP interface MTU option [RFC2132]. 298 This document recommends that implementations of IPv4 and IPv4 CS 299 clients SHOULD implement the DHCP interface MTU option [RFC2132] in 300 order to configure its interface MTU accordingly. 302 In the absence of DHCP MTU configuration, the client node (MS) has 303 two alternatives: 1) use the default MTU (1500 bytes) or 2) determine 304 the MTU by the methods described in IEEE 802.16-2009[IEEE802_16]. 306 Additionally, the clients are encouraged to run PMTU [RFC1191] or 307 PPMTUD [RFC4821]. However, the PMTU mechanism has inherent problems 308 of packet loss due to ICMP messages not reaching the sender and IPv4 309 routers not fragmenting the packets due to the DF bit being set in 310 the IP packet. The above mentioned path MTU mechanisms will take 311 care of the MTU size between the MS and its correspondent node across 312 different flavors of convergence layers in the access networks. 314 5. Subnet Model and IPv4 Address Assignment 316 The Subnet Model recommended for IPv4 over IEEE 802.16 using IPv4 CS 317 is based on the point-to-point link between MS and AR [RFC4968], 318 hence each MS shall be assigned an address with 32bit prefix-length 319 or subnet-mask. The point-to-point link between MS and AR is 320 achieved using a set of IEEE 802.16 MAC connections (identified by 321 service flows) and an L2 tunnel (e.g., a GRE tunnel) per MS between 322 BS and AR. If the AR is co-located with the BS, then the set of IEEE 323 802.16 MAC connections between the MS and BS/AR represent the 324 point-to- point connection. 326 The 'Next hop' IP address of the IPv4 CS MS is always the IP address 327 of the AR, because MS and AR are attached via a point-to-point link. 329 5.1. IPv4 Unicast Address Assignment 331 DHCP [RFC2131] SHOULD be used for assigning IPv4 address for the MS. 332 DHCP messages are transported over the IEEE 802.16 MAC connection to 333 and from the BS and relayed to the AR. In case the DHCP server does 334 not reside in the AR, the AR SHOULD implement a DHCP relay Agent 335 [RFC1542]. 337 5.2. Address Resolution Protocol 339 The IPv4 CS does not allow for transmission of ARP [RFC0826] packets. 340 Furthermore, in a point-to-point link model, address resolution is 341 not needed. 343 5.3. IP Broadcast and Multicast 345 Multicast or broadcast packets from the MS are delivered to the AR 346 via the BS through the point-to-point link. This specification 347 simply assumes that the broadcast and multicast services are 348 provided. How these services are implemented in an IEEE 802.16 349 Packet CS deployment is out of scope of this document. 351 6. Security Considerations 353 This document specifies transmission of IPv4 packets over IEEE 802.16 354 networks with IPv4 Convergence Sublayer and does not introduce any 355 new vulnerabilities to IPv4 specifications or operation. The 356 security of the IEEE 802.16 air interface is the subject of 357 [IEEE802_16]. In addition, the security issues of the network 358 architecture spanning beyond the IEEE 802.16 base stations is the 359 subject of the documents defining such architectures, such as WiMAX 360 Network Architecture [WMF]. 362 7. IANA Considerations 364 This document has no actions for IANA. 366 8. Acknowledgements 368 The authors would like to acknowledge the contributions of Bernard 369 Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil, 370 Paolo Narvaez, and Bruno Sousa for their review and comments. The 371 working group members Burcak Beser, Wesley George, Max Riegel and DJ 372 Johnston helped shape the MTU discussion for IPv4 CS link. Thanks to 373 many other members of the 16ng working group who commented on this 374 document to make it better. 376 9. References 378 9.1. Normative References 380 [IEEE802_16] 381 "IEEE Std 802.16-2009, Draft Standard for Local and 382 Metropolitan area networks, Part 16: Air Interface for 383 Broadband Wireless Access Systems", May 2009. 385 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 386 September 1981. 388 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 389 converting network protocol addresses to 48.bit Ethernet 390 address for transmission on Ethernet hardware", STD 37, 391 RFC 826, November 1982. 393 [RFC1542] Wimer, W., "Clarifications and Extensions for the 394 Bootstrap Protocol", RFC 1542, October 1993. 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 400 RFC 2131, March 1997. 402 9.2. Informative References 404 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 405 November 1990. 407 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 408 Extensions", RFC 2132, March 1997. 410 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 411 Network Tunneling", RFC 4459, April 2006. 413 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 414 Discovery", RFC 4821, March 2007. 416 [RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple 417 Encapsulation Methods Considered Harmful", RFC 4840, 418 April 2007. 420 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 421 Based Networks", RFC 4968, August 2007. 423 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 424 Madanapalli, "Transmission of IPv6 via the IPv6 425 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 426 February 2008. 428 [RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 429 802.16 Problem Statement and Goals", RFC 5154, April 2008. 431 [WMF] "WiMAX End-to-End Network Systems Architecture Stage 2-3 432 Release 1.2, http://www.wimaxforum.org/", January 2008. 434 Appendix A. Multiple Convergence Layers - Impact on Subnet Model 436 Two different MSs using two different Convergence Sublayers (e.g. an 437 MS using Ethernet CS only and another MS using IPv4 CS only) cannot 438 communicate at data link layer and requires interworking at IP layer. 439 For this reason, these two nodes must be configured to be on two 440 different subnets. For more information refer to [RFC4840]. 442 Appendix B. Sending and Receiving IPv4 Packets 444 IEEE 802.16 MAC is a point-to-multipoint connection oriented air- 445 interface, and the process of sending and receiving of IPv4 packets 446 is different from multicast-capable shared medium technologies like 447 Ethernet. 449 Before any packets are transmitted, a IEEE 802.16 transport 450 connection must be established. This connection consists of IEEE 451 802.16 MAC transport connection between MS and BS and an L2 tunnel 452 between BS and AR (if these two are not co-located). This IEEE 453 802.16 transport connection provides a point-to-point link between 454 the MS and AR. All the packets originated at the MS always reach the 455 AR before being transmitted to the final destination. 457 IPv4 packets are carried directly in the payload of IEEE 802.16 458 frames when the IPv4 CS is used. IPv4 CS classifies the packet based 459 on upper layer (IP and transport layers) header fields to place the 460 packet on one of the available connections identified by the CID. 461 The classifiers for the IPv4 CS are source and destination IPv4 462 addresses, source and destinations ports, Type-of-Service and IP 463 protocol field. The CS may employ Packet Header Suppression (PHS) 464 after the classification. 466 The BS optionally reconstructs the payload header if PHS is in use. 468 It then tunnels the packet that has been received on a particular MAC 469 connection to the AR. Similarly the packets received on a tunnel 470 interface from the AR, would be mapped to a particular CID using the 471 IPv4 classification mechanism. 473 AR performs normal routing for the packets that it receives, 474 processing them per its forwarding table. However, the DHCP relay 475 agent in the AR MUST maintain the tunnel interface on which it 476 receives DHCP requests so that it can relay the DHCP responses to the 477 correct MS. The particular method is out of scope of this 478 specification as it need not depend on any particularities of IEEE 479 802.16. 481 Appendix C. WiMAX IPCS MTU size 483 WiMAX (Worldwide Interoperability for Microwave Access) forum has 484 defined a network architecture [WMF]. Furthermore, WiMAX has 485 specified IPv4 CS support for transmission of IPv4 packets between MS 486 and BS over the IEEE 802.16 link. The WiMAX IPv4 CS and this 487 specification are similar. One significant difference, however, is 488 that the WiMAX Forum [WMF] has specified the IP MTU as 1400 octets 489 [WMF] as opposed to 1500 in this specification. 491 Hence if an IPv4 CS MS configured with an MTU of 1500 octet enters a 492 WiMAX network, some of the issues mentioned in this specification may 493 arise. As mentioned in section 4.3, the possible mechanisms are not 494 guaranteed to work. Furthermore, an IPv4 CS client is not capable of 495 doing ARP probing to find out the link MTU. On the other hand, it is 496 imperative for an MS to know the link MTU size. In practice, an MS 497 should be able to sense or deduce the fact that it is operating 498 within a WiMAX network (e.g., given the WiMAX-specific 499 particularities of the authentication and network entry procedures), 500 and adjust its MTU size accordingly. Even though this method is not 501 perfect, and the potential for conflict may remain, this document 502 recommends a default MTU of 1500. This represents the WG's consensus 503 (after much debate) to select the best value for IEEE802.16 from the 504 point of view of the IETF, in spite of WiMAX Forum's deployment. 506 Authors' Addresses 508 Syam Madanapalli 509 Ordyn Technologies 510 1st Floor, Creator Building, ITPL 511 Bangalore - 560066 512 India 514 Email: smadanapalli@gmail.com 516 Soohong Daniel Park 517 Samsung Electronics 518 416 Maetan-3dong, Yeongtong-gu 519 Suwon 442-742 520 Korea 522 Email: soohong.park@samsung.com 524 Samita Chakrabarti 525 IP Infusion 526 1188 Arques Avenue 527 Sunnyvale, CA 528 USA 530 Email: samitac@ipinfusion.com 532 Gabriel Montenegro 533 Microsoft Corporation 534 Redmond, Washington 535 USA 537 Email: gabriel.montenegro@microsoft.com