[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs) 00 01 02 03 04 05 06 07 RFC 5948

16ng Working Group                                        S. Madanapalli
Internet-Draft                                        Ordyn Technologies
Intended status: Standards Track                         Soohong D. Park
Expires: December 16, 2009                           Samsung Electronics
                                                          S. Chakrabarti
                                                             IP Infusion
                                                           G. Montenegro
                                                   Microsoft Corporation
                                                           June 14, 2009


Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
              draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 16, 2009.

Copyright Notice



Madanapalli, et al.     Expires December 16, 2009               [Page 1]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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 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 MAC.

   This document specifies the frame format, the Maximum Transmission
   Unit (MTU) and address assignment procedures for transmitting IPv4
   packets over the IP-specific part of the Packet Convergence Sublayer
   of IEEE 802.16.




























Madanapalli, et al.     Expires December 16, 2009               [Page 2]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Typical Network Architecture for IPv4 over IEEE 802.16 . . . .  4
     3.1.  IEEE 802.16 IPv4 Convergence Sublayer Support  . . . . . .  5
   4.  IPv4 CS link in 802.16 Networks  . . . . . . . . . . . . . . .  5
     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 and Router Discovery . . .  8
     5.2.  Address Resolution Protocol  . . . . . . . . . . . . . . .  9
     5.3.  IP Multicast Address Mapping . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Multiple Convergence Layers - Impact on Subnet
                Model . . . . . . . . . . . . . . . . . . . . . . . . 11
   Appendix B.  Sending and Receiving IPv4 Packets  . . . . . . . . . 11
   Appendix C.  WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 12
   Appendix D.  Thoughts on handling multicast-broadcast IP
                packets . . . . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
























Madanapalli, et al.     Expires December 16, 2009               [Page 3]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


1.  Introduction

   IEEE 802.16 [IEEE802_16] is a connection oriented access technology
   for the last mile.  The IEEE 802.16 specification includes the PHY
   and MAC layers.  The MAC includes various Convergence Sublayers (CS)
   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.

   This document also discusses ARP (Address Resolution Protocol) and
   Multicast Address Mapping.

   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].


2.  Terminology

   o  Subscriber station (SS), Mobile Station (MS), Mobile Node (MN) -
      The terms subscriber station, mobile station, and mobile node are
      used interchangeably in this document and mean the same, i.e., an
      IP host.  Notice that this usage is more informal than that in
      IEEE 802.16, in which SS and MS refer to the interface
      implementing the IEEE 802.16 MAC and PHY layers and not to the
      entire host.

   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].  In a nutshell, each MS is attached to an Access Router
   (AR) through a Base Station (BS), a layer 2 entity (from the
   perspective of the IPv4 link between the MS and access router (AR)).

   For further information on the typical network architecture, see



Madanapalli, et al.     Expires December 16, 2009               [Page 4]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   [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 the IPv4 over Packet Convergence
   Sublayer.

   For further information on the IEEE 802.16 Convergence Sublayer and
   encapsulation of IP packets, see [RFC5121] section 4 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 colocated, 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
   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 an unique
   IPv4 address per recommendations in [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 procedures following section 6.2 of [RFC5121].  Steps
   1-4 are same as indicated in 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] ).



