Network Working Group                                          M-K. Shin
Internet-Draft                                                      ETRI
Expires: November 25, 2006
Intended status: Informational                                  Y-H. Han
Expires: April 4, 2007                                               KUT
                                                            May 24,
                                                                S-E. Kim
                                                                      KT
                                                               D. Premec
                                                          Siemens Mobile
                                                         October 1, 2006

  ISP

            IPv6 Deployment Scenarios in Wireless Broadband Access 802.16(e) Networks
            draft-ietf-v6ops-802-16-deployment-scenarios-00
            draft-ietf-v6ops-802-16-deployment-scenarios-01

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on November 25, 2006. April 4, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides 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
   network and its differences from IPv4 IEEE 802.16 networks and how
   IPv6 is deployed and integrated in each of the IEEE 802.16
   technologies using tunneling mechanisms and native IPv6.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Wireless Broadband Access Network Technologies - IEEE
       802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Elements of IEEE 802.16 Networks . . . . . . . . . . . . .  4
     2.2.  Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . .  5
       2.2.1.  Scenario A . . . . . . . . . . . .  Mobile Access Deployment Scenarios . . . . . . . . . .  7  6
       2.2.2.  Scenario B . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Scenario C . . . . . . . . . . . .  Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 10
       2.2.4.  Scenario D . . . . . . . . . . . . . . . . . . . . . . 12
     2.3.  IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13
     2.4.  IPv6 Mobility  . . . . . . . . . . . . . . . . . . . . . . 14
     2.5.  IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.6.
     2.5.  IPv6 Security  . . . . . . . . . . . . . . . . . . . . . . 15
     2.7. 14
     2.6.  IPv6 Network Management  . . . . . . . . . . . . . . . . . 15
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

1.  Introduction

   Recently, broadband wireless access network is emerging for wireless
   communication for user requirements such as high quality data/voice
   service, fast mobility, wide coverage, etc.  The IEEE 802.16 Working
   Group develops standards and recommended practices to support the
   development and deployment of broadband wireless metropolitan area
   networks.

   Whereas the existing IEEE 802.16 standard [IEEE802.16] standard addresses fixed wireless
   applications only, the IEEE 802.16(e) standard [IEEE802.16e] aims to serve standard serves the needs of
   fixed, nomadic, and fully mobile networks.  It adds mobility support
   to the original standard so that mobile subscriber stations can move while receiving
   during services.  The standardization of IEEE 802.16e is completed,
   which plans to support mobility up to speeds of 70~80 mile/h that
   will enable the subscribers to carry mobile devices such as PDAs,
   phones, or laptops.  IEEE 802.16e is one of the most promising access
   technologies which would be applied to the IP-based broadband mobile
   communication.

   WiMAX Forum is an industrial corporation formed to promote and
   certify compatibility and interoperability of broadband wireless
   products mainly based on IEEE 802.16.  The Network Working Group
   (NWG) of WiMAX Forum is defining the IEEE 802.16 network architecture
   (e.g., IPv4, IPv6, Mobility, interworking with different networks,
   AAA, etc).  Similarly, WiBro (Wireless Broadband), Korea effort which
   focuses on the 2.3 GHz spectrum band, is also based on the IEEE
   802.16 and IEEE 802.16e specifications.

   As the deployment of wireless broadband access network progresses,
   users will be connected to IPv6 networks.  While the IEEE 802.16
   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.  In this document, we will discuss main
   components of IPv6 IEEE 802.16 access network and its differences
   from IPv4 IEEE 802.16 networks and how IPv6 is deployed and
   integrated in each of the IEEE 802.16 technologies using tunneling
   mechanisms and native IPv6.

   This document extends works of [I-D.ietf-v6ops-bb-deployment-
   scenarios] and follows the structure and common terminology of the
   document.

2.  Wireless Broadband Access Network Technologies - IEEE 802.16

   This section describes the infrastructure that exists today in is based on IEEE
   802.16 networks providing wireless broadband services to the
   customer.  It also describes a way to deploy IPv6 deployment options in these over IEEE 802.16
   networks.

2.1.  Elements of IEEE 802.16 Networks

   The IEEE 802.11 access network (WLAN) has driven the revolution of
   wireless communication but communication.  However, the more people use it the more its
   limitations like such as short range or and lack of mobility support were
   revealed. arose.
   Compared with such IEEE 802.11 network, IEEE 802.16 supports enhanced
   features like such as wider range coverage and mobility.  So it is expected that
   IEEE 802.16 network could be the next step of IEEE 802.11 network.

   The mechanism of transporting IP traffic over IEEE 802.16 networks is
   outlined in [IEEE802.16], but the details of IPv6 operations over
   IEEE 802.16 are being discussed now.

   Here are some of the key elements of an IEEE 802.16 networks network:

   o  MS: Mobile Station.  A station in the mobile service intended to
      be used while in motion or during halts at unspecified points.  A
      mobile station (MS) is always a subscriber station (SS). (SS) which must
      provide mobility function.

   o  BS: Base Station.  A generalized equipment set providing
   connectivity,
      management and control of MS connections.  There is a
      unidirectional mapping between BS and MS medium access control
      (MAC) peers for the purpose of transporting a service flow's
      traffic.
   Connections are  A connection is identified by a connection identifier (CID) and all
      (CID).  All traffic is carried on a the connection.  Sometimes there
      can be alternative IEEE 802.16 network deployment where a BS is
      integrated with an access router, composing one box in view of
      implementation.

   Figure 1 illustrates the key elements of

   o  AR: Access Router.  A generalized equipment set providing IP
      connectivity between BS and IP based network.  An AR performs
      first hop routing function to all MS.

   Figure 1 illustrates the key elements of IEEE 802.16 802.16(e) networks.

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

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

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

