IPv4 over IEEE 802.16 IP CS draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-03

1. IPv4 over IEEE 802.16 IP CSdraft-ietf-16ng-ipv4-over-802-dot-16-ipcs-03 Samita Chakrabarti IP Infusion Syam Madanapalli Ordyn Technologies Daniel Park Samsung

2. Background • WG LC comments addressed • Issue from the last IETF • Major: • Default MTU - whether it should be 1500 bytes or less • Minor: • Editorial clarifications

3. What Changed in rev 03 • Addressed major comments from Burcak Beser, Wesley George, Max Riegel and Keshav Chawla • Finalized text on MTU choices based on IEEE feedback and working group discussions • Added a few sections for clarifications; added thoughts on multicast packet handling at the appendix

4. The following considerations were used to choose the default MTU value (suggested by AD, Jari Arkko) difficulty of manual configuration ability to raise/lower the values automatically capability of 802.16 backhaul networks to handle larger MTUs (ipcs, ethcs, wimax and non-wimax) ability or inability to determine what network you are in inability of L2 devices to send ICMP messages Default MTU

5. New Text The MTU value for IPv4 packets on an IEEE 802.16 link is configurable. The default MTU for IPv4 packets over an IEEE 802.16 link is 1400 bytes. This default value accommodates for the overhead of the GRE tunnel used to transport IPv4 packets between the BS and AR and the IP-transport header. The choice of default MTU value in IPv4-CS link is determined by the present deployment of IEEE 802.16 network specifications and the legacy IPv4 client implementations where they do not typically ask for MTU configuration of the link, while DHCP servers are required to provide the MTU information only when requested. The default MTU value ensures that no packet loss happens at the L2 level due to the low-capacity IP CS link-MTU in order to accommodate the GRE encapsulation over IP-transport between the AR and BS. 1400 bytes to accommodate GRE/IPSec/VLAN overhead Avoids L2 packet loss and unnecessary fragmentation Default MTU

6. Setting MTU dynamically • The IEEE is currently revising 802.16 (802.16rev2) - To inform the SDU MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase, such that future IEEE 802.16 compliant clients can configure the negotiated MTU size for IP-CS link. • If MS and BS are connected with bridges then the SDU MTU may not provide correct information of the path • All Future IPv4 and IP4-CS clients SHOULD implement DHCP interface MTU option [RFC 2132] at layer 3 • Is SHOULD ok for this requirement? • PMTU [RFC 1191] and PPMTUD[RFC 4821] are recommended for the new IPv4 and IP-CS client implementations

7. Other Changes • Section 5.1 discusses router discovery mechanism and clarifies and IPv4 subnet model and address assignment • Text added for handling multicast and broadcast address mapping – it clarifies that defining multicast/broadcast handling in 802.16 networks is out of scope. Some thoughts are presented at the Appendix section • Clarified IPv4 CS sub-layer support (section 3.1) • Clarified IPv4 CS link and link establishment (section 4, 4.1) • Made reference to RFC 5154 and RFC 5121 for IPv4 network architecture over IEEE 802.16 networks (section 3)

8. Next revision • Will fix typos and make minor editorial modifications before submission for AD review • Adding a co-author : Gabriel Montenegro

9. Acknowledgement • Authors like to acknowledge Basavaraj Patil and DJ Johnston for educating us about the IEEE 802.16Rev2 modifications for SDU MTU • Johnston, D., "SDU MTU Capability Declaration", March 2008, <http://www.ieee.org/16>.

10. Thanks! samitac@ipinfusion.com