Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks
draft-ietf-16ng-ipv6-over-ipv6cs-11

Still needs to address this:


All discusses on this document have cleared, but my review of the
changes and e-mail discussion reveals two remaining issues.

1. MTU recommendation. MTU 1500 is recommended, on the grounds
    that distributed implementation between BS and AR may use Ethernet,
    and hence > 1500 may be problematic.

    But is this the right number? Presumably some sort of GRE or other
    tunneling will take place on such Ethernet, and it seems that
    the right number should instead be 1500 - X. Or am I missing
    something?

    We could add an RFC Editor note to fix the number, if you
    have a more suitable number.

2. Interoperability in a situation where different devices support
    different CSs for IPv6.

    This has been a topic of concern during WG chartering, was
    raised in my AD review and, to my understanding, clearly
    communicated as a required issue to solve, and has also
    been raised from Bernard and Dave in the context of what
    their multiple encapsulations document says.

    Basavaraj has a number of times said that he does not believe
    this document can mandate what CSes the different devices
    support. I understood his objections to be related to how
    (for instance) Wimax Forum intends to roll out functionality.
    However, I see it as an IETF issue to ensure that our specifications
    are actually interoperable.

    There is also the issue that we do not want to make a normative
    reference to the Ethernet CS specification, as that would imply
    this document cannot be published as an RFC before the reference
    is also ready. This issue is similar to Basavaraj's concern.

    Nevertheless, I do not think we can simply forget about the
    issue.

    I have a suggested change to the document that would allow
    us to specify the required strategy, but would not require
    everything to be finished at the same time.

    At the end of Section 4 (just before 4.1), add the following
    paragraph:

    In addition, to ensure interoperability between devices that
    support different encapsulations, it is REQUIRED that BS
    implementations support all standards track encapsulations
    defined for 802.16 by the IETF. At the time of writing this
    specification, this is the only encapsulation, but additional
    specifications are being worked on. It is, however, not
    required that the BS implementations use all the encapsulations
    they support; some modes of operation may be off by
    configuration.

[Ballot discuss]
We need to see a summary of IEEE review comments and corresponding revisions before this can be approved. Waiting for chairs/authors to deliver this.

Also, discussion in IETF-68 on intereoperability between different implementations of CSes on BS/MS side has not completed.

[Ballot discuss]
We need to see a summary of IEEE review comments and corresponding revisions before this can be approved. Waiting for chairs/authors to deliver this.

[Ballot discuss]
During the discussion of the 16ng WG charter, there was much discussion
  about the number of CSes that ought to be supported.  It was recognized
  that supporting all possible choices would lead to interoperability
  concerns.  The approved charter talks about two standards-track ways to
  carry IPv6 datagrams.  I believe that this document is intended to
  fulfill this part of the charter:

  - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS"
  to define IPv6 operation including the transmission of IPv6 over IEEE
  802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and
  Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed
  Standard RFC]

  However, the document title makes this quite difficult to figure out.

  Section 4 (especially figure 2) causes confusion.  It tells me that
  there are other ways to handle IPv6, but they are not specified in this
  document.  Based on the charter, one of them (Ethernet CS) will be
  specified in another standards-track document.  Others are discussed in
  this section, without references, details, or any hint about the
  interoperability concerns.  Either the discussion needs to address the
  interoperability issue or the other choices should be omitted.

[Ballot discuss]
Security directorate comments from Juergen Schoenwaelder were not addressed.
In particular, please address the following:

Q2: The text on page 12 starts talking about MNs; the acronym is never
    introduced, also not in [PSDOC]. The acronym MS, which appears the
    first time on page 4, also is not expanded the first time it is
    used, but this time there is a definition is [PSDOC]. For improved
    readability, I would like to see each acronym expanded the first
    time it is used (and perhaps the dependence on [PSDOC] can also be
    avoided).

Q3: Section 8.1 mentions that router advertisements may be used for
    movement detection. Section 8.3 then explains why RAs should be
    send not too frequently and recommends 3 hours as the interval,
    which I am not sure makes RAs a good choice for movement
    detection. If text about movement detection is needed at all, you
    may want to spell out that relying on RAs may not be such a good
    choice.



