doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc5121.txt b/doc/rfc/rfc5121.txt
new file mode 100644
index 0000000..91a8974
--- /dev/null
+++ b/doc/rfc/rfc5121.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                           B. Patil
+Request for Comments: 5121                        Nokia Siemens Networks
+Category: Standards Track                                         F. Xia
+                                                             B. Sarikaya
+                                                              Huawei USA
+                                                                JH. Choi
+                                                             Samsung AIT
+                                                          S. Madanapalli
+                                                      Ordyn Technologies
+                                                           February 2008
+
+
+         Transmission of IPv6 via the IPv6 Convergence Sublayer
+                       over IEEE 802.16 Networks
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   IEEE Std 802.16 is an air interface specification for fixed and
+   mobile Broadband Wireless Access Systems.  Service-specific
+   convergence sublayers to which upper-layer protocols interface are a
+   part of the IEEE 802.16 MAC (Medium Access Control).  The Packet
+   convergence sublayer (CS) is used for the transport of all packet-
+   based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN
+   CSMA/CD Access Method (Ethernet).  IPv6 packets can be sent and
+   received via the IP-specific part of the Packet CS.  This document
+   specifies the addressing and operation of IPv6 over the IP-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 interface identifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                     [Page 1]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
+   4.  IEEE 802.16 Convergence Sublayer Support for IPv6  . . . . . .  4
+     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 . . . . . . . . . . . . . . . . . . . . 12
+   8.  Router Discovery . . . . . . . . . . . . . . . . . . . . . . . 12
+     8.1.  Router Solicitation  . . . . . . . . . . . . . . . . . . . 12
+     8.2.  Router Advertisement . . . . . . . . . . . . . . . . . . . 12
+     8.3.  Router Lifetime and Periodic Router Advertisements . . . . 13
+   9.  IPv6 Addressing for Hosts  . . . . . . . . . . . . . . . . . . 13
+     9.1.  Interface Identifier . . . . . . . . . . . . . . . . . . . 13
+     9.2.  Duplicate Address Detection  . . . . . . . . . . . . . . . 13
+     9.3.  Stateless Address Autoconfiguration  . . . . . . . . . . . 14
+     9.4.  Stateful Address Autoconfiguration . . . . . . . . . . . . 14
+   10. Multicast Listener Discovery . . . . . . . . . . . . . . . . . 14
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
+   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
+   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+     13.2. Informative References . . . . . . . . . . . . . . . . . . 16
+   Appendix A.  WiMAX Network Architecture and IPv6 Support . . . . . 17
+   Appendix B.  IPv6 Link in WiMAX  . . . . . . . . . . . . . . . . . 19
+   Appendix C.  IPv6 Link Establishment in WiMAX  . . . . . . . . . . 19
+   Appendix D.  Maximum Transmission Unit in WiMAX  . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                     [Page 2]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+1.  Introduction
+
+   IEEE 802.16e is an air interface for fixed and mobile broadband
+   wireless access systems.  The IEEE 802.16 [802.16] standard specifies
+   the air interface, including the Medium Access Control (MAC) layer
+   and multiple physical layer (PHY) specifications.  It can be deployed
+   in licensed as well as unlicensed spectrum.  While the PHY and MAC
+   are specified in IEEE 802.16, the details of IPv4 and IPv6 operation
+   over the air interface are not included.  This document specifies the
+   operation of IPv6 over the IEEE 802.16 air interface.
+
+   IPv6 packets can be carried over the IEEE Std 802.16 specified air
+   interface via:
+
+   1.  the IP-specific part of the Packet CS or
+
+   2.  the 802.3[802.3]-specific part of the Packet CS
+
+   The scope of this specification is limited to the operation of IPv6
+   over IP CS only.
+
+   The IEEE 802.16 specification includes the PHY and MAC details.  The
+   convergence sublayers are a part of the MAC.  The packet convergence
+   sublayer includes the IP-specific part that is used by the IPv6
+   layer.
+
+   The mobile station (MS)/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 that 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
+   access router (AR)) and relays the IPv6 packets between the AR and
+   the host via a point-to-point connection over the air interface.
+
+2.  Terminology
+
+   The terminology in this document is based on the definitions in "IP
+   over 802.16 Problem Statement and Goals" [PS-GOALS].
+
+   o  IP CS - The IP-specific part of the Packet convergence sublayer is
+      referred to as IP CS.  IPv6 CS and IP CS are used interchangeably.
+
+   o  Subscriber station (SS), Mobile Station (MS), Mobile Node (MN) -
+      The terms subscriber station, mobile station, and mobile node are
+      used interchangeably in this document and mean the same, i.e., an
+      IP host.
+
+
+
+
+Patil, et al.               Standards Track                     [Page 3]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+3.  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].
+
+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.  Internet Protocol (IPv4 and IPv6)
+
+   The service-specific CS resides on top of the MAC Common Part
+   Sublayer (CPS) as shown in Figure 1.  The service-specific CS is
+   responsible for:
+
+   o  accepting packets (Protocol Data Units, PDUs) from the upper
+      layer,
+
+   o  performing classification of the packet/PDU based on a set of
+      defined classifiers that 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:
+
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                     [Page 4]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+     ------------------------------\
+     |  ATM CS     | Packet CS    | \
+     ------------------------------  \
+     |  MAC Common Part Sublayer  |   \
+     | (Ranging, scheduling, etc.)|    802.16 MAC
+     ------------------------------   /
+     |        Security            |  /
+     |(Auth, encryption, key mgmt)| /
+     ------------------------------/
+     |            PHY             |
+     ------------------------------
+
+                         Figure 1: IEEE 802.16 MAC
+
+   Classifiers for each of the specific upper-layer protocols, i.e.,
+   Ethernet and IP, are defined in the IEEE 802.16 specification, 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 (IP
+   CS).  IPv4 packets also are transported over the IP-specific part of
+   the Packet CS.  The classifiers used by IP CS enable the
+   differentiation of IPv4 and IPv6 packets and their mapping to
+   specific transport connections over the air interface.
+
+   The figure below shows the options for IPv6 transport over the packet
+   CS of IEEE 802.16:
+
+                                      +-------------------+
+                                      |    IPv6           |
+         +-------------------+        +-------------------+
+         |    IPv6           |        |    Ethernet       |
+         +-------------------+        +-------------------+
+         |  IP-specific      |        |  802.3-specific   |
+         | part of Packet CS |        | part of Packet CS |
+         |...................|        |...................|
+         |    MAC            |        |    MAC            |
+         +-------------------+        +-------------------+
+         |    PHY            |        |    PHY            |
+         +-------------------+        +-------------------+
+
+         (1) IPv6 over                (2) IPv6 over
+             IP-specific part             802.3/Ethernet-
+             of Packet CS                 specific part
+                                          of Packet CS
+
+     Figure 2: IPv6 over IP- and 802.3-specific parts of the Packet CS
+
+
+
+
+
+Patil, et al.               Standards Track                     [Page 5]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   The figure above shows that while there are multiple methods by which
+   IPv6 can be transmitted over an 802.16 air interface, the scope of
+   this document is limited to IPv6 operation over IP CS only.
+   Transmission of IP over Ethernet is specified in [IPoE-over-802.16].
+   Transmission of IPv4 over IP CS is specified in [IPv4-over-IPCS].
+
+   It should be noted that immediately after ranging (802.16 air
+   interface procedure) and exchange of SBC-REQ/RSP messages (802.16
+   specific), the MS and BS exchange their capabilities via REG-REQ
+   (Registration Request) and REG-RSP (Registration Response) 802.16 MAC
+   messages.  These management frames negotiate parameters such as the
+   Convergence Sublayer supported by the MS and BS.  By default, Packet,
+   IPv4, and 802.3/Ethernet are supported.  IPv6 via the IP CS is
+   supported by the MS and the BS only when the IPv6 support bit in the
+   capability negotiation messages (REG-REQ and REG-RSP) implying such
+   support is indicated in the parameter "Classification/PHS options and
+   SDU (Service Data Unit) encapsulation support" (refer to [802.16]).
+   Additionally, during the establishment of the transport connection
+   for transporting IPv6 packets, the DSA-REQ (Dynamic Service Addition)
+   and DSA-RSP messages between the BS and MS indicate via the CS-
+   Specification TLV the CS that the connection being set up shall use.
+   When the IPv6 packet is preceded by the IEEE 802.16 6-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.  Based on the classification rules, the
+   MAC layer selects an appropriate transport connection for the
+   transmission of the packet.  An IPv6 packet is transported over a
+   transport connection that is specifically established for carrying
+   such packets.
+
+   Transmission of IPv6 as explained above is possible via multiple
+   methods, i.e., via IP CS or via Ethernet interfaces.  Every Internet
+   host connected via an 802.16 link:
+
+   1.  MUST be able to send and receive IPv6 packets via IP CS when the
+       MS and BS indicate IPv6 protocol support over IP CS
+
+   2.  MUST be able to send and receive IPv6 packets over the Ethernet
+       (802.3)-specific part of the Packet CS when the MS and BS
+       indicate IPv6 protocol support over Ethernet CS.  However, when
+       the MS and BS indicate IPv6 protocol support over both IP CS and
+       Ethernet CS, the MS and BS MUST use IP CS for sending and
+       receiving IPv6 packets.
+
+   When the MS and BS support IPv6 over IP CS, it MUST be used as the
+   default mode for transporting IPv6 packets over IEEE 802.16 and the
+   recommendations in this document that are followed.  Inability to
+   negotiate a common convergence sublayer for IPv6 transport between
+
+
+
+Patil, et al.               Standards Track                     [Page 6]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   the MS and BS will result in failure to set up the transport
+   connection and thereby render the host unable to send and receive
+   IPv6 packets.  In the case of a host that implements more than one
+   method of transporting IPv6 packets, the default choice of which
+   method to use (i.e., IPv6 over the IP CS or IPv6 over 802.3) is IPv6
+   over IP CS when the BS also supports such capability.
+
+   In any case, the MS and BS MUST negotiate at most one convergence
+   sublayer for IPv6 transport on a given link.
+
+   In addition, to ensure interoperability between devices that support
+   different encapsulations, it is REQUIRED that BS implementations
+   support all standards-track encapsulations defined for 802.16 by the
+   IETF.  At the time of writing this specification, this is the only
+   encapsulation, but additional specifications are being worked on.  It
+   is, however, not required that the BS implementations use all the
+   encapsulations they support; some modes of operation may be off by
+   configuration.
+
+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 IEEE 802.16 generic MAC header.  The
+   format of the IPv6 packet encapsulated by the generic MAC header is
+   shown in the figure below.  The format of the 6-byte MAC header is
+   described in the [802.16] specification.  The CRC (cyclic redundancy
+   check) is optional.  It should be noted that the actual MAC address
+   is not included in the MAC header.
+
+             ---------/ /-----------
+             |    MAC SDU          |
+             --------/ /------------
+                     ||
+                     ||
+      MSB            \/                                    LSB
+      ---------------------------------------------------------
+      | Generic MAC header|  IPv6 Payload              | CRC  |
+      ---------------------------------------------------------
+
+                       Figure 3: IPv6 encapsulation
+
+   For transmission of IPv6 packets via the IP CS over IEEE 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 IEEE 802.16 MAC.
+   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,
+
+
+
+Patil, et al.               Standards Track                     [Page 7]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   Masked IP source and destination addresses, and Protocol source and
+   destination port ranges.  Next header in this case refers to the last
+   header of the IP header chain.  Parsing these 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 (MAC SDU) and transmits it.  The figure below shows
+   the operation on the downlink, i.e., the transmission from the BS to
+   the host.  The reverse is applicable for the uplink transmission.
+
+     -----------                               ----------
+     | IPv6 Pkt|                               |IPv6 Pkt|
+     -----------                               ----------
+        | |                                      /|\
+        | |                                       |
+     --[SAP]---------------------       ---------[SAP]--------
+     ||-| |----------|          |       |        /|\         |
+     || \ /        0---->[CID1] |       |     --- |--------  |
+     || Downlink   0\/-->[CID2] |       |     |Reconstruct|  |
+     || classifiers0/\-->[....] |       |     | (undo PHS)|  |
+     ||            0---->[CIDn] |       |     ---   -------  |
+     ||--------------|          |       |        /|\         |
+     |                          |       |         |          |
+     |  {SDU, CID,..}           |       |    {SDU, CID,..}   |
+     |       |                  |       |        /|\         |
+     |       v                  |       |         |          |
+     ------[SAP]-----------------       |-------[SAP]---------
+     |     802.16 MAC CPS       |------>|   802.16 MAC CPS   |
+     ----------------------------       ----------------------
+              BS                                  MS
+
+               Figure 4: IPv6 packet transmission: Downlink
+
+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.  An AR
+   may be attached to multiple BSs in a network.  IPv6 packets between
+   the MS and BS are carried over a point-to-point transport connection
+   which is identified by 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.
+
+
+
+
+
+
+Patil, et al.               Standards Track                     [Page 8]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   Option A:
+
+           +-----+    CID1     +--------------+
+           | MS1 |------------/|     BS/AR    |-----[Internet]
+           +-----+           / +--------------+
+              .         /---/
+              .     CIDn
+           +-----+    /
+           | MSn |---/
+           +-----+
+
+              Figure 5: IPv6 AR as an integral part of the BS
+
+   Option B:
+
+         +-----+   CID1    +-----+          +-----------+
+         | MS1 |----------/| BS1 |----------|     AR    |-----[Internet]
+         +-----+         / +-----+          +-----------+
+            .           /        ____________
+            .     CIDn /        ()__________()
+         +-----+      /            L2 Tunnel
+         | MSn |-----/
+         +-----+
+
+                 Figure 6: 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.
+
+6.  IPv6 Link
+
+   "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861] defines link
+   as a communication facility or medium over which nodes can
+   communicate at the link layer, i.e., the layer immediately below IP.
+   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, and multiple transport
+   connections can exist between an MS and a BS.
+
+
+
+
+
+Patil, et al.               Standards Track                     [Page 9]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   When an AR and a BS are colocated, 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 be established
+   between the AR and a BS whose granularity 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 that uses the same higher-layer protocol 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 neighbor
+   discovery for IPv6 [RFC4861].  Hence, the point-to-point link model
+   for IPv6 operation over the IP-specific part of the Packet CS in
+   802.16 SHOULD be used.  A unique IPv6 prefix(es) per link (MS/host)
+   MUST be assigned.
+
+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.  The 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 successful completion of
+       ranging and is ready to set up a connection.
+
+   2.  The MS and BS exchange basic capabilities that are necessary for
+       effective communication during the initialization using SBC-REQ/
+       RSP (802.16 specific) messages.
+
+   3.  The MS progresses to an authentication phase.  Authentication is
+       based on Privacy Key Management version 2 (PKMv2) as defined in
+       the IEEE Std 802.16 specification.
+
+   4.  On successful completion of authentication, the MS performs
+       802.16 registration with the network.
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 10]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   5.  The MS and BS perform capability exchange as per 802.16
+       procedures.  Protocol support is indicated in this exchange.  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]).
+
+   6.  The MS MUST request the establishment of a service flow for IPv6
+       packets over IP CS if the MS and BS have confirmed capability for
+       supporting IPv6 over IP CS.  The service flow MAY 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.
+
+   7.  The AR and MS SHOULD send router advertisements and solicitations
+       as specified in neighbor discovery [RFC4861].
+
+   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 MTU value for IPv6 packets on an 802.16 link is configurable.
+   The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500
+   octets.
+
+   The 802.16 MAC PDU is composed of 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 header.  The Len parameter has a size of 11 bits.
+   Hence, the total MAC PDU size is 2048 bytes.  The IPv6 payload size
+   can vary.  In certain deployment scenarios, the MTU value can be
+   greater than the default.  Neighbor discovery for IPv6 [RFC4861]
+   defines an MTU option that an AR MUST advertise, via router
+   advertisement (RA), if a value different from 1500 is used.  The MN
+   processes this option as defined in [RFC4861].  Nodes that implement
+   Path MTU Discovery [RFC1981] MAY use the mechanism to determine the
+   MTU for the IPv6 packets.
+
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 11]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+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 that
+   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 [RFC4861].  The size and number of the prefixes are a
+   configuration issue.  Also, Dynamic Host Configuration Protocol
+   (DHCP) or Authentication, Authorization, and Accounting (AAA)-based
+   prefix delegation MAY be used to provide one or more prefixes to MS
+   for an AR connected over 802.16.  The other properties of the
+   prefixes are also dealt with 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 the
+   neighbor discovery for IPv6 specification [RFC4861].  An MS that is
+   network attached may also send router solicitations at any time.
+   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.
+   The use of router advertisements as a means for movement detection is
+   not recommended for MNs connected via 802.16 links as the frequency
+   of periodic router advertisements would have to be high.
+
+8.2.  Router Advertisement
+
+   The AR SHOULD send a number (configurable value) of router
+   advertisements to the MS as soon as the IPv6 link is established.
+   The AR sends unsolicited router advertisements periodically as per
+   [RFC4861].  The interval between periodic router advertisements is
+   however greater than the specification in neighbor discovery for
+   IPv6, and is discussed in the following section.
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 12]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+8.3.  Router Lifetime and Periodic Router Advertisements
+
+   The router lifetime SHOULD be set to a large value, preferably in
+   hours.  This document overrides the specification for the value of
+   the router lifetime in "Neighbor Discovery for IP Version 6 (IPv6)"
+   [RFC4861].  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 that 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 overrides the
+   recommendation in "Neighbor Discovery for IP Version 6
+   (IPv6)"[RFC4861].  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 networks follows the
+   IETF's recommendation for hosts specified in "IPv6 Node Requirements"
+   [RFC4294].  The IPv6 node requirements [RFC4294] specify 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 globally unique MAC address as specified in
+   802.16 [802.16].  This MAC address MUST be used to generate the
+   modified EUI-64 format-based interface identifier as specified in "IP
+   Version 6 Addressing Architecture" [RFC4291].  The modified EUI-64
+   interface identifier is used in stateless address autoconfiguration.
+   As in other links that support IPv6, EUI-64-based interface
+   identifiers are not mandatory and other mechanisms, such as random
+   interface identifiers, "Privacy Extensions for Stateless Address
+   Autoconfiguration in IPv6" [RFC4941], MAY also be used.
+
+9.2.  Duplicate Address Detection
+
+   DAD SHOULD be performed as per "Neighbor Discovery for IP Version 6
+   (IPv6)", [RFC4861] and "IPv6 Stateless Address Autoconfiguration"
+   [RFC4862].  The IPv6 link over 802.16 is specified in this document
+   as a point-to-point link.  Based on this criteria, it may be
+
+
+
+Patil, et al.               Standards Track                    [Page 13]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   redundant to perform DAD on a global unicast address that is
+   configured using the EUI-64 or generated as per RFC 4941 [RFC4941]
+   for the interface as part of the IPv6 Stateless Address
+   Autoconfiguration Protocol [RFC4862] as long as the following two
+   conditions are met:
+
+   1.  The prefixes advertised through the router advertisement messages
+       by the access router terminating the 802.16 IPv6 link are unique
+       to that link.
+
+   2.  The access router terminating the 802.16 IPv6 link does not
+       autoconfigure any IPv6 global unicast addresses from the prefix
+       that it advertises.
+
+9.3.  Stateless Address Autoconfiguration
+
+   When stateless address autoconfiguration is performed, it MUST be
+   performed as specified in [RFC4861] and [RFC4862].
+
+9.4.  Stateful Address Autoconfiguration
+
+   When stateful address autoconfiguration is performed, it MUST be
+   performed as specified in [RFC4861] and [RFC3315].
+
+10.  Multicast Listener Discovery
+
+   "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
+   SHOULD be supported as specified by the hosts and routers attached to
+   each other via an 802.16 link.  The access router that has hosts
+   attached to it via a point-to-point link over an 802.16 SHOULD NOT
+   send periodic queries if the host is in idle/dormant mode.  The AR
+   can obtain information about the state of a host from the paging
+   controller in the network.
+
+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].  It should be noted that 802.16
+   provides capability to cipher the traffic carried over the transport
+   connections.  A traffic encryption key (TEK) is generated by the MS
+   and BS on completion of successful authentication and is used to
+   secure the traffic over the air interface.  An MS may still use IPv6
+   security mechanisms even in the presence of security over the 802.16
+   link.  In addition, the security issues of the network architecture
+   spanning beyond the 802.16 base stations are the subject of the
+   documents defining such architectures, such as WiMAX Network
+   Architecture [WiMAXArch] in Sections 7.2 and 7.3 of Stage 2, Part 2.
+
+
+
+Patil, et al.               Standards Track                    [Page 14]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+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, Alexandru Petrescu, Margaret
+   Wasserman, and Pekka Savola for their review and comments.  Review
+   and comments by Phil Barber have also helped in improving the
+   document quality.
+
+13.  References
+
+13.1.  Normative 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, <http://standards.ieee.org/
+                       getieee802/download/802.16e-2005.pdf>.
+
+   [RFC1981]           McCann, J., Deering, S., and J. Mogul, "Path MTU
+                       Discovery for IP version 6", RFC 1981,
+                       August 1996.
+
+   [RFC2119]           Bradner, S., "Key words for use in RFCs to
+                       Indicate Requirement Levels", BCP 14, RFC 2119,
+                       March 1997.
+
+   [RFC3810]           Vida, R. and L. Costa, "Multicast Listener
+                       Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
+                       June 2004.
+
+   [RFC4291]           Hinden, R. and S. Deering, "IP Version 6
+                       Addressing Architecture", RFC 4291,
+                       February 2006.
+
+   [RFC4861]           Narten, T., Nordmark, E., Simpson, W., and H.
+                       Soliman, "Neighbor Discovery for IP version 6
+                       (IPv6)", RFC 4861, September 2007.
+
+   [RFC4862]           Thomson, S., Narten, T., and T. Jinmei, "IPv6
+                       Stateless Address Autoconfiguration", RFC 4862,
+                       September 2007.
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 15]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+13.2.  Informative References
+
+   [802.3]             "IEEE Std 802.3-2005: IEEE Standard for
+                       Information technology-Telecommunications and
+                       information exchange between systems-Local and
+                       metropolitan area networks--Specific requirements
+                       Part 3: Carrier Sense Multiple Access with
+                       Collision Detection (CSMA/CD) Access Method and
+                       Physical Layer Specifications", December 2005,
+                       <http://standards.ieee.org/getieee802/
+                       802.3.html>.
+
+   [IPoE-over-802.16]  Jeon, H., Riegel, M., and S. Jeong, "Transmission
+                       of IP over Ethernet over IEEE 802.16 Networks",
+                       Work in Progress, January 2008.
+
+   [IPv4-over-IPCS]    Madanapalli, S., Park, S., and S. Chakrabarti,
+                       "Transmission of IPv4 packets over IEEE 802.16's
+                       IP Convergence Sublayer", Work in Progress,
+                       November 2007.
+
+   [PS-GOALS]          Jee, J., Madanapalli, S., and J. Mandin, "IP over
+                       802.16 Problem Statement and Goals", Work
+                       in Progress, December 2007.
+
+   [RFC3315]           Droms, R., Bound, J., Volz, B., Lemon, T.,
+                       Perkins, C., and M. Carney, "Dynamic Host
+                       Configuration Protocol for IPv6 (DHCPv6)",
+                       RFC 3315, July 2003.
+
+   [RFC4294]           Loughney, J., "IPv6 Node Requirements", RFC 4294,
+                       April 2006.
+
+   [RFC4941]           Narten, T., Draves, R., and S. Krishnan, "Privacy
+                       Extensions for Stateless Address
+                       Autoconfiguration in IPv6", RFC 4941,
+                       September 2007.
+
+   [WMF]               "WiMAX Forum", <http://www.wimaxforum.org>.
+
+   [WiMAXArch]         "WiMAX End-to-End Network Systems Architecture",
+                       September 2007.
+
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 16]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+Appendix A.  WiMAX Network Architecture and IPv6 Support
+
+   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 are applicable to the WiMAX
+   network as well.
+
+   WiMAX is an example architecture of a network that uses the 802.16
+   specification for the air interface.  WiMAX networks are also in the
+   process of being deployed in various parts of the world, and the
+   operation of IPv6 within a WiMAX network is explained in this
+   appendix.
+
+   The WiMAX network architecture consists of the Access Service Network
+   (ASN) and the Connectivity Service Network (CSN).  The ASN is the
+   access network that includes the BS and the AR in addition to other
+   functions such as AAA, mobile IP foreign agent, paging controller,
+   location register, etc.  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.  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 7: WiMAX network reference model
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 17]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+   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
+   are separate entities and linked via the R6 interface, IPv6 packets
+   between the BS and the AR are carried over a Generic Routing
+   Encapsulation (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 is 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 8: 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.
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 18]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+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 that is identified by a Connection
+       Identifier (CID) over the air interface, i.e., the MS and BS, and
+
+   2.  A GRE tunnel between the BS and AR that 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 [RFC4861].
+
+Appendix C.  IPv6 Link Establishment in WiMAX
+
+   The mobile station performs initial network entry as specified in
+   802.16.  On successful 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 successful 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 quality of service (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 that is managed as a (virtual) interface.
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 19]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+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 MTU for IPv6 be set to 1400 octets in WiMAX
+   networks, and this value (different from the default) be communicated
+   to the MS.  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.               Standards Track                    [Page 20]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+Authors' Addresses
+
+   Basavaraj Patil
+   Nokia Siemens Networks
+   6000 Connection Drive
+   Irving, TX  75039
+   USA
+
+   EMail: basavaraj.patil@nsn.com
+
+
+   Frank Xia
+   Huawei USA
+   1700 Alma Dr. Suite 500
+   Plano, TX  75075
+   USA
+
+   EMail: xiayangsong@huawei.com
+
+
+   Behcet Sarikaya
+   Huawei USA
+   1700 Alma Dr. Suite 500
+   Plano, TX  75075
+   USA
+
+   EMail: sarikaya@ieee.org
+
+
+   JinHyeock Choi
+   Samsung AIT
+   Networking Technology Lab
+   P.O.Box 111
+   Suwon, Korea  440-600
+
+   EMail: jinchoe@samsung.com
+
+
+   Syam Madanapalli
+   Ordyn Technologies
+   1st Floor, Creator Building, ITPL.
+   Off Airport Road
+   Bangalore, India  560066
+
+   EMail: smadanapalli@gmail.com
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 21]
+
+RFC 5121           IPv6 via IPv6 CS over IEEE 802.16       February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Patil, et al.               Standards Track                    [Page 22]
+