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

Hi all,

I asked Pekka Savola to review this specification,
which he did -- thank you! You will find his comments
below. Please send any responses or text updates
with respect to his points to the list.

Jari

(Sorry for the duplicates, I forgot to copy the list
when sending this.)

-----

The editorial clarity could have been somewhat better.

It is not obvious whether the scenarios where "MS" is a fixed station
and/or a router has been adequately considered or whether this is an
editorial issue.

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?

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.

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

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.

...

The packet CS defines a set of classifiers that are
   used to determine how to handle the packet.  The IP classifiers that
   are used at the MAC operate on the fields of the IP header and the
   transport protocol and these include the IP Traffic class, Next
   header field, Masked IP source and destination addresses and,
   Protocol source and destination port ranges.

==> this is probably defined better in 802.16, but not all traffic may have
a traffic class (v4 has DSCP which is similar), you don't define what is
"masked {dst,src} address" (just some kind of prefix part of an address?),
and there may not necessarily be any port ranges involved (non-TCP/UDP
protocols).

Is more precise specification of this required to create interoperable
implementations?  Is it a problem if different hosts make different
classifications for the same kind of traffic?

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

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.

8.1.  Router Solicitation
   [...] Movement detection at the IP layer of an MS
   in many cases is based on receiving periodic router advertisements.

==> yet, in 8.3 you make the period much longer, to be counted in hours.
That's not useful for movement detection, text above should probably be
adjusted.

8.3.  Router lifetime and periodic router advertisements

==> it is not clear if the implications of the design decision to raise the
default advertisement intervals has been adequately understood.  Will this
mean that every single instance of protocols which use too low intervals
will need to be modified?  How do you deal with periodic MLD reports, for
example?  How do you prevent frequent port scanning from waking up the host
every 5 minutes when the router wants to do Neighbor Solicititation for the
address?

 The
   granularity of the GRE tunnel should be on a per MS basis or on a per
   service flow basis (an MS can have multiple service flows, each of
   which are identified uniquely by a service flow ID).

==> So, it's possible to have multiple GRE tunnels between AR and BS.  Yet,
I do not see how different GRE tunnels are multiplexed/demultiplexed.  GRE
header does not support this AFAICS -- you'd need to use different
source/destination IP address pairs, or encode different flows as different
'Protocol type' values (16 bits), but the latter would require
modifications
to GRE processing code at both endpoints of the tunnel.   Therefore I'm not
sure if this approach is workable.

Appendix D.  Maximum transmission unit in WiMAX

   The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
   Hence the IPv6 path MTU can be 1500 octets.  However because of the
   overhead of the GRE tunnel used to transport IPv6 packets between the
   BS and AR and the 6 byte MAC header over the air interface, using a
   value of 1500 would result in fragmentation of packets.  It is
   recommended that the default MTU for IPv6 be set to 1400 octets for
   the MS in WiMAX networks.  Note that the 1522 octet specification is
   a WiMAX forum specification and not the size of the SDU that can be
   transmitted over 802.16, which has a higher limit.

==> This brings up multiple problems:

 1) main body said SHOULD use 1500 bytes, yet this recommends 1400.
 2) there is no statement in the document how to treat the appendices,
i.e.,
why thet even exist in this document especially if they contain
contradicting material.
 3) The text above seems technically incorrect.  The key point here is what
is the MTU on the wired link between BS and AR.  If it supports MTUs higher
than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling
could
possibly still be used.

editorial
---------

Abstract

   IEEE Std 802.16 is an air interface specification.  IEEE has
   specified several service specific convergence sublayers (CS) for
   802.16 which are used by upper layer protocols.  The ATM CS and
   Packet CS are the two main service specific convergence sublayers and
   these are a part of the 802.16 MAC which the upper layers interface
   to.  The packet CS is used for transport for all packet-based
   protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet)
   and, IEEE Std 802.1Q (VLAN).  The IP specific part of the Packet CS
   enables transport of IPv6 packets directly over the MAC.  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.

==> s/the assignment of/assigning/ ?
==> abstract is a bit on the lengthy side.  Maybe shorten a bit from the
beginning, e.g. leaving ATM CS and some more generic sublayer discussions
out of the abstract?

2.  Introduction

==> the introduction mentions "mobile station/host", yet I think there
is no
restriction that the endpoint be a) mobile (could be a fixed wireless link
as well), and b) a host (could be a router as well).  Maybe some further
clarification here is needed to make it clear that fixed/router scenarios
are also to be addressed by this specification.

==> it might be helpful to have a diagram in section 2, as there are at
least four functional components (AR, BS, link, MS) and at least AR hasn't
been spelled out.  This also seems to include some assumptions about
connecting a host to a router (above).

4.1.  IPv6 encapsulation over the IP CS of the MAC

   The IPv6 payload when carried over the IP specific part of the Packet
   CS is encapsulated by the 6 byte 802.16 MAC header.  [...]

==> "encapsulated by" seems a bit strange.. also, later you use
"encapsulated .. in".

   The IPv6 node requirements RFC RFC4294 [RFC4294] specifies [...]

==> s/ RFC RFC4294//

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