Also, Juergen points out that the references to wimax in the
discussion of security point to hundreds of pages of text; please more
narrowly refer to the parts of the wimax documents that actually
discuss security.

[Ballot comment]
Section 3., paragraph 0:
>    1.  the IP specific part of the Packet CS or,
>    2.  the 802.3 [802.3] specific part of the Packet CS or,
>    3.  the 802.1Q [802.1Q] specific part of the Packet CS.

  Although this document is only concerned with (1), Sections 2 and 4
  talk quite a bit about the other sublayers. This seems redundant,
  given that we've just approved
  draft-ietf-16ng-ipv6-link-model-analysis. Suggest to clearly state
  here that this document is about (1) and reference
  draft-ietf-16ng-ipv6-link-model-analysis for the discussion of various
  sublayers.


Section 3., paragraph 13:
>    When IPv6 is carried via the IP convergence
>    sublayer, this specification SHOULD be followed.

  Why isn't this a "MUST be followed"?


Section 3., paragraph 14:
>    In order to ensure
>    interoperability the BS SHOULD support the IP specific part of the
>    packet CS and the Ethernet specific part of the packet CS for IPv6
>    transport.

  Why isn't this a "MUST support"?


Section 5., paragraph 0:
>  5.  Generic network architecture using the 802.16 air interface

  I suggest to move this section before Section 4, because it explains
  some terms I struggled with in Section 4 ("transport connection",
  etc.)


Section 6.1., paragraph 1:
>    In 802.16, the Transport Connection between an MS and a BS is used to
>    transport user data, i.e.  IPv6 packets in this case.  A Transport
>    Connection is represented by a CID (Connection Identifier) and
>    multiple Transport Connections can exist between an MS and BS.

  Move this explanation up to where you talk about transport connections
  for the first time.


Section 9.3., paragraph 1:
>    Stateless address autoconfiguration SHOULD be performed as specified
>    in [I-D.ietf-ipv6-2461bis], [I-D.ietf-ipv6-rfc2462bis] .

  I think this should say "SHOULD be performed, and if performed, MUST
  be performed as in..."


Section 9.4., paragraph 1:
>    Stateful address autoconfiguration SHOULD be performed as specified
>    in [I-D.ietf-ipv6-2461bis], [RFC3315].

  I think this should say "SHOULD be performed, and if performed, MUST
  be performed as in..."


Appendix A., paragraph 1:

>    The WiMAX (Worldwide Interoperability for Microwave Access) forum
>    [WMF] has defined a network architecture in which the air interface
>    is based on the IEEE 802.16 standard.  The addressing and operation
>    of IPv6 described in this document is applicable to the WiMAX network
>    as well.

  I'd be good to preface these appendices with a motivation of why
  they're included in this document. For example, I'm not sure what "is
  applicable to the WiMAX network as well" means, when WiMAX has made
  some divergent design choices (MTU, etc.)


[More editing nits emailed to the authors directly.]

[Ballot comment]
Section 3., paragraph 0:
>    1.  the IP specific part of the Packet CS or,
>    2.  the 802.3 [802.3] specific part of the Packet CS or,
>    3.  the 802.1Q [802.1Q] specific part of the Packet CS.

  Although this document is only concerned with (1), Sections 2 and 4
  talk quite a bit about the other sublayers. This seems redundant,
  given that we've just approved
  draft-ietf-16ng-ipv6-link-model-analysis. Suggest to clearly state
  here that this document is about (1) and reference
  draft-ietf-16ng-ipv6-link-model-analysis for the discussion of various
  sublayers.


Section 3., paragraph 13:
>    When IPv6 is carried via the IP convergence
>    sublayer, this specification SHOULD be followed.

  Why isn't this a "MUST be followed"?


Section 3., paragraph 14:
>    In order to ensure
>    interoperability the BS SHOULD support the IP specific part of the
>    packet CS and the Ethernet specific part of the packet CS for IPv6
>    transport.

  Why isn't this a "MUST support"?


Section 5., paragraph 0:
>  5.  Generic network architecture using the 802.16 air interface

  I suggest to move this section before Section 4, because it explains
  some terms I struggled with in Section 4 ("transport connection",
  etc.)


