<?xml version='1.0'?> 

<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?> 

<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ 


<!ENTITY rfc4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>

<!ENTITY rfc4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>

<!ENTITY rfc4779 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4779.xml'>

<!ENTITY rfc4968 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4968.xml'>

<!ENTITY rfc4942 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4942.xml'>

<!ENTITY rfc2740 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2740.xml'>

<!ENTITY rfc3314 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3314.xml'>

<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>

<!ENTITY rfc2464 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml'>

<!ENTITY rfc4605 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4605.xml'>

<!ENTITY rfc4541 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4541.xml'>

<!ENTITY rfc4068 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4068.xml'>


] >

<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>

<rfc number="5181" category="info">

<front>

<title abbrev="IPv6 over IEEE 802.16 Scenarios">
IPv6 Deployment Scenarios in 802.16 Networks 
</title>

<author initials="M-K." surname="Shin, Ed." fullname="Myung-Ki Shin">
<organization>ETRI</organization>
<address>
<postal>
<street> 161 Gajeong-dong Yuseng-gu</street>
<city>Daejeon, 305-350</city>
<country>Korea</country>
</postal>
<phone> +82 42 860 4847</phone> 
<email>myungki.shin@gmail.com</email>
</address>
</author>

<author initials="Y-H." surname="Han" fullname="Youn-Hee Han">
<organization>KUT</organization>
<address>
<postal>
<street> Gajeon-Ri 307 Byeongcheon-Myeon
</street>
<city> Cheonan-Si Chungnam Province, 330-708</city>
<country>Korea</country>
</postal>
<email>yhhan@kut.ac.kr</email>
</address>
</author>

<author initials="S-E." surname="Kim" fullname="Sang-Eon Kim">
<organization> KT </organization>
<address>
<postal>
<street> 17 Woomyeon-dong, Seocho-gu
</street>
<city> Seoul, 137-791  </city>
<country>Korea</country>
</postal>
<email>sekim@kt.com</email>
</address>
</author>

<author initials="D." surname="Premec" fullname="Domagoj Premec">
<organization> Siemens Mobile </organization>
<address>
<postal>
<street> Heinzelova 70a </street>
<city> 10010 Zagreb</city>
<country>Croatia</country>
</postal>
<email>domagoj.premec@siemens.com</email>
</address>
</author>


<date month="May" year="2008"/>
<!--    <workgroup>PANA Working Group </workgroup> -->

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfceditor.org/rfcsearch.html. --> 

<keyword>example</keyword>

<abstract>
<t>
This document provides a detailed description of IPv6 deployment and integration methods and 
scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. 
In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their 
differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each 
of the IEEE 802.16 technologies.  
</t>
</abstract>

</front>
<middle>

<section title='Introduction'>

<t>
As the deployment of IEEE 802.16 access networks progresses,
users will be connected to IPv6 networks.  While the IEEE 802.16 standard
defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16
Media Access Control (MAC) 
<!--[rfced] Please confirm the expansion of MAC as Media Access Control per RFC 4779. -->
payload, a complete description of IPv4/IPv6 operation and
deployment is not present.  
The IEEE 802.16 standards are limited to L1 and L2, 
so they may be used within any number of IP network architectures and scenarios. 
In this document, we will discuss the main
components of IPv6 IEEE 802.16 access networks and their differences
from IPv4 IEEE 802.16 networks and how IPv6 is deployed and
integrated in each of the IEEE 802.16 technologies.
</t>

<t>
This document extends the work of [RFC4779] and 
follows the structure and common terminology of that document.
</t>


<section title='Terminology'>

<t>
The IEEE 802.16-related terminologies in this document are to be interpreted 
as described in [RFC5154].
</t>

<list style='symbols'>

<t>
Subscriber Station (SS): An end-user equipment that provides
connectivity to the 802.16 networks.  It can be either fixed/nomadic
or mobile equipment.  In a mobile environment, SS represents the Mobile
Subscriber Station (MS) introduced in [IEEE802.16e].
</t>

<t>
Base Station (BS): A generalized equipment set providing
connectivity, management, and control between the subscriber station
and the 802.16 networks.
</t>

