doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc5181.txt b/doc/rfc/rfc5181.txt
new file mode 100644
index 0000000..09bae05
--- /dev/null
+++ b/doc/rfc/rfc5181.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                     M-K. Shin, Ed.
+Request for Comments: 5181                                          ETRI
+Category: Informational                                         Y-H. Han
+                                                                     KUT
+                                                                S-E. Kim
+                                                                      KT
+                                                               D. Premec
+                                                          Siemens Mobile
+                                                                May 2008
+
+
+              IPv6 Deployment Scenarios in 802.16 Networks
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   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.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . .  3
+     2.1.  Elements of IEEE 802.16 Networks . . . . . . . . . . . . .  3
+     2.2.  Scenarios and IPv6 Deployment  . . . . . . . . . . . . . .  3
+       2.2.1.  Mobile Access Deployment Scenarios . . . . . . . . . .  4
+       2.2.2.  Fixed/Nomadic Deployment Scenarios . . . . . . . . . .  8
+     2.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 10
+     2.4.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 11
+     2.5.  IPv6 Security  . . . . . . . . . . . . . . . . . . . . . . 11
+     2.6.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 11
+   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     5.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 1]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+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
+   Media Access Control (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 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.
+
+   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 [RFC5154].
+
+   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 a mobile environment, SS
+      represents the Mobile Subscriber Station (MS) introduced in
+      [IEEE802.16e].
+
+   o  Base Station (BS): A generalized equipment 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 a 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
+      BS.
+
+   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.
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 2]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+2.  Deploying IPv6 in IEEE 802.16 Networks
+
+2.1.  Elements of IEEE 802.16 Networks
+
+   [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 IPv6 CS definition is already
+   an approved specification [RFC5121].  IP over Ethernet CS in IEEE
+   802.16 is defined in [IP-ETHERNET].
+
+   Figure 1 illustrates the key elements of typical mobile 802.16
+   deployments.
+
+          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 [RFC5154].
+
+   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
+
+
+
+Shin, Ed., et al.            Informational                      [Page 3]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   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.
+
+   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
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 4]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   (2) Point-to-Point Link Model
+
+   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].
+
+      +-----+            +-----+     +-----+
+      | MS1 |<-(16)------|     |---->|     |
+      +-----+            | BS1 |     |     |
+      +-----+            |     |     |     |    +--------+
+      | MS2 |<-(16)------|     |---->|     |----| Edge   |    ISP
+      +-----+            +-----+     |     |    | Router +==>Network
+                                     | AR  |    +--------+
+      +-----+            +-----+     |     |
+      | MS3 |<-(16)------|     |---->|     |
+      +-----+            | BS2 |     |     |
+      +-----+            |     |     |     |
+      | MS4 |<-(16)------|     |---->|     |
+      +-----+            +-----+     +-----+
+
+                    Figure 3: Point-to-Point Link Model
+
+2.2.1.1.  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 (Physical Layer) layers without router
+   functionality and operate as a bridge.  The BS should support IPv6
+   classifiers as specified in [IEEE802.16].
+
+2.2.1.2.  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
+   2.2.2).
+
+   (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.
+
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 5]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   (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.
+
+   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.
+
+   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.
+
+2.2.1.3.  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.
+
+   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 [RFC5121].
+
+   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).
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 6]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+2.2.1.4.  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 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.
+
+   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.
+
+2.2.1.5.  Mobility
+
+   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.
+
+   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.
+
+   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
+
+
+
+Shin, Ed., et al.            Informational                      [Page 7]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   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 [MIPSHOP-FH80216E].
+
+   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.
+
+   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.
+
+2.2.2.  Fixed/Nomadic Deployment Scenarios
+
+   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.
+
+            +-----+                        +-----+    +-----+    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 Wireless Local
+   Area Network (WLAN), this case should also be considered.  The Hot-
+   zone deployment model falls within this case.
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 8]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   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 the 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).
+
+2.2.2.1.  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].
+
+   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).
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                      [Page 9]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+2.2.2.2.  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.
+
+2.2.2.3.  IPv6 Transport
+
+   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 [IP-ETHERNET].
+
+2.2.2.4.  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.
+
+2.2.2.5.  Mobility
+
+   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.
+
+   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.
+
+2.3.  IPv6 Multicast
+
+   [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.
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 10]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+2.4.  IPv6 QoS
+
+   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].
+
+2.5.  IPv6 Security
+
+   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.
+
+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
+   available.
+
+   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
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 11]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   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.  SNMP messages can be
+   carried by either IPv4 or IPv6.
+
+3.  Security Considerations
+
+   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 have 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.
+
+4.   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.
+
+5.  References
+
+5.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.
+
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 12]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+5.2.  Informative References
+
+   [IEEE802.16]        "IEEE 802.16-2004, IEEE Standard for Local and
+                       Metropolitan Area Networks, Part 16: Air
+                       Interface for Fixed Broadband Wireless Access
+                       Systems", October 2004.
+
+   [IEEE802.16e]       "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.
+
+   [IEEE802.16f]       "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.
+
+   [IEEE802.16g]       "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.
+
+   [IP-ETHERNET]       Jeon, H., Riegel, M., and S. Jeong, "Transmission
+                       of IP over Ethernet over IEEE 802.16 Networks",
+                       Work in Progress, April 2008.
+
+   [MIPSHOP-FH80216E]  Jang, H., Jee, J., Han, Y., Park, S., and J. Cha,
+                       "Mobile IPv6 Fast Handovers over IEEE 802.16e
+                       Networks", Work in Progress, March 2008.
+
+   [RFC2464]           Crawford, M., "Transmission of IPv6 Packets over
+                       Ethernet Networks", RFC 2464, December 1998.
+
+   [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.
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 13]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+   [RFC4068]           Koodli, R., "Fast Handovers for Mobile IPv6",
+                       RFC 4068, July 2005.
+
+   [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.
+
+   [RFC4605]           Fenner, B., He, H., Haberman, B., and H. Sandick,
+                       "Internet Group Management Protocol (IGMP) /
+                       Multicast Listener Discovery (MLD)-Based
+                       Multicast Forwarding ("IGMP/MLD Proxying")",
+                       RFC 4605, August 2006.
+
+   [RFC4779]           Asadullah, S., Ahmed, A., Popoviciu, C., Savola,
+                       P., and J. Palet, "ISP IPv6 Deployment Scenarios
+                       in Broadband Access Networks", RFC 4779,
+                       January 2007.
+
+   [RFC4840]           Aboba, B., Davies, E., and D. Thaler, "Multiple
+                       Encapsulation Methods Considered Harmful",
+                       RFC 4840, April 2007.
+
+   [RFC4942]           Davies, E., Krishnan, S., and P. Savola, "IPv6
+                       Transition/Co-existence Security Considerations",
+                       RFC 4942, September 2007.
+
+   [RFC4968]           Madanapalli, S., "Analysis of IPv6 Link Models
+                       for 802.16 Based Networks", RFC 4968,
+                       August 2007.
+
+   [RFC5121]           Patil, B., Xia, F., Sarikaya, B., Choi, JH., and
+                       S. Madanapalli, "Transmission of IPv6 via the
+                       IPv6 Convergence Sublayer over IEEE 802.16
+                       Networks", RFC 5121, February 2008.
+
+   [RFC5154]           Jee, J., Madanapalli, S., and J. Mandin, "IP over
+                       IEEE 802.16 Problem Statement and Goals",
+                       RFC 5154, April 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 14]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 2008
+
+
+Authors' Addresses
+
+   Myung-Ki Shin
+   ETRI
+   161 Gajeong-dong Yuseng-gu
+   Daejeon, 305-350
+   Korea
+
+   Phone: +82 42 860 4847
+   EMail: myungki.shin@gmail.com
+
+
+   Youn-Hee Han
+   KUT
+   Gajeon-Ri 307 Byeongcheon-Myeon
+   Cheonan-Si Chungnam Province, 330-708
+   Korea
+
+   EMail: yhhan@kut.ac.kr
+
+
+   Sang-Eon Kim
+   KT
+   17 Woomyeon-dong, Seocho-gu
+   Seoul, 137-791
+   Korea
+
+   EMail: sekim@kt.com
+
+
+   Domagoj Premec
+   Siemens Mobile
+   Heinzelova 70a
+   10010 Zagreb
+   Croatia
+
+   EMail: domagoj.premec@siemens.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 15]
+
+RFC 5181            IPv6 over IEEE 802.16 Scenarios             May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Shin, Ed., et al.            Informational                     [Page 16]
+