2.2.  Deploying IPv6 in IEEE 802.16 Networks

   IEEE 802.16 supports

   [IEEE802.16] specifies two modes such as 2-way PMP (Point-to-
   Multipoint) and Mesh topology for sharing the wireless networks.  In this document,
   we focus medium:
   point-to-multipoint (PMP) and mesh (optional).  This document only
   focuses on 2-way PMP topology wireless networks.

   There are two different deployment options in current IEEE 802.16
   networks: Cellular-like and Hot-zone mode.

   Some of the factors that hinder deployment scenarios. of native IPv6 can
   be deployed in both core
   protocols are introduced by [I-D.jee-16ng-problem-statement].  The
   summary of these deployment models.

   A. Cellular-like Deployment Model them is as follows:

   1.  Lacking of Facility for IPv6 Native Multicasting

   IEEE 802.16 BS can offer both fixed communications and mobile PMP mode is a connection oriented technology without bi-
   directional native multicast support.  IPv6 neighbor discovery
   [RFC2461] supports various functions unlike IEEE 802.11.  In particular, IEEE 802.16e working
   group standardized for the interaction between
   nodes attached on the same subnet, such mobility features as on-link determination and
   address resolution.  It is designed with no dependence on a specific
   link layer technology, but requires that the specification link layer technology
   support native multicast.  This lacking of
   IEEE 802.16e provides some competition facility for IPv6 native
   multicast results in inappropriateness to apply the standard neighbor
   discover protocol specially regarding, address resolution, router
   discovery, stateless auto-configuration and duplicated address
   detection.

   2.  Impact on IPv6 Subnet Model

   IEEE 802.16 is different from existing cellular
   systems.  This use case will be implemented only with the licensed
   spectrum. wireless access technologies
   such as IEEE 802.11 or 3G, and, while IEEE 802.16 BS might be deployed with a proprietary
   backend managed by defines the
   encapsulation of an operator.  All original IP datagram in an IEEE 802.16 MAC payload, a
   complete description of IPv6 functionalities
   will operation is not survive present.  IEEE 802.16
   can rather benefit from IETF input and some of them might be compromised specification to efficiently
   serve support IPv6
   operation.  Especially, BS should look at the classifiers and decide
   where to this 'Cellular-like' use case.

   Under send the use case, however, packet, since IEEE 802.16 standards are still IP-
   centric, providing packet-switched approach, connection always ends at
   BS, while cellular standards
   like GSM have IPv6 connection terminates at a more circuit-switched approach.

   B. Hot Zone Deployment Model

   The success default router.  This
   operation and limitation may be dependent on the given subnet model
   [I-D.madanapalli-16ng-subnet-model-analysis].

   3.  Multiple Convergence Sublayers (CS)

   There are operational complexity problems of a Hotspot service with IEEE 802.11 has been prominent.
   The new IEEE IP over 802.16 standards basically support such Hotspot services
   with large coverage area and high data rate.  An area served caused by one
   base station is usually termed 'Hot Zone' because it is considerably
   larger than an IEEE 802.11 access point service area called Hotspot.

   Many wireless Internet service providers (Wireless ISPs) have planned
   to use IEEE 802.16 for
   the purpose existence of high quality service.  A
   company multiple convergence sublayers [I-D.iab-link-
   encaps].  We should consider which type of Convergence Sublayer (CS)
   can use be efficiently used on each subnet models and scenarios.  IEEE
   802.16 to build up mobile office.  Wireless
   Internet spreading through a campus or a cafe can be also implemented
   with it.  The distinct point CS delivers and classifies various kinds of this use case is that it can use
   unlicensed (2.4 & 5 GHz) band as well higher layer PDUs
   such as licensed (2.6 & 3.5GHz)
   band.  By using the unlicensed band, a ATM, IPv4 packet and IPv6 packets over radio channel.  For
   this purpose, IEEE 802.16 BS might be used
   just as a wireless hub which a user purchases to build a private
   wireless network in his/her home or laboratory.

   Under 'Hot Zone' use case, a IEEE 802.16 BS will be deployed using an
   Ethernet (IP) backbone rather than a proprietary backend like
   cellular systems.  Thus, many IPv6 functionalities will be preserved
   when adopting IPv6 to IEEE 802.16 networks, which brings out many
   research issues [I-D.jee-16ng-problem-statement] [I-D.madanapalli-nd-
   over-802.16-problems].

   Some of the factors that hinder deployment of native IPv6 core
   protocols include:

   1.  Lacking of Facility for IPv6 Native Multicasting

   IEEE 802.16 is a PMP connection oriented technology without bi-
   directional native multicast support.  IPv6 neighbor discovery
   [RFC2461] supports various functions for the interaction between
   nodes attached on the same subnet, such as on-link determination and
   address resolution.  It is designed with no dependence on a specific
   link layer technology, but requires that the link layer technology
   support native multicast.  The specification of IEEE 802.16 provides
   multicast and broadcast services.  However, the aim of such services
   is to transmit IEEE 802.16 MAC management messages, not IP messages.
   This lacking of facility for IPv6 native multicast results in
   inappropriateness to apply the standard neighbor discover protocol
   specially regarding, address resolution, router discovery, stateless
   auto-configuration and duplicated address detection.

   2.  Impact of BS on Subnet Model

   IEEE 802.16 is different from existing wireless access technologies
   such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the
   encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a
   complete description of IPv6 operation is not present.  IEEE 802.16
   can rather benefit from IETF input and specification to support IPv6
   operation.  Especially, BS should look at the classifiers and decide
   where to send the packet, since IEEE 802.16 connection always ends at
   BS, while IPv6 connection terminates at a default router.  This
   operation and limitation may be dependent on the given subnet model.

   Also, we should consider which type of Convergence Sublayer (CS) can
   be efficiently used on each subnet models.  IEEE 802.16 CS provides
   the tunneling of IP(v6) packets over IEEE 802.16 air-link.  The
   tunnels are identified by introduces the Connection Identifier (CID).
   Generally, CS performs the following functions in terms of IP packet
   transmission: 1) Receipt of protocol data units (PDUs) from the
   higher layer, 2) Performing classification and CID mapping of the
   PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt
   of PDUs from the peer MAC SAP. SAP, and 5) Forwarding the PDUs to the
   corresponding AR.  The specification of IEEE 802.16 defines several
   CSs for carrying IP packets, but does not provide a provide a detailed
   description of how to carry them.  The several CSs are generally
   classified into two types of CS: IPv6 CS and Ethernet CS.

   In addition, due to the problems caused by the existence of multiple
   convergence sublayers [I-D.iab-link-encaps], the mobile access
   scenarios need solutions about how roaming will work when forced to
   move from one CS to another.  Note that, at this phase this issue is
   the out of scope of this draft.  It should be also discussed in 16ng
   WG.

   There are two different deployment scenarios: fixed and mobile
   access.  A fixed access scenario substitudes for existing wired-based
   access technologies such as digital subscriber line (xDSL) and cable
   network.  This fixed access scenario can provide nomadic access
   within the radio coverages, which is called Hot-zone model.  A mobile
   access scenario is for new paradigm for voice, data and video over
   mobile network.  This scenario can provide high speed data rate
   equalivent to wire-based Internet as well as mobility function
   equivalent to cellular system.  The mobile access scenario can be
   classified into two different IPv6 sunbet models: shared IPv6 prefix
   link model and point-to-point link model.

2.2.1.  Mobile Access Deployment Scenarios

   Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as
   well as fixed communication.  [IEEE802.16e] has been standardized to
   provide mobility features on IEEE 802.16 environments.  This use case
   will be implemented only with the licensed spectrum.  IEEE 802.16 BS
   might be deployed with a proprietary backend managed by an operator.
   All original IPv6 functionalities [RFC2461], [RFC2462] will not
   survive.  Some architectural characteristics of IEEE 802.16 networks
   may affect the detailed description operations of how to carry them.  The several CSs NDP [RFC2461].

   There are
   generally classified into two types of CS: possible IPv6 CS subnet models for mobile access
   deployment scenarios: shared IPv6 prefix link model and Ethernet CS.

   While deploying point-to-
   point link model [I-D.madanapalli-16ng-subnet-model-analysis].  The
   mobile access deployment models, WiMax and WiBro, fall within this
   deployment model.

   1.  Shared IPv6 in the above mentioned approach, there are four
   possible typical scenarios as discussed below.

2.2.1.  Scenario A

   Scenario A Prefix Link Model

   This link model represents IEEE 802.16 mobile access network
   deployment where a
   BS is separated from a router, and a subnet consists of only single
   router interface of AR and
   multiple BSs and MSs.  Current celluar-like deployment
   models, WiMax  Therefore, all MSs and WiBro, fall within this scenario A. corresponding interface of AR
   share the same IPv6 prefix as shown in Figure 2.  IPv6 prefix will be
   different from the interface of AR.

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

                  Figure 2: Scenario A Shared IPv6 Prefix Link Model

   2.  Point-to-Point Link Model

   This link model represents IEEE 802.16 mobile access network
   deployment 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)---------+
      +-----+               |
      +-----+            +-----+     +-----+    +--------+
      | MS2 |<-(16)------| BS1 |--+->| AR  |----| Edge   |    ISP
      +-----+            +-----+  |  +-----+    | Router +==>Network
                                  |             +--------+
      +-----+            +-----+  |
      | 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, BS (if possible), BS, AR and Edge Router.  In
   this scenario the ER.  In this scenario, IEEE
   802.16 BSs have only MAC and PHY layers without router function and
   operates as a bridge.  The BS is Layer 3 unaware, so no changes are needed does not need to support IPv6.
   However, if IPv4 stack is loaded to them for management and
   configuration purpose, it is expected that BS should be upgraded by
   implementing IPv6 stack, too.