<t>
Access Router (AR): An entity that performs an IP routing function to
provide IP connectivity for a subscriber station (SS or MS).
</t>

<t>
Connection Identifier (CID): A 16-bit value that identifies a
connection to equivalent peers in the 802.16 MAC of the SS(MS) and
BS.
</t>

<t>
Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS-specific part of the Packet
CS defined in 802.16 STD.
</t>

<t>
IPv6 CS (Convergence Sublayer): IPv6-specific subpart of the Packet CS, Classifier 2
(Packet, IPv6) defined in 802.16 STD.
</t>


</list>



</section>

</section>



<section title='Deploying IPv6 in IEEE 802.16 Networks'>


<section title='Elements of IEEE 802.16 Networks'>
<t>
[IEEE802.16e] is an air interface for fixed and mobile broadband
wireless access systems.  [IEEE802.16] only specifies the convergence 
sublayers and the ability to transport IP over the air interface.
The details of IPv6 (and IPv4) operations over IEEE 802.16 are 
defined in the 16ng WG.  The IPv6 over IPCS 
<!--[rfced] Please provide expansion for IPCS.   Should this be 
"IP CS" as it appears in RFC 5121:

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.
-->
definition is already 
an approved specification <xref target="RFC5121"/>. 
IP over Ethernet CS in IEEE 802.16 is defined in
<xref target="IP-ETHERNET"/>. 
</t>

<t>
Figure 1 illustrates the key elements of typical mobile 802.16 deployments.
</t>


<figure anchor="f1" title="Key Elements of IEEE 802.16(e) Networks">
<artwork>  
       Customer |     Access Provider    | Service Provider
       Premise  |                        | (Backend Network)

    +-----+            +----+     +----+   +--------+
    | SSs |--(802.16)--| BS |-----|    |   | Edge   |   ISP
    +-----+            +----+     | AR |---| Router |==>Network
                               +--|    |   | (ER)   |
                               |  +----+   +--------+
    +-----+            +----+  |                |  +------+
    | SSs |--(802.16)--| BS |--+                +--|AAA   |
    +-----+            +----+                      |Server|
                                                   +------+                                                                                                           
</artwork>
</figure>

</section>



<section title='Scenarios and IPv6 Deployment'>

<t>
[IEEE802.16] specifies two modes for sharing the wireless medium:
point-to-multipoint (PMP) and mesh (optional). 
This document only focuses on the PMP mode.
</t>

<t>
Some of the factors that hinder deployment of native IPv6 core protocols are already introduced by 
[RFC5154]. 
</t>

<t>
There are two different deployment scenarios: fixed and mobile
access deployment scenarios.  A fixed access scenario substitutes for existing wired-based
access technologies such as digital subscriber lines (xDSL) and cable
networks.  
This fixed access scenario can provide nomadic access within the radio coverages, which is called the Hot-zone model.
A mobile access scenario exists for the new paradigm of transmitting voice, data, and video over mobile networks. 
This scenario can provide high-speed data rates
equivalent to the wire-based Internet as well as mobility functions
equivalent to cellular systems.  
There are the different IPv6 impacts on convergence sublayer type, link model, addressing,
mobility, etc. between fixed and mobile access deployment scenarios. 
The details will be discussed below. 
The mobile access scenario can be classified 
into two different IPv6 link models: shared IPv6 prefix link model and point-to-point link model.

</t>


<section title='Mobile Access Deployment Scenarios'>
<t>
Unlike IEEE 802.11, the IEEE 802.16 BS can provide mobility functions
and fixed communications.  [IEEE802.16e] has been standardized to
provide mobility features on IEEE 802.16 environments. IEEE 802.16 BS
might be deployed with a proprietary backend managed by an operator.  
</t>

<t>
There are two possible IPv6 link models for mobile access deployment 
scenarios: shared IPv6 prefix link model and point-to-point link model [RFC4968].
There is always a default access router in the scenarios. 
There can exist multiple hosts behind an MS (networks behind an MS may exist).
The mobile access deployment models, Mobile WiMax and WiBro, fall within this
deployment model.
</t> 

<t>
(1) Shared IPv6 Prefix Link Model
</t>

