[16NG] ipv6 over ipv6cs document approval

Jari Arkko <jari.arkko@piuha.net> Wed, 21 November 2007 15:08 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurCD-0003xo-CF; Wed, 21 Nov 2007 10:08:57 -0500
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1IurCB-0003xh-Bb for 16ng-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:08:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurC6-0003px-2N for 16ng@ietf.org; Wed, 21 Nov 2007 10:08:50 -0500
Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IurC5-0007tZ-AW for 16ng@ietf.org; Wed, 21 Nov 2007 10:08:49 -0500
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A3B2A19867C for <16ng@ietf.org>; Wed, 21 Nov 2007 17:08:48 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 60669198670 for <16ng@ietf.org>; Wed, 21 Nov 2007 17:08:48 +0200 (EET)
Message-ID: <47444A00.5080907@piuha.net>
Date: Wed, 21 Nov 2007 17:08:48 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: 16ng@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Subject: [16NG] ipv6 over ipv6cs document approval
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

We're trying to close the remaining issues and approve
the current document.

The current proposal is what we have in the draft, with
the following changes. If there is any concern with
these changes, let me know as soon as possible.

There are a few editorial changes. The substantive
changes are clarifying MTU rules in the presence
of tunneling on the BS side, and strengthening
the requirements related to interoperability.

----

  Please change in Section 8.1:

  OLD:
    The use of router advertisements as a means for movement detection is
    not recommended for MNs connected via 802.16 links as the frequency
    of periodic router advertisements can be high.
  NEW:
    The use of router advertisements as a means for movement detection is
    not recommended for MNs connected via 802.16 links as the frequency
    of periodic router advertisements would have to be high.

  Please add new text at the end of Section 4 (just before 4.1),
  these are the new paragraphs:

    In any case, the MS and BS MUST negotiate at most one
    convergence sublayer for IPv6 transport on a given link.

    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.

  Change in Appendix D:

  OLD:
    It is
    recommended that the default MTU for IPv6 be set to 1400 octets for
    the MS in WiMAX networks. 
  NEW:
    It is recommended that the MTU for IPv6 be set to 1400 octets in
    WiMAX networks, and this value (different from the default)
    be communicated to the MS.

  Change Section 6.3 to:

   The MTU value for IPv6 packets on an 802.16 link is configurable.
   The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500
   octets.

   The 802.16 MAC PDU (Protocol Data Unit) is composed of a 6 byte
   header followed by an optional payload and an optional CRC covering
   the header and the payload.  The length of the PDU is indicated by
   the Len parameter in the Generic MAC Header.  The Len parameter has a
   size of 11 bits.  Hence the total MAC PDU size is 2048 bytes.  The
   IPv6 payload size can vary.  In certain deployment scenarios the MTU
   value can be greater than the default.  Neighbor Discovery for IPv6
   [RFC4861] defines an MTU option that an AR MUST advertise, via router
   advertisement (RA) if a value different from 1500 is used.
   If an AR advertises an
   MTU via the RA MTU option, the MN SHOULD use the MTU from the RA.
   Nodes that implement Path MTU discovery [RFC1981] MAY use the
   mechanism to determine the MTU for the IPv6 packets.

  In the abstract:
    s/fxed/fixed/
 
  In section 6.1:
    s/it is recommended that a tunnel is established/it is recommended
    that a tunnel be established/



_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng