Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt

gabriel montenegro <g_e_montenegro@yahoo.com> Tue, 09 June 2009 16:48 UTC

Return-Path: <g_e_montenegro@yahoo.com>
X-Original-To: 16ng@core3.amsl.com
Delivered-To: 16ng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871FF28C10D for <16ng@core3.amsl.com>; Tue, 9 Jun 2009 09:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_63=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeHfLMowtLd3 for <16ng@core3.amsl.com>; Tue, 9 Jun 2009 09:48:45 -0700 (PDT)
Received: from web82601.mail.mud.yahoo.com (web82601.mail.mud.yahoo.com [68.142.201.118]) by core3.amsl.com (Postfix) with SMTP id 35ACE3A68FD for <16ng@ietf.org>; Tue, 9 Jun 2009 09:48:45 -0700 (PDT)
Received: (qmail 16301 invoked by uid 60001); 9 Jun 2009 16:48:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244566131; bh=l9dNUrVKeeUeCsXhQVzqWYsfN9NgqOnRHnlvczZz8Bc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xLiX3BtcIVF9jfzfeeQ3NiK/HOsgzS8tTtbMBa9oNfdMj9S1S2jJyGqqG0ojqieSiv+nGY+l9fwpiI9NjXuhsp7OdG4DRU71CpZGs8oXPv0FNECzWBbjAF+W2h/hsClKXeGGyrXMGhJg6Z2gIZRnWoqITAsr+uGmCbda0KsyHXo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JKy6BRkriSKQGsszaK4WfThvkqonnDuj0K2uk3TWoX5bpFiWkdxjTOuWxKUkqCGvb92MD41O6Z7X8KOockHIAMs/mJ0Cla1mpuE2T1r5RRZcW5YsnQvw+KxQNez7nd9knN+ZS3+2CpYSPqOmSyCoXl4McXcmVBTCfiwt1f46Qfc=;
Message-ID: <279552.13378.qm@web82601.mail.mud.yahoo.com>
X-YMail-OSG: SwB4aMEVM1lagQIgkzaPZQeJRmHrUBi.aRUNH2x5j1l8VsUa25DR_ALp9nAVIO2_YzRjqqZe1zDd_1053wHhDfuTCjBxuNSto4Ho7JNZZVFd24ZyUWPvDBYBDtnQT8bQslOZkgHDN4F1djq4hR2XnwNJ_iplQ.khF2XcIammgOW.3iiLtW0mpTi6Xp8Fkanv6NvDj9YyontATVI5cHhH3NupiNmF3kNgMgbEKI7op0U78Mz0HO7Irw5CmyiGzG.IJINI7aX2KKQZEdok1xg6pfeCs440MSa.ozbKObiiPWrZKKlQRR.bO96dCCTIXhy5Q_sfGLhvkRVJYZrDkdhuiLiYc2ytGPLi
Received: from [24.16.92.42] by web82601.mail.mud.yahoo.com via HTTP; Tue, 09 Jun 2009 09:48:47 PDT
X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10
References: <20090603154501.B0C963A6CBB@core3.amsl.com> <BC27158B99D3064A955ADE084783900C021E70E1@DEMUEXC014.nsn-intra.net> <BC27158B99D3064A955ADE084783900C021E70E2@DEMUEXC014.nsn-intra.net>
Date: Tue, 09 Jun 2009 09:48:47 -0700
From: gabriel montenegro <g_e_montenegro@yahoo.com>
To: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>, 16ng@ietf.org
In-Reply-To: <BC27158B99D3064A955ADE084783900C021E70E2@DEMUEXC014.nsn-intra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ext Alper Yegin <alper.yegin@yegin.org>
Subject: Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 16:48:54 -0000

Thanks Max, the attached version is better! I'm still going through the comments.
Will respond later on.


