[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5121

Network Working Group                                    Basavaraj Patil
Internet-Draft                                                     Nokia
Intended status: Standards Track                               Frank Xia
Expires: July 27, 2007                                   Behcet Sarikaya
                                                              Huawei USA
                                                                JH. Choi
                                                             Samsung AIT
                                                        Syam Madanapalli
                                                               LogicaCMG
                                                        January 23, 2007


  IPv6 Over the IP Specific part of the Packet Convergence sublayer in
                            802.16 Networks
                  draft-ietf-16ng-ipv6-over-ipv6cs-07

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 27, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   IEEE Std 802.16 is an air interface specification.  IEEE has



Patil, et al.             Expires July 27, 2007                 [Page 1]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   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.





































Patil, et al.             Expires July 27, 2007                 [Page 2]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


Table of Contents

   1.  Conventions used in this document  . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  IEEE 802.16 convergence sublayer support for IPv6  . . . . . .  5
     4.1.  IPv6 encapsulation over the IP CS of the MAC . . . . . . .  7
   5.  Generic network architecture using the 802.16 air interface  .  8
   6.  IPv6 link  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  IPv6 link in 802.16  . . . . . . . . . . . . . . . . . . .  9
     6.2.  IPv6 link establishment in 802.16  . . . . . . . . . . . . 10
     6.3.  Maximum transmission unit in 802.16  . . . . . . . . . . . 11
   7.  IPv6 prefix assignment . . . . . . . . . . . . . . . . . . . . 11
   8.  Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Router Solicitation  . . . . . . . . . . . . . . . . . . . 11
     8.2.  Router Advertisement . . . . . . . . . . . . . . . . . . . 12
     8.3.  Router lifetime and periodic router advertisements . . . . 12
   9.  IPv6 addressing for hosts  . . . . . . . . . . . . . . . . . . 12
     9.1.  Interface Identifier . . . . . . . . . . . . . . . . . . . 12
     9.2.  Duplicate address detection  . . . . . . . . . . . . . . . 13
     9.3.  Stateless address autoconfiguration  . . . . . . . . . . . 13
     9.4.  Stateful address autoconfiguration . . . . . . . . . . . . 13
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     13.2. Informative References . . . . . . . . . . . . . . . . . . 14
   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
   Appendix E.  Stateless address autoconfiguration . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20
















Patil, et al.             Expires July 27, 2007                 [Page 3]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Introduction

   IPv6 packets can be carried over the IEEE Std 802.16 specified air
   interface via 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.

   The 802.16 [802.16] specification includes the Phy and MAC details.
   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
   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.  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.


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.





Patil, et al.             Expires July 27, 2007                 [Page 4]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


4.  IEEE 802.16 convergence sublayer support for IPv6

   The IEEE 802.16 MAC specifies two main service specific convergence
   sublayers:

   1.  ATM Convergence sublayer
   2.  Packet Convergence sublayer

   The Packet CS is used for the transport of packet based protocols
   which include:

   1.  IEEE Std 802.3(Ethernet)
   2.  IEEE Std 802.1Q(VLAN)
   3.  Internet Protocol (IPv4 and IPv6)

   The service specific CS resides on top of the MAC Common Part
   Sublayer (CPS).  The service specific CS is responsible for:

   o  accepting packets (PDUs) from the upper layer,
   o  performing classification of the packet/PDU based on a set of
      classifiers that are defined which are service specific,
   o  delivering the CS PDU to the appropriate service flow and
      transport connection and,
   o  receiving PDUs from the peer entity.

   Payload header suppression (PHS) is also a function of the CS but is
   optional.

   The figure below shows the concept of the service specific CS in
   relation to the MAC:




     -----------------------------\
     |  ATM CS     | Packet CS   | \
     -----------------------------  \
     |  MAC Common Part Sublayer |   \
     | (Ranging, scheduling, etc)|    802.16 MAC
     -----------------------------   /
     |        Security           |  /
     |(Auth, encryption,key mgmt)| /
     -----------------------------/
     |         PHY               |
     -----------------------------


                         Figure 1: The 802.16 MAC



Patil, et al.             Expires July 27, 2007                 [Page 5]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   Classifiers for each of the specific upper-layer protocols, i.e
   Ethernet, VLAN and IP, are defined which enable the packets from the
   upper layer to be processed by the appropriate service specific part
   of the packet CS.  IPv6 can be transported directly over the IP
   specific part of the packet CS or over 802.3/Ethernet (which in turn
   is handled by the Ethernet specific part of the packet CS) or over
   802.1Q (which is handled by the 802.1Q specific part of the packet
   CS).

   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

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



Patil, et al.             Expires July 27, 2007                 [Page 6]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   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.

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

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

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



Patil, et al.             Expires July 27, 2007                 [Page 7]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


                       Figure 3: IPv6 encapsulation

   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
   header field, Masked IP source and destination addresses and,
   Protocol source and destination port ranges.  Using the classifiers,
   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

   In a network that utilizes the 802.16 air interface the host/MS is
   attached to an IPv6 access router (AR) in the network.  The BS is a
   layer 2 entity only.  The AR can be an integral part of the BS or the
   AR could be an entity beyond the BS within the access network.  IPv6
   packets between the MS and BS are carried over a point-to-point
   transport connection which has a unique connection identifier (CID).
   The transport connection is a MAC layer link between the MS and the
   BS.  The figures below describe the possible network architectures
   and are generic in nature.  More esoteric architectures are possible
   but not considered in the scope of this document.  Option A:



           +-----+    CID1     +--------------+
           | MS1 |------------/|     BS/AR    |-----[Internet]
           +-----+           / +--------------+
              .         /---/
              .     CIDn
           +-----+    /
           | MSn |---/
           +-----+


            Figure 4: The IPv6 AR as an integral part of the BS

   Option B:







Patil, et al.             Expires July 27, 2007                 [Page 8]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


         +-----+   CID1    +-----+          +-----------+
         | MS1 |----------/| BS1 |----------|     AR    |-----[Internet]
         +-----+         / +-----+          +-----------+
            .           /        ____________
            .     CIDn /        ()__________()
         +-----+      /            L2 Tunnel
         | MSn |-----/
         +-----+


               Figure 5: The IPv6 AR is separate from the BS

   The above network models serve as examples and are shown to
   illustrate the point to point link between the MS and the AR.
   Appendix A shows a realization of the generic architecture by the
   WiMAX forum.


6.  IPv6 link

   RFC 2461 defines link as a communication facility or medium over
   which nodes can communicate at the link layer, i.e., the layer
   immediately below IP [RFC2461].  A link is bounded by routers that
   decrement the Hop limit field in the IPv6 header.  When an MS moves
   within a link, it can keep using its IP addresses.  This is a layer 3
   definition and note that the definition is not identical with the
   definition of the term '(L2) link' in IEEE 802 standards.

6.1.  IPv6 link in 802.16

   In 802.16, the Transport Connection between an MS and a BS is used to
   transport user data, i.e.  IPv6 packets in this case.  A Transport
   Connection is represented by a CID (Connection Identifier) and
   multiple Transport Connections can exist between an MS and BS.

   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.

   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,



Patil, et al.             Expires July 27, 2007                 [Page 9]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   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.

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.

   The MS goes through the network entry procedure as specified by
   802.16.  A high level description of the network entry procedure is
   as follows:

   1.  MS performs initial ranging with the BS.  Ranging is a process by
       which an MS becomes time aligned with the BS.  The MS is
       synchronized with the BS at the succesful completion of ranging
       and is ready to setup a connection.
   2.  MS and BS perform capability exchange as per 802.16 procedures.
       The CS capability parameter indicates which classification/PHS
       options and SDU encapsulation the MS supports.  By default,
       Packet, IPv4 and 802.3/Ethernet shall be supported, thus absence
       of this parameter in REG-REQ (802.16 message) means that named
       options are supported by the MS/SS.  Support for IPv6 over the IP
       specific part of the packet CS is indicated by Bit#2 of the CS
       capability parameter (Refer to [802.16]).
   3.  The MS progresses to an authentication phase.  Authentication is
       based on PKMv2 as defined in the IEEE Std 802.16 specification.
   4.  On succesful completion of authentication, the MS performs 802.16
       registration with the network.
   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.
   6.  The AR sends a router advertisement to the MS.  Alternatively or
       in addition, the MS can also send a router solicitation.

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







Patil, et al.             Expires July 27, 2007                [Page 10]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


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


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.


8.  Router Discovery

8.1.  Router Solicitation

   On completion of the establishment of the IPv6 link, the MS may send
   a router solicitation message to solicit a Router Advertisement
   message from the AR to acquire necessary information as per RFC2461.
   An MS that is network attached may also send router solicitations at
   any time as per RFC2461.  Movement detection at the IP layer of an MS
   in many cases is based on receiving periodic router advertisements.
   An MS may also detect changes in its attachment via link triggers or
   other means.  The MS can act on such triggers by sending router
   solicitations.  The router solicitation is sent over the IPv6 link
   that has been previously established.  The MS sends router
   solicitations to the all-routers multicast address.  It is carried
   over the point-to-point link to the AR via the BS.  The MS does not
   need to be aware of the link-local address of the AR in order to send
   a router solicitation at any time.



Patil, et al.             Expires July 27, 2007                [Page 11]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


8.2.  Router Advertisement

   The AR should send a number (configurable value) of router
   advertisements as soon as the IPv6 link is established, to the MS.
   The AR sends unsolicited router advertisements periodically as per
   RFC2461.  The interval between periodic router advertisements is
   however greater than the specification in RFC2461 and is discussed in
   the following section.

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.


9.  IPv6 addressing for hosts

   The addressing scheme for IPv6 hosts in 802.16 network follows the
   IETFs recommendation for hosts specified in RFC 4294.  The IPv6 node
   requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are
   applicable for addressing and the same is applicable for hosts that
   use 802.16 as the link layer for transporting IPv6 packets.

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.





Patil, et al.             Expires July 27, 2007                [Page 12]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


9.2.  Duplicate address detection

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

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


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


12.  Acknowledgments

   The authors would like to acknowledge the contributions of the 16NG
   working group chairs Soohong Daniel Park and Gabriel Montenegro as
   well as Jari Arkko, Jonne Soininen, Max Riegel, Prakash Iyer, DJ
   Johnston, Dave Thaler, Bruno Sousa and Alexandru Petrescu for their
   review and comments.


13.  References







Patil, et al.             Expires July 27, 2007                [Page 13]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement  Levels", RFC 2119, March 1997,
              <ftp://ftp.isi.edu/in-notes/rfc2119>.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998,
              <ftp://ftp.isi.edu/in-notes/rfc2462>.

   [RFC4291]  Hinden, R. and S.  Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February  2006,
              <ftp://ftp.isi.edu/in-notes/rfc4291>.

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

   [PSDOC]    Jee, J., Madanapalli, S., Montenegro, G., Riegel, M.,
              Mandin, J., and S. Park, "IP over 802.16 Problem Statement
              and Goals", October 2006, <http://www.ietf.org/
              internet-drafts/draft-ietf-16ng-ps-goals-00.txt>.

   [RFC3041]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", August 2006, <http://www.ietf.org/internet-drafts/
              draft-ietf-ipv6-privacy-addrs-v2-05.txt>.

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

   [RFC4294]  Loughney, Ed., J., "IPv6 Node requirements", RFC 4294,
              April 2006, <ftp://ftp.isi.edu/in-notes/rfc4294>.

   [WMF]      "http://www.wimaxforum.org".

   [WiMAXArch]
              "WiMAX End-to-End Network Systems Architecture
              http://www.wimaxforum.org/technology/documents",



Patil, et al.             Expires July 27, 2007                [Page 14]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


              August 2006.


Appendix A.  WiMAX network architecture and IPv6 support

   The WiMAX network architecture consists of the Access Service Network
   (ASN) and the Connectivity Service Network (CSN).  The ASN is the
   access network which includes the BS and the AR in addition to other
   functions such as AAA, Mobile IP Foreign agent, Paging controller,
   Location Register etc.  The CSN is the entity that provides
   connectivity to the Internet and includes functions such as Mobile IP
   Home agent and AAA.  The figure below shows the WiMAX reference
   model:



                        -------------------
                        | ----      ASN   |                    |----|
         ----           | |BS|\ R6 -------|    |---------|     | CSN|
         |MS|-----R1----| ---- \---|ASN-GW| R3 |  CSN    | R5  |    |
         ----           |  |R8  /--|------|----|         |-----|Home|
                        | ---- /          |    |  visited|     | NSP|
                        | |BS|/           |    |   NSP   |     |    |
                        | ----            |    |---------|     |    |
                        |       NAP       |         \          |----|
                        -------------------          \---|        /
                                |                        |       /
                                |                     (--|------/----)
                                |R4                  (                )
                                |                   (      ASP network )
                            ---------                ( or Internet    )
                            |  ASN  |                 (              )
                            ---------                   (----------)



                  Figure 6: WiMAX Network reference model

   Three different types of ASN realizations called profiles are defined
   by the architecture.  ASNs of profile types A and C include BS' and
   ASN-gateway(s) (ASN-GW) which are connected to each other via an R6
   interface.  An ASN of profile type B is one in which the
   functionality of the BS and other ASN functions are merged together.
   No ASN-GW is specifically defined in a profile B ASN.  The absence of
   the R6 interface is also a profile B specific characteristic.  The MS
   at the IPv6 layer is associated with the AR in the ASN.  The AR may
   be a function of the ASN-GW in the case of profiles A and C and is a
   function in the ASN in the case of profile B. When the BS and the AR



Patil, et al.             Expires July 27, 2007                [Page 15]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   are separate entities and linked via the R6 interface, IPv6 packets
   between the BS and the AR are carried over a GRE tunnel.  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).  The protocol
   stack in WiMAX for IPv6 is shown below:


   |-------|
   | App   |- - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
   |       |
   |-------|                                   /------      -------
   |       |                                  / IPv6 |      |     |
   | IPv6  |- - - - - - - - - - - - - - - -  /       |      |     |-->
   |       |      ---------------    -------/        |      | IPv6|
   |-------|      |    \Relay/  |    |      |        |- - - |     |
   |       |      |     \   /   |    | GRE  |        |      |     |
   |       |      |      \ /GRE | -  |      |        |      |     |
   |       |- - - |       |-----|    |------|        |      |     |
   | IPv6CS|      |IPv6CS | IP  | -  | IP   |        |      |     |
   | ..... |      |...... |-----|    |------|--------|      |-----|
   |  MAC  |      | MAC   | L2  | -  | L2   |  L2    |- - - | L2  |
   |-------|      |------ |-----|    |----- |--------|      |-----|
   |  PHY  |- - - | PHY   | L1  | -  | L1   |  L1    |- - - | L1  |
    --------      ---------------    -----------------      -------

      MS             BS                   AR/ASN-GW          CSN Rtr



                      Figure 7: WiMAX protocol stack

   As can be seen from the protocol stack description, the IPv6 end-
   points are constituted in the MS and the AR.  The BS provides lower
   layer connectivity for the IPv6 link.


