Network Working Group                                     M-K. Shin, Ed.
Internet-Draft                                                      ETRI
Intended status: Informational                                  Y-H. Han
Expires: June 22, July 31, 2008                                               KUT
                                                                S-E. Kim
                                                               D. Premec
                                                          Siemens Mobile
                                                       December 20, 2007
                                                        January 28, 2008

              IPv6 Deployment Scenarios in 802.16 Networks

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on June 22, July 31, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).


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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . .  3
     2.1.  Elements of IEEE 802.16 Networks . . . . . . . . . . . . .  3
     2.2.  Scenarios and IPv6 Deployment  . . . . . . . . . . . . . .  4
       2.2.1.  Mobile Access Deployment Scenarios . . . . . . . . . .  4  5
       2.2.2.  Fixed/Nomadic Deployment Scenarios . . . . . . . . . .  9  8
     2.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11
     2.4.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12 11
     2.5.  IPv6 Security  . . . . . . . . . . . . . . . . . . . . . . 12 11
     2.6.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 13 12
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13 12
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 14 13
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 14 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

1.  Introduction

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

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

1.1.  Terminology

   The IEEE 802.16 related terminologies in this document are to be
   interpreted as described in [I-D.ietf-16ng-ps-goals].
   o  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 mobile environment, SS represents
      the Mobile Subscriber Station (MS) introduced in [IEEE802.16e].
   o  Base Station (BS): A generalized equipment sets set providing
      connectivity, management, and control between the subscriber
      station and the 802.16 networks.
   o  Access Router (AR): An entity that performs an IP routing function
      to provide IP connectivity for subscriber station (SS or MS).
   o  Connection Identifier (CID): A 16-bit value that identifies a
      connection to equivalent peers in the 802.16 MAC of the SS(MS) and
   o  Ethernet CS (Convergence Sublayer): 802.3/Ethernet CS specific
      part of the Packet CS defined in 802.16 STD.
   o  IPv6 CS (Convergence Sublayer): IPv6 specific subpart of the
      Packet CS, Classifier 2 (Packet, IPv6) defined in 802.16 STD.

2.  Deploying IPv6 in IEEE 802.16 Networks