<t>
This link model represents the IEEE 802.16 mobile access network deployment where
a subnet consists of only single
AR interfaces and multiple MSs.  Therefore, all MSs and
corresponding AR interfaces share the same IPv6 prefix as shown in Figure 2.
The IPv6 prefix will be different from the interface of the AR.  
</t>

<figure anchor="f2" title="Shared IPv6 Prefix Link Model">
<artwork>  
  +-----+
  | MS1 |&lt;-(16)-+
  +-----+       |    +-----+     
  +-----+       +----| BS1 |--+
  | MS2 |&lt;-(16)-+    +-----+  |  
  +-----+                     |  +-----+    +--------+            
                              +->| AR  |----| Edge   |    ISP    
  +-----+                     |  +-----+    | Router +==>Network
  | MS3 |&lt;-(16)-+    +-----+  |             +--------+
  +-----+       +----| BS2 |--+
  +-----+       |    +-----+
  | MS4 |&lt;-(16)-+
  +-----+      
</artwork>
</figure>
<vspace blankLines="100" />
<t>
(2) Point-to-Point Link Model
</t> 

<t>
This link model represents IEEE 802.16 mobile access network deployments where a subnet consists of only a single AR, BS, and MS. 
That is, each connection to a mobile node is treated as a single link. 
Each link between the MS and the AR is
allocated a separate, unique prefix or a set of unique prefixes by the AR.
The point-to-point link model follows the recommendations of [RFC3314]. 
</t>

<figure anchor="f5" title="Point-to-Point Link Model">
<artwork>  
   +-----+            +-----+     +-----+
   | MS1 |&lt;-(16)------|     |---->|     |
   +-----+            | BS1 |     |     |
   +-----+            |     |     |     |    +--------+
   | MS2 |&lt;-(16)------|     |---->|     |----| Edge   |    ISP
   +-----+            +-----+     |     |    | Router +==>Network
                                  | AR  |    +--------+
   +-----+            +-----+     |     |
   | MS3 |&lt;-(16)------|     |---->|     |
   +-----+            | BS2 |     |     |
   +-----+            |     |     |     |
   | MS4 |&lt;-(16)------|     |---->|     |
   +-----+            +-----+     +-----+
</artwork>
</figure>

<section title='IPv6-Related Infrastructure Changes'>

<t>
IPv6 will be deployed in this scenario by upgrading the following
devices to dual stack: MS, AR, and ER.  In this scenario, IEEE
802.16 BSs have only MAC and PHY (Physical Layer)
layers without router functionality and
operate as a bridge. 
The BS should support IPv6 classifiers as specified in [IEEE802.16]. 
</t>

</section>


<section title='Addressing'>
<t>
An IPv6 MS has two possible options to get an IPv6 address.  These
options will be equally applied to the other scenario below (Section 2.2.2).
</t>

<t>
(1) An IPv6 MS can get the IPv6 address from an access router using
stateless auto-configuration.  In this case, router discovery and Duplicate Address Detection (DAD)
operation should be properly operated over an IEEE 802.16 link.
</t>
<vspace blankLines="100" />
<t>
(2) An IPv6 MS can use Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to get an IPv6 address from the DHCPv6
server.  In this case, the DHCPv6 server would be located in the
service provider core network, and the AR should provide a DHCPv6
relay agent.  This option is similar to what we do today in case of
DHCPv4.
</t>

<t>
In this scenario, a router and multiple BSs form an IPv6 subnet, and a
single prefix is allocated to all the attached MSs.  All MSs attached
to the same AR can be on the same IPv6 link.
</t>

<t>
As for the prefix assignment, in the case of the shared IPv6 prefix link model,
one or more IPv6 prefixes are assigned to the link and are hence shared
by all the nodes that are attached to the link. 
In the point-to-point link model, the AR assigns a unique prefix or a set of
unique prefixes for each MS.  
Prefix delegation can be required if networks exist behind an MS. 
</t>

</section>

<section title='IPv6 Transport'>

<t>
In an IPv6 subnet, there are always two underlying links: one is the IEEE 802.16 wireless link between the MS and BS, 
and the other is a wired link between the BS and AR. 
</t>