Appendix B.  IPv6 link in WiMAX

   WiMAX is an example of a network based on the IEEE Std 802.16 air
   interface.  This section describes the IPv6 link in the context of a
   WiMAX network.  The MS and the AR are connected via a combination of
   :

   1.  The transport connection which is identified by a Connection
       Identifier (CID) over the air interface, i.e the MS and BS and,





Patil, et al.             Expires July 27, 2007                [Page 16]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   2.  A GRE tunnel between the BS and AR which transports the IPv6
       packets

   From an IPv6 perspective the MS and the AR are connected by a point-
   to-point link.  The combination of transport connection over the air
   interface and the GRE tunnel between the BS and AR creates a (point-
   to-point) tunnel at the layer below IPv6.

   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.  No two MSs belong to the same 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].


Appendix C.  IPv6 link establishment in WiMAX

   The mobile station performs initial network entry as specified in
   802.16.  On succesful completion of the network entry procedure the
   ASN gateway/AR triggers the establishment of the initial service flow
   (ISF) for IPv6 towards the MS.  The ISF is a GRE tunnel between the
   ASN-GW/AR and the BS.  The BS in turn requests the MS to establish a
   transport connection over the air interface.  The end result is a
   transport connection over the air interface for carrying IPv6 packets
   and a GRE tunnel between the BS and AR for relaying the IPv6 packets.
   On succesful completion of the establishment of the ISF, IPv6 packets
   can be sent and received between the MS and AR.  The ISF enables the
   MS to communicate with the AR for host configuration procedures.
   After the establishment of the ISF, the AR can send a router
   advertisement to the MS.  An MS can establish multiple service flows
   with different QoS characteristics.  The ISF can be considered as the
   primary service flow.  The ASN-GW/ AR treats each ISF, along with the
   other service flows to the same MS, as a unique link which is managed
   as a (virtual) interface.


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.



Patil, et al.             Expires July 27, 2007                [Page 17]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


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.


Authors' Addresses

   Basavaraj Patil
   Nokia
   6000 Connection Drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nokia.com


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Email: sarikaya@ieee.org


   JinHyeock Choi
   Samsung AIT
   Networking Technology Lab
   P.O.Box 111
   Suwon, Korea  440-600

   Email: jinchoe@samsung.com









Patil, et al.             Expires July 27, 2007                [Page 18]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


   Syam Madanapalli
   LogicaCMG
   125 Yemlur P.O.
   Off Airport Road
   Bangalore, India  560037

   Email: smadanapalli@gmail.com












































Patil, et al.             Expires July 27, 2007                [Page 19]

Internet-Draft        IPv6 over Packet CS in 802.16         January 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Patil, et al.             Expires July 27, 2007                [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/