Section 6.1., paragraph 1:
>    In 802.16, the Transport Connection between an MS and a BS is used to
>    transport user data, i.e.  IPv6 packets in this case.  A Transport
>    Connection is represented by a CID (Connection Identifier) and
>    multiple Transport Connections can exist between an MS and BS.

  Move this explanation up to where you talk about transport connections
  for the first time.


Section 9.3., paragraph 1:
>    Stateless address autoconfiguration SHOULD be performed as specified
>    in [I-D.ietf-ipv6-2461bis], [I-D.ietf-ipv6-rfc2462bis] .

  I think this should say "SHOULD be performed, and if performed, MUST
  be performed as in..."


Section 9.4., paragraph 1:
>    Stateful address autoconfiguration SHOULD be performed as specified
>    in [I-D.ietf-ipv6-2461bis], [RFC3315].

  I think this should say "SHOULD be performed, and if performed, MUST
  be performed as in..."


Appendix A., paragraph 1:

>    The WiMAX (Worldwide Interoperability for Microwave Access) forum
>    [WMF] has defined a network architecture in which the air interface
>    is based on the IEEE 802.16 standard.  The addressing and operation
>    of IPv6 described in this document is applicable to the WiMAX network
>    as well.

  I'd be good to preface these appendices with a motivation of why
  they're included in this document. For example, I'm not sure what "is
  applicable to the WiMAX network as well" means, when WiMAX has made
  some divergent design choices (MTU, etc.)

[Ballot discuss]
Section 43200, paragraph 0:
>    The router lifetime SHOULD be set to a large value, preferably in
>    hours.  This document over-rides the specification for the value of
>    the router lifetime in Neighbor Discovery for IP Version 6 (IPv6)
>    [I-D.ietf-ipv6-2461bis].

  DISCUSS: draft-ietf-ipv6-2461bis is going to be the new standard for
  ND for IPv6 across all link types, and normatively requires that
  certain timing parameters are within certain ranges. It is not
  appropriate for this document to simply "override" these MUSTs. If
  there is a need for different values, that should be an argument to
  change draft-ietf-ipv6-2461bis accordingly.


Section 9.2., paragraph 1:
>    DAD SHOULD be performed as per Neighbor Discovery for IP Version 6,
>    [I-D.ietf-ipv6-2461bis] and, IPv6 Stateless Address
>    Autoconfiguration, [I-D.ietf-ipv6-rfc2462bis].

  DISCUSS: These documents say that you MUST perform DAD (except for
  some well-defined cases).

I reviewed the new version of this spec, and
I'm generally quite happy with it. I found three
small remaining issues which are listed below:
>          +-----+  CID1    +-----+          +-----------+
>          | MS1 |----------/| BS1 |----------|    AR    |-----[Internet]
>          +-----+        / +-----+          +-----------+
>            .          /        ____________
>            .    CIDn /        ()__________()
>          +-----+      /            L2 Tunnel
>          | MSn |-----/
>          +-----+
>
>
>    Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge
The part about the BS acting as a bridge seems surprising.
Is this really the case? A standard bridge function?

>  This
>  section presents a model for the last mile link, i.e. the link to
>  which MSs attach themselves.
I would remove this sentence. You need to explain
how the link looks like from an IP perspective.
And I think you are doing that. Whether there
is a distributed or integrated BS/AR at the other
end is really not a key issue.

>  IEEE
>    802.16 also defines a secondary management connection that can be
>    used for host configuration.  However support for secondary
>    management connections is not mandatory.  A transport connection has
>    the advantage of it being used for host configuration as well as for
>    user data.
Are you specifying something about the use of the
management connections? If not, take it out.

> Each MS belongs to
>    a different link.  No two MSs belong to the same link.
Duplication. Remove the first sentence.