<t>
IPv6 packets can be sent and received via the IP-specific part of the packet convergence sublayer.
The Packet CS is used for the transport of packet-based protocols,
which include Ethernet and Internet Protocol (IPv4 and IPv6).
Note that in this scenario, IPv6 CS may be more appropriate than
Ethernet CS to transport IPv6 packets, since there is
some overhead of Ethernet CS (e.g., Ethernet header) under mobile
access environments.  However, when PHS (Payload Header Suppression)
is deployed, it mitigates this overhead through the compression of
packet headers. The details of IPv6 operations over the IP-specific
part of the packet CS are defined in <xref target="RFC5121"/>. 
</t>

<t>
Simple or complex network equipment may constitute the underlying wired network between the AR and the ER. 
If the IP-aware equipment between the AR and the ER does not support IPv6, 
the service providers can deploy IPv6-in-IPv4 tunneling mechanisms 
to transport IPv6 packets between the AR and the ER.
</t>

<t>
The service providers are deploying tunneling mechanisms to transport 
IPv6 over their existing IPv4 networks as well as deploying native IPv6 where possible.
Native IPv6 should be preferred over tunneling mechanisms as native IPv6 deployment options 
might be more scalable and provide the required service performance. 
Tunneling mechanisms should only be used when native IPv6 deployment is not an option. 
This can be equally applied to other scenarios below (Section 2.2.2).
</t>

</section>

<vspace blankLines="100" />
<section title='Routing'>

<t>
In general, the MS is configured with a default route that points to the
AR.  Therefore, no routing protocols are needed on the MS.  
The MS just sends to the AR using the default route.
</t>

<t>
The AR can configure multiple links to the ER for network reliability.
The AR should support IPv6 routing protocols such as OSPFv3
[RFC2740] or Intermediate System to Intermediate System (IS-IS) for IPv6 when connected to the ER with multiple links.
</t>

<t>
The ER runs the Interior Gateway Protocol (IGP) such as OSPFv3 or IS-IS for IPv6 in the service provider
network.  The routing information of the ER can be redistributed to the AR.
Prefix summarization should be done at the ER.
</t>

</section>


<section title='Mobility'>

<t>
There are two types of handovers for the IEEE 802.16e networks: link layer 
handover and IP layer handover. In a link layer handover, BSs involved in the 
handover reside in the same IP subnet. An MS only needs to reestablish a link 
layer connection with a new BS without changing its IP configuration, such as 
its IP address, default router, on-link prefix, etc. The link layer handover in
IEEE 802.16e is by nature a hard handover since the MS has to cut off the 
connection with the current BS at the beginning of the handover process and
cannot resume communication with the new BS until the handover completes 
[IEEE802.16e]. In an IP layer handover, the BSs involved reside in different IP 
subnets, or in different networks. Thus, in an IP layer handover, an MS needs to 
establish both a new link layer connection, as in a link layer handover, and a 
new IP configuration to maintain connectivity.
</t>

<t>
IP layer handover for MSs is handled by Mobile IPv6 [RFC3775]. Mobile IPv6 
defines that movement detection uses Neighbor Unreachability Detection to detect
when the default router is no longer bidirectionally reachable, in which case the
mobile node must discover a new default router. Periodic Router Advertisements 
for reachability and movement detection may be unnecessary because the IEEE 802.16
MAC provides the reachability by its ranging procedure and the movement detection
by the Handoff procedure.
</t>

<t>
Mobile IPv6 alone will not solve the handover latency problem for the IEEE 802.16e
networks. To reduce or eliminate packet loss and to reduce the handover delay in 
Mobile IPv6, therefore, Fast Handover for Mobile IPv6 (FMIPv6) [RFC4068] can be 
deployed together with MIPv6. To perform predictive packet forwarding, the FMIPv6's 
IP layer assumes the presence of handover-related triggers delivered by the IEEE 
802.16 MAC layers. Thus, there is a need for cross-layering design to support proper 
behavior of the FMIPv6 solution. This issue is also discussed in <xref target="MIPSHOP-FH80216E"/>.
</t>