Madanapalli, et al.     Expires December 16, 2009               [Page 5]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


                        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

      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: CRC Indicator. 1 = CRC is included, 0 = 1 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.  CRC appended to the PDU after
      encryption.
      TYPE: This field indicates the subheaders (Mesh subheader,
      Fragmentation Subheader, Packing subheader etc and special payload
      types (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 bottom 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"



Madanapalli, et al.     Expires December 16, 2009               [Page 6]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   tunneling, supporting this MTU at the endhosts 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
   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  The IEEE recently revised 802.16 (see IEEE 802.16-2009
      [IEEE802_16]) to (among other things) allow providing the Service
      Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase,
      such that IEEE 802.16 compliant clients 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 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 implement 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 PMTU [RFC1191] or
   PPMTUD [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 DF bit being set in



Madanapalli, et al.     Expires December 16, 2009               [Page 7]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   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.


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 MS and AR [RFC4968],
   hence each MS shall be assigned an address with 32bit prefix-length
   or subnet-mask.  The point-to-point link between MS and AR is
   achieved using a set of IEEE 802.16 MAC connections (identified by
   service flows) and an L2 tunnel (e.g., a GRE tunnel) per MS between
   BS and AR.  If the AR is co-located with the BS, then the set of IEEE
   802.16 MAC connections between the MS and BS/AR represent the
   point-to- point connection.

5.1.  IPv4 Unicast Address Assignment and Router Discovery

   DHCP [RFC2131] SHOULD be used for assigning 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].

   Router discovery messages [RFC1256] contain router solicitation and
   router advertisements.  The Router solicitation messages (multicast
   or broadcast) from the MS are delivered to the AR via the BS through
   the point-to-point link.  The BS SHOULD map the all-routers multicast
   nodes or broadcast nodes for router discovery to the AR's IP address
   and deliver directly to the AR.  Similarly a router advertisement to
   the all-nodes multicast nodes will be either unicast to each MS by
   the BS separately or put onto a multicast connection to which all MSs
   are listening to.  If no multicast connection exists, and the BS does
   not have the capability to aggregate and disaggregate the messages to
   and from the MS hosts, then the AR implementation must ensure that
   unicast messages are sent to the corresponding individual MS hosts
   within the set of broadcast or multicast recipients.  This
   specification simply assumes that the multicast service is provided.
   How the multicast service is implemented in an IEEE 802.16 Packet CS
   deployment is out of scope of this document.

   The 'Next hop' IP address of the IPv4 CS MS is always the IP address
   of the AR, because MS and AR are attached via a point-to-point link.







Madanapalli, et al.     Expires December 16, 2009               [Page 8]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


5.2.  Address Resolution Protocol

   The IPv4 CS does not allow for transmission of ARP [RFC0826] packets.
   Furthermore, in a point-to-point link model, address resolution is
   not needed.

5.3.  IP Multicast Address Mapping

   IPv4 multicast packets are carried over the point-to-point link
   between the AR and the MS (via the BS).  The IPv4 multicast packets
   are classified normally at the IPv4 CS if the IEEE 802.16 MAC
   connection has been set up with a multicast IP address as a
   classification parameter for the destination IP address.  The IPv4
   multicast address may be mapped into a multicast CID as defined in
   the IEEE 802.16 specification.  The mapping mechanism at the BS or
   the relative efficiency of using a multicast CID as opposed to
   simulating multicast by generating multiple unicast messages are out
   of scope of this document.  For further considerations on the use of
   multicast CIDs see [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16].


6.  Security Considerations

   This document specifies transmission of IPv4 packets over IEEE 802.16
   networks with 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
   architecture spanning beyond the IEEE 802.16 base stations is the
   subject of the documents defining such architectures, such as WiMAX
   Network Architecture [WMF].


7.  IANA Considerations

   This document has no actions for IANA.


8.  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 IPv4 CS link.  Thanks to
   many other members of the 16ng working group who commented on this
   document to make it better.




Madanapalli, et al.     Expires December 16, 2009               [Page 9]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


9.  References

9.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.

9.2.  Informative References

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
              September 1991.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [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



Madanapalli, et al.     Expires December 16, 2009              [Page 10]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


              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.

   [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16]
              Riegel, M., Jeong, S., and H. Jeon, "Transmission of IP
              over Ethernet over IEEE 802.16 Networks",
              draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08 (work
              in progress), January 2009.

   [WMF]      "WiMAX End-to-End Network Systems Architecture Stage 2-3
              Release 1.2,
              http://www.wimaxforum.org/technology/documents",
              January 2008.


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 data link layer and requires interworking at 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 of IPv4 packets
   is different from multicast-capable shared medium technologies like
   Ethernet.

   Before any packets are transmitted, a IEEE 802.16 transport
   connection must be established.  This connection consists of IEEE
   802.16 MAC transport connection between MS and BS and an L2 tunnel
   between BS and AR (if these two are not co-located).  This IEEE
   802.16 transport connection provides a point-to-point link between
   the MS and AR.  All the packets originated 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



Madanapalli, et al.     Expires December 16, 2009              [Page 11]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   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 destinations 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.

   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.


Appendix C.  WiMAX IPCS MTU size

   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 MS
   and 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 octet 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, MS
   should be able to sense or deduce the fact that they are operating
   within a WiMAX network (e.g., given the WiMAX-specific
   particularities of the authentication and network entry procedures),
   and adjust their MTU size accordingly.  This document makes no
   further assumptions in this respect.


Appendix D.  Thoughts on handling multicast-broadcast IP packets

   Although this document does not directly specify details of multicast



Madanapalli, et al.     Expires December 16, 2009              [Page 12]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   or broadcast packet handling, here are some suggestions:

   While uplink connections from the MSs to the BS provide only unicast
   transmission capabilities, downlink connections can be used for
   multicast transmission to a group of MSs as well as unicast
   transmission from the BS to a single MS.  For all-node IP addresses,
   the AR or BS should have special mapping and the packets should be
   distributed to all active point-to-point connections by the AR or by
   the BS.  All-router multicast packets and any broadcast packets from
   a MS will be forwarded to the AR by the BS.  If BS and MS are co-
   located, then the first approach is more useful.  If the AR and BS
   are located separately then the second approach should be
   implemented.  An initial capability exchange message should be
   performed between BS and AR (if they are not co-located) to determine
   who would perform the distribution of multicast/broadcast packets.
   Such mechansim should be part of L2 exchange during the connection
   setup and is out of scope of this document.  In order to save energy
   of the wireless end devices in the IEEE 802.16 wireless network, it
   is recommened that the multicast and broadcast from network side to
   device side should be reduced.  Only DHCP, IGMP, Router advertisemnet
   packets are allowed on the downlink for multicast and broadcast IP
   addresses.  Other protocols using multicast and broadcast IP
   addresses should be permitted through local AR/BS configuration.


Authors' Addresses

   Syam Madanapalli
   Ordyn Technologies
   1st Floor, Creator Building, ITPL
   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








Madanapalli, et al.     Expires December 16, 2009              [Page 13]


Internet-Draft       IPv4 over IEEE 802.16's IPv4 CS           June 2009


   Samita Chakrabarti
   IP Infusion
   1188 Arques Avenue
   Sunnyvale, CA
   USA

   Email: samitac@ipinfusion.com


   Gabriel Montenegro
   Microsoft Corporation
   Redmond, Washington
   USA

   Email: gabriel.montenegro@microsoft.com




































Madanapalli, et al.     Expires December 16, 2009              [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/