2.2.1.2.  Addressing

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

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

   2.  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 Edge Router would simply act as a
   DHCP Relay Agent. the AR should provide 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 MS. MSs.  All MSs attached
   to same AR can be on same IPv6 link.

2.2.1.3.

   As for the prefix assignment, in case of shared IPv6 Control prefix link
   model, one or more IPv6 prefixes are assigned to the link and Data hence
   shared by all the nodes that are attached to the link.  In point-to-
   point link model, the AR assigns a unique prefix or set of unique
   prefixes for each MS.

2.2.1.3.  IPv6 Transport

   In a subnet, there are always two underlying links: one is the IEEE
   802.16 wireless link between MS and BS, and the other is a wired link
   between BS and AR.  Also, there are multiple BSs  The IPv6 packet should be classified by IPv6
   source/destination addresses, etc.  BS generates the flow based on
   the same link. classification.  It also decides where to send the packet or just
   forward the packet to the ACR, since IEEE 802.16 connection always
   ends at BS while IPv6 connection terminates at the AR.  This
   operation may be dependent on IPv6 subnet models.

   If stateless auto-configuration is used to get an IPv6 address,
   router discovery and DAD operation should be properly operated over
   IEEE 802.16 link.  So, BS may support  In case of shared IPv6 basic protocols such as ND
   using multicast functions, or provide some schemes to facilitate prefix link model, the
   stateless auto-configuration.  Especially, IEEE 802.16 connection
   terminates at BS, DAD
   [RFC2461] does not a router.  So, BS should look at the
   classifiers and decide where adapt well to send the packet.  In addition, one BS
   can send the packet to other BSs, since multiple BSs are 802.16 air interface as there is
   no native multicast support and when supported consumes air bandwidth
   as well as it would have adverse effect on MSs that were in the same
   link.

   The operation and transmission methods are being intensively
   discussed
   dormant mode.  An optimization, called Relay DAD, may be required to
   perform DAD.  However, in other documents [I-D.shin-16ng-ipv6-transmission]. case of point-to-point link model, DAD is
   easy since each connection to a MN is treated as a unique IPv6 link.

   Note that in this scenario Ethernet CS as well as IPv6 CS may be used more appropriate than
   Ethernet CS to transport IPv6 packets. packets, since there are some overhead
   of Ethernet CS (e.g., Ethernet header) under mobile access
   environments .

   Simple or complex network equipments may constitute the underlying
   wired network between BS the AR and AR. the ER.  If the IP aware equipments
   between the AR and the ER do not support IPv6, the service providers are deploying
   can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6
   packets between an the AR and an
   Edge router. 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 option might be more scalable
   and provide required service performance.  Tunneling mechanisms
   should only be used when native IPv6 deployment is not an option.
   This can be equally applied to other three scenarios below.

2.2.1.4.  Routing

   In general, the AR is configured with a default route that points to
   the Edge router.  No routing protocols are needed on these devices
   which generally have limited resources.

   The Edge Router runs the IGP used in the ISP network such as OSPFv3
   or IS-IS for IPv6.  The connected prefixes have to be redistributed.
   Prefix summarization should be done at the Edge Router.

2.2.2.  Scenario B

   Scenario B represents IEEE 802.16 network deployment where a BS is
   separated from a router, there are multiple access routers, and a
   subnet consists of multiple BS and MSs.  If 802.16 access networks
   are widely deployed like WLAN, this scenario should be also
   considered.  Hot-zone deployment model falls within this scenario B.

       +-----+                        +-----+    +-----+    ISP 1
       | MS1 |<-----+              +->| AR1 |----| ER1 |===>Network
       +-----+      |              |  +-----+    +-----+
       +-----+      |     +-----+  |
       | MS2 |<-----+-----| BS1 |--|
       +-----+            +-----+  |  +-----+    +-----+    ISP 2
                                   +->| AR2 |----| ER2 |===>Network
       +-----+            +-----+  |  +-----+    +-----+
       | Ms3 |<-----------| BS2 |--+
       +-----+            +-----+
                                          <---> IP termination

   Figure 3: Scenario B

2.2.2.1.  IPv6 Related Infrastructure Changes

   IPv6 will be deployed in this scenario by upgrading the following
   devices to dual-stack: MS, BS (if possible), AR and Edge Router.  In
   this
   This can be equally applied to other scenario below (Section 2.2.2).

2.2.1.4.  Routing

   In general, the BS MS is Layer 3 unaware, so configured with a default route that points to
   the the AR.  Therefore, no changes routing protocols are needed on the MS.
   The MS just sends to
   support IPv6.  However, if IPv4 stack is loaded the AR by default route.

   The AR can configure multiple link to them ER for
   management and configuration purpose, it is expected that BS network reliability.
   The AR should
   be upgraded by implementing support IPv6 stack, too.