<t>
Also, [IEEE802.16g] defines L2 triggers for link status such as 
link-up, link-down, and handoff-start. These L2 triggers may make the Mobile IPv6 or 
FMIPv6 procedure more efficient and faster. 
</t>

<t>
In addition, due to the problems caused by the existence of multiple
convergence sublayers [RFC4840], the mobile access scenarios need
solutions about how roaming will work when forced to move from one CS
to another (e.g., IPv6 CS to Ethernet CS).  Note that, at this phase,
this issue is the out of scope of this document.
</t>

</section>

</section>



<section title='Fixed/Nomadic Deployment Scenarios'>

<t>
The IEEE 802.16 access networks can provide plain Ethernet end-to-end
connectivity. This scenario represents a deployment model using Ethernet CS.   
A wireless DSL deployment model is an example of a fixed/nomadic IPv6
deployment of IEEE 802.16.  Many wireless Internet
service providers (wireless ISPs) have planned to use IEEE 802.16 for
the purpose of high-quality broadband wireless services.  A company
can use IEEE 802.16 to build up a mobile office.  Wireless Internet
spreading through a campus or a cafe can also be implemented with it.
</t>


<figure anchor="f3" title="Fixed/Nomadic Deployment Scenario">
<artwork>
            +-----+                        +-----+    +-----+    ISP 1 
            | SS1 |&lt;-(16)+              +->| AR1 |----| ER1 |===>Network
            +-----+      |              |  +-----+    +-----+   
            +-----+      |     +-----+  |   
            | SS2 |&lt;-(16)+-----| BS1 |--|       
            +-----+            +-----+  |  +-----+    +-----+    ISP 2 
                                        +->| AR2 |----| ER2 |===>Network 
 +-----+    +-----+            +-----+  |  +-----+    +-----+  
 |Hosts|&lt;-->|SS/GW|&lt;-(16)------| BS2 |--+  
 +-----+    +-----+            +-----+             
    This network   
 behind SS may exist 
</artwork>
</figure>

<t>
This scenario also represents IEEE 802.16 network deployment where a subnet consists of multiple MSs and
multiple interfaces of the multiple BSs.  Multiple access routers can exist. 
There exist multiple hosts behind an SS (networks behind an SS may exist).
When 802.16 access networks are widely deployed as in a Wireless Local Area Network (WLAN), this case should also be considered.  The Hot-zone deployment model falls within this case.
</t>

<vspace blankLines="100" />
<t>
While Figure 4 illustrates a generic deployment scenario, 
the following, Figure 5, shows in more detail how an existing DSL ISP would 
integrate the 802.16 access network into its existing infrastructure.
</t>

<figure anchor="f4" title="Integration of 802.16 Access into the DSL Infrastructure">
<artwork>
 +-----+                        +---+      +-----+    +-----+    ISP 1
 | SS1 |&lt;-(16)+                 |   |  +-->|BRAS |----| ER1 |===>Network
 +-----+      |                 |  b|  |   +-----+    +-----+
 +-----+      |     +-----+     |E r|  |      
 | SS2 |&lt;-(16)+-----| BS1 |-----|t i|  |      
 +-----+            +-----+     |h d|--+
                                |  g|  |   +-----+    +-----+    ISP 2
 +-----+            +-----+     |  e|  +-->|BRAS |----| ER2 |===>Network
 | SS3 |&lt;-(16)------| BS2 |-----|   |  |   +-----+    +-----+
 +-----+            +-----+     +---+  |       
                                       |       
 +-----+            +-----+            |       
 | TE  |&lt;-(DSL)-----|DSLAM|------------+
 +-----+            +-----+
</artwork>
</figure>

<t>
In this approach, the 802.16 BS is acting as a DSLAM (Digital Subscriber Line Access Multiplexer). 
On the network side, the BS is connected to an Ethernet bridge, which can be separate equipment 
or integrated into the BRAS (Broadband Remote Access Server). 
</t>

<section title='IPv6-Related Infrastructure Changes'>
<t>
IPv6 will be deployed in this scenario by upgrading the following
devices to dual stack: MS, AR, ER, and the Ethernet bridge.  
The BS should support IPv6 classifiers as specified in [IEEE802.16]. 
</t>

