Re: [16NG] Review of draft-ietf-16ng-ipv6-over-ipv6cs-07.txt

Margaret, Basavaraj,

First, thank you Margaret for your review! I talked to
the chairs and Basavaraj, and they will revise the
document according to your and Pekka's comments.

Please find some observations inline wrt
to the biggest substantial comments.

>
> EDIT:  This document would, IMO, benefit greatly from the inclusion of
> RFC 2119 language to make it clear what is actually being specified.
> There are a fairly large number of places where loose language is used
> to talk about existing IPv6 functionality, and it is not always clear
> whether that information is being included for reference purposes, or
> if this document is intending to change (or at least loosen the
> requirements) for those parts of IPv6.
Yes, the same feedback has been received from different
reviewers. The draft needs to make clear what its
requirements are.

>
>    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.
>
> SUBS: There seems to be some confusion here about whether the IEEE
> has defined an IP-specific CS (presumably for both IPv4 and IPv6) or
> an IPv6-specific CS.  Which is correct?
>
> SUBS: Why is this document defining an IPv6 encapsulation and not
> both an IPv4 and an IPv6 encapsulation?  If they are defined
> separately, where will you describe how a dual stack will work over
> the convergence sublayer(s)?
>

This document is separate from the IPv4 part mainly to
allow the issues to be worked on separately (and because
in terms of timing, the IPv6 part is urgent).

But I agree that the document should talk about
dual stack. This is also required by the WG's charter.

>    Appendix A.  WiMAX network architecture and IPv6 support . . . . . 15
>    Appendix B.  IPv6 link in WiMAX  . . . . . . . . . . . . . . . . . 16
>    Appendix C.  IPv6 link establishment in WiMAX  . . . . . . . . . . 17
>    Appendix D.  Maximum transmission unit in WiMAX  . . . . . . . . . 17
>
> SUBS:  What is the purpose of including this WiMAX-specific
> information in
> the document?

I am also getting now the sense that these parts have brought
more confusion than clarity. It would be better to keep the main
body of the document and deal with the Wimax aspects in Wimax
documents -- using the capabilities defined in this document
of course. For instance, the document allows routers to advertise
a non-default MTU, which Wimax could use.

>
>    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
>    immediately after ranging (802.16 air interface procedure), the MS
>    and BS exchange their capability negotiation via REG-REQ and REG-RSP.
>
> SUBS:  Need more explanation in order to understand what this means. 
> Also,
> expand acronyms/abbreviations.

Yes. The wording could also be changed to ensure that
people understand REG-REQ is not a part of this spec,
it exists in 802.16. For instance, "As specified in [...], ...".
In any case, the text is there only to explain how the
capability negotiation of CSes happens.

>
>    Additionally during the establishment of the
>    transport connection for transporting IPv6 packets, the DSA-REQ and
>    DSA-RSP messages between the BS and MS indicate via the CS-
>    Specification TLV the CS that the connection being setup shall use.
>    When the IPv6 packet is encapsulated by the 802.16 six byte MAC
>    header there is no specific indication in the MAC header itself about
>    the payload type.  The processing of the packet is based entirely on
>    the classifiers.
>
> SUBS:  Does this indicate that IPv4 and IPv6 would need to run over
> separate
> 802.16 connections?  Or that they would run over a single connection?

Separate, I believe, but this needs to spelled out.

>    Transmission of IPv6 as explained above is possible via multiple
>    methods, i.e, via the IP specific part of the packet CS or via
>    Ethernet or 802.1Q interfaces.  The choice of which method to use is
>    implementation specific.  In order to ensure interoperability the BS
>    should at least support both the IP specific part of the packet CS
>    and the Ethernet specific part of the packet CS for IPv6 transport.
>
> SUBS:  I think we need something stronger than a lowercase should here.
> In order to assure interoperability, this specification must make it
> clear what each side is required to implement in order to be compliant
> with
> this spec.

Right.

>
>    For transmission of IPv6 packets via the IP specific part of the
>    Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC
>    directly.  The IPv6 layer delivers the IPv6 packet to the Packet CS
>    of the 802.16.  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
>
> SUBS:  Why include the traffic class and not the entire IPv6 Flow Label
> field?

The 802.16 specification determines how the classifers
work. We cannot change that (but we are setting up
a review with IEEE that would detect differences, if
any.)

>
>    header field, Masked IP source and destination addresses and,
>
> SUBS: Will the classifier walk any chained IPv6 headers and use the next
> header field that corresponds to the upper layer protocol?  Or the next
> header field in the main IPv6 header?
>
> SUBS: How/why are the source and dest addresses masked?
>
>    Protocol source and destination port ranges.  Using the classifiers,
>
> SUBS: What does the classifier use for source/dest ports if the packet
> is encrypted?

