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

[I sent to the wrong e-mail address the first time.  I apologize for any
duplicates.]

Hi All,

I have a fairly large number of comments and questions on
draft-ietf-16ng-ipv6-over-ipv6cs-07.txt.  I have included them all
below, hopefully with enough document context that you can tell what
I am commenting about.  Substantive issues are preceded by "SUBS:"
and editorial issues are preceded by "EDIT:".

IMO, this document needs some work, especially in the areas of
organization and clarity, before it will be ready for publication.   
In some
cases, I was not able to understand the document well-enough to
determine what it is specifying.

Thanks,
Margaret

---

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.

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.

EDIT: s/which the upper layers interface to/to which the upper layers
interface.

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

    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.

ED: s/identifiers/interface identifiers.

    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 realize that the WiMAX architecture is expected to make
use of this mechanism, but I don't understand why we would want to put
this WiMAX information here, where it is unnecessary and may become  
obsolete
over time.

2.  Introduction

SUBS:  Is there a short description we can borrow from the IEEE
regarding what 802.16 is and what it intends to accomplish?  It
seems like this document would greatly benefit from a summary of
802.16 up front that can be referred to later.

    IPv6 packets can be carried over the IEEE Std 802.16 specified air
    interface via either:

SUBS: The document should be independent of the abstract, so you
may want to repeat some of the abstract information here, rather
than just jumping in.  Also, shouldn't you define what IEEE Std
802.16 is and include a reference here, rather than in the next
paragraph?

EDIT:  I think that "either" is only used when there are exactly
two choices, so s/either:/:

    1.  the IP specific part of the Packet CS or,
    2.  the 802.3 specific part of the Packet CS or,
    3.  the 802.1Q specific part of the Packet CS.

SUBS:  You have not yet defined the acronym CS.  Also, all of
these technologies need references.

    The 802.16 [802.16] specification includes the Phy and MAC details.

EDIT: You should define the abbreviations Phy and MAC before using
them.

    The convergence sublayers are a part of the MAC.  This document
    specifies IPv6 from the perspective of the transmission of IPv6 over
    the IP specific part of the packet convergence sublayer.  The mobile

EDIT:  Paragraph break?

    station/host is attached to an access router via a base station  
(BS).
    The host and the BS are connected via the IEEE Std 802.16 air
    interface at the link and physical layers.  The IPv6 link from  
the MS
    terminates at an access router which may be a part of the BS or an
    entity beyond the BS.  The base station is a layer 2 entity (from  
the
    perspective of the IPv6 link between the MS and AR) and relays the
    IPv6 packets between the AR and the host via a point-to-point
    connection over the air interface.

EDIT:  If the text below is retained, it should be a separate paragraph.

    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.  The
    various aspects of IPv6 over 802.16 as applicable to WiMAX are
    captured in the appendix sections of this document.

SUBS: Why is this needed in the document?  Are we defining IPv6 over
the IEEE 802.16 IP CS exclusively for WiMAX?  If not, I think we should
avoid any indication that this specification is somehow WiMAX-specific.

3.  Terminology

    The terminology in this document is based on the definitions in
    [PSDOC], in addition to the ones specified in this section.

    Access Service Network (ASN) - The ASN is defined as a complete set
    of network functions needed to provide radio access to a WiMAX
    subscriber.  The ASN is the access network to which the MS attaches.
    The IPv6 access router is an entity within the ASN.  The term ASN is
    specific to the WiMAX network architecture.

SUBS: Same question on whether this document is WiMAX-specific. Also, it
is not clear to me that this term is actually needed to understand or
implement this specification.

4.  IEEE 802.16 convergence sublayer support for IPv6

    The figure below shows the options for IPv6 transport over the  
packet
    CS of 802.16:

                         -----------------  -----------------
                         |   IPv6        |  |   IPv6        |
      ----------------   |---------------|  |-----------    |
      |  IPv6        |   | Ethernet      |  | 802.1Q        |
      |--------------|   |---------------|  |-----------    |
      | IP Specific  |   | 802.3 specific|  |802.1Q specific|
      |part of Pkt CS|   |part of Pkt CS |  |part of Pkt CS |
      |..............|   |...............|  |...............|
      |    MAC       |   |    MAC        |  |   MAC         |
      |--------------|   |---------------|  |---------------|
      |    PHY       |   |    PHY        |  |   PHY         |
      ----------------   -----------------  -----------------

      (1) IPv6 over      (2) IPv6 over       (3) IPv6 over
      IP Specific part   802.3/Ethernet       802.1Q
      of Packet CS

    Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the  
Packet
                                     CS

EDIT:  Include an informative pointer to the I6ng WG document that
defines IP(v4 & v6) over the Ethernet CS?

    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.

    These management frames negotiate parameters such as the Convergence
    Sublayer support.  By default, Packet, IPv4 and 802.3/Ethernet are
    supported.  IPv6 via the Packet CS is supported by the MS and the BS
    only when the bit specifying such support is indicated in the
    parameter "Classification/PHS options and SDU encapsulation support"
    (Refer to [802.16]).