<t>
The BRAS in Figure 5 is providing the functionality of the AR.
An Ethernet bridge is necessary for protecting the BRAS from 802.16 link layer peculiarities. 
The Ethernet bridge relays all traffic received through the BS to its network side port(s) connected to the BRAS. 
Any traffic received from the BRAS is relayed to the appropriate BS. 
Since the 802.16 MAC layer has no native support for multicast (and broadcast) in the uplink direction, 
the Ethernet bridge will implement multicast (and broadcast) 
by relaying the multicast frame received from the MS to all of its ports. 
The Ethernet bridge may also provide some IPv6-specific functions to increase link efficiency of 
the 802.16 radio link (see Section 2.2.2.3).
</t>

</section>


<section title='Addressing'>
<t>
One or more IPv6 prefixes can be shared to all the attached MSs.
Prefix delegation can be required if networks exist behind the SS. 
</t>

</section>



<section title='IPv6 Transport'>


<t>
Transmission of IPv6 over Ethernet CS follows [RFC2464] and does not
introduce any changes to [RFC4861] and [RFC4862]. However, there
are a few considerations in the viewpoint of operation, such as
preventing periodic router advertisement messages from an access
router and broadcast transmission, deciding path MTU size, and so on.
The details about the considerations are described in
<xref target="IP-ETHERNET"/>. 
</t>

</section>


<section title='Routing'>
<t>
In this scenario, IPv6 multi-homing considerations exist.
For example, if there exist two routers to support MSs, a default router must be selected.
</t>

<t>
The Edge Router runs the IGP used in the SP network such as OSPFv3
[RFC2740] or IS-IS for IPv6.  The connected prefixes have to be
redistributed.  Prefix summarization should be done at the Edge Router.
</t>

</section>

<section title='Mobility'>

<t>
No mobility functions of Layer 2 and Layer 3 are supported in the fixed access
scenario. Like WLAN technology, however, nomadicity can be supported in the radio
coverage without any mobility protocol. So, a user can access Internet nomadically
in the coverage.
</t>

<t>
Sometimes, service users can demand IP session continuity or home address reusability
even in the nomadic environment. In that case, Mobile IPv6 [RFC3775] may be used
in this scenario even in the absence of Layer 2's mobility support.
</t>

</section>

</section>


</section>




<section title="IPv6 Multicast">

<t>
<xref target="IP-ETHERNET"/> realizes IPv6 multicast 
support by Internet Group Management Protocol/Multicast Listener Discovery (IGMP/MLD) proxying [RFC4605] and IGMP/MLD snooping [RFC4541]. 
Additionally, it may be possible to efficiently implement multicast packet 
transmission among the multicast subscribers by means of IEEE 802.16 
Multicast CIDs. However, such a protocol is not yet available 
and under development in WiMAX Forum.
</t>


</section>


<section title="IPv6 QoS">
<t>
In IEEE 802.16 networks, a connection is unidirectional and has 
a Quality of Service (QoS) specification. Each connection is associated with a single 
data service flow, and each service flow is associated with a set 
of QoS parameters in [IEEE802.16].  The QoS-related parameters are 
managed using the Dynamic Service Addition (DSA) and Dynamic Service 
Change (DSC) MAC management messages specified in [IEEE802.16].
The [IEEE802.16] provides QoS differentiation for the different types 
of applications by five scheduling services. Four scheduling services 
are defined in 802.16: Unsolicited Grant Service (UGS), real-time 
Polling Service (rtPS), non-real-time Polling Service (nrtPS), and Best 
Effort (BE).  A fifth scheduling service is Extended Real-time Polling 
Service (ertPS), defined in [IEEE802.16e].  It is required to
define IP layer quality of service mapping to MAC layer QoS types 
[IEEE802.16], [IEEE802.16e].
</t>

</section>

<section title="IPv6 Security">
<t>
When initiating the connection, an MS is authenticated by the Authentication, Authorization, and Accounting (AAA)
server located at its service provider network. To achieve that, 
the MS and the BS use Privacy Key Management [IEEE802.16],[IEEE802.16e], 
while the BS communicates with the AAA server using a AAA protocol.
Once the MS is authenticated with the AAA server, it can associate successfully with the BS 
and acquire an IPv6 address through stateless auto-configuration or DHCPv6.  
Note that the initiation and authentication process is the same as the one used in IPv4.
</t>

