Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07

[Ballot discuss]
David Black performed a quick OPS-DIR review and raised a number of issues which were not answered as far as I know, and should be clarified before approving this document.

(1) MTU size seems problematic.  This document strongly recommends
(SHOULD) a 1500 byte MTU, but Appendix C observes that a lot of actual equipment uses a 1400 byte MTU.  The latter's likely to cause more problems with the former as it's visibly smaller than a typical Ethernet MTU, but it's apparently in "running code".

[DR - I would like to understand better the operational implications of the limitations because of the fact that mechanisms defined in Section 4 would not work, and because an IPv4 CS client is not capable of doing ARP probing to find out the link MTU in such cases]

(2) It's not at all clear whether link-level broadcast or multicast can be relied upon to work.  Section 5.3 and Appendix D are not promising - it looks like the baseline is that IPv4 multicast is point to point up to at least the Access Router and possibly beyond.
I'm not sure that this is an actual problem, but the document probably ought to be more explicitly about saying that one ought to have low expectations for useful multicast behavior from a point-to-point link layer technology.

(3) Section 5.1 seems to assume that ICMP Router Discovery is in use.  Either that needs to be stated as a requirement of this specification, or some other spec needs to be cited as imposing this requirement.  The discussion of multicast in router discovery is actually clearer than other parts of the document.

[Ballot comment]
Section 4.2:

C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included

It looks confusing that 0 = 1, I guess the 1 can be removed.

[Ballot comment]
4.2.  Frame Format for IPv4 Packets

                        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        |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Nit: it would be nicer to readers to say that MSB means "Most Significant Byte" and LSB means "Less Significant Byte".

[Ballot discuss]
This is a DISCUSS DISCUSS and I will clear it during/after the telechat.

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.

This begs the question: why have 2 similar but incompatible specs?

[Ballot comment]
4.2.  Frame Format for IPv4 Packets

                        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        |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Nit: it would be nicer to readers to say that MSB means "Most Significant Byte" and LSB means "Less Significant Byte".

[Ballot comment]
A few comments all at the level of nits...

---

Sections 1 and 5.2

In section 1
  This document also discusses ARP (Address Resolution Protocol) and
  Multicast Address Mapping.
Well, section 5.2 contains precisely 2 lnes and two words to say that
ARP is not used.

---

Section 2
As far as I can see, the terms "Subscriber station (SS)" and "Mobile
Node (MN)" are not used in the document at all.

---

Section 3 para 1
You have shown "(AR)" twice

---

Section 4.3
s/if an MS/If an MS/

---

Appendix D
s/advertisemnet/advertisement/

Document Shepherd Write-Up on draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06:
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Gabriel Montenegro. Yes and yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

Proper review including WiMAX NWG (Network Working Group) folks in addition to the IETF.
The document's first officially adopted version (draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00)
appeared on May 28, 2007.
 
Note: This is the so-called "IPv4 CS" document ("IPv6 CS" has already been published as RFC5121).
More info below.
• 1st WG LC feb 25 - mar 10, 2008
• MTU issue of 1500 (versus 1400 in WiMAX).
• same as in IPv6 CS, but in IPv6 an RA reliably takes care of this
• however, there is no good mechanism in IPv4.
• Review from NWG/WiMAX was unfavorable due to this issue and other inaccuracies due to much text that
is not actually related directly to "IP-over-foo" business
• a revised version elided much needless text and provided a simpler flow.
• 14-Jun-09: Addressed feedback with publication of version 06
• 03-Jul-09: 2nd WG LC on version 06 announced from 3 thru 13 Jul 2009 (completed with no further
feedback).

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No. The document has received more than enough review. The issue is not lack of
review but the fact that WiMAX NWG and this document do not say the same thing with respect
to the MTU.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

Other 16ng document have been adopted by WiMAX NWG and are referred to by their specs:
- draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 (currently in RFC ed queue)
- RFC5121 ("IPv6 CS").
However, given that this document deals with the more urgent deployment need to specify IPv4 over
802.16, WiMAX finalized their specification before a proper IETF response was posible
(before 16ng). Accordingly, this document is too late for WiMAX to refer to it. Furthermore,
there is a disagreement on the MTU size when using IPv4 CS over 802.16. The MTU in this
document started out at 1500, was moved back to 1400 and then--due to strong
objection within the WG--moved back to 1500. While it is true
that WiMAX does not represent all the 802.16 deployments, it is a significant portion of them.
It is unfortunate that both organizations could not agree, but after trying for a couple of years
it is clear that this is not possible. Accordingly, WiMAX NWG position is not favorable to
this document as they have already decided on 1400 MTU which they don’t foresee changing in the near
future.
Nevertheless, the consensus within the IETF debate is that publishing this document with an MTU of
1500 is important as it is the IETF position.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

It represents an IETF consensus, even if it does not have full support from WiMAX.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeals threatened.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

One minor nit found:
  == Outdated reference: A later version (-12) exists of
    draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08
This outdated reference to an informative document will be updated when addressing
IESG comments.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes. All normative references are final published documents.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

No IANA implications as documented in the IANA section.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not applicable.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:     

Technical Summary

  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.

Working Group Summary

The document underwent much heated discussion, particularly on the proper choice of MTU.
The document captures consensus within the IETF and includes some information about the
source of such opposing views: WiMAX Forum's use of an MTU of 1400 as opposed to 1500 in
this document. Such discrepancy is not new, as it is also found in the case of the so-called
IPv6 CS (RFC5121). However, in the IPv6 case, the RA MTU option provides an easy solution,
whereas no such reliable method exists for IPv4. Other topics received much input and
guidance from 802.16 and WiMAX participants.

          Document Quality

This document was produced with the appropriate expertise, as it benefitted from the efforts
within the IETF of many participants in IEEE 802.16 and the WiMAX Forum, including formal
reviews from relevant experts in those bodies.