2.2.2.2.  Addressing

   In this scenario, multiple BSs and MSs form an routing protocol such as OSPFv3 [RFC2740]
   or IS-IS for IPv6 subnet and
   multiple prefixes are allocated when connected to all the attached MS.  All MSs
   attached to different BSs under ER with multiple links.

   The ER runs the same AR, IGP such as OSPFv3 or IS-IS for IPv6 in the service
   provider network.  The routing information of the ER can be on same IPv6
   link.

2.2.2.3.
   redistributed to the AR.  Prefix summarization should be done at the
   ER.

2.2.1.5.  Mobility

   As for mobility management, the movement between BSs is handled by
   Mobile IPv6 Control and Data Transport

   In [RFC3775], if it requires a subnet, like scenario A, there are always two underlying links:
   one subnet change.  Also, in
   certain cases (e.g., fast handover [I-D.ietf-mipshop-fmipv6-
   rfc4068bis]) the link mobility information must be available for
   facilitating layer 3 handoff procedure.

   Mobile IPv6 defines that movement detection uses Neighbor
   Unreachability Detection to detect when the default router is no
   longer bi-directionally 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 IEEE
   802.16 MAC provides the reachability by its Ranging procedure and the
   movement detection by the Handoff procedure.

   IEEE 802.16 wireless link between MS and BS, and the other defines L2 triggers whether refresh of an IP address is a wired link between BS and AR.  Also, there are multiple BSs on
   required during the same link.

   If stateless auto-configuration is used to get handoff.  Though a handoff has occurred, an IPv6 address,
   considerations on
   additional router discovery and DAD operation are the same as
   scenario A.

   The operation and transmission methods are being intensively
   discussed in other documents [I-D.shin-16ng-ipv6-transmission].  Note
   that procedure is not required in this scenario Ethernet CS case of
   intra-subnet handoff.  Also, faster handoff may be more suitable to transport
   IPv6 packets, rather than IPv6 CS, since this scenario requires
   broadcast-like functions (e.g., multi-homing).

   Simple or complex network equipments may constitute the underlying
   wired network between BS and AR.  If the IP aware equipments do not
   support IPv6, occurred by the service providers are deploying IPv6-in-IPv4
   tunneling mechanisms to transport L2
   trigger in case of inter-subnet handoff.

   Also, IEEE 802.16g which is under-developed defines L2 triggers for
   link status such as link-up, link-down, handoff-start.  These L2
   triggers may make Mobile IPv6 packets between an AR procedure more efficient and an
   Edge router.

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

   The Edge Router runs Fast Handover assumes the IGP used in support from link-
   layer technology, but the SP network such particular link-layer information being
   available, as OSPFv3 well as the timing of its availability (before, during
   or
   IS-IS for IPv6.  The connected prefixes have after a handover has occurred), differs according to be redistributed.
   Prefix summarization should be done at the Edge Router.

2.2.3.  Scenario C

   Scenario C represents
   particular link-layer technology in use.  This issue is also being
   discussed in [I-D.ietf-mipshop-fh80216e].

2.2.2.  Fixed/Nomadic Deployment Scenarios

   The IEEE 802.16 access network networks can provide plain Ethernet
   connectivity end-to-end.  Wireless DSL deployment where a
   BS model is integrated with a router, composing one box in view an example
   of
   implementation, and a subnet consists of only single BS/router and
   multiple MSs.

       +-----+
       | MS1 |<------+
       +-----+       |
       +-----+       |    +-------+         +--------+
       | MS2 |<------+--->|BS/AR1 |---------| Edge   |    ISP
       +-----+            +-------+         | Router +==>Network
                                            +--------+
       +-----+            +-------+           |
       | Ms3 |<---------->|BS/AR2 |-----------+
       +-----+            +-------+
                                     <---> IP termination

   Figure 4: Scenario C

2.2.3.1.  IPv6 Related Infrastructure Changes fixed/nomadic IPv6 will be deployed in this scenario by upgrading the following
   devices to dual-stack: MS, BS/AR and Edge Router.

2.2.3.2.  Addressing

   In this scenario, a single prefix is allocated deployment of IEEE 802.16.  Many wireless
   Internet service providers (Wireless ISPs) have planned to all use IEEE
   802.16 for the attached
   MS.  All MSs attached to same BS purpose of high quality broadband wireless service.  A
   company can be on same IPv6 link.

2.2.3.3.  IPv6 Control and Data Transport

   If stateless auto-configuration is used to get an IPv6 address,
   router discovery and DAD operations should be properly operated over use IEEE 802.16 link.  So, BS/AR should support IPv6 basic protocols such
   as ND using multicast functions, or provide some schemes to
   facilitate the stateless auto-configuration. build up mobile office.  Wireless
   Internet spreading through a campus or a cafe can be also implemented
   with it.  The operation and transmission methods are being intensively
   discussed in other documents [I-D.shin-16ng-ipv6-transmission].  Note
   that in distinct point of this scenario Ethernet CS use case is that it can use
   unlicensed (2.4 & 5 GHz) band as well as IPv6 CS may licensed (2.6 & 3.5GHz)
   band.  By using the unlicensed band, an IEEE 802.16 BS might be used to
   transport IPv6 packets.

