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

Hi Margaret,

Thanks for the review.
My responses to your comments are prefixed with Raj> below:

-Raj

--------------------------

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.

Raj> Okay. 

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.

Raj> Agree.

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?

Raj> IEEE 802.16 specifies two main convergence sublayers, ATM and
Packet. The Packet CS supports IPv4, IPv6, 802.3 and 802.1Q. A set of
classification rules are used to process upper layer packets and map
them to a transport connection that is established for either IPv4,
IPv6, 802.3 or 802.1Q . So to answer your question, there is not a
specific IPv6 CS. Rather the packet CS using the classification rules
that determine a packet is an IPv6 packet map it to a service flow and
a transport connection that is established for carrying the IPv6
packet. The same packet CS with classification rules for IPv4
deal with IPv4 packets.
I can add some text in the I-D to make this clear. But I believe that
this is clear by virtue of referencing the 802.16 specification.

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

Raj> Because there is a separate I-D and WG goal to define the same
for IPv4 as well. I dont know if the I-D has been posted yet, but I
have seen a preliminary version of it.
Operation of dual-stack over the packet CS and more specifically the
IP specific part of the packet CS (i.e exclusing operation of dual
stack over 802.3) is not in the scope of this I-D. This may be done in
a separate document by the WG depending on the types of issues
identified. At this time, I do not see any serious concerns about
operating a dual-stack over the IP specific part of the packet CS.

   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.

Raj> Okay.

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.

Raj> The WiMAX specific part is in an appendix. The 802.16
air-interface is being adopted and deployed as WiMAX networks
today. Hence from an applicability perspective it gives information
about how the operation of IPv6 over 802.16 is utilized. IMO, this is
useful information and given that it is in an appendix, it is only
informative and does no harm. I am not sure I understand your concern
about it being obsoleted. This is technology that is being built and
deployed now and will exist for several years. I agree that as with
everything else there will be evolution, but so will RFCs that are
revised. 

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.

Raj> My intention was to avoid having to get into the details of
802.16 beyond the fact that it is an air-interface specification. The
reference to the IEEE specification IMO is sufficient. But I have no
problems in adding a paragraph with a brief explanation of 802.16. The
problem is that everyone will have an opinion about what 802.16
intends to accomplish. All I can say about it is the fact that it is
just another radio technology.

   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?

Raj> Okay. I can do that.

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.

Raj> Agreed.

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

Raj> It is in the abstract itself. "IEEE has specified several service
specific convergence sublayers (CS)..."
When you say technologies, I am not sure what you mean. Basically the
technology being referenced here is 802.16. The terminology of CS, SF
(service flow), CID etc. are all part of 802.16 and the terminology is
intended to be included in the next rev of the problem-specification
(PSDOC). The terminology that will be included in the PSDOC is in the
email:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html

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

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

Raj> Okay. 

   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?

Raj> Yes.

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.

Raj> Okay.

   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.

Raj> The specification is intended to be generic. It is also a fact
that this specification will be the basis for IPv6 operation in WiMAX
networks and the networking group in WiMAX forum is referencing this
specification. Mentioning the above fact IMO does no harm. But if you
think this is a serious concern, I can simply mention this in the
Appendix.

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.

Raj> I agree that the term ASN can be moved to the appendix since it
is applicable only in that context. Will remove it from the main body
of the text.

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?

Raj> Okay.

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.

Raj> I can add additional text to explain this. But the explanation of
ranging and capability exchange via 802.16 MAC messages
(REG-REQ/REG-RSP) are in the 802.16 spec. I can mention the reference
here again. Let me propose some additional text and see if it
clarifies the above paragraph further to a reader who may not have an
understanding of .16. However an implementer will need to know a
certain extent 802.16 details and hence the reference to 802.16 should
be normative as you have suggested as well.

   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?

Raj> Hmmm... Let me see if I can do a better job of explaining this
paragraph. Will provide new text for this. Basically what I am trying
to say is that 802.16 MAC messages exchanged between the host and the
BS (base-station) negotiate capability and the existence of support
for IPv6. 

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?