2.1.  Elements of IEEE 802.16 Networks

   The mechanism of transporting IP traffic over IEEE 802.16 networks

   [IEEE 802.16e] is
   outlined in [IEEE802.16].  [IEEE802.16] an air interface for fixed and mobile broadband
   wireless access systems.  [IEEE 802.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 being discussed now defined in the 16ng WG.  The IPv6 over IPCS definition is
   already an approved specification [I-D.ietf-16ng-ipv6-over-ipv6cs].

   IP over Ethernet CS in IEEE 802.16 is defined in

   Figure 1 illustrates the key elements of typical mobile 802.16

          Customer |     Access Provider    | Service Provider
          Premise  |                        | (Backend Network)

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

             Figure 1: Key Elements of IEEE 802.16(e) Networks

2.2.  Scenarios and IPv6 Deployment

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

   Some of the factors that hinder deployment of native IPv6 core
   protocols are already introduced by [I-D.ietf-16ng-ps-goals].

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

2.2.1.  Mobile Access Deployment Scenarios

   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.  Some architectural characteristics of IEEE 802.16 networks
   may affect the detailed operations of NDP (Neighbor Discovery
   Protocol) [RFC4861], [RFC4862].

   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.


   (1) Shared IPv6 Prefix Link Model

   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.

     | MS1 |<-(16)-+
     +-----+       |    +-----+
     +-----+       +----| BS1 |--+
     | MS2 |<-(16)-+    +-----+  |
     +-----+                     |  +-----+    +--------+
                                 +->| AR  |----| Edge   |    ISP
     +-----+                     |  +-----+    | Router +==>Network
     | MS3 |<-(16)-+    +-----+  |             +--------+
     +-----+       +----| BS2 |--+
     +-----+       |    +-----+
     | MS4 |<-(16)-+

                  Figure 2: Shared IPv6 Prefix Link Model


   (2) Point-to-Point Link Model

   This link model represents IEEE 802.16 mobile access network
   deployments where a subnet consists of only 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 unique set of prefixes by the AR.  The point-to-
   point link model follows the recommendations of [RFC3314].

      +-----+            +-----+     +-----+
      | MS1 |<-(16)------|     |---->|     |
      +-----+            | BS1 |     |     |
      +-----+            |     |     |     |    +--------+
      | MS2 |<-(16)------|     |---->|     |----| Edge   |    ISP
      +-----+            +-----+     |     |    | Router +==>Network
                                     | AR  |    +--------+
      +-----+            +-----+     |     |
      | MS3 |<-(16)------|     |---->|     |
      +-----+            | BS2 |     |     |
      +-----+            |     |     |     |
      | MS4 |<-(16)------|     |---->|     |
      +-----+            +-----+     +-----+

                    Figure 3: Point-to-Point Link Model  IPv6 Related Infrastructure Changes

   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 layers without router functionality and
   operate as a bridge.  The BS should support IPv6 classifiers as
   specified in [IEEE802.16].  However, if IPv4 stack is loaded to them
   for management and configuration purposes, it is expected that BS
   should be upgraded by implementing IPv6 stack, too.  Addressing

   An IPv6 MS has two possible options to get an IPv6 address.  These
   options will be equally applied to the other scenario below (Section


   (1) An IPv6 MS can get the IPv6 address from an access router using
   stateless auto-configuration.  In this case, router discovery and DAD
   operation should be properly operated over an IEEE 802.16 link.


   (2) An IPv6 MS can use 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

   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 same AR can be on the same IPv6 link.

   As for the prefix assignment, in case of the shared IPv6 prefix link
   model, one or more IPv6 prefixes are assigned to the link and 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.  IPv6 Transport

   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.

   If stateless auto-configuration is used to get an

   IPv6 address,
   router discovery and DAD operation should packets can be properly operated over
   IEEE 802.16 links.  In case of the shared IPv6 prefix link model, the
   DAD (Duplicate Address Detection) [RFC4861] does not adapt well to sent and received via the 802.16 air interface as there is no native multicast support.  An
   optimization, called Relay DAD, may be required to perform DAD.
   However, in case IP specific part of the point-to-point link model, DAD is easy since
   each connection to a MN
   packet convergence sublayer.  The Packet CS is treated as a unique IPv6 link. used for the transport
   of packet based protocols which include Ethernet and Internet
   Protocol (IPv4 and IPv6).  Note that in this scenario IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] may be
   more appropriate than Ethernet CS [I-D.ietf-16ng-ip-over-
   ethernet-over-802.16] 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 defined in

   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.

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

   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.

   The AR can configure multiple links to ER for network reliability.
   The AR should support IPv6 routing protocols such as OSPFv3 [RFC2740]
   or IS-IS for IPv6 when connected to the ER with multiple links.

   The ER runs the 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.  Mobility


   There are two types of handovers for mobility management, the movement between BSs is handled by
   Mobile IPv6 [RFC3775], if it requires IEEE 802.16e networks: link
   layer handover and IP layer handover.  In a subnet change.  Also, link layer handover, BSs
   involved in
   certain cases (e.g., fast handover) the link mobility information
   must be available for facilitating handover reside in the same IP subnet.  A MS only
   needs to re-establish a link layer 3 handoff procedure. 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, a MS needs to establish both a new
   link layer connection, as in a link layer handover, and a new IP
   configuration to maintain connectivity.

   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 ranging procedure
   and the movement detection by the Handoff procedure.

   Mobile IPv6 alone will not solve the handover latency problem for the
   IEEE 802.16 defines L2 triggers 802.16e networks.  To reduce or eliminate packet loss and to
   reduce the handover delay in case Mobile IPv6, therefore, Fast Handover
   for Mobile IPv6 (FMIPv6) [RFC4068] can be deployed together with
   MIPv6.  To perform predictive packet forwarding, the refresh of an FMIPv6's IP address
   is required during
   layer assumes the handoff.  Though a handoff has occurred, an
   additional router discovery procedure is not required in case presence of
   intra-subnet handoff.  Also, faster handoff may occur handover-related triggers delivered by
   the L2
   trigger in case IEEE 802.16 MAC layers.  Thus, there is a need for cross-layering
   design to support proper behavior of inter-subnet handoff. the FMIPv6 solution.  This issue
   is also being discussed in [I-D.ietf-mipshop-fh80216e].

   Also, [IEEE802.16g] defines L2 triggers for link status such as
   link-up, link-down, handoff-start.  These L2 triggers may make the
   Mobile IPv6 or FMIPv6 procedure more efficient and faster.  In addition, Mobile
   IPv6 Fast Handover assumes the support from link- layer technology,
   but the particular link-layer information being available, as well as
   the timing of its availability (before, during or after a handover
   has occurred), differs according to the particular link-layer
   technology in use.

2.2.2.  Fixed/Nomadic Deployment Scenarios

   The IEEE 802.16 access networks can provide plain Ethernet end-to-end
   connectivity.  This issue is also being discussed in

   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.  It should be also
   discussed in the 16ng WG.

2.2.2.  Fixed/Nomadic Deployment Scenarios

   The IEEE 802.16 access networks can provide plain Ethernet end-to-end
   connectivity.  Wireless DSL deployment model scenario represents deployment model using
   Ethernet CS.  Wireless DSL deployment model is an example of a
   fixed/nomadic 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 be also implemented with it.
   The distinct point of this use case is that it can use the unlicensed
   (2.4 & 5 GHz) band as well as the licensed (2.6 & 3.5GHz) band.  By
   using the unlicensed band, an IEEE 802.16 BS might be used just as a
   wireless switch/hub which a user purchases to build a private
   wireless network in his/her home or laboratory.

   Under fixed access model, the IEEE 802.16 BS will be deployed using
   an IP backbone rather than a proprietary backend like cellular
   systems.  Thus, many IPv6 functionalities such as [RFC4861],
   [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16

            +-----+                        +-----+    +-----+    ISP 1
            | SS1 |<-(16)+              +->| AR1 |----| ER1 |===>Network
            +-----+      |              |  +-----+    +-----+
            +-----+      |     +-----+  |
            | SS2 |<-(16)+-----| BS1 |--|
            +-----+            +-----+  |  +-----+    +-----+    ISP 2
                                        +->| AR2 |----| ER2 |===>Network
 +-----+    +-----+            +-----+  |  +-----+    +-----+
 |Hosts|<-->|SS/GW|<-(16)------| BS2 |--+
 +-----+    +-----+            +-----+
    This network
 behind SS may exist

                Figure 4: Fixed/Nomadic Deployment Scenario

   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 WLAN, this case
   should be also considered.  The Hot-zone deployment model falls
   within this case.

   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.

 +-----+                        +---+      +-----+    +-----+    ISP 1
 | SS1 |<-(16)+                 |   |  +-->|BRAS |----| ER1 |===>Network
 +-----+      |                 |  b|  |   +-----+    +-----+
 +-----+      |     +-----+     |E r|  |
 | SS2 |<-(16)+-----| BS1 |-----|t i|  |
 +-----+            +-----+     |h d|--+
                                |  g|  |   +-----+    +-----+    ISP 2
 +-----+            +-----+     |  e|  +-->|BRAS |----| ER2 |===>Network
 | SS3 |<-(16)------| BS2 |-----|   |  |   +-----+    +-----+
 +-----+            +-----+     +---+  |
 +-----+            +-----+            |
 | TE  |<-(DSL)-----|DSLAM|------------+
 +-----+            +-----+

      Figure 5: Integration of 802.16 access into DSL infrastructure
   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).  IPv6 Related Infrastructure Changes

   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].
   However, if a IPv4 stack is loaded to them for management and
   configuration purpose, it is expected that the BS should be upgraded
   by implementing an IPv6 stack, too.

   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  Addressing

   One or more IPv6 prefixes can be shared to all the attached MSs.
   Prefix delegation can be required if networks exist behind the SS.  IPv6 Transport

   Note that in this scenario Ethernet CS
   [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate
   than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport

   Transmisson of IPv6
   packets, since the scenario needs to support plain over Ethernet end-to-
   end connectivity.  However, the IPv6 CS can also be supported.  The
   MS and BS will consider the connections between the peer IP CSs at
   the MS follows [RFC2464] and BS does not
   introduce any changes to form [RFC4861] and [RFC4862].  However, there are
   a point to point link.  In few considerations in the Ethernet CS
   case, an Ethernet bridge may provide implementation viewpoint of operation, such as
   preventing periodic router advertisement messages from an
   authoritative address cache access
   router and Relay DAD.  An Authoritative address
   cache is a mapping between the IPv6 address broadcast transmission, deciding path MTU size, and the MAC addresses of
   all attached MSs. so on.
   The bridge builds its authoritative address cache by parsing the IPv6
   Neighbor Discovery messages used during address configuration (DAD).
   Relay DAD means that details about the Neighbor Solicitation message used considerations are described in the
   DAD process will be relayed only to the MS which already has
   configured the solicited address as its own address (if such an MS
   exist at all).
   [I-D.ietf-16ng-ip-over-ethernet-over-802.16].  Routing

   In this scenario, IPv6 multi-homing considerations exist.  For
   example, if there exist two routers to support MSs, a default router
   must be selected.

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

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

2.3.  IPv6 Multicast

   In IEEE 802.16 air link, downlink connections

   Sometime, service users can be shared among
   multiple MSs, enabling multicast channels with multiple MSs receiving
   the same information from demand IP session continuity or home
   address reusability even in the BS.  Multicast and Broadcast Service
   (MBS) nomadic environment.  In case of
   that, Mobile IPv6 [RFC3775] may be used to efficiently implement multicast.  However, it is
   not clear how to do this, as currently CID is assigned by BS, but in
   MBS it should be done at an AR and it's network scope.  It is not
   clear how this mapping will happen for MBS, so MBS discussions have
   been postponed scenario even in WiMax for now.  Note that it should be intensively
   researched later, since MBS will be one of the killer services in
   IEEE 802.16 networks.

   In order to support multicast services in IEEE 802.16,
   absence of Layer 2's mobility support.

2.3.  IPv6 Multicast
   Listener Discovery (MLD) [RFC2710] must be supported between the MS
   and AR.  Also, the inter-working with IP

   [I-D.ietf-16ng-ip-over-ethernet-over-802.16] realizes IPv6 multicast protocols and MBS
   should be considered.

   MBS defines Multicast and Broadcast Services, but actually, MBS seems
   support by IGMP/MLD proxying [RFC4605] and IGMP/MLD snooping
   [RFC4541].  Additionally, it may be a broadcast service, not multicasting.  MBS adheres possible to
   broadcast services, while traditional IP efficiently implement
   multicast schemes define packet transmission among the multicast routing using a shared tree or source-specific tree to
   deliver packets efficiently.

   In subscribers by
   means of IEEE 802.16 networks, two types of access to MBS may be supported:
   single-BS access Multicast CIDs.  However, such a protocol is not
   yet available and multi-BS access.  Therefore, these two types of
   services may be roughly mapped into Source-Specific Multicast. under development in WiMAX Forum.

2.4.  IPv6 QoS

   In IEEE 802.16 networks, a connection is unidirectional and has a QoS
   specification.  The 802.16 supported  Each connection is associated with a single data
   service flow and each service flow is associated with a set of QoS has different semantics from
   parameters in [IEEE802.16].  The QoS (e.g., diffserv).  Mapping CID to related parameters are managed
   using the Dynamic Service Flow IDentifier
   (SFID) defines Addition (DSA) and Dynamic Service Change
   (DSC) MAC management messages that specified in [IEEE802.16].  The
   [IEEE802.16] provides QoS parameters of differentiation for the different types of
   applications by five scheduling service.  Four scheduling services
   are defined in 802.16 such as Unsolicited Grant Service (UGS), real-
   time Polling Service (rtPS), non-real-time Polling Service (nrtPS)
   and Best Effort (BE).  A fifth scheduling service flow associated with is Extended Real-
   time Polling Service (ertPS) that connection.  In order is defined in [IEEE802.16e].  It is
   required to interwork with IP QoS, provide IP QoS (e.g.,
   diffserv, or flow label for IPv6) layer quality of service mapping to IEEE 802.16 link
   specifics should be provided. MAC layer
   QoS types [IEEE802.16], [IEEE802.16e].

2.5.  IPv6 Security

   When initiating the connection, an MS is authenticated by the AAA
   server located at its service provider network.  All  To achieve that, the parameters
   related to authentication (username, password
   MS and etc.) are forwarded
   by the BS to use Privacy Key Management [IEEE802.16],[IEEE802.16e],
   while the BS communicates with the AAA server.  The AAA server authenticates using a AAA protocol.
   Once the MSs
   and when an MS is once authenticated and associated with the AAA server, it can associate
   successfully with
   BS, IPv6 the BS and acquire an IPv6 address will be acquired by the MS through
   stateless autoconfiguration or DHCPv6.  Note that the initiation and
   authentication process is the same as the one used in IPv4.

   IPsec is a fundamental part of IPv6.  Unlike IPv4, IPsec for IPv6 may
   be used within the global end-to-end architecture.  But, we do not
   have PKIs across organizations and IPsec is not integrated with IEEE
   802.16 network mobility management.

   IEEE 802.16 network threats may be different from IPv6 and IPv6
   transition threat models [RFC4942].  It should be also discussed.

2.6.  IPv6 Network Management

   [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

   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
   management messages such as Dynamic Host Configuration Protocol
   (DHCP), Trivial File Transfer Protocol (TFTP), and Simple Network
   Management Protocol (SNMP).

   IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
   network elements are implemented dual stack.  For example, network
   management systems (NMS) can send SNMP messages by IPv4 with IPv6
   related object identifiers.  Also, an NMS can use IPv6 for SNMP
   requests and responses including IPv4 related OID.

3.  IANA Considerations

   This document requests no action by IANA.

4.  Security Considerations

   Please refer

   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 security implications for protocols
   that are designed to Section 2.5 "IPv6 Security" technology sections 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 networks.  This may restrict the usage of
   a shared prefix model to enterprise environments.

5.   Acknowledgements

   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.

6.  References

6.1.  Normative References

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

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

6.2.  Informative References

   [RFC4779]  Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
              J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
              Access Networks", RFC 4779, January 2007.

   [RFC4968]  Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
              Based Networks", RFC 4968, August 2007.

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              September 2007.

   [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
              RFC 2740, December 1999.

   [RFC3314]  Wasserman, M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4840]  Aboba,

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC4605]  Fenner, B., He, H., Haberman, B., Davies, E., and D. Thaler, "Multiple
              Encapsulation Methods Considered Harmful", H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4840,
              April 2007. 4605, August 2006.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, May 2006.

   [RFC4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.

              Jee, J., Madanapalli, S., Mandin, J., and S. Park, J. Mandin, "IP over 802.16
              Problem Statement and Goals",
              draft-ietf-16ng-ps-goals-03 draft-ietf-16ng-ps-goals-04
              (work in progress),
              November December 2007.

              Patil, B., Xia, F., Sarikaya, B., Choi, J., and S.
              Madanapalli, "Transmission of IPv6 via the IPv6 CS over
              IEEE 802.16 Networks", draft-ietf-16ng-ipv6-over-ipv6cs-11
              (work in progress), November 2007.

              Jeon, H., "Transmission of IP over Ethernet over IEEE
              802.16 Networks",
              draft-ietf-16ng-ip-over-ethernet-over-802.16-04 (work in
              progress), November 2007. January 2008.

              Jang, H., Jee, J., Han, Y., Park, S., and J. Cha, "Mobile
              IPv6 Fast Handovers over IEEE 802.16e Networks",
              draft-ietf-mipshop-fh80216e-05 (work in progress),
              November 2007.

              "IEEE 802.16-2004, IEEE Standard for Local and
              Metropolitan Area Networks, Part 16: Air Interface for
              Fixed Broadband Wireless Access Systems", October 2004.

              "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",
              February 2006.

              "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", January 2007.

              "Amendment to IEEE Standard for Local and Metropolitan
              Area Networks,  Part 16: Air Interface for Fixed Broadband
              Wireless Access Systems - Management Information Base",
              December 2005.

Authors' Addresses

   Myung-Ki Shin
   161 Gajeong-dong Yuseng-gu
   Daejeon, 305-350

   Phone: +82 42 860 4847

   Youn-Hee Han
   Gajeon-Ri 307 Byeongcheon-Myeon
   Cheonan-Si Chungnam Province, 330-708


   Sang-Eon Kim
   17 Woomyeon-dong, Seocho-gu
   Seoul, 137-791

   Domagoj Premec
   Siemens Mobile
   Heinzelova 70a
   10010 Zagreb


Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (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

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

   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


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