----- Original Message ----
> From: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>
> To: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>; 16ng@ietf.org
> Cc: ext Alper Yegin <alper.yegin@yegin.org>; ext gabriel montenegro <g_e_montenegro@yahoo.com>
> Sent: Thursday, June 4, 2009 3:58:26 PM
> Subject: Re: [16NG] I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
> 
> Please find attached the txt document with my comments, in the case your
> screen looks as awful as mine (word wrapping did a horrible job)
> 
> Bye
> Max
> 
> -----Original Message-----
> From: 16ng-bounces@ietf.org [mailto:16ng-bounces@ietf.org] On Behalf Of
> ext Riegel, Maximilian (NSN - DE/Munich)
> Sent: Friday, June 05, 2009 12:50 AM
> To: 16ng@ietf.org
> Cc: ext Alper Yegin; ext gabriel montenegro
> Subject: Re: [16NG]
> I-DAction:draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
> 
> I went through the document and found a couple of issues, which I would
> like to see in a better shape.
> Please find my comments inline:
> 
> Bye
> Max
> 
> > 16ng Working Group                                        S.
> Madanapalli
> > Internet-Draft                                        Ordyn
> Technologies
> > Intended status: Standards Track                        Soohong D.
> Park
> > Expires: April 4, 2009                              Samsung
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> > 16ng Working Group                                        S. Madanapalli
> > Internet-Draft                                        Ordyn Technologies
> > Intended status: Standards Track                        Soohong D. Park
> > Expires: April 4, 2009                              Samsung Electronics
> >                                                          S. Chakrabarti
> >                                                              IP Infusion
> >                                                            G. Montenegro
> >                                                    Microsoft Corporation
> >                                                            October 2008
> > 
> > 
> > Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
> >            draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-05.txt
> > 
> > Status of this Memo
> > 
> >    By submitting this Internet-Draft, each author represents that any
> >    applicable patent or other IPR claims of which he or she is aware
> >    have been or will be disclosed, and any of which he or she becomes
> >    aware will be disclosed, in accordance with Section 6 of BCP 79.
> > 
> >    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 April 4, 2009.
> > 
> > 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), IEEE 802.3
> >    (Ethernet) and IEEE 802.1Q (VLAN).  The IP-specific part of the
> 
> Meanwhile the IEEE802.16-2009 (was REV2) specification has been released.
> IEEE802.16-2009 does not know anymore about the IEEE 802.1Q (VLAN) CS.
> 
> >    Packet CS enables the transport of IPv4 packets directly over the
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 1]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    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.
> > 
> > 
> > Table of Contents
> > 
> >    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
> >    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
> >    3.  Typical Network Architecture for IPv4 over IEEE 802.16 . . . .  3
> >      3.1.  IEEE 802.16 IPv4 Convergence sub-layer support . . . . . .  3
> >    4.  IPv4 CS link in 802.16 Networks  . . . . . . . . . . . . . . .  4
> >      4.1.  IPv4 CS link establishment . . . . . . . . . . . . . . . .  4
> >      4.2.  Frame Format for IPv4 Packets  . . . . . . . . . . . . . .  4
> >      4.3.  Maximum Transmission Unit  . . . . . . . . . . . . . . . .  5
> >    5.  Subnet Model and IPv4 Address Assignment . . . . . . . . . . .  7
> >      5.1.  IPv4 Unicast Address Assignment and Router Discovery . . .  7
> >      5.2.  Address Resolution Protocol  . . . . . . . . . . . . . . .  8
> >      5.3.  IP Multicast Address Mapping . . . . . . . . . . . . . . .  8
> >    6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
> >    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
> >    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
> >    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
> >      9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
> >      9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
> >    Appendix A.  Multiple Convergence Layers - Impact on Subnet
> >                Model . . . . . . . . . . . . . . . . . . . . . . . . 10
> >    Appendix B.  Sending and Receiving IPv4 Packets  . . . . . . . . . 10
> >    Appendix C.  WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 11
> >    Appendix D.  Thoughts on handling multicast-broadcast IP
> >                packets . . . . . . . . . . . . . . . . . . . . . . . 12
> >    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
> >    Intellectual Property and Copyright Statements . . . . . . . . . . 14
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 2]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> > 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
> >    [RFC5154].
> > 
> >    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"
> >    or simply "IP CS" in this document).
> 
> IPv4 CS should be used throughout the document to prevent mixing it up with the 
> IPv6 CS specification. There is nothing like IP CS in the IEEE802.16 
> specification, there is only IPv4 CS and IPv6 CS.
> BTW: there is now a single ETH CS carrying IPv4 as well as IPv6 payload.
> 
> >    This document specifies a method for encapsulating and transmitting
> >    IPv4 [RFC0791] packets over the IP CS of IEEE 802.16.  This document
>                                     ^IPv4 CS
> >    also specifies the MTU and address assignment method for the IEEE
> 
> Which MTU, which address assignment? More concise wording would help.
> 
> >    802.16 based networks using IP CS.
>                                 ^IPv4 CS
> > 
> >    This document also discusses ARP (Address Resolution Protocol) and
> >    Multicast Address Mapping whose operation is similar to any other
> >    point-to-point link model.
> 
> What do you mean with this sentence?
> 
> >    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
> > 
> >    The 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
> 
> Please clarify 'MS'; according to IEEE802.16 it only covers PHY and MAC.
> According to IEEE802.16 the MS is not a 'host'.
> 
> >    (AR) through a Base Station (BS), a layer 2 entity (from the
> >    perspective of the IPv6 link between the MS and access router (AR)).
>                         ^IPv4??? Copy&Paste mistake?
> > 
> >    For further information on the typical network architecture, see
> >    [RFC5121] section 5.
> > 
> > 3.1.  IEEE 802.16 IPv4 Convergence sub-layer support
> > 
> >    As described in [RFC5154] section 3.3., an IP specific subpart
> >    classifier carries either IPv4 or IPv6 payloads.  In this document,
> >    we are focusing on the IPv4 over IP Convergence Sublayer.
> 
> Section 3.3 of [RFC5154] is outdated! IEEE802.16-2009 introduced a refined CS 
> structure. IMHO, we shouldn't make references to outdated specifications, but 
> base the work on the most recent IEEE802.16 specification.
> 
> > 
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 3]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    For further information on the IEEE 802.16 Convergence Sublayer and
> >    encapsulation of IP packets, see [RFC5121] section 4 and [RFC5154]
> >    section 3.3.
> 
> As [RFC5154] is outdated, I would propose to provide an updated section 3.3. as 
> part of the IPv4 CS document.
> 
> > 4.  IPv4 CS link in 802.16 Networks
> > 
> >    This document defines the IPv4 CS link as a point-to-point link
> >    between the MS and the AR using a set of service flows consisting of
> 
> MS is not the host. What is a link between a L2 device (MS) and a L3 device 
> (AR)?
> 
> >    MAC transport connections between a MS and BS, and L2 tunnel(s)
> >    between between a BS and AR.  It is recommended that a tunnel be
>                                                                   ^is
> >    established between the AR and a BS based on 'per MS' or 'per service
> >    flow' (An MS can have multiple service flows each of which are
> 
> What is a tunnel between BS and AR based on 'per MS'? It seems, some GRE 
> functionality is assumed here without spelling it out.
> 
> >    identified by a unique service flow ID).  Then the tunnel(s) for an
> >    MS, in combination with the MS's MAC transport connections, forms a
> >    single point-to-point link.  Each MS belongs to a different link and
> 
> How does this work - multiple tunnels between two endpoints forming a single 
> link? I would assume, that there must be some classification in place, which is 
> part of the BS according to IEEE802.16, not part of the AR, like the authors 
> assume in the sentence.
> 
> >    is assigned an unique IPv4 address per recommendations in [RFC4968].
> > 
> >    To summarize:
> > 
> >    o  IPv4 CS uses the IPv4 header fields to classify the packets and
> >      map to the appropriate CID.
> 
> The previous text talks about service flows; why 'CID' is mentioned here?
> 
> >    o  A point-to-point link between MS and AR is established.
> 
> How do the two statements fit together? How does IPv4 CS establish a p2p link?
> 
> > 
> > 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, an initial service flow is created
> 
> Initial service flow? [RFC5121] does not specifies further service flows.
> 
> >    that can be used for exchanging IP layer signaling messages, e.g.
> >    address assignment procedures using DHCP.
> > 
> >    The address assignment procedure depends on the MS mode - i,e.
> >    whether it is acting as a Mobile IPv4 client or a Proxy Mobile IP
> >    client or a Simple IP client.  In the most common case, the MS
> >    requests an IP address using DHCP.
> 
> What is the difference between a Proxy MIP client and a Simple IP client?
> Does the 'MS' request an IP address by DHCP in the case of Client-MIP?
> 
> > 
> > 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 April 4, 2009                [Page 4]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >                        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.  The default MTU for IPv4 packets over an IEEE 802.16
> 
> 'is configurable'?? How, by which means??
> 
> >      link SHOULD be 1500 octets.
> > 
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 5]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    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, 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 is currently revising 802.16 (see 802.16Rev2
> 
> IEEE802.16 has revised the specification. Update the reference.
> 
> >      [802_16REV2]) 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 future 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 all future implementations of IPv4 and
> 
> Why 'future'?
> 
> >    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 [802_16REV2].
> 
> Can MS rely on the IEEE802.16 methods? Mandatory for all IEEE802.16 
> implementations?
> 
> >    Additionally, the clients are encouraged to run PMTU[RFC 1191] or
> >    PPMTUD[RFC 4821].  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
> >    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.
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 6]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> > 5.  Subnet Model and IPv4 Address Assignment
> > 
> >    The Subnet Model recommended for IPv4 over IEEE 802.16 using IP 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 CIDs) 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 DHCP relay Agent
> >    [RFC1542].
> > 
> >    Although DHCP is the recommended method of address assignment, it is
> >    possible that the MS could be a pure Mobile IPv4 [RFC3344] device
> >    which will be offered an IP address from its home network after
> >    successful Mobile IP [RFC3344] registration.  In such situations, the
> >    mobile host SHOULD use the default link MTU in order to avoid any
> >    link-layer packet loss due to larger than supported packet size in
> >    the IP CS link.
> > 
> >    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 IP 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 April 4, 2009                [Page 7]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> > 5.2.  Address Resolution Protocol
> > 
> >    The IP 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 IP 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 [ETHCS].
> > 
> > 
> > 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 April 4, 2009                [Page 8]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> > 9.  References
> > 
> > 9.1.  Normative References
> > 
> >    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
> >              Requirement Levels", BCP 14, RFC 2119, March 1997.
> > 
> >    [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.
> > 
> >    [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
> >              RFC 2131, March 1997.
> > 
> >    [RFC1542]  Wimer, W., "Clarifications and Extensions for the
> >              Bootstrap Protocol", RFC 1542, October 1993.
> > 
> >    [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.
> > 
> >    [RFC4968]  Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
> >              Based Networks", RFC 4968, August 2007.
> > 
> > 9.2.  Informative References
> > 
> >    [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
> >              November 1990.
> > 
> >    [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
> >              Discovery", RFC 4821, March 2007.
> > 
> >    [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
> >              Extensions", RFC 2132, March 1997.
> > 
> >    [RFC4840]  Aboba, B., Davies, E., and D. Thaler, "Multiple
> >              Encapsulation Methods Considered Harmful", RFC 4840,
> >              April 2007.
> > 
> >    [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 9]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >              August 2002.
> > 
> >    [RFC1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
> >              September 1991.
> > 
> >    [ETHCS]    Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP
> >              over Ethernet over IEEE 802.16 Networks", April 2008,
> >              > >              draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt>.
> > 
> >    [802_16REV2]
> >              Johnston, D., "SDU MTU Capability Declaration",
> >              March 2008, .
> > 
> >    [IEEE802_16]
> >              "IEEE 802.16e, IEEE standard for Local and metropolitan
> >              area networks, Part 16:Air Interface for fixed and Mobile
> >              broadband wireless access systems", October 2005.
> 
> IEEE802.16-2009 is released and supersedes 16e as well as REV2.
> Why is the IEEE802.16 specification listed under informative?
> 
> >    [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 IP 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.
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 10]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    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
> >    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.  One way of doing this is to have a mapping between MAC
> >    address and Tunnel Identifier.
> 
> Which MAC address?
> 
> > 
> > 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 C should be removed.
> Only WiMAX devices will enter WiMAX networks, and WiMAX devices know about the 
> MTU size in WiMAX networks.
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > Madanapalli, et al.      Expires April 4, 2009                [Page 11]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> > Appendix D.  Thoughts on handling multicast-broadcast IP packets
> > 
> >    Although this document does not directly specify details of multicast
> >    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 April 4, 2009                [Page 12]
> > 
> > Internet-Draft        IPv4 over IEEE 802.16's IP CS        October 2008
> > 
> > 
> >    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
> >