Raj> IPv4 and IPv6 when run over the IP specific part of the packet CS
are run over separate transport connections over the
air-interface. They cannot be 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.

Raj> Okay. 

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?

Raj> Via the capability negotiation in the MAC messages and the
parameters exchanged in the request to establish a transport
connection. The MS indicates what it is capable of supporting and the
BS provides an indication in the response which mode to use. You may
also want to refer to the email below for further details:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00021.html

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?

Raj> It is part of the MAC header. I will clarify the term PHSI. PHSI
= Payload Header Suppression Index

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

Raj> This is explained in section 5.2.3 of the 802.16 specification. I
will add the appropriate reference.

   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?

Raj> Because the flow label is not a parameter used in the
classification as specified by 802.16 today.

   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?

Raj> No. To quote 802.16 : "For IPv6 (IETF RFC 2460), this refers to
next header entry in the last header of the IP header chain." I can
clarify in the I-D.

SUBS: How/why are the source and dest addresses masked?

Raj> I am not sure I understand what you mean. Applying a mask to
obtain a range is straightforward. And the reason for applying the
mask is to use the filters (classification rules) to apply for
multiple adresses or address ranges.

   Protocol source and destination port ranges.  Using the classifiers,

SUBS: What does the classifier use for source/dest ports if the packet
is encrypted?

Raj> In the case of encrypted packets, the SRC/Dest ports do not
apply. As the 802.16 spec says :"If this parameter is omitted, the
protocol source port is irrelevant. This parameter is irrelevant for
protocols without port numbers."
And the same for destination ports. So in the case of an encrypted
packet, the rule does not apply.

   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.

Raj> But that would cause clutter and less readable IMO.

   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.

Raj> Good catch. I will clarify.

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.

Raj> Well... IPv6 can also be transported over Ethernet. If IPv6 is to
be transported over the IP specific part of the packet CS, then this
I-D specifies the mechanism. I can make such a statement in the I-D.

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?

Raj> I am okay with making such a recommendation. I am just wondering
if there may be a need to assign a /128 prefix in some cases as a way
to limit the capability of the host.

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?

Raj> The default option is the triggering of the service flow on
completion of access authentication. Will clarify.

   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.

Raj> Okay.

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.

Raj> PMTUD is applicable when implemented on the host. The MTU
recommendation is for the case when the host does not do PMTUD or does
not obtain the information in the RA. The above section is basically
explaining the MTU of the .16 link but recommending the use of 1500
octets as the default.

   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?

Raj> Well... I would expect the AR to advertise a value that is
between 1280 and 2038. It would be configured for the specific
link. Maybe I can add the extra sentence to say that this value should
be between 1280 and 2038.

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.

Raj> Are you suggesting that the AR should not advertise a /48 prefix?

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?

Raj> The fact is that IETF has not specified behavior for hosts that
can transition to Idle mode. A host which is connected at the IP layer
and in idle mode does not have any radio bearer or connection as such
to the AR. There is state in the host and the AR which allows the
establishment of the connection when needed via paging mechanisms. So
when you say network connection being lost, this happens only if the
host does not see any of the .16 radio signaling at all. And in such a
case there do exist mechanisms for the link layer to trigger network
connection loss. A host in idle mode which has no lower layer
connections to the AR but is still able to see the .16 radio signals
is considered to be connected. I do not believe there are significant
impacts to IPv6 operations with these changes (AFAIK).

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?

Raj> Yes.

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

Raj> Okay.

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.

Raj> Okay.

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?

Raj> Okay... Will clarify what is specific to this I-D and 802.16

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.

Raj> As I said, the host is capable of detecting network attachment
quite well at the link layer. Classification rules are specified such
that if a packet does not meet the criteria, they are dropped. In the
case of encrypted packets, the classification rules may exclude the
use of the upper layer parameters. It is flexible. Changes to the RA
interval IMO at least does not have a security impact.

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?

Raj> Will delete.

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.

Raj> Agree. Will correct.

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

Raj> Okay

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

Raj> Sec 9.4 of the I-D has a reference to 3315.

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