These are good questions, but I believe they should be subject
for the relevant IEEE specifications. The document should make
it clear that it does not claim to provide normative rules for
the classification process.

>
>    When an AR and a BS are collocated, the collection of Transport
>    Connections to an MS is defined as a single link.  When an AR and a
>    BS are separated, it is recommended that a tunnel is established
>    between the AR and a BS whose granuality is no greater than 'per MS'
>    or 'per service flow' ( An MS can have multiple service flows which
>    are identified by a service flow ID).  Then the tunnel(s) for an MS,
>    in combination with the MS's Transport connections, forms a single
>    point-to-point link.
>
> SUBS:  If this is only recommended, what are the other options and how
> would IPv6 be supported over them?  From the rest of the discussion, it
> appears that this is required, not recommended.
>

Indeed. This should be changed to a normative requirement.

>    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.  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].  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.
>
> SUBS: Should we make it clear that this prefix should be no longer than
> a /64, in order to provide full support for the features of IPv6?

Yes.

>
>    6.  The AR sends a router advertisement to the MS.  Alternatively or
>        in addition, the MS can also send a router solicitation.
>
> SUBS: The AR and MS should send router advertisements and solicitations
> as specified in the Neighbor Discovery specification.  If it is not your
> intent to change that, I would put a pointer here instead of the wording
> that is currently included.

Right.

>
>    The 802.16 MAC PDU (Protocol Data Unit) is composed by 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 HDR.  The Len parameter has a
>    size of 11 bits.  Hence the total PDU size is 2048 bytes.  The IPv6
>    payload can be a max value of 2038 bytes ( Total PDU size minus (MAC
>    Header + CRC)).  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.
>
> SUBS:  It is unclear what you are specifying here.  We don't get to
> declare a default value for the 802.16 MTU.  One of two things seems to
> be true here, and I don't have enough information to know which one:
> the MTU of 802.16 networks is 2038 bytes, or the MTU for 802.16 network
> is configurable between 1280 and 2038 bytes.
>

The latter was the intent, I believe. Text should change.

>    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.
>
> SUBS: Even if it is greater than 2038 or less than 1280 bytes?
>

No -- should be noted.

>
> 8.3.  Router lifetime and periodic router advertisements
>
>    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 RFC2461 [RFC2461].  The AdvDefaultLifetime in
>    the router advertisement MUST be either zero or between
>    MaxRtrAdvInterval and 43200 seconds.  The default value is 2 *
>    MaxRtrAdvInterval.
>
>    802.16 hosts have the capability to transition to an idle mode in
>    which case the radio link between the BS and MS is torn down.  Paging
>    is required in case the network needs to deliver packets to the MS.
>    In order to avoid waking a mobile which is in idle mode and consuming
>    resources on the air interface, the interval between periodic router
>    advertisements should be set quite high.  The MaxRtrAdvInterval value
>    specified in this document over-rides the recommendation in RFC2461
>    [RFC2461].  The MaxRtrAdvInterval MUST be no less than 4 seconds and
>    no greater than 21600 seconds.  The default value for
>    MaxRtrAdvInterval is 10800 seconds.
>
> SUBS:  I would like to see some exploration of what the impact of these
> changes would be on IPv6 operations.  Are there other mechanisms that
> are used in 802.16 for black-hole detection and/or detecting when a
> network connection has been lost?

There may be L2 mechanisms, but I'm not sure if
that guarantees reachability all the way to the router.

>
> 9.3.  Stateless address autoconfiguration
>
>    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 prefix (or
>    prefixes) that is used by the MS to configure an address.
>
> 9.4.  Stateful address autoconfiguration
>
>    The Stateful Address Autoconfiguration is invoked if the M-flag is
>    set in the Router Advertisement.  Obtaining the IPv6 address through
>    stateful address autoconfiguration method is specified in RFC3315
>    [RFC3315].
>
> SUBS: In both of the previous two sections, is this any different from
> standard IPv6?  If so, spell out what is changed.  If not, why include
> these sections?

Previous proposals included mechanisms that changed the
way address autoconfiguration worked, for instance. I think
it is useful to state that ND operates as specified in IPv6.

But it may be that these sections have too many words.

>
>    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 [802.16].  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 WiMAX Network Architecture [WiMAXArch].
>
> SUBS: I am not sure that this is correct.  I am not clear on how 802.16
> packet classification is consistent with encrypted upper-layer headers.

I do not think this is any different on packet classification
on firewalls, for instance. The information that is available
is used, not more...

--Jari

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