IPv4 over IEEE IP CS draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-03 Samita Chakrabarti IP Infusion Syam Madanapalli Ordyn Technologies Daniel Park Samsung

Background  WG LC comments addressed  Issue from the last IETF – Major: Default MTU - whether it should be 1500 bytes or lessDefault MTU - whether it should be 1500 bytes or less – Minor: Editorial clarificationsEditorial clarifications

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

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

Setting MTU dynamically  The IEEE is currently revising (802.16rev2) - To inform the SDU MTU in the IEEE SBC-REQ/SBC-RSP phase, such that future IEEE compliant clients can configure the negotiated MTU size for IP-CS link. - To inform the SDU MTU in the IEEE SBC-REQ/SBC-RSP phase, such that future IEEE 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

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 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 networks (section 3)

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

Acknowledgement  Authors like to acknowledge Basavaraj Patil and DJ Johnston for educating us about the IEEE Rev2 modifications for SDU MTU – Johnston, D., "SDU MTU Capability Declaration", March 2008,.

Thanks!