2.2.3.4.  Routing

   In general, BS/Router is configured with
   just as a default route that points
   to the Edge router.  No routing protocols are needed on these devices wireless switch/hub which generally have limited resources.

   The Edge Router runs the IGP used a user purchases to build a
   private wireless network in his/her home or laboratory.

   Under fixed access model, the SP network 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 OSPFv3 or
   IS-IS for IPv6.  The connected prefixes have to be redistributed.
   Prefix summarization should [RFC2461],
   [RFC2462] will be done at the Edge Router.

2.2.4.  Scenario D

   Scenario D preserved when adopting IPv6 to IEEE 802.16
   devices.

   This scenario also represents IEEE 802.16 access network deployment where a
   BS is integrated with a router, composing one box in view of
   implementation.  In this scenario, a
   subnet consists of only single
   BS/router multiple MSs and single MS. multiple interface of the
   multiple BSs.  Multiple access routers can exist.  There exist
   multiple hosts behind an SS (networks behind an MS may exist).  When
   802.16 access networks are widely deployed like WLAN, this case
   should be also considered.  Hot-zone deployment model falls within
   this case.

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

                Figure 4: Fixed/Nomadic Deployment Scenario

   While Figure 3 illustrates a generic deployment scenario, the
   following Figure 4 shows in more detail how an existing DSL ISP would
   integrate the current 3GPP-like
   IPv6 deployment model. 802.16 access network into its existing infrastructure.

   +-----+                        +---+      +-----+    +-----+    ISP 1
   | MS1 |<-------------+ SS1 |<-(16)+                 |   |  +-->|BRAS |----| ER1 |===>Network
   +-----+      |                 |  b|  |   +-----+    +-----+              v
   +-----+            +-------+         +--------+      | MS2 |<---------->|BS/AR1 |---------| Edge     +-----+     |E r|  |
   | SS2 |<-(16)+-----| BS1 |-----|t i|  |
   +-----+            +-----+     |h d|--+
                                  |  g|  |   +-----+    +-----+    ISP 2
   +-----+            +-----+            +-------+     | Router +==>Network
                                            +--------+  e|  +-->|BRAS |----| ER2 |===>Network
   | SS3 |<-(16)------| BS2 |-----|   |  |   +-----+    +-----+
   +-----+            +-------+            +-----+     +---+  |
                                         | Ms3 |<---------->|BS/AR2 |-----------+
   +-----+            +-------+
                                     <---> IP termination            +-----+            |
   | TE  |<-(DSL)-----|DSLAM|------------+
   +-----+            +-----+

      Figure 5: Scenario D

2.2.4.1. 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 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, BS/AR BS, AR and Edge Router.

2.2.4.2.  Addressing ER.  In this case, scenario, IEEE
   802.16 BSs have only MAC and PHY layers without router function and
   operates as a bridge.  The BS does not need to support IPv6.
   However, if stateless auto-configuration IPv4 stack is used, 3GPP-like IPv6
   addressing scheme [RFC 3314] can be used.  That is, a unique prefix
   can be allocated loaded to each MS.  [RFC 3314] recommends them for management and
   configuration purpose, it is expected that a given
   prefix BS should be assigned to only one primary PDP context so that
   3GPP terminals are allowed to generate multiple upgraded by
   implementing IPv6 address using
   the prefix without stack, too.

   The BRAS in Figure 4 is providing the concerns functionality of address confliction (DAD).

2.2.4.3.  IPv6 Control and Data Transport

   In this scenario, IEEE 802.16 connection and IPv6 termination point
   are the same, since a AR.  The
   Ethernet bridge is necessary for protecting the BRAS from 802.16 link
   layer peculiarities.  The Ethernet bridge relays all traffic received
   through BS to its network side port(s) connected to BRAS.  Any
   traffic received from BRAS is integrated with a router.  In addition,
   each relayed to appropriate BS.  Since
   802.16 MAC layer has no native support for multicast (and broadcast)
   in the uplink direction, the Ethernet bridge will emulate Ethernet
   level multicast (and broadcast) by relaying the multicast frame
   received from the MS can be on different to all of its ports.  Ethernet bridge may also
   provide some IPv6 link.  So, many specific functions to increase link efficiency of
   the 802.16 radio link (see Section 2.2.2.3).

2.2.2.2.  Addressing

   One or more IPv6 protocols prefixes can be operated without much consideration about shared to all the underlying network
   implementation.

   Only IEEE 802.16 link will attached MSs.
   Prefix delegation can be taken into consideration for IPv6
   adoption.  For example, DAD operation is not needed required since each MS has
   only a well-known neighbor, a router.  The operation and transmission
   methods are being intensively discussed in other documents [I-D.shin-
   16ng-ipv6-transmission]. networks can exist behind SS.

2.2.2.3.  IPv6 Transport

   Note that in this scenario IPv6 Ethernet CS type may be more suitable appropriate than
   IPv6 CS to transport IPv6 packets rather than packets, since the scenario need to support
   plain Ethernet connectivity end-to-end.  However, the IPv6 CS can
   also be supported.  Every MS and the BS has the Ethernet type since broadcast-
   like functions are not required.