</section>



<section title="IPv6 Network Management">
<t>
[IEEE802.16f] includes the management information base for IEEE 802.16 networks. 
For IPv6 network management, the necessary instrumentation (such as MIBs, NetFlow Records, etc.) should be available.
</t>
<t>
Upon entering the network, an MS is assigned three management
connections in each direction.  These three connections reflect the
three different QoS requirements used by different management levels.
The first of these is the basic connection, which is used for the
transfer of short, time-critical MAC management messages and radio
link control (RLC) messages.  The primary management connection is
used to transfer longer, more delay-tolerant messages such as those
used for authentication and connection setup.  The secondary
management connection is used for the transfer of standards-based
<vspace blankLines="100" />
management messages such as Dynamic Host Configuration Protocol
(DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network
Management Protocol (SNMP).
</t>
<t>
IPv6-based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
network elements are implemented dual stack. SNMP messages can be
carried by either IPv4 or IPv6.
</t>

</section>

</section>


<section title="Security Considerations">
<t>
This document provides a detailed description of various IPv6
deployment scenarios and link models for IEEE 802.16-based networks,
and as such does not introduce any new security threats. 
No matter what the scenario applied is, the networks should employ
the same link layer security mechanisms defined in [IEEE802.16e]
and IPv6 transition security considerations defined in [RFC4942].      
However, as already described in [RFC4968], a shared prefix
model-based mobile access deployment scenario may
<!--[rfced] Is there text missing here?  Please provide the missing text or rephrase.  -->
 security implications
for protocols that are designed to work within the scope. This is
the concern for a shared prefix link model wherein private
resources cannot be put onto a public 802.16-based network.
This may restrict the usage of a shared prefix model to
enterprise environments. 
</t>
</section>



<section title=" Acknowledgements">
<t>
This work extends v6ops work on [RFC4779]. 
We thank all the authors of the document.
Special thanks are due to Maximilian Riegel, Jonne Soininen, Brian E. Carpenter, Jim Bound, David Johnston, 
Basavaraj Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa, Jung-Mo Moon, Sangjin Jeong, and Jinhyeock Choi
for extensive review of this document. 
We acknowledge Dominik Kaspar for proofreading the document.
</t>

</section>


</middle>

<back>

<references title='Normative References'>

&rfc4861;
&rfc4862;

</references>

<vspace blankLines="100" />
<references title='Informative References'>
&rfc4779;
&rfc4968;
&rfc4942;
&rfc2740;
&rfc3314;
&rfc3775;
&rfc2464;
&rfc4605;
&rfc4541;
&rfc4068;

 <reference anchor="RFC4840">
 <front>
  <title>Multiple Encapsulation Methods Considered Harmful</title> 
 <author initials="B." surname="Aboba" fullname="B. Aboba">
  <organization /> 
  </author>
 <author initials="E." surname="Davies" fullname="E. Davies">
  <organization /> 
  </author>
 <author initials="D." surname="Thaler" fullname="D. Thaler">
  <organization /> 
  </author>
  <date year="2007" month="April" /> 
 <abstract>
  <t>This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. This memo provides information for the Internet community.</t> 
  </abstract>
  </front>
  <seriesInfo name="RFC" value="4840" /> 
  <format type="TXT" octets="65287" target="ftp://ftp.isi.edu/in-notes/rfc4840.txt" /> 
  </reference>

 <reference anchor="RFC5154">
 <front>
  <title>IP over IEEE 802.16 Problem Statement and Goals</title> 
 <author initials="J." surname="Jee" fullname="J. Jee">
  <organization /> 
  </author>
 <author initials="S." surname="Madanapalli" fullname="S. Madanapalli">
  <organization /> 
  </author>
 <author initials="J." surname="Mandin" fullname="J. Mandin">
  <organization /> 
  </author>
  <date year="2008" month="April" /> 
 <abstract>
  <t>This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. This memo provides information for the Internet community.</t> 
  </abstract>
  </front>
  <seriesInfo name="RFC" value="5154" /> 
  <format type="TXT" octets="29853" target="ftp://ftp.isi.edu/in-notes/rfc5154.txt" /> 
  </reference>

 <reference anchor="RFC5121">
 <front>
  <title>Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks</title> 
 <author initials="B." surname="Patil" fullname="B. Patil">
  <organization /> 
  </author>
 <author initials="F." surname="Xia" fullname="F. Xia">
  <organization /> 
  </author>
 <author initials="B." surname="Sarikaya" fullname="B. Sarikaya">
  <organization /> 
  </author>
 <author initials="JH." surname="Choi" fullname="JH. Choi">
  <organization /> 
  </author>
 <author initials="S." surname="Madanapalli" fullname="S. Madanapalli">
  <organization /> 
  </author>
  <date year="2008" month="February" /> 
 <abstract>
  <t>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. [STANDARDS TRACK]</t> 
  </abstract>
  </front>
  <seriesInfo name="RFC" value="5121" /> 
  <format type="TXT" octets="50092" target="ftp://ftp.isi.edu/in-notes/rfc5121.txt" /> 
  </reference>

 <reference anchor="IP-ETHERNET">
 <front>
  <title>Transmission of IP over Ethernet over IEEE 802.16 Networks</title> 
 <author initials="H" surname="Jeon" fullname="HongSeok Jeon">
  <organization /> 
  </author>
<author initials='M' surname="Riegel" >
   <organization />
  </author>
 <author initials="S" surname="Jeong">
   <organization />
   </author>
  <date month="April" day="18" year="2008" /> 
 <abstract>
  <t>This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections which the IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior.</t> 
  </abstract>
  </front>
  <seriesInfo name="Work in" value="Progress" /> 
  <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt" /> 
  </reference>

 <reference anchor="MIPSHOP-FH80216E">
 <front>
  <title>Mobile IPv6 Fast Handovers over IEEE 802.16e Networks</title> 
 <author initials="H" surname="Jang" fullname="Hee-Jin Jang">
  <organization /> 
  </author>
 <author initials="J" surname="Jee" fullname="Junghoon Jee">
  <organization /> 
  </author>
 <author initials="Y" surname="Han" fullname="Youn-Hee Han">
  <organization /> 
  </author>
 <author initials="S" surname="Park" fullname="Soohong Daniel Park">
  <organization /> 
  </author>
 <author initials="J" surname="Cha" fullname="Jaesun Cha">
  <organization /> 
  </author>
  <date month="March" day="10" year="2008" /> 
 <abstract>
  <t>This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently.</t> 
  </abstract>
  </front>
  <seriesInfo name="Work in" value="Progress" /> 
  <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fh80216e-07.txt" /> 
  </reference>
             
      <reference anchor="IEEE802.16">
        <front>
          <title>
          IEEE 802.16-2004, IEEE Standard for Local and Metropolitan Area Networks,
     Part 16: Air Interface for Fixed Broadband Wireless Access Systems
          </title> 
         <date month="October" year="2004" />
        </front>
      </reference>
      
       <reference anchor="IEEE802.16e">
        <front>
          <title>
           IEEE Standard for Local and Metropolitan Area Networks Part 16: 
           Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: 
           Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1
          </title> 
         <date month="February" year="2006" />
        </front>
      </reference>

       <reference anchor="IEEE802.16g">
        <front>
          <title>
           Draft Amendment to IEEE Standard for Local and Metropolitan Area Networks, 
           Part 16: Air Interface for Fixed Broadband Wireless Access Systems - Management Plane Procedures and Services 
          </title> 
         <date month="January" year="2007" />
        </front>
      </reference>
      
             <reference anchor="IEEE802.16f">
        <front>
          <title>
           Amendment to IEEE Standard for Local and Metropolitan Area Networks, 
           Part 16: Air Interface for Fixed Broadband Wireless Access Systems - Management Information Base 
          </title> 
         <date month="December" year="2005" />
        </front>
      </reference>
      
</references>


</back>
<vspace blankLines="100" />
</rfc>