Finally completely out from the WG:

  (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, the shepherding co-chair, has read this
            version and thinks it is ready to advance.

  (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?

            There has been considerable review on this draft from WG members,
            an AD and the WG's technical advisors. It has also been the subject
            of discussion in face-to-face meetings at regular IETF
            sessions as well as an interim meeting last September.
            Also very important is the review done at the WiMax forum,
            where this document is now being referred to from their
            specifications.

  (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?

            I believe there is sufficient review. This document has
            undergone two WG LC periods, an initial 2-week period in
            October and a shorter 1-week period which ended on Jan 5.

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

            None.

  (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?

            There is strong consensus behind the approach. There was
            considerable discussion during both WG LC period. In particular,
            this version clarifies some points discussed during the last
            WG LC related to multicast support, router discovery and some
            additional information about the 802.16 procedures.

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

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html 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?

            No issues found.

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

            No issues here.

  (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 suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  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?

            IANA section does not require any actions.

  (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?

            No such sections.

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

          Technical Summary

            This document specifies the addressing and operation of IPv6 over
            the IPv6 specific part of the packet CS for hosts served by a
            network that utilizes the IEEE Std 802.16 air interface. It
            recommends the assignment of a unique prefix (or prefixes) to each
            host and allows the host to use multiple identifiers within that
            prefix, including support for randomly generated identifiers.


          Working Group Summary

            There was much initial debate about the link model to adopt.
            The interim made it clear that the "per-MS" prefix was
            preferable. Beyond that, there has been debate about how much
            802.16-specific details to include (e.g., on network entry
            procedure) for clarity.

          Document Quality

            There are no currently known implementations of this document.
            However, the per-MS prefix model has been deployed in 3GPP, so
            at least that part is known to work, and this was a major point
            in deciding in its favor. The WiMax forum sees this document as one
            of its pilars, so it is expected that it will see significant
            deployment within the next years.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?

                Shepherd: Gabriel Montenegro
                AD: Jari Arkko

AD review, part 2:

> The prefixes
>    are advertised with the on-link (L-bit) flag set to facilitate
>    Detecting Network Attachment (DNA) operation [RFC4135].
You are referring to a goals document and there is
no published protocol to go with it.

But there are other reasons why setting the L bit
makes sense. In general, this specification mixes
operational advice with implementation requirement,
and it is very unclear whether, for instance,
if L=0 would be disallowed in 802.16.

I would suggest making it clear which parts of
the document actually state something that is
mandatory and what is not. For instance, this
section could be rewritten as follows:

  Each MS MUST be considered to be on a separate subnet as
  a result of the point-to-point connection.

  The size and number of the prefixes is a configuration
  issue. Also, prefix delegation may be used to provide
  additional prefixes for a router connected over 802.16.

  The other properties of the prefixes are also a
  configuration issue. But typically the prefixes
  are advertised with the on-link (L-bit) flag set.

>    The MS has a 48-bit MAC address as specified in 802.16e [802.16e].
>    This MAC address is used to generate the 64 bit interface identifier
>    which is used by the MS for address autoconfiguration.
>    The IID is
>    generated by the MS as specified in RFC2464 [RFC2464].  For addresses
>    that are based on privacy extensions, the MS may generate random IIDs
>    as specified in RFC3041 [RFC3041].
IID is an undefined abbreviation in this document.
Also, again, its hard to determine what the document is
really mandating in terms of EUI-64 usage.

How about this: "The MS has a 48-bit MAC address as specified in
802.16e [802.16e]. This MAC address can be used if EUI-64 -based
interface identifier is needed for autoconfiguration [RFC 4291].
As in other links that support IPv6, EUI-64 -based interface
identifiers are not mandatory and other mechanisms, such as
random interface identifiers [RFC 3041] may also be used."

>    If the A-bit in the prefix information option (PIO) is set, the MS
>    performs stateless address autoconfiguration as per RFC 2461, 2462.
>    The AR is the default router that advertises a unique /64 prefix (or
>    prefixes) that is used by the MS to configure an address.
The second sentence seems to imply that the prefix
size has to be exactly 64 bits. You could fix that
but I'm not sure the second sentence is actually
adding anything useful here. You already stated
earlier that the prefixes are per-MN.

>    This document does not introduce any new vulnerabilities to IPv6
>    specifications or operation as a result of the 802.16 air interface
>    or the WiMAX network architecture.
I do not think you want to claim that there are no
new vulnerabilities because of the 802.16 link.
How about this:

  This document does not introduce any new vulnerabilities to IPv6
  specifications or operation. The security of the 802.16 air
  interface is the subject of [REFERENCE]. In addition, the
  security issues of the network architecture spanning beyond
  the 802.16 base stations is the subject of the documents
  defining such architectures, such as [REFERENCE].

>    [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
>              Stateless Address Autoconfiguration in IPv6", RFC 3041,
>              January 2001, .
Please refer to draft-ietf-ipv6-privacy-addrs-v2-05, because
it is in the RFC Editor's queue already.
>
>    [RFC3314]  Wasserman, Ed., M., "Recommendations for IPv6 in Third
>              Generation Partnership Project (3GPP) Standards",
>              RFC 3314, September 2002,
>              .
>
>    [RFC3756]  Nikander, P., Kempf, J., and E.  Nordmark, "IPv6 Neighbor
>              Discovery (ND) Trust Models and Threats", RFC 3756,
>              May 2004, .
>
>    [RFC4135]  Choi, JH. and G. Daley, "Goals of Detecting Network
>              Attachment in IPv6", RFC 4135, August 2005,
>              .
These should be informational references. Nothing
in those document is needed to implement this.

>    The addressing scheme for IPv6 hosts in 802.16 network follows the
>    IETFs recommendation for hosts specified in RFC 4294.  The IPv6 node
>    requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are
>    applicable for addressing.
> ...
>    [RFC4294]  Loughney, Ed., J., "IPv6 Node requirements", RFC 4294,
>              April 2006, .
Not sure what "recommendation" exists in 4294 -- it simply points
to existing RFCs on, say, addressing. Perhaps you meant RFC 3314
in the first sentence? By the way it isn't mentioned in the text.
> TBD.

I realize this in an acks section, but the document
needs to be complete when its shipped to the IESG.
You cannot edit it afterwards.

>    o  delivering the CS PDU to theappropriate service flow and transport
s/thea/the a/

--Jari

AD review, part 1:

I reviewed the new version of this specification.
Overall, it has no major technical problems but
still needs another editing round to tighten
the language, move non-core descriptive text to
an appendix, correct a few mistakes, and explain
how IPCS/Eth/Etc will be interoperable in a
multi-vendor environment that is not completely
under the control of a single administration.

Please see the comments below:

>    The scope of this document is limited to IPv6 operation over the IP
>    specific part of the Packet CS only.  It should be noted that while
>    capability exchange of the MS and BS is performed, there is no
>    negotiation of which service specific part of the packet CS will be
>    used for IPv6 transport.
This is still problematic.

I would not keep on raising this if I thought the current
text would pass the final IESG review, but given the attention
to this issue in the chartering stage you HAVE to provide
a credible explanation of how this does not end up
in interoperability problems.

>                        Figure 3: IPv6 encapsulation
This is vague. I know it was me who asked for the
picture, but this picture is not helpful in terms
of me actually knowing how to implement anything.
Perhaps you should just keep the first sentence
of Section 4.1, and add references to the specific
IEEE documents and their sections.
> 5.1.  WiMAX network architecture and IPv6 support
> 6.1.1.  IPv6 link in WiMAX
> 6.2.1.  IPv6 link establishment in WiMAX
> 6.3.1.  Maximum transmission unit in WiMAX

I would like to move the WIMAX sections to an
appendix. I do not see anything in them that
requires the implementor to know about it,
as long as we are talking about the "IPv6
over 802.16" part. And this spec is the
better the shorter it is. And there will
be less questions from the reviewers
and the rest of the IESG.

You can add a forward reference
to the appendix in their place,
however. For instance, "Further details
relating to the network setup / tunnel set
up / MTU in WIMAX networks are described
in Appendix X."

>    The collection of service flows (tunnels) to an MS is defined as a
>    single link.  Each link has only an MS and an AR.  Each MS belongs to
>    a different link.  No two MSs belong to the same link.  A different
>    prefix should be assigned to each unique link.  This link is fully
>    consistent with a standard IP link, without exception and conforms
>    with the definition of a point-to-point link in RFC2461 [RFC2461].
This part of 6.1.1 should probably be listed
in Section 6.1 already, because it appears
to be universally true.