2.2.4.4.  Routing MAC
   address.  If the MS is using IP CS, then the BS needs to take care of
   the Ethernet header.  In general, the access router upstream direction, the BS will need to
   generate an appropriate Ethernet header and prepend it to the IP
   datagram.  In the downstream direction, the BS will use the
   destination address from the Ethernet header to identify the MS and
   then it will strip the Ethernet header before relaying the IP
   datagram over the 802.16 MAC connection.  Ethernet bridge may provide
   implementation of authoritative address cache and Relay DAD.
   Authoritative address cache is configured with a default route mapping between the IPv6 address and
   the MAC addresses of all attached MSs.

   The bridge builds its authoritative address cache by parsing the IPv6
   Neighbor Discovery messages used during address configuration (DAD).
   Relay DAD means that
   points the Neighbor Solicitation message used in DAD
   process will be relayed only to the Edge Router.  No routing protocols are needed on these
   devices MS which generally have limited resources. already has configured
   the solicited address as its own address (if such MS exist at all).

2.2.2.4.  Routing

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

   The Edge Router runs the IGP used in the service provider 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.3.  IPv6 Multicast

   In order to

2.2.2.5.  Mobility

   No mobility functions are supported in fixed access scenario.
   However, mobility can support multicast services in IEEE 802.16, Multicast
   Listener Discovery (MLD) [RFC2710] must be supported between the MS
   and BS/Router.  Also, radio coverage without any
   mobility protocol like WLAN technology.  Therefore, a user can access
   Internet nomadically in the inter-working with IP multicast protocols
   and coverage.

2.3.  IPv6 Multicast and Broadcast Service (MBS) should be considered.

   Within

   In IEEE 802.16 networks, an MS connects to its BS/router via
   point-to-point links.  MLD allows an MS to send link-local air link, downlink connections can be shared among
   multiple MSs, enabling multicast
   destination queries and reports.  The packets are transmitted as
   normal IEEE 802.16 MAC frames, as channels with multiple MSs receiving
   the same as regular unicast
   packets.  Especially, multicast CIDs can information from the BS.  MBS may be used to transmit efficiently query packets on the downlink.

   There are exactly two IP devices connected to the point-to-point
   link, and no attempt
   implement multicast.  However, it is made (at the link-layer) to suppress the
   forwarding of multicast traffic.  Consequently, sending MLD reports
   for link-local addresses in IEEE 802.16 network may not always be
   necessary.  MLD is needed for multicast group knowledge that clear how to do this, as
   currently CID is not
   link-local.

   MBS defines Multicast and Broadcast Services, assigned by BS, but actually, MBS seems
   to be a broadcast service, not multicasting.  MBS adheres to
   broadcast services, while traditional IP multicast schemes define
   multicast routing using a shared tree or source-specific tree to
   deliver packets efficiently.

   In IEEE 802.16 networks, two types of access to in MBS may it should be supported:
   single-BS access done at an
   AR and multi-BS access.  Therefore, these two types of
   services may be roughly mapped into Source-Specific Multicast. it's network scope.  For MBS how this mapping will happen is
   not clear, so MBS discussions have been postponed 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.

2.4.  IPv6 Mobility

   As for mobility management, the movement between BSs is handled by
   Mobile IPv6 [RFC3775], if it requires a subnet change.  Also, in
   certain cases (e.g., fast handover [I-D.ietf-mipshop-fast-mipv6]) the
   link mobility information must be available for facilitating layer 3
   handoff procedure.

   Mobile IPv6 defines that movement detection uses Neighbor
   Unreachability Detection

   In order to detect when the default router is no
   longer bi-directionally reachable, support multicast services in which case the mobile node IEEE 802.16, Multicast
   Listener Discovery (MLD) [RFC2710] must
   discover a new default router.  Periodic Router Advertisements for
   reachability and movement detection may be unnecessary because IEEE
   802.16 MAC provides supported between the reachability by its Ranging procedure MS
   and the
   movement detection by the Handoff procedure, if a BS is integrated
   with a AR.

   In addition, IEEE 802.16e has facilities in determining whether  Also, the
   change of MS's inter-working with IP address is required during the handoff.  Therefore,
   Mobile IPv6 can get a hint from such low-layer facilities, multicast protocols and
   conduct its Layer 3 mobility protocol only when it is needed.  Though
   a handoff has occurred, an additional router discovery procedure is
   not required in case of intra-subnet handoff.  Also, faster handoff
   may
   Multicast and Broadcast Service (MBS) should be occurred by the L2 trigger in case of inter-subnet handoff.

   Mobile IPv6 Fast Handover assumes the support from link-layer
   technology, considered.

   MBS defines Multicast and Broadcast Services, but the particular link-layer information being
   available, as well as the timing of its availability (before, during
   or after actually, MBS seems
   to be a broadcast service, not multicasting.  MBS adheres to
   broadcast services, while traditional IP multicast schemes define
   multicast routing using a handover has occurred), differs according shared tree or source-specific tree to the
   particular link-layer technology in use.  IEEE 802.16g which is
   under-developed defines L2 triggers for
   deliver packets efficiently.

   In IEEE 802.16 link status such
   as link-up, link-down, handoff-start.  These L2 triggers networks, two types of access to MBS may make
   Mobile IPv6 procedure more efficient be supported:
   single-BS access and faster.

   This issue is also being discussed in [I-D.ietf-mipshop-fh80216e].

