Re: [16NG] FW: Review of the ipv6-over-ipv6cs draft

Jari Arkko <jari.arkko@piuha.net> Wed, 31 January 2007 13:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFX7-0000oZ-PX; Wed, 31 Jan 2007 08:29:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFX6-0000jf-8g for 16ng@ietf.org; Wed, 31 Jan 2007 08:29:52 -0500
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFX3-0005wQ-QZ for 16ng@ietf.org; Wed, 31 Jan 2007 08:29:52 -0500
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BBB71986AF; Wed, 31 Jan 2007 15:29:49 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F26671986AD; Wed, 31 Jan 2007 15:29:48 +0200 (EET)
Message-ID: <45C099CD.8010506@piuha.net>
Date: Wed, 31 Jan 2007 15:29:49 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version: 1.0
To: Basavaraj Patil <basavaraj.patil@nokia.com>, Pekka Savola <pekkas@netcore.fi>
Subject: Re: [16NG] FW: Review of the ipv6-over-ipv6cs draft
References: <45BDFD58.8060202@piuha.net>
In-Reply-To: <45BDFD58.8060202@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: 16ng@ietf.org
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

Hi,

Some thoughts on the substantive points raised by
Pekka's review:

> The design implications of raising RA intervals (intead of, say, filtering
> extra RAs out) may not be fully understood.  How are other protocols (e.g.,
> periodic MLD reports, Neighbor Solicitations due to port scanning or
> pinging
> the all nodes multicast address, etc.) handled?
>   

I believe there are generic issues such as port scanning that may
be best handled elsewhere. This document should be free to
address the specific IP layer issues, however. (Not commenting
on what the solution is, however, or the lack of a solution for
some of these things. But all-nodes address in the recommended
link scope does not appear to be a problem.)

> There seem to be some technical problems (e.g., GRE tunnel multiplexing,
> different MTU recommendation) with Appendices and an issue of
> clarity why the appendices are there to begin with.
>   

I am getting the sense that removing the Wimax-specific discussion
is the right thing. In addition, your comments regarding GRE
multiplexing should be taken into account in the Wimax work.
Basavaraj works in Wimax Forum, I'm sure he can bring that
issue up there.

> It is not clear if traffic classification is adequately specified (or is
> it specified elsewhere?) and some miscellaneous issues.
>   

Specified elsewhere. This needs to be made clearer.

> substantial
> -----------
>
> ==> looking at the other "IPv6 over foo" documents, this document doesn't
> specify or mention the following:
>  - link-local address generation  (exactly as described in RFC2464, I
> suppose?)
>  - unicast and multicast address mapping
>
> Maybe these don't require much text but an explicit note might be a good
> thing to have.
>   

Yes.

>    Hence the point-to-point link model
>    for IPv6 operation over the IP specific part of the Packet CS in
>    802.16 is recommended.  A unique IPv6 prefix(es) per link (MS) is
>    also recommended.
>
> ==> you don't discuss what will happen if these recommendations are not
> followed, in fact, the whole document assumes they are adhered to.  Either
> this should be discussed or the recommendations should be made stronger
> (requirements).
>   

They should be requirements.

> 6.3.  Maximum transmission unit in 802.16
>
> [...]  The Max value of the IPv6 MTU for 802.16 is 2038
>    bytes and the minimum value of 1280 bytes.  The default MTU for IPv6
>    over 802.16 SHOULD be the same as specified in RFC2460 which is 1500
>    octets.  RFC2461 defines an MTU option that an AR can advertise to an
>    MN.  If an AR advertises an MTU via the RA MTU option, the MN should
>    use the MTU from the RA.
>
> ==> Should the last sentence use uppercase keywords?
> ==> However, if the MS is a router, RA is basically ignored in this kind of
> context.  Hence, this approach of non-default MTU configuration seems
> applicable between host and a router only.
>   

This should be made clear in the text -- perhaps with appropriate
warning label that discourages such usage. (If Wimax Forum wants
to do that due to the MTU of the backend tunnels, it would be their
conscious choice.)

Jari



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