SUBS:  It is not clear what this means.  Which entities negotiate  
IPv6 support
using what mechanisms?

    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?

    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.

    Hosts which may implement one or the other method for transmission
    would be assured of the ability to establish a transport connection
    that would enable the transport of IPv6 packets.  Inability to
    negotiate a common convergence sublayer for the transport connection
    between the MS and BS will result in failure to setup the transport
    connection and thereby render the host unable to send and receive
    IPv6 packets.  In the case of a host which implements more than one
    method of transporting IPv6 packets, the choice of which method to
    use (i.e IPv6 over the IP specific part of the packet CS or IPv6  
over
    802.3 or, IPv6 over 802.1Q) is implementation specific.

SUBS:  How does the MS tell which modes are supported by the BS?  Or  
vice
versa?

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.  Header
    suppression can also be applied to the IP packet.  The format of the
    IPv6 packet with and without header suppression is shown in the
    figure below:

              ---------/ /-----------
              |    MAC SDU          |
              --------/ /------------
                      ||
                      ||
                      \/
       ---------------------------------------------------------
       | PHSI=0 |         IPv6 Packet (including Header)       |
       ---------------------------------------------------------
           (i) IPv6 packet without header suppression

SUBS:  What is PHSI?  Is this part of the 6-byte MAC header?  Or
something separate?

       ---------------------------------------------------------
       | PHSI=1 |        (Header suppressed IPv6 packet)       |
       ---------------------------------------------------------
           (ii) IPv6 packet with header suppression

SUBS:  What type of header suppression is used in this case?  Please
add a pointer to the relevant specification.

    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?

    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?

    the MAC maps an upper layer packet to a specific service flow and
    transport connection to be used.  The MAC encapsulates the IPv6
    packet in the 6 byte MAC header and transmits it.

5.  Generic network architecture using the 802.16 air interface

EDIT: It would be helpful to move all of the information in this section
to the introduction.

    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.

EDIT:  You have not previous defined "service flow", as far as I know.

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.

    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?

6.2.  IPv6 link establishment in 802.16

    In order to enable the sending and receiving of IPv6 packets between
    the MS and the AR, the link between the MS and the AR via the BS
    needs to be established.  This section illustrates the link
    establishment procedure.

[...]

    5.  The MS can request the establishment of a service flow for IPv6
        packets over the IP specific part of the Packet CS.  The service
        flow can also be triggered by the network as a result of pre-
        provisioning.  The service flow establishes a link between  
the MS
        and the AR over which IPv6 packets can be sent and received.

SUBS:  When you say "the MS can request" or "the service flow can  
also be
triggered", which is the mandatory mode that both ends must support?

    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.

    The above flow does not show the actual 802.16 messages that are  
used
    for ranging, capability exchange or service flow establishment.
    Details of these are in [802.16].

6.3.  Maximum transmission unit in 802.16

    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.  Either way, IPv6 should be
aware of the actual MTU in use on a give link and PMTUD should function
accordingly.

    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?

7.  IPv6 prefix assignment

    The MS and the AR are connected via a point-to-point connection at
    the IPv6 layer.  Hence each MS can be considered to be on a separate
    subnet.  A CPE (Customer Premise Equipment) type of device which
    serves multiple IPv6 hosts, may be the end point of the connection.
    Hence one or more /64 prefixes should be assigned to a link.  The
    prefixes are advertised with the on-link (L-bit) flag set as
    specified in RFC2461 [RFC2461].  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 dealt via configuration.

SUBS:  As above, we should strongly recommend prefixes no shorter than
a /64 in order for all IPv6 features to function properly.

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?

9.1.  Interface Identifier

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

SUBS: Would the translation from 802.16's 48-bit MAC address to an  
EUI-64
identifier be the same as for an Ethernet address?

EDIT: IPv6 addressers are based on Modified EUI-64 identifiers, not on
EUI-64s in their original form.

9.2.  Duplicate address detection

    DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462].

EDIT:  Here and elsewhere, it would be more useful to name these  
documents
and include the RFC number in the citation, rather than simply  
repeating the RFC
number.

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?

10.  IANA Considerations

    This draft does not require any actions from IANA.

11.  Security Considerations

    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.
Also, the changes to the Router Solicitation/Advertisement timers may
have some security-related implications, particularly WRT to how long
it may take end-nodes to detect changes to network attachment.

Appendix E.  Stateless address autoconfiguration

    The MS can perform stateless address autoconfiguration as per
    RFC2461, 2462 if the A-bit in the prefix information option (PIO) is
    set.  The AR is the default router that advertises a unique /64
    prefix (or prefixes) that is used by the MS to configure an address.

EDIT:  Why is this in an appendix?  How does this differ from section  
9.3?

3.2.  Informative References

    [802.16]   "IEEE Std 802.16e: IEEE Standard for Local and
               metropolitan area networks, Amendment for Physical and
               Medium Access Control Layers for Combined Fixed and  
Mobile
               Operation in Licensed Bands", October 2005.

SUBS:  The IEEE 802.16 document should be a normative reference for
this specification, not an informative one.

EDIT:  Since this is now available for free download, a URL would
be helpful.

    [RFC3315]  Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins,
               C., and M. Carney, "Dynamic Host Configuration Protocol
               for IPv6 (DHCPv6)", RFC 3315, July 2003,
               <ftp://ftp.isi.edu/in-notes/rfc3315>.

EDIT:  There is no reference to RFC 3315 in the document.

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