2.5. multi-BS access.  Therefore, these two types of
   services may be roughly mapped into Source-Specific Multicast.

2.4.  IPv6 QoS

   In IEEE 802.16 networks, a connection is unidirectional and has a QoS
   specification.  The QoS has different semantics with IP QoS (e.g.,
   diffserv).  Mapping CID to Service Flow IDentifier (SFID) defines QoS
   parameters of the service flow associated with that connection.  In
   order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label
   for IPv6) mapping to IEEE 802.16 link specifics should be provided.

2.6.

2.5.  IPv6 Security

   When initiating the connection, an MS is authenticated by the AAA
   server located at its service provider network.  All the parameters
   related to authentication (username, password and etc.) are forwarded
   by the BS to the AAA server.  The AAA server authenticates MSs.  If the MSs
   and once authenticated.  When an MS is once authenticated and
   associated successfully with BS, an IPv6 address will be acquired by the MS.
   MS with stateless autoconfiguration or DHCPv6.  Note the initiation
   and authentication process is the same as 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 don't
   have PKIs across organizations and IPsec isn't integrated with IEEE
   802.16 network mobility management.

   IEEE 802.16 network threats may be different from IPv6 and IPv6
   transition threat models [I-D.ietf-v6ops-security-overview].  It
   should be also discussed.

2.7.

2.6.  IPv6 Network Management

   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 message 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 network can be managed by IPv4 or IPv6 when
   network elements are implemented dual stak.  For example, network
   management system (NMS) can send SNMP message by IPv4 with IPv6
   related object identifier.  Also, an NMS can use IPv6 for SNMP
   request and response including IPv4 related OID.

3.  IANA Considerations

   This document requests no action by IANA.

4.  Security Considerations

   Please refer to sec 2.6 Section 2.5 "IPv6 Security" technology sections for
   details.

5.   Acknowledgements

   This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment-
   scenarios].  We thank all the authors of the document.  Special
   thanks are due to Maximilian Riegel, Jonne Soininen, Brian E
   Carpenter, Jim Bound, and Jung-Mo Moon for extensive review of this
   document.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

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

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

6.2.  Informative References

   [RFC3316]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J.
              Wiljakka, "Internet Protocol Version 6 (IPv6)

   [RFC3314]  Wasserman, M., "Recommendations for Some
              Second and IPv6 in Third
              Generation Cellular Hosts", Partnership Project (3GPP) Standards",
              RFC 3316,
              April 2003.

   [I-D.ietf-mipshop-fast-mipv6]
              Koodli, R., "Fast Handovers for Mobile 3314, September 2002.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6",
              draft-ietf-mipshop-fast-mipv6-03 RFC 3775, June 2004.

   [I-D.jee-16ng-problem-statement]
              Jee, J., "16ng Problem Statement",
              draft-jee-16ng-problem-statement-02 (work in progress),
              October 2004.

   [I-D.madanapalli-nd-over-802.16-problems] 2005.

   [I-D.madanapalli-16ng-subnet-model-analysis]
              Madanapalli, S., "IPv6 Neighbor Discovery over 802.16:
              Problems and Goals",
              draft-madanapalli-nd-over-802.16-problems-00 "Analysis of IPv6 Link Models for 802.16
              based Networks",
              draft-madanapalli-16ng-subnet-model-analysis-01 (work in
              progress), September 2006.

   [I-D.ietf-mipshop-fmipv6-rfc4068bis]
              Koodli, R., "Fast Handovers for Mobile IPv6",
              draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in
              progress), December 2005.

   [I-D.mandin-ip-over-80216-ethcs]
              Mandin, J., "Transport of IP May 2006.

   [I-D.ietf-mipshop-fh80216e]
              Jang, H., "Mobile IPv6 Fast Handovers over 802.16",
              draft-mandin-ip-over-80216-ethcs-00 IEEE 802.16e
              Networks", draft-ietf-mipshop-fh80216e-00 (work in
              progress),
              October 2005. April 2006.

   [I-D.ietf-v6ops-security-overview]
              Davies, E., "IPv6 Transition/Co-existence Security
              Considerations", draft-ietf-v6ops-security-overview-04 draft-ietf-v6ops-security-overview-05
              (work in progress), March September 2006.

   [I-D.ietf-v6ops-bb-deployment-scenarios]
              Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband
              Access Networks",
              draft-ietf-v6ops-bb-deployment-scenarios-04
              draft-ietf-v6ops-bb-deployment-scenarios-05 (work in
              progress), October 2005.

   [I-D.shin-16ng-ipv6-transmission]
              Shin, M. and H. Jang, "Transmission of IPv6 Packets over
              IEEE 802.16", draft-shin-16ng-ipv6-transmission-00 June 2006.

   [I-D.iab-link-encaps]
              Aboba, B., "Multiple Encapsulation Methods Considered
              Harmful", draft-iab-link-encaps-02 (work in progress), February
              August 2006.

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

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

   Domagoj Premec
   Siemens Mobile
   Heinzelova 70a
   10010 Zagreb
   Croatia

   Email: domagoj.premec@siemens.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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

   